Amanda-Users

Re: new feature: client-side, server-side encryption dumptype option

2005-12-20 09:26:04
Subject: Re: new feature: client-side, server-side encryption dumptype option
From: Greg Troxel <gdt AT ir.bbn DOT com>
To: Josef Wolf <jw AT raven.inka DOT de>
Date: 20 Dec 2005 09:03:50 -0500
Josef Wolf <jw AT raven.inka DOT de> writes:

> On Mon, Dec 19, 2005 at 12:56:26PM -0500, Greg Troxel wrote:
> 
> > I think the essence is that while both are encryption, one is applied
> > to transport and one to storage.
> 
> Is it really _that_ different?  IMHO, a public-key method encrypted on
> the client would be good for both, transport _and_ storage.

Yes, it really is totally different.  It's important to keep separate
particular mechanisms and general issues.  I can list five scenarios,
and they have different properties.  To make a rational choice, one
has to have a threat model (assumptions about adversary intent and
capacity).  For backups, the threat model isn't solely adversarial -
one has to think about the likelihood of data loss, both normal and
catastrophic.

transport       storage         tag
no              no              A
yes             no              B
no              yes             C
yes             yes             D       [separate encryption, back to
                                        clear on server]
yes             still           E       [client encrypts, server passthrough]


In scenarios A and C, and eavesdropper on the network can observe the
data.  In B D and E an eavesdropper cannot.

In secenarios A and B, one can retrieve the data from backup tapes
without keying material.   This is perhaps obvious, but very important
for backups.

In C, D, and E, the backup tapes are encrypted.  Thus, one could store
them someplace where you trust people not to destroy them but you
don't trust them to read them.   This can make some sense for
particularly sensitive data.

In E, the backup data doesn't appear on the server in plaintext.  This
can be useful for backing up clients with particularly sensitive
data.  To really make sense, the client should be configured so that
it will only honor dump requests to a preconfigured set of public
keys.


Note that any of these scenarios can be implemented with symmetric
encryption (e.g. AES) or public key techniques (e.g. OpenPGP with RSA
used to encrypt an AES key used for the bulk data, or IKE).  An
OpenPGP approach is certainly easier to manage for storage, where one
needs to be able to decrypt backups much later in time.  For
transport, the backups are decrypted at the server, so techniques like
Kerberos are workable, in addition to OpenPGP or IPsec/IKE.

I run or oversee 5 separate amanda configs, with different security
requirements and environments.  On one of them, I use transport
encryption but not storage.  I'm slighthly concerned about
eavesdroppers, and I'm not concerned about someone accessing the
tapes.  But, I'm very concerned about getting my data back if
something bad happens, so I haven't been inclined to encrypt the
tapes.

-- 
        Greg Troxel <gdt AT ir.bbn DOT com>

<Prev in Thread] Current Thread [Next in Thread>