On Thu, Dec 29, 2005 at 09:19:33AM -0500, Greg Troxel wrote:
> > > So I believe
> > > that a number of people will choose, and rationally so, not to encrypt
> > > the tapes.
> > Thus I proposed the option to write the private key onto the tape. No
> > key management needed for those who don't want security...
>
> Having a key on the tape and needing to decrypt them is far more
> complicated.
I'm not really convinced about that...
> To many (including me), the most important thing, which
> is far more important than all others, is to be able to get my bits
> back from tape when something bad happens, ranging from rm -rf / to a
> disk failing, to total loss of the building due to fire/flood/etc.
So you want the benefits of encryption but don't want to pay the price?
Sounds strange to me.
> So
> the notion that things are encrypted but the key is on the tape means
> that I can no longer read my backup tapes with a basic NetBSD install
> without amanda and just dd, gzip, and restore.
I bet GPG and/or PGP is available for NetBSD. The only reason I don't
use encryption now is because it is not available out-of-the-box on
_any_ $DISTRIBUTION now. You need to compile amanda yourself if you
want encryption.
> Plus, this complexity can have errors,
That much is true. But everything I am proposing have already matured
for years now. Thus I believe most of the bugs are already shaked out.
> > Those who use krb4 today can continue to use it the way they use it today,
> > don't they? I don't see why they are no more able to do what they are
> > doing today.
>
> They can, but you are proposing architectural changes,
No, I don't. Pubkey-encryption on the client is available _now_.
Check out http://security.uchicago.edu/tools/gpg-amanda/ for an example.
IMHO, this method can be improved to serve all cases mentioned in this
thread without architectual changes to amanda.
But sadly enough, one needs to recompile amanda. Thus no distribution
is capable of this functionality out-of-the-box. This is the main reason
I don't use encryption right now.
My proposal is to make the tar-command a run-time option. Or even better,
have the default to be something different than /bin/tar. This way the
admin could "ln -s /bin/tar /usr/lib/amanda/amandatar" if he don't want
encryption. Those who want encryption can use any tools they like
(I would prefer GPG since this is available out-of-the-box on the
distribution-of-my-choice).
No architectual changes required here and all mentioned cases can be
covered.
> and it's
> important that they be done in way which admits future good things and
> doesn't make them harder.
How comes that it will be harder? It's the same as it is today.
Just some minor changes (and a couple of scripts e.g.
/usr/lib/amanda/amandatar-gpg)
> Sure, but I'm making the point that (clueful) people will object to
> encrypted tapes.
So don't encrypt them. Want encrypted backups but don't want the tapes
to be encrypted sounds somewhat schizophrenic to me.
Why not use a tunnel if you want only transport to be encrypted.
"ln -fs /bin/tar /usr/lib/amanda/amandatar" and you're done (as far as
amanda is concerned).
> I find this key management scheme to be very weak. It suffices for
> manual management, but for transport encryption it seems awkward. I'd
> far rather do something like ssh (or with a real PKI) to authenticate
> DH for transport.
So use a tunnel. OpenVPN exists. Ssh already has -L and -R options.
Only minor changes need to be done to make use of them. I don't see
why amanda needs fundamental chnages to achieve a task that is
already solved by people who know _exactly_ how to handle transport
encryption. Why re-invent the wheel? Instead, provide a way to plug
existing tools.
> > > But, not having so makes interactive restores harder.
> >
> > Security don't come for free. You have to pay a price if you want
> > encryption (AFAIK). Either you need a key to get the data, or everyone
> > can get the data without a key. If you want to be secure, you need to
> > store the key in a secure place.
>
> I think it would be helpful for you to write out your assumptions
> about threats. I am relatively unconcerned with people getting access
> to my tapes - they are locked up as well as the computers.
They are locked up _today_. Do you know what will happen to them in a
couple of months/years? I remember at least two cases where big banks
have lost tapes with sensitive data on them and no one knows where the
tapes are or who have/had access to them. How do you know that this
will not happen to your tapes?
> Really, I am trying to ask you to think about keeping transport and
> storage encryption conceptually separate, even if you have a mechanism
> that does both without any bits on the server.
So use a tunnel for transport and GPG/PGP for storage. Both mechanisms
are already available _now_ and they are already matured. Why implement
yet an other mechanism and potentially introduce new bugs? I can't see
what archetectual changes are needed here. The only thing I am missing
is tar-command to be a runtime option.
> > > It's broken from a security viewpoint to only configure this on the
> > > server, particularly without authentication of the dump requests.
> > You're right here. It was just an example, since amanda don't have
> > client-side configs yet. But I bet you got the idea :)
> Right, but if you don't fix that, you haven't really gained the
> security properties you are trying to get.
Why fix something that's not broken? /usr/lib/amanda/amandatar (on the
client!) can (and should) take care of that.
> > A completely different question (which was not touched yet in this thread)
> > is to make sure that the data comes from the correct _client_.
>
> Sure, that's important as well. the krb4 stuff more or less handles this.
I see I should take a close look on krb :)
--
No software patents in Europe -- http://nosoftwarepatents.com
-- Josef Wolf -- jw AT raven.inka DOT de --
|
