Silk Road forums

Discussion => Security => Topic started by: LouisCyphre on July 01, 2012, 12:09 pm

Title: GPG HOWTO: Backing up secret keys securely
Post by: LouisCyphre on July 01, 2012, 12:09 pm
This document describes how to properly backup any GPG secret key.  This should be performed immediately after making any new key, such as described in this post:

http://dkn255hz262ypmii.onion/index.php?topic=28474.0

As with the instructions in that post, this document assumes that you are using GPG and accessing it via a *nix command line.  These instructions should work with both GPG 1.4.x and GPG 2.0.x, but the examples were created with GPG 1.4.12.

It is strongly advised that this process be performed in an encrypted volume and that all digital storage methods used to hold the secret key backup also be encrypted (e.g. USB sticks, backup drives, etc.).  The secret key will still be protected by the passphrase and stored in an encrypted form, but additional encryption for the backup devices increases the level of security for information which absolutely must be protected.

Since I deleted the test key I created for that document, I have created a new key for this example.  The details of this key are similar to, but not quite the same as the first example:

Quote
bash-3.2$ gpg -k --fingerprint FD868CB5
pub   4096R/FD868CB5 2012-07-01
      Key fingerprint = 7487 95A6 29A5 C59B FF75  A490 B5A6 614E FD86 8CB5
uid                  Harry Angel (SR Test Key) <nobody@example.com>
sub   2048R/506A0834 2012-07-01
sub   4096g/3646D905 2012-07-01

bash-3.2$ gpg -K --fingerprint FD868CB5
sec   4096R/FD868CB5 2012-07-01
      Key fingerprint = 7487 95A6 29A5 C59B FF75  A490 B5A6 614E FD86 8CB5
uid                  Harry Angel (SR Test Key) <nobody@example.com>
ssb   2048R/506A0834 2012-07-01
ssb   4096g/3646D905 2012-07-01

bash-3.2$

Step One:

Once you have your key and the relevant subkeys, the first and most important step is to export your backup:

Quote
bash-3.2$ gpg -a --export-secret-keys FD868CB5 > FD868CB5-seckey.asc
bash-3.2$

Step Two:

You should also take the opportunity to export a copy of the public key:

Quote
bash-3.2$ gpg -a --export FD868CB5 > FD868CB5-pubkey.asc
bash-3.2$

Step Three:

The public key is ready to be distributed to anyone you wish to be able to encrypt data to you using that key.  It can be published freely and sent anywhere.

Step Four:

The secret key should be copied to multiple secure locations, such as encrypted volumes on USB sticks and possibly other media.  Ideally you do not want a backup on the same system or systems you will normally be using the key on.  When you have finished transferring the secret key to other digital repositories, do *not* delete the secret key file as it is still needed for a few more steps.


The key comprises three components: the master key or certificate (0xFD868CB5 in this example), the signing subkey (0x506A0834) and the encryption subkey (0x3646D905).  Each serves a different task, as the names suggest:

* The master key/certificate is used to create new subkeys, revoke old subkeys and sign other people's keys.  In this example it can also be used to sign messages and files, but only if a signing subkey is not present.
* The signing subkey is used to sign messages and files.  Signatures are verified with the public key.
* The encryption subkey is used encrypt messages and files so that you can decrypt them.

For day-to-day use only the signing subkey and the encryption subkey are required.  So there is a security benefit to removing the master key and only restoring it from a backup when it is required to perform some action on the key or on another key.


Step Five:

Export the subkeys only:

Quote
bash-3.2$ gpg -a --export-secret-subkeys FD868CB5 > FD868CB5-subkey.asc
bash-3.2$

Make sure there are backups of the subkey file as well as the secret key file in each of your secure backup locations.

Step Six:

Delete the entire key from your secret keyrings:

Quote
bash-3.2$ gpg --delete-secret-keys FD868CB5

sec  4096R/FD868CB5 2012-07-01 Harry Angel (SR Test Key) <nobody@example.com>

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
bash-3.2$

This will leave the public key in your keyrings, but that's fine as it won't change during the rest of this tutorial.

Step Seven:

Import the subkeys from the file you created in Step Five:

Quote
bash-3.2$ gpg --import FD868CB5-subkey.asc
gpg: key FD868CB5: secret key imported
gpg: key FD868CB5: "Harry Angel (SR Test Key) <nobody@example.com>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
bash-3.2$

You now have just the subkeys present:

Quote
bash-3.2$ gpg -K FD868CB5
sec#  4096R/FD868CB5 2012-07-01
uid                  Harry Angel (SR Test Key) <nobody@example.com>
ssb   2048R/506A0834 2012-07-01
ssb   4096g/3646D905 2012-07-01

bash-3.2$

The hash symbol ("#") next to the "sec" indicates that the master key is absent.


