Resume backup - encryption password required

[benempson]

Hi zertrin, I have been doing a fair bit of testing with duplicity-backup.

I've noticed that when a backup fails (eg. because of dropped connection - I'm backing up to s3), on the next run it will try to resume. On resume, it downloads the first volume of the backupset and tries to decrypt it.

At this point, I was getting the following error:

GPG error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 1411, in
with_tempdir(main)
File "/usr/bin/duplicity", line 1404, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1374, in main
full_backup(col_stats)
File "/usr/bin/duplicity", line 509, in full_backup
globals.backend)
File "/usr/bin/duplicity", line 346, in write_multivol
validate_encryption_settings(globals.restart.last_backup, mf)
File "/usr/bin/duplicity", line 334, in validate_encryption_settings
fileobj.close()
File "/usr/lib64/python2.6/site-packages/duplicity/dup_temp.py", line 225, in close
assert not self.fileobj.close()
File "/usr/lib64/python2.6/site-packages/duplicity/gpg.py", line 251, in close
self.gpg_failed()
File "/usr/lib64/python2.6/site-packages/duplicity/gpg.py", line 218, in gpg_failed
raise GPGError, msg
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID 3C6E2351, created 2013-05-19 "Duplicity Backup Encryption Key for profiaa22 (Encryption key for Duplicity Backup for profiaa22) <securityteam@***>"
gpg: public key decryption failed: Bad passphrase
gpg: decryption failed: No secret key
can't connect to `/root/.gnupg/S.gpg-agent': No such file or directory ===== End GnuPG log =====

The key bit of this was "gpg: public key decryption failed: Bad passphrase". Since it is using the Encryption key to decrypt, and this key is not stored in the duplicity-backup config file, it doesn't seem surprising that it can't decrypt.

I've worked around this by 1). creating an ENC_PASSPHRASE variable in my duplicity-backup.conf file, eg:

PASSPHRASE="12345"
ENC_PASSPHRASE="1234"

and 2). modifying duplicity-backp.sh to export this as follows:

SIGN_PASSPHRASE=$PASSPHRASE
PASSPHRASE=$ENC_PASSPHRASE
export AWS_ACCESS_KEY_ID
export AWS_SECRET_ACCESS_KEY
export PASSPHRASE
export SIGN_PASSPHRASE

Clearly before the script was exporting the Signature passphrase as both PASSPHRASE & SIGN_PASSPHRASE - I'm not sure why this would be? Can you see any problems with what I've done? If not, then it would seem sensible to roll this into the production version...

Regards, Ben

[zertrin]

Hi Ben, and thanks a lot for this report.

The fact that duplicity needs the decryption passphrase to resume the backup doesn't surprise me, although I didn't know until now that there is a "resume backup" feature in duplicity, and I didn't stumble upon this situation yet.

Your workaround, while working of course, is not satisfying for being included as is in the production version, for the following reason:
If you are using 2 different passphrase for signing and encryption, this means you don't want the encryption passphrase to be somewhere in cleartext (see http://www.debian-administration.org/articles/209#d0e109). Thus it is not acceptable to add any variable in the config file to hold the encrypting passphrase in the case of different signing and encryption keys (this would reduce the purpose of using 2 different keys to nothing).

The real solution would be to do like for the verification option, i.e. to ask interactively for the decryption passphrase at the runtime.

But if this "resume backup" situation happens while the script is not run interactively (cronjobs), there is no chance for the user to be able to answer the passphrase prompt.
For those who are regularly faced with such situations, it seems they would have to degrade their security requirements one level lower (see next §).

Those who are not concerned by leaving the encryption passphrase in cleartext in the configuration file don't need to bother with two different GPG keys, they can either use the same key for signing and encryption, or use the symmetric encryption.

And about the naming convention of the passphrases variables, it is still an heritage from the original script, and is probably improvable.

Regards

[benempson]

Hi zertrin, yes I did think that it would probably be unsuitable from a security point of view.

I have read other posts from other people regarding gpg-agent which apparently stores passphrases in a cache available to local software, but I’m not clear on exactly how I could get this working, and there seem to be some issues with cache length and what happens if the cache has timed-out – ie. duplicity can’t get the password out of it!!

I looked at http://www.debian-administration.org/articles/209#d0e109 – thanks for the link. The key point for me here was: “ If our encryption key and signature key are the same, then a compromise of the server means a compromise of the backed up data as well. We'll therefore use separate encryption and signature keys.” Given that the server is backing up local data, then a compromise of the server means that the data is already compromised anyway without even looking at the backup files! My main concern for encryption is that the backups cannot be decrypted at their destination (Amazon s3) or any point inbetween – so I guess in that scenario I don’t really need to be concerned about having a separately unavailable encryption password and can use the same GPG key for encryption and signing. For sure that would simplify things which is also high on the priority list right now ;)

Regards, Ben

[jaltek]

Hi Ben,
just to catch up your thoughts:

so I guess in that scenario I don’t really need to be concerned about having a separately
unavailable encryption password and can use the same GPG key for encryption and signing

Well, as usual, it depends ;)
If you always backup the same data, you are right - but think of files you e.g. deleted on the server. Depending on the "remove older than.." settings the deleted files will be available in the backup for some time.

[benempson]

Hi Jan. The same applies whether or not I’m using identical or different passphrases for encryption and signing – ie. deleted files will be available in the backups. I’m not sure how your point applies to the problem?

What I was saying is that a compromised server means that the data I would theoretically be trying to protect is already compromised anyway, regardless of whether the keys are the same or different, as such it’s irrelevant from this point of view whether the keys are the same or different. Since this seems to be the only advantage of having a separate signing key (ie. a compromised server does not mean compromised data) – where exactly do deleted files enter this scenario?

[munkee]

I think the idea is with seperate keys a compromised server only compromises the data currently on the server(not things deleted from the server but still in the backup). Deleted data is still in the backup but the backup is not readable with the contents of the compromised server. 

[benempson]

OK, understood!