On Tue, Dec 20, 2005 at 09:03:50AM -0500, Greg Troxel wrote: > Josef Wolf <[EMAIL PROTECTED]> 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. I'm still not very convinced. IMHO, case E has (from the security/safety perspective) only advantages and no disadvantages when compared to the other cases. Let's take a closer look at the use-cases you listed. > 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] A. This is the trivial case. If we talk about encryption, this case doesn't make any sense at all. Just don't activate encryption, and you're done. I don't see why this case deserves any discussion at all. The end-result (if you can read the tape you have access to unencrypted data) is identical to case B. So why not fall back to case B here? B. If the tapes are stored in a trusted environment, it should be no problem to store the private key along with the tapes. In addition, you can store a copy of the key in a safe. Technically, it would even be possible to store the key on the amanda tapes (in a preamble). This could even be automatable by an amanda config-option (or holding the priv-keys on an un-encrypted DLE). On first sight, such a solution might look like a disadvantage, but please keep reading. C. If you are storing encrypted anyway, why not transporting encrypted too? Most amanda-installations have lots of clients anyway, so putting the burdon of encryption on the server will probaly slow down backups on most installations. I don't see any benefits of this case. D. What would be the benefit of this case? I see only disadvantages here: - high load on tapeserver. - more surface for attackers. E. This is the case I would prefer. Obviosly, I don't see any disadvantages here ;-) But I am pretty sure someone on this list will be able to enlighten me in the near future ;-) > In scenarios A and C, and eavesdropper on the network can observe the > data. In B D and E an eavesdropper cannot. So E has no disadvantages here. > 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. Should be no problem for E as long as you store the key along with the tapes or even _on_ the tapes. > 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. Again, no disadvantages for E here. > 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. Clearly, only E can achieve that. > 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. It's true there are many ways to implement all that. But restricting to client-encrypted-pubkey method would greatly simplify implementation _and_ configuration. >From the perspective of an end-user, I would prefer to have only two additional config-options: 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 } In the above, %h (if available) would be replaced by the hostname and %d by the DLE name. This makes it possible to have DLE-specific key-pairs, host-specific key-pairs, or to have one key-pair for the entire amanda configuration, depending on the security-requirements of the user. So, to implement the use-cases you mentioned above: case A: just omit both options. Or better, use case B, since the end-result is identical (if you can read the tapes you have the private keys, so decrypting is no additional hurdle) case B: crypt-pubkey foo; store-pubkey bar case C: crypt-pubkey foo case D: crypt-pubkey foo case E: crypt-pubkey foo-%h-%d # for particularly sensitive DLEs crypt-pubkey foo-%h # for sensitive hosts crypt-pubkey foo # on the avarage hosts So all mentioned cases boil down to only two cases: B and E. For backwards compatibility case A would be desirable, too. And all of those cases can be acomplished by the client-encrypted-pubkey method, IMHO. So why complicating things more than necessary? -- No software patents in Europe -- http://nosoftwarepatents.com -- Josef Wolf -- [EMAIL PROTECTED] --