This should be the state the key is in when used on a day-to-day basis.  There are, however, some further options I have not covered yet which may be of interest to some people, depending on your threat model.  These include a paper backup of the secret key as ink and paper generally have a longer lifespan tha digital media and a pseudo-escrow option in case law enforcement comes calling.


Step Eight:

Delete the signing subkey so that only the encryption subkey is left:

Quote
bash-3.2$ gpg --edit-key FD868CB5
Secret key is available.

pub  4096R/FD868CB5  created: 2012-07-01  expires: never       usage: SC 
sub  2048R/506A0834  created: 2012-07-01  expires: never       usage: S   
sub  4096g/3646D905  created: 2012-07-01  expires: never       usage: E   
[ unknown] (1). Harry Angel (SR Test Key) <nobody@example.com>

gpg> key 1
         
pub  4096R/FD868CB5  created: 2012-07-01  expires: never       usage: SC 
sub* 2048R/506A0834  created: 2012-07-01  expires: never       usage: S   
sub  4096g/3646D905  created: 2012-07-01  expires: never       usage: E   
[ unknown] (1). Harry Angel (SR Test Key) <nobody@example.com>

gpg> delkey
Do you really want to delete this key? (y/N) y
                                             
pub  4096R/FD868CB5  created: 2012-07-01  expires: never       usage: SC 
sub  4096g/3646D905  created: 2012-07-01  expires: never       usage: E   
[ unknown] (1). Harry Angel (SR Test Key) <nobody@example.com>

gpg> save
bash-3.2$

This shows that both the public and secret keys have been changed to reflect this deletion:

Quote
bash-3.2$ gpg -k FD868CB5
pub   4096R/FD868CB5 2012-07-01
uid                  Harry Angel (SR Test Key) <nobody@example.com>
sub   4096g/3646D905 2012-07-01

bash-3.2$ gpg -K FD868CB5
sec#  4096R/FD868CB5 2012-07-01
uid                  Harry Angel (SR Test Key) <nobody@example.com>
ssb   4096g/3646D905 2012-07-01

bash-3.2$

Step Nine:

Change the passphrase on the encryption subkey to something unrelated to any passphrase you have ever used or ever plan to use.  This passphrase does not need to be very complex or secure:

Quote
bash-3.2$ gpg --edit-key FD868CB5
Secret key is available.

pub  4096R/FD868CB5  created: 2012-07-01  expires: never       usage: SC 
sub  4096g/3646D905  created: 2012-07-01  expires: never       usage: E   
[ unknown] (1). Harry Angel (SR Test Key) <nobody@example.com>

gpg> passwd
Secret parts of primary key are not available.

You need a passphrase to unlock the secret key for
user: "Harry Angel (SR Test Key) <nobody@example.com>"
4096-bit ELG-E key, ID 3646D905, created 2012-07-01

Enter the new passphrase for this secret key.

                   
gpg> save
bash-3.2$

You will be prompted for the current passphrase, followed by the new passphrase and a confirmarion of the new passphrase.


The purpose of this is to have a copy of the encryption subkey only with a passphrase that can be provided to adversaries (law enforcement or otherwise) when there is no other option (and there should be other options).

If you do find yourself in a position where you must hand over your secret key and the passphrase then you want to be sure that:

1) The passphrase is not one that is important to you.

2) Your key cannot be used to sign messages or files i your name.

3) The master key cannot be used to create additional subkeys which you do not have access to, but do appear in your name and attached to a valid key.


Step Ten:

Save the new password in clear text in another file (e.g. FD868CB5-passphrase.txt).

Export the encryption secret subkey to a file:

Quote
bash-3.2$ gpg -a --export-secret-subkeys 3646D905 > 3646D905-subkey.asc
bash-3.2$

Step Eleven:

Delete the remaining public and secret keys from the keyring:

Quote
bash-3.2$ gpg --delete-secret-and-public-keys FD868CB5

sec  4096R/FD868CB5 2012-07-01 Harry Angel (SR Test Key) <nobody@example.com>

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
                                             
pub  4096R/FD868CB5 2012-07-01 Harry Angel (SR Test Key) <nobody@example.com>

Delete this key from the keyring? (y/N) y
bash-3.2$

Then import the encryption subkey file we created in Step Ten to test what an opponent or enemy would see if it were provided:

Quote
bash-3.2$ gpg --import 3646D905-subkey.asc
gpg: key FD868CB5: secret key imported
gpg: key FD868CB5: public key "Harry Angel (SR Test Key) <nobody@example.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
bash-3.2$ gpg -k FD868CB5
pub   4096R/FD868CB5 2012-07-01
uid                  Harry Angel (SR Test Key) <nobody@example.com>
sub   4096g/3646D905 2012-07-01

