OpenPGP Part 4: Backup Your Keys

In this post we’re going to backup the keys we created in the previous posts. After generating your Primary Key and subkeys, they reside on the machine used to create them. In our case that’s just a Docker container but, in the real world, that will be on your personal computer.

• Part 1: Introduction
• Part 2: Create Your Primary Key
• Part 3: Create Your Subkeys

Remember, part 2 shows how you can following along at home in Docker.

Now, you could just leave them on your personal machine and go on your merry way and use your keys. But we can do a little better from a security standpoint. If your laptop is ever stolen or compromised an attacker will have access to all of your private keys. Granted, they are still protected by the passphrase but if somebody possesses the private keys they can begin to attack them. It’s especially bad to have access to your Primary Key. It is also still protected by your passphrase but if an attacker manages to unlock it they have full ability to revoke your keys, decrypt your stuff and generate new keys with your identity. Additionally, they can sign other people’s keys on your behalf which messes with your chain of trust. They can pretend to be the digital version of you. Anyway, you get the point, it’s bad news.

Ultimately we may want to move the keys off to a smart card (Yubikey) or other media like an encrypted USB drive. But before we can do that we need to back everything up. That way, if something goes wrong we can always restore to a known good state.

Here’s what we’ll be doing in this post.

• Create hard-copy backups
• Backup the trust store
• Create a revocation certificate
• Take the Primary Key offline
• Change the passphrase on our subkeys

Create Hard-Copy Backups

There is some debate on the best way to backup your keys to survive the apocalypse. Encrypted USB drives, CD ROMS in envelopes in safe deposit boxes, etc. Ultimately it will depend on your personal circumstances. If you live in a mansion with 24/7 security and a nuclear fallout shelter you have onsite secure options. If you live in a small apartment in an area of high crime you may want to consider a safe deposit box at a bank or other secure location.

To back up your keys you have to make 2 decisions:

1. What storage medium to use
2. Where to keep that medium once the keys are on it

Storage Medium

This is a matter of what you feel is best but I’m going to make an opinionated recommendation. Good ‘ol fashioned paper. Humanity has uncovered documents that are hundreds, even thousands, of years old on paper or papyrus that are still preserved enough to read. It’s a low tech storage medium with extreme durability when properly stored. If you print your private keys on good paper with quality toner or ink and then laminate it there is no reason it can’t last for hundreds of years.

Some people use encrypted USB drives or CD/DVD media. Disks are certainly more long-term viable but they require technology to access them. Technology that is changing all the time. Imagine if you had stored your private keys on a VHS or 5.25” floppy disk. Could you access them today? Sure. Would it be easy? Not really. If your keys are on paper they can always be re-entered into whatever the latest computer terminal is and you’re on your way.

Storage Location

Some things to think about here:

• How secure is the location?
• How accessible is the location? If I need my backups, how quickly can I get them?
• Will my next-of-kin have access to the location in the event of my untimely demise?
• Do you want a redundant backup location?

How crazy you get here also depends on what you are using your keys for. If you are only playing around with security and casually using them you should modify your storage location accordingly. For example, if I’m using my keys just to sign Git commits on my open source repo I’m going to store the backups in a different location than keys I’m using to decrypt highly sensitive information.

The signing key for your ESP32 SecureBoot process needs to be guarded as carefully as your Primary Key. If it is ever compromised somebody can build firmware that seems like it’s from you and will run on your devices.

Minimalist Suggestion

At a minimum, backup your keys to a laminated paper medium and store them in a lock box. It’s cheap and it’s effective. I’d also recommend putting the backups on a USB drive that also goes in the lock box. This is for short-term access. As long as computers recognize USB drives you’ll be thankful you didn’t have to type in a bunch of long private keys by hand.

Generate the Backups

Enough talk, let’s actually create the backups we need. All we need to do is run the following commands.

gpg --armor --export-options backup --export > public-keys.asc
gpg --armor --export-options backup --export-secret-keys > private-keys.asc
gpg --armor --export-options backup --output private-subkeys.asc --export-secret-subkeys {your key ID}
gpg --export-ownertrust > ownertrust.asc

For the public and private keys this will create a PEM-formatted file that you can open in plain text. Back them up to the storage medium and location you have chosen. The last command listed creates a backup of your local trust store. This keeps track of other identities you have trusted. At this point it just has your own key fingerprint but as you trust and sign other people’s keys more entries will be added so future backups of the trust database will be necessary.

The private-subkeys.asc file will be needed below when we take the Primary Key offline.

Create a Revocation Certificate

It is highly recommended that you create a revocation certificate immediately after generating your Primary Key.¹ The certificate should be stored in a secure location and can be used at any future point to mark your Primary Key as revoked. You can create multiple revocation certificates containing different reasons for revocation but the one we are going to create now is for the event of your key being compromised.

gpg --armor --output revoke.asc --gen-revoke {your key ID}

sec  rsa4096/C14EB8AF5DF94F07 2024-01-12 Fake McFakerton <me@fake.com>

