Public key encryption and incremental backups

This was true until duplicity version 0.6.0 .. This version keeps the necessary metadata for incrementing backups in an archive/cache folder. Duplicity checks it against the repository and only downloads/decrypts these files if outdated(backup from another machine) or missing/corrupted.

Hence you can do it this way, but will have to keep an eye on duplicity's output. On smaller backup's I'd suggest going for fulls only, which never need a private key, except for verifying/restoring.

But what good is your backup anyway if the hacker has access to your private key, he has access to the duplicity backend credentials as well as to the data itself.

ede

Thanks ede

Note that this is actually addressed in the man page (a classic case of RTFM, sorry):
http://duplicity.nongnu.org/duplicity.1.html
===
--encrypt-key key
When backing up, encrypt to the given public key, instead of using symmetric (traditional) encryption. Can be specified multiple times.

To save bandwidth, duplicity generates full signature sets and incremental signature sets. A full signature set is generated for each full backup, and an incremental one for each incremental backup. These start with duplicity-full-signatures and duplicity-new-signatures respectively. These signatures will be stored both locally and remotely. The remote signatures will be encrypted if encryption is enabled. The local signatures will not be encrypted and stored in the archive dir (see --archive-dir ).

The archive directory should not be deleted, or duplicity will have to recreate it from the remote repository (which may require decrypting the backup contents).
===

So, as ede says, this should all work correctly unless the local (decrypted) copy of the signatures are deleted.

> But what good is your backup anyway if the hacker has access to your private key, he has
> access to the duplicity backend credentials as well as to the data itself.

I'm sorry, I'm not sure what this means. Using public key encryption is in a lot of ways more sensible for unattended backups, as passphrase (symmetric) encryption requires that the unattended script have access to the cleartext passphrase. The only (and significant) downside to public key encryption for backups is that the key needs to be backed up somewhere manually for the backup to be any use. I understand that this is why déjà-dup does not have the option enabled.

I'm guessing that you are saying that storing a cleartext passphrase isn't a big deal, as if the "hacker" could get to that, they could get to the files themselves, which is probably true. Arguably, it would be a lot easier to get a copy of/sniff a single phrase without my knowledge than copy 300GB of data (assuming the hacker had access to the ciphertext of the backup), but there isn't a lot in it. In my case, I'm backing up a number of machines, some of which I trust less than others. I don't really want to have different passphrases for each and I don't want my valuable passphrases in cleartext on some of these machines. Encrypting to my public key means that I only need to put my public key on untrusted machines (no security risk), but does mean I have to keep backups of my private key outside of Duplicity.

>>
On smaller backup's I'd suggest going for fulls only, which never need a
private key, except for verifying/restoring.
<<

this was meant of course for older duplicity versions, which were not
able to do incremental backups without the private key.

>>
But what good is your backup anyway if the hacker has access to your
private key, he has access to the duplicity backend credentials as well
as to the data itself.
<<

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.

A clever hacker wouldn't probably steal 300GB, but

- try to put tempered data in the backup that looks trustworthy because
it was "securely" backed up
- shredder the whole system, but not without deleting the remote backed
up data first

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. Having said that I think the easiest/safest
route currently would be:

A dedicated key for the backup host (host key) plus your very own public
key. The backup would be encrypted to both public keys and signed with
the host private key.
The encryption to your own public key would act as a fallback in case
you manage to "loose" the host private key. This way you would still be
able decrypt your backup.
If you manage to loose the complete host key pair, this is also true,
but you loose the ability to verify that the backup is actually from
that machine.

In conclusion: I think duplicity only protects your backed up data from
manipulation and spying eyes. If you want protection from deletion or
silently injected bad data you probably will have to keep copies of old
chains somewhere not reachable/mentioned on the backup host.

regards ede

On 07.05.2010 00:00, Aaron Whitehouse wrote:
> Question #107216 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/107216
>
> Status: Answered => Solved
>
> Aaron Whitehouse confirmed that the question is solved:
> Thanks ede
>
> Note that this is actually addressed in the man page (a classic case of RTFM, sorry):
> http://duplicity.nongnu.org/duplicity.1.html
> ===
> --encrypt-key key
> When backing up, encrypt to the given public key, instead of using symmetric (traditional) encryption. Can be specified multiple times.
>
> To save bandwidth, duplicity generates full signature sets and
> incremental signature sets. A full signature set is generated for each
> full backup, and an incremental one for each incremental backup. These
> start with duplicity-full-signatures and duplicity-new-signatures
> respectively. These signatures will be stored both locally and remotely.
> The remote signatures will be encrypted if encryption is enabled. The
> local signatures will not be encrypted and stored in the archive dir
> (see --archive-dir ).
>
> The archive directory should not be deleted, or duplicity will have to recreate it from the remote repository (which may require decrypting the backup contents).
> ===
>
> So, as ede says, this should all work correctly unless the local
> (decrypted) copy of the signatures are deleted.
>
>> But what good is your backup anyway if the hacker has access to your private key, he has
>> access to the duplicity backend credentials as well as to the data itself.
>
> I'm sorry, I'm not sure what this means. Using public key encryption is
> in a lot of ways more sensible for unattended backups, as passphrase
> (symmetric) encryption requires that the unattended script have access
> to the cleartext passphrase. The only (and significant) downside to
> public key encryption for backups is that the key needs to be backed up
> somewhere manually for the backup to be any use. I understand that this
> is why déjà-dup does not have the option enabled.
>
> I'm guessing that you are saying that storing a cleartext passphrase
> isn't a big deal, as if the "hacker" could get to that, they could get
> to the files themselves, which is probably true. Arguably, it would be a
> lot easier to get a copy of/sniff a single phrase without my knowledge
> than copy 300GB of data (assuming the hacker had access to the
> ciphertext of the backup), but there isn't a lot in it. In my case, I'm
> backing up a number of machines, some of which I trust less than others.
> I don't really want to have different passphrases for each and I don't
> want my valuable passphrases in cleartext on some of these machines.
> Encrypting to my public key means that I only need to put my public key
> on untrusted machines (no security risk), but does mean I have to keep
> backups of my private key outside of Duplicity.
>

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

>
> 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.
>

no need for apologies and thanks for the ingenious idea of separating
encryption and signing key ... ede

See updated information on this topic in this mailing list thread:
http://lists.nongnu.org/archive/html/duplicity-talk/2015-03/msg00022.html