Backup GPG keys with Paperkey

Sun 28 Jul 2019

We've already covered a few articles that use GPG keys. We've created our password manager and set up a backup routine with Duplicity. GPG keys are being used to encrypt the processed data by these tools.

Quickly you realize that you have multiple keys that you need to back up and keep safe in case of disaster. In this article, we are covering how to backup a GPG key with Paperkey and turn that Paperkey back into a GPG key in case disaster struck. There are a lot of articles that show how to create the backup, yet most of them don't show how to use the Paperkey and recover your precious data.

A few things to consider

There are a few things to consider when making your backups. Most companies don't handle super sensitive data. The method I'm explaining here will suit most companies. If you are working with highly sensitive data than you might even want to consult a security expert on how to safely back up and store your keys.

Also, a backup is a direct copy. Keep this in mind. If a knowledgeable hacker knows what to do with your key then you simply gave them access to whatever the key gives access to. A quick word to counter and also to make you feel at ease, most people with physical access to these keys most likely won't know what to do with it. It is a "big if" but certainly possible.

There are also a lot of things that you can do with security through obscurity. Google has a lot of good practices applied here when it comes to that. A few examples are for example:

  • Using code names for projects
    • This way you cannot directly tell a key matches to a certain project.
    • You cannot tell the purpose of a certain key.
  • They are using strongly auto-generated passwords
    • Prevents the use of already used passwords.
    • Prevents the use of weak passwords.
  • They provide the secret key just once
    • Limited access ensures the rights are tight.
    • Ensures the only one with access is the only one with a copy.

Then you need a solid procedure within and another for outside the company. You are going to store keys that could potentially unlock your intellectual property. This is where my method comes in. I thought it would be a good idea to share my method of storing these keys and explain why I do it the way I do.

Backing up your key with Paperkey

Paperkey is the defacto tool to make a paper backup of your keys. It might sound strange but paper is a great vehicle for a backup of a key that potentially could decrypt very secure or sensitive data. Keeping a key like that digital or 'connected' could mean a security risk. Another great backup device could be a USB stick.

I keep a paper and USB backup paired together in a sealed envelope. I make sure that each envelope is unique and not just a normal white envelope. why? It makes it harder to make a forged copy. An intruder could have made a forged copy to fool you, giving you a false sense of security when you see this false copy. Using unique envelopes will make this harder.

As a second security/unique vector, I will write on this envelope. I will write the project's code name. How many copies there are and the date when it was put into rotation. This data will tell me everything I need to know when I need to recover data with that specific key. It will look a little like the following.

Butterspread lazer
Copy 1 of 2
01 January 2019

I always keep one envelope on my company's location. The other goes to an off-site location. Now, thats enough about the physical side of things. Let's back up some keys with that out of the way! The first obvious step is to install Paperkey.

rob@Rathalos ~ $ apt-get install paperkey

Then we need to decide what key we want to backup. It will show you multiple keys and it will look something like the following -- of course I obscured my data.

rob@Rathalos ~ $ gpg2 --list-keys
/home/rob/.gnupg/pubring.kbx
----------------------------
pub   rsa4096/81HEOK54 2019-04-19 [SC]
uid         [ultimate] Example name (Butterspread lazer) <support@butterspread-lazer.nl>
sub   rsa4096/AB6D8J32 2019-04-19 [E]

You see each key represented by their name, note, and email address. In the pub section you see what type of key, indicated by its algorithm and length. Then the ID of key follows. The following command will export the key and make a printable version of it.

rob@Rathalos ~ $ gpg2 --export-secret-key 81HEOK54 | paperkey --output paperkey.asc

If you look at this file then you will see comments, these are lines started with a #. You can ignore these when recovering. Then there are the lines with numbers, followed by groups of hexadecimal characters. This is your key.

To practice the recovery procedure we will remove the comments from the newly exported key. This will simulate the situation where we typed the characters back in a file. I've also seen other methods where people use scanners or reading pens to get the contents back into a recovery file. I have no such tools and thus will rely on typing the contents over to a file.

The following command will recover your key, afterwards, we will verify both to see if the key was correctly recovered. In the worst-case disaster scenario, you won't have access to the original key anymore. In most cases, you fully want to verify the key before putting it back into place.

Do take note that you will need the public key of the keypair also! Without this, you cannot recover your private key. The public key, however, unlike the private key is most likely distributed in your web of trust. Thus readily available. I will put the command to export your public key here also, note that this isn't an armor key.

# Command to export your public key
rob@Rathalos ~ $ gpg2 --export 81HEOK54 > publickey.asc

# Obviously you cannot do this in a real scenario, we are practicing :)
rob@Rathalos ~ $ gpg2 --export-secret-key 81HEOK54 > real-secret.asc

# Lets restore our paperkey
rob@Rathalos ~ $ paperkey --pubring public.asc --secrets paperkey.asc --output restored-secret.asc

Now you have recovered your key! Let's check the integrity of this key. We need to make sure it is the same before we put it back into place. If the process went right then you should see the details of your key. These details won't be displayed if your key is corrupt in one way or the other.

# Let's check our original and restored key
rob@Rathalos ~ $ gpg2 -v < real-secret.asc 
rob@Rathalos ~ $ gpg2 -v < restored-secret.asc

That's it! Now you move the key to where you need it. Most guides don't show the whole process. I thought it would be good practice and a great article to put out there.