duplicity-team team mailing list archive

[Aaron Whitehouse <question107216@xxxxxxxxxxxxxxxxxxxxx>]

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.