Create a revocation certificate for this key? (y/N) y <--------- Confirm creation
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1 <---------------------------------------------- Reason is key is compromised
Enter an optional description; end it with an empty line:
> They hacked me! <--------------------------------------------- Optional description
>
Reason for revocation: Key has been compromised
They hacked me!
Is this okay? (y/N) y <----------------------------------------- Confirm choices
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

This will generate a file named revoke.asc. Back this up to the secure storage medium and location of your choice. It should be just as secure as your Primary Key.

Take the Primary Key Offline

Now that we have generated all of our subkeys and backed everything up, we are done with the Primary Key. There is no reason to leave it lying around on your machine as this presents a major security risk. First, let’s run the command to look at our keys.

gpg --list-secret-keys

------------------------
sec   rsa4096 2024-01-12 [SC]
      FE690745891460F5563083F4F98122173492B5C6
uid           [ultimate] Fake McFakerton <me@fake.com>
ssb   rsa4096 2024-01-12 [E]
ssb   rsa4096 2024-01-12 [A] [expires: 2026-01-11]
ssb   ed25519 2024-01-12 [S] [expires: 2026-01-11]
ssb   rsa4096 2024-01-12 [S] [expires: 2026-01-11]

It lists all of our keys. Take note of the sec line as that’s our Primary Key. Now let’s remove it. There is no way, currently, to delete just the Primary Key. We have to delete all of the keys and then reimport the subkeys. This is where the private-subkeys.asc file we created earlier is used.

gpg --delete-secret-keys {your key ID}
gpg --import private-subkeys.asc

Now let’s look at the output from listing the keys again.

gpg --list-secret-keys

------------------------
sec#  rsa4096 2024-01-12 [SC]
      FE690745891460F5563083F4F98122173492B5C6
uid           [ultimate] Fake McFakerton <me@fake.com>
ssb   rsa4096 2024-01-12 [E]
ssb   rsa4096 2024-01-12 [A] [expires: 2026-01-11]
ssb   ed25519 2024-01-12 [S] [expires: 2026-01-11]
ssb   rsa4096 2024-01-12 [S] [expires: 2026-01-11]

You have to look close but there is a very subtle difference in the output. Our Primary Key is listed as sec# instead of just sec. That little # means the private key is not actually present which is exactly what we want. It’s safe and secure in offline storage. Right? You did actually back it up to a safe place, didn’t you?

If you need the Primary Key in the future to perform any tasks you will need to retrieve it from offline storage (your backup) and import it again temporarily. Be sure to always return it to the offline state.

Change the SubKey Passphrase

With just the subkeys available to us it’s recommended we change the passphrase. If, for some reason, our subkey passphrase is ever hacked the Primary Key passphrase is still safe. This is very simple to do.

gpg --edit-key {your key ID}

In the gpg command we’ll run passwd to change the passphrase.

Secret subkeys are available.

pub  rsa4096/F98122173492B5C6
     created: 2024-01-12  expires: never       usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa4096/65D3D4AD26ACB485
     created: 2024-01-12  expires: never       usage: E
ssb  rsa4096/9FCE7B19DB2B7341
     created: 2024-01-12  expires: 2026-01-11  usage: A
ssb  ed25519/52897C60BFF8FC99
     created: 2024-01-12  expires: 2026-01-11  usage: S
ssb  rsa4096/0DBE743E8CF6D01D
     created: 2024-01-12  expires: 2026-01-11  usage: S
[ultimate] (1). Fake McFakerton <me@fake.com>

gpg> passwd
gpg: key F98122173492B5C6/F98122173492B5C6: error changing passphrase: No secret key

Don’t let the error scare you. The key id the error references is the Primary Key id. It’s telling us it couldn’t change the passphrase on the Primary Key which is exactly what we want. The passphrase for all of our subkeys has now been changed.

Cleanup

DON’T FORGET: This step is SUPER important. DO NOT SKIP IT! Only perform these steps if you have successfully backed up your keys.

With our keys backed up and our Primary Key offline we can cleanup our backups. We don’t want to leave them on our machine because a bad actor may gain access to them. If he or she has our backups they can restore them and it’s game over.

Don’t just delete the files as that will move them to the trash where they can be restored. “I’ll just delete and empty the trash” you say? Here is a better, more secure way to do it.

shred -u --zero private-subkeys.asc
shred -u --zero revoke.asc
shred -u --zero ownertrust.asc
shred -u --zero private-keys.asc

You may have noticed we didn’t delete public-keys.asc. That’s because those are the public keys which we are free to share with others. That file is not a security risk.

Conclusion

At this point all of your keys are generated and backed up. Your Primary Key is offline and safe and all of your subkeys reside on your local machine and are protected by a passphrase that differs from your Primary Key passphrase. You are now in a state where you can perform everyday security procedures like signing commits, encrypting files and using your authentication key for SSH access.

However, you may want to go a step further and actually remove your keys from your machine to a smart card device such as a Yubikey. That is what we’re going to cover in the next post in this series.

References

1. The GnuPG docs recommend creating the revocation immediately after generating a new Primary Key. ↩