duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Private key management, signature verification


From: edgar . soldin
Subject: Re: [Duplicity-talk] Private key management, signature verification
Date: Tue, 21 Jul 2015 11:17:55 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 21.07.2015 01:16, Jeff Rizzo wrote:
> First off, a brief description of what I'm trying to accomplish:
> 
> I'd like to have a "master" key which can decrypt backups, but whose private 
> key doesn't live on any backed-up host.   I seem to have ALMOST achieved what 
> I want with the script "duply" and duplicity 0.6.24/0.6.25 (it's what I 
> currently have available - i'd be willing to move to a newer version if it 
> actually fixes things).
> 
> If I create a config file for "duply" that looks like this:
> 
> ulimit -n 2048
> GPG_KEYS_ENC='EA2F12BE,FA174E5B'
> GPG_KEY_SIGN='EA2F12BE'
> GPG_PW=‘redacted'
> TARGET='ssh://address@hidden//backups/duplicity/duply3'
> SOURCE='/var'
> VOLSIZE=500
> DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
> DUPL_PARAMS="${DUPL_PARAMS} 
> --ssh-options='-oIdentityFile=/root/.ssh/id-backups' "
> DUPL_PARAMS="${DUPL_PARAMS} --ssh-backend=pexpect "
> 
> 
> I can successfully create backups from the original host using "duply".  This 
> host has the private key for EA2F12BE on it.
> 
> On the "restore" host, which has the key FA174E5B but not EA2F12BE, I create 
> a config file that looks like this:
> 
> ulimit -n 2048
> #GPG_KEYS_ENC='EA2F12BE,FA174E5B'
> GPG_KEY='FA174E5B'
> #GPG_KEY_SIGN='EA2F12BE'
> GPG_PW=‘redacted'
> TARGET='ssh://address@hidden//backups/duplicity/duply3'
> SOURCE='/var'
> VOLSIZE=500
> DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
> #DUPL_PARAMS="${DUPL_PARAMS} 
> --ssh-options='-oIdentityFile=/root/.ssh/id-backups' "
> DUPL_PARAMS="${DUPL_PARAMS} --ssh-backend=pexpect "
> 
> 
> Using this file, I can eventually do a "duply test3 list" and get a list of 
> backed-up files (there are some errors of the form:
> 
> OSError: [Errno 1] Operation not permitted: 
> '/Users/jrizzo/.cache/duplicity/duply_test3/duplicity-inc.20150224T012820Z.to.20150720T205314Z.manifest'
> 
> 
> which occur, but don't happen on the second run).
> 
> 
> I can _also_ restore some files. However, after restoring the first volume, I 
> get this error:
> 
> 
> Volume was signed by key EA2F12BE, not FA174E5B
> 
> 
> 
> ...which makes sense.  But really, I'd like to check that the signature from 
> EA2F12BE is good.  Adding it to GPG_KEY_SIGN is no good, because the script 
> expects me to have the private key then. (huh?)
> 
> Does anyone have a suggestion for tweaks to make to achieve my goal?   Thanks!
> 
> +j
> 


assuming FA174E5B is your "master key". if you _only_ want to restore/verify on 
the second host simply use the same duply conf parameters as on the backup host 
but install only these keys
1. EA2F12BE public key (needed to verify signature)
2. FA174E5B secret and public key (needed for decryption)

actually duply has the functionality to ex/reimport used keys into the profile. 
so once your backup is set up properly you can copy the profile folder over to 
your second machine and it will install the keys that were used on the backup 
box. suggesting that it makes your approach kind of senseless as you can easily 
reuse the "machine" key.

btw. the "Volume was signed by .." is no fatal error, meaning the restore will 
continue albeit with an error exit code, suggesting you to check the log.

another option:

you could simply disable signing, because
- the "machine" public key is _only_ used on that machine
- if someone gains access to it he can easily backup malicious data and sign it 
as well because he also has access to the "machine" secret key

a signature only makes real sense if you sign a message encrypted to a 
different key, so you can verify the sender. eg. you only encrypt to your 
"master" key and sign w/ the "machine" key to make sure that the backup data 
was not modified'n'recreated by someone only having ripped your private key 
somewhere.


..ede/duply.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]