I realize I'm jumping into the middle here and not fully
understanding the issues but I have questions (and that is
just the sort of guy I am).

I'm not meaning to make light or waste time but the following
questions/observations occur.

Concerning tape encryption but not addressing encryption during 
transit between client and server I wonder about the following ?

1) I don't fully apreciate implications having the key on the tape
   - you don't lose it
   - you complicate the restore
   - I suppose you could always store it in an extended amanda tape
     label or a secondary label on the tape.
   - How safe is it to store the key with the encrypted data ?
     What purpose does the encryption serve ?

2) You do complicate the restore process.
   - then I've felt for a long time that a recovery kit of some
     kind might be nice.
     - for example, VMS supports a boot strap backup utility for
       bear metal restore
     - I have started maintaining local accounts on each machine
       in local "amanda" user accounts. This removes a number of
       dependencies and homoginized the installation process for
       (NIS/NIS+ and soon LDAP) cluster cluster vs standalone
       amanda (client or server) systems.
     * In the local amanda user login directory I store a copy
       of the installation tar kit, completely built and ready
       to expand, for that particular client or server.
     - Something that would gather and build a recovery kit would
       be complex but nice to have, it would have to include not
       just amanda, which is easy, but gzip, encryption modules that
       are outside of amanda and any libraries these things are 
       dependent on, including "install" which I often have to install
       before I can even being with amanda.
     - My tar kit does not contain these things.

The amanda disklist allows optional encryption, selected per DLE ?
Can you say, never encrypt the file system(s), root, etc, with the
requisit binaries, key ring, etc and encrypt everything else ?

On Thu, Dec 29, 2005 at 09:19:33AM -0500, Greg Troxel wrote:
> Josef Wolf <jw AT raven.inka DOT de> writes:
> 
> > On Wed, Dec 21, 2005 at 08:38:56AM -0500, Greg Troxel wrote:
> > 
> > > The fundamental point that I think you are missing is that other
> > > people will have different concerns and threat models that you do.
> > 
> > So please, can we keep this conversation going until we all have a clear
> > understanding?  I tried to cover all of the aspects you mentioned.
> > But since you failed to mention _all_ aspects, I admit that I am far
> > from being perfect ;-)
> > 
> > > 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.  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
> 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.  Plus, this complexity
> can have errors, and I'd have to do more extensive testing.  So for my
> situation, encrypting the tapes and putting the key on them is just
> totally unreasonable.  I suspect many others feel the same way, as it
> is just complexity without security benefit.
> 
> 
> > >   D. What would be the benefit of this case?  I see only disadvantages 
> > > here:
> > >      - high load on tapeserver.
> > >      - more surface for attackers.
> > > 
> > > I don't see much benefit, but it could work with existing krb4 support
> > > for transport (with old clients) and a local modification on the
> > > server.
> >
> > 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, and it's
> important that they be done in way which admits future good things and
> doesn't make them harder.
> 
> > >   So E has no disadvantages here.
> > > 
> > > With respect to confidentiality, no.  But E is weaker than the cases
> > > that don't encrypt tapes from the backup availability perspective.
> > 
> > No doubt here.  As long as encryption is an _option_, no one is forced
> > to use it.  Those who actually use encryption, should be aware of the
> > fact that they loose data when they loose the key.  IMHO, this is basic
> > knowledge.  If an admin is not aware of such facts, he needs to be
> > fired (IMHO).
> 
> Sure, but I'm making the point that (clueful) people will object to
> encrypted tapes.
> 
> > >     define dumptype foo {
> > >       foo-bar-dumptype
> > >       crypt-pubkey  /path/to/pubkey-%h-%d  # public  key is on client
> > >       store-privkey /path/to/privkey-%h-%d # private key is on server
> > >     }
> > > 
> > > If the private key is on the server the data on the server might as
> > > well be in the clear.
> > 
> > This is to solve the case where you wanted to have the tapes to be
> > in clear-text.  I don't think it is a big security issue to have the
> > keys in clear on the server when the alternative would be to have no
> > keys at all because the tapes are in clear.  If you don't want the
> > priv-key on the tape (that is, if you have some sort of key-management)
> > then there is no need to keep the priv-key on the tape-server or to use
> > the store-privkey option at all.
> 
> 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.
> 
> > > 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.
> 
> I don't claim that encrypted tapes aren't useful.  If I wanted to
> store sensitive data offsite with a storage facility that I trusted
> not to break/lose the tapes but didn't trust (or couldn't
> contractually) not to read them, I'd want this.
> 
> 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.  This 'both' is also
> very useful for sensitive clients on common backup servers.  I could
> actually use that right now, but it would require client config to
> only do encrypted dumps to be safe.
> 
> > > This really needs quite a lot of key management thought.  But
> > > later, I see that you intend to be able to implement cleartext on
> > > tapes but with transport encryption via this.
> > 
> > I don't inted this.  It was just a quick thougt in response to your
> > requirement list.  It was just an example of how such a requirement
> > could be satisfied.  Security don't come for free.  You _need_ to do
> > some thoughts about key management.
> 
> Yes, and IMHO that's the hardest part of security design.
> 
> > > 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.
> 
> > 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.
> 
> -- 
>         Greg Troxel <gdt AT ir.bbn DOT com>
---
   Brian R Cuttler                 brian.cuttler AT wadsworth DOT org
   Computer Systems Support        (v) 518 486-1697
   Wadsworth Center                (f) 518 473-6384
   NYS Department of Health        Help Desk 518 473-0773