bash-3.2$ gpg -K FD868CB5
sec#  4096R/FD868CB5 2012-07-01
uid                  Harry Angel (SR Test Key) <nobody@example.com>
ssb   4096g/3646D905 2012-07-01

bash-3.2$

If the key appears to be limited as above this key should be unable to sign any files and only decrypt files using the weaker or disposable passphrase:

Quote
bash-3.2$ echo something > something.txt
bash-3.2$ gpg -s -u FD868CB5 something.txt
gpg: secret key parts are not available
gpg: skipped "FD868CB5": general error
gpg: signing failed: general error
bash-3.2$ gpg -ea -r FD868CB5 something.txt
bash-3.2$ rm -f something.txt
bash-3.2$ gpg something.txt.asc

You need a passphrase to unlock the secret key for
user: "Harry Angel (SR Test Key) <nobody@example.com>"
4096-bit ELG-E key, ID 3646D905, created 2012-07-01 (main key ID FD868CB5)

gpg: Invalid passphrase; please try again ...

You need a passphrase to unlock the secret key for
user: "Harry Angel (SR Test Key) <nobody@example.com>"
4096-bit ELG-E key, ID 3646D905, created 2012-07-01 (main key ID FD868CB5)

gpg: encrypted with 4096-bit ELG-E key, ID 3646D905, created 2012-07-01
      "Harry Angel (SR Test Key) <nobody@example.com>"
bash-3.2$ cat something.txt
something
bash-3.2$

The test is successful and we can now remove this key in exactly the same way we did at the beginning of this step:

Quote
bash-3.2$ gpg --delete-secret-and-public-keys FD868CB5

sec  4096R/FD868CB5 2012-07-01 Harry Angel (SR Test Key) <nobody@example.com>

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
                                             
pub  4096R/FD868CB5 2012-07-01 Harry Angel (SR Test Key) <nobody@example.com>

Delete this key from the keyring? (y/N) y
bash-3.2$

Step Twelve:

Add the modified encryption subkey and the text file containing the weak passphrase to a zip file (or tarball or other archiving system) and then delete the source files:

Quote
bash-3.2$ tar -cvf FD868CB5-escrow.tar FD868CB5-passphrase.txt 3646D905-subkey.asc
./._FD868CB5-passphrase.txt
FD868CB5-passphrase.txt
./._3646D905-subkey.asc
3646D905-subkey.asc
bash-3.2$ rm -f FD868CB5-passphrase.txt
bash-3.2$ rm -f 3646D905-subkey.asc
bash-3.2$

Step Thirteen:

Import the full key and masterkey:

Quote
bash-3.2$ gpg --import FD868CB5-seckey.asc
gpg: key FD868CB5: secret key imported
gpg: key FD868CB5: public key "Harry Angel (SR Test Key) <nobody@example.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
bash-3.2$

Then encrypt the archive file (zip, tarball, whatever) with the key and then delete the archive file:

Quote
bash-3.2$ gpg -e -r FD868CB5 FD868CB5-escrow.tar
bash-3.2$ rm -f FD868CB5-escrow.tar
bash-3.2$

Make copies of the encrypted escrow version of the key with every digital backup of the secret and public keys.

Step Fourteen:

You can now, optionally, make a paper copy of your secret key.  To do this you will need David Shaw's Paperkey program, which is available here:

http://www.jabberwocky.com/software/paperkey/    (clearnet)

You will need to compile the source code if you are using *nix, but there are binaries available for Windows users.

Once paperkey is installed, a printable copy of your key can be created with the following command:

Quote
bash-3.2$ gpg --export-secret-key FD868CB5 | paperkey --output FD868CB5-paperkey.txt
bash-3.2$

You should keep a printed copy in a safe place and then either delete the Paperkey output file or encrypt it and keep it with the other backup files.

Step Fifteen:

Delete the current keys:

Quote
bash-3.2$ gpg --delete-secret-and-public-keys FD868CB5

sec  4096R/FD868CB5 2012-07-01 Harry Angel (SR Test Key) <nobody@example.com>

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
                                             
pub  4096R/FD868CB5 2012-07-01 Harry Angel (SR Test Key) <nobody@example.com>

Delete this key from the keyring? (y/N) y
bash-3.2$

Import the subkeys only backup that was created in Step Five:

Quote
bash-3.2$ gpg --import FD868CB5-subkey.asc
gpg: key FD868CB5: secret key imported
gpg: key FD868CB5: "Harry Angel (SR Test Key) <nobody@example.com>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
bash-3.2$

You are now back to the point you were at the end of Step Seven.


Any remaining files should be backed up in either an encrypted volume, with individual GPG encryption or both.  The copies made during this process should all be deleted.  Feel free to use a program like shred to expunge the files from the sytem(s) you operate from in addition to the normal "rm -f" command.

Once again, I hope the above guide is of some assistance.