|
|
(One intermediate revision by one other user not shown) |
Line 1: |
Line 1: |
| == Different encryption configuration ==
| | #redirect [[Encryption]] |
| | |
| {| border="1" style="background:white; color:black"
| |
| !Transport!!Data!!Tag
| |
| |-
| |
| |<nowiki>No</nowiki>||No||A
| |
| |-
| |
| |<nowiki>Yes</nowiki>||No||B
| |
| |-
| |
| |<nowiki>No</nowiki>||Yes||C
| |
| |-
| |
| |<nowiki>Yes</nowiki>||Yes||D
| |
| |-
| |
| |<nowiki>Yes</nowiki>||No||E(public-key)
| |
| |}
| |
| | |
| | |
| | |
| 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.
| |
| | |
| == SSH ==
| |
| ssh provides transport encryption and authentication. The only caveat is that the amanda binary needs to be installed at the same location in the server as well as in the client since server is running:
| |
| /path/ssh -l <CLIENT_LOGIN> client.zmanda.com $libexecdir/amandad
| |
| to start the backup process.
| |
| | |
| While this is possible, it has two disadvantages:
| |
| | |
| 1. You need to set up keys for both, ssh _and_ amanda.
| |
| | |
| 2. You need to set up ssh keys either by storing the passphrase in
| |
| cleartext or use ssh-agent. Using ssh-agent has security-flaws, too.
| |
| In addition, with ssh-agent, you will need to type the passphrase
| |
| at least once after every reboot. Not very suitable for a
| |
| fully-automated backup-system, IMHO.
| |
| | |
| When you use a public key on the client to encrypt, you can lock away
| |
| the private key in a secure place. Both, transport _and_ storage will
| |
| be encrypted with such a setup.
| |
| | |
| | |
| | |
| == Symmetric vs Public-key encryption ==
| |
| '''Symmetric Encryption'''<br/>
| |
| aka single-key (or secret-key) encryption. One key for encryption as well as decryption.<br/>
| |
| Pro:<br/>
| |
| #just one key to manage<br/> | |
| #faster<br/>
| |
| Con:<br/>
| |
| #need to share the key between two parties through a secured channel<br/>
| |
| #to do automatic backup, passphrase needs to store somewhere in this case. <br/>
| |
| | |
| | |
| '''Public Key/Private Key Encryption'''<br/>
| |
| aka asymmetric encryption. Public Key is used for encryption while a private (different) key is used for decryption.<br/>
| |
| need only other person's public key to encrypt.<br/>
| |
| Pro:<br/>
| |
| #no secret (i.e. public key) needed for encrypting.
| |
| #if public key is lost, it can be revised from the private key
| |
| #no need to use passphrase during encryption
| |
| Con:<br/>
| |
| #computationally expensive, thus slower[**]
| |
| #data is encrypted for a specific person/group. Only the specific person with the right private key can decrypt the data.
| |
| #potential man-in-the-middle attack
| |
| | |
| [**] it has been pointed out that computational resources don't matter that much: most systems generate a
| |
| symmetric session key, which is encrypted using the public key. Hence the slow
| |
| part is limited to the encryption of the session key, while the actual data is
| |
| encrypted using the fast symmetric algorithm.
| |