Question #107216 on Duplicity changed: https://answers.launchpad.net/duplicity/+question/107216
Aaron Whitehouse posted a new comment: edso wrote: > yes. I meant, if the hacker has come as far as having access to the > private key used, he pretty much has access to all data of the user the > backup job runs as. This means primarily: credentials and location of > the backed up data, passphrase for the private key used, the precious > data itself. Oh, I see. I didn't see where you are coming from. For anybody who is less familiar with encryption, there are two issues here: * Encrypting asymmetrically to a public key can happen without the host knowing the private key. This is secure encryption and cannot be decrypted without the private key (secured with a passphrase). Think of it like a locked ballot box, that anyone can put ballot papers in, but you need a key to get them out again. It does not, theoretically, prevent somebody from tampering with the backup and adding a new (malicious) "backup" to your backup set, encrypted to your public key. Continuing the analogy, adding 100 ballots for a candidate. I'm not sure of the mechanics of doing this from a duplicity point of view. * Signing a backup allows you to know that the backup has not been tampered with since it was created, but requires the private key and passphrase. In my example, imagine that each voter must sign their ballot paper, so you know all ballots in there are genuine. If the "hacker" has access to the automatically-signing host, they necessarily have access to the private signing key (as it can't require a passphrase or it cannot be automatic) and could tamper with the backups so that you could no longer assume that they were unchanged. This does not, therefore, prevent tampering if the hacker has access to the host. It does prevent tampering at the remote location, say on an Amazon/FTP site out of your control. Obviously, someone with access to the host can also tamper with the data on the host itself. > Actually I spent some thought on security of the private key lately. It > is possible to use different keys for encrypting and signing. Encrypting > even supports multiple keys. Yes. DSA keys are currently recommended for signing and El-Gamal for encryption. > Having said that I think the easiest/safest route currently would be: (My slight modification to this:) * Create three keys: a DSA host-signing-key, an El-Gamal host-encryption-key and your normal key (admin-encryption-key). The admin-encryption-key is only necessary if, like me, you have a number of systems and want to have a key specific to that host and also one key that can decrypt them all (which in my case is my normal GnuPG key). All keys should have different passphrases. * Set up duplicity to encrypt to the two encryption keys: --encrypt-key [keyid of host-encryption-key] --encrypt-key [keyid of admin-encryption-key] This means that the data is encrypted to these two keys and can not be decrypted, even by somebody who has compromised the host, as the passphrase of the private key is not necessary for encryption. * Set up duplicity to sign with the host-signing-key: --sign-key [keyid of host-signing-key] and give duplicity the PASSPHRASE for the signing key (only). This means that the backups are signed and you can be confident that they have not been tampered with at any offsite location. This set-up will mean that: * if the hacker has complete access to the off-site (FTP/Amazon) location but no access to the host, the backups are unreadable and unmodifiable; * if the hacker has complete access to the host (briefly, say with a trojan) and off-site location (often), the hacker could get the signing passphrase and could potentially add new backups and sign them (if it is even possible to craft an additional file that duplicity would think was one of its backups), but could not get access to the decrypted data; and * if the hacker has permanent complete access to the host and off-site location, you're pretty stuffed, but that has nothing to do with duplicity! The advantage to this approach over my understanding of your approach (one host key, plus one admin key) is that, even if the hacker gets access to the cleartext passphrase for the signing key, they can still never decrypt the backups. I apologise if I have misunderstood you. Regards, Aaron -- You received this question notification because you are a member of duplicity-team, which is an answer contact for Duplicity. _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
