Essay 11 / Digital

[YubiKey - OpenPGP] A Token Is Not the Secret

Use a hardware token for daily OpenPGP operations, preserve a tested key backup, and plan account recovery before losing the device.

An open shared-tool cupboard with used hand tools, blank loan tags, an empty hook and maintenance supplies.
Shared access depends on shared care. An original illustrative scene.

An OpenPGP hardware token protects private subkeys during daily use. Signing, decryption, and authentication happen on the device, which does not provide a private-key export. If you lose the device, recovery depends on a backup made before the keys were imported, or on another device provisioned with those keys.

This article covers OpenPGP subkeys on a YubiKey. Keep the certification primary offline, as described in Keep the Secret Off the Machine. Generate and back up the operational subkeys before moving them to the card. Keys generated directly on the card cannot be backed up as files.

Configure the card before importing keys. Change the factory OpenPGP User PIN (123456) and Admin PIN (12345678), and set a Reset Code. Enter credentials through interactive prompts. ykman openpgp reset and ykman piv reset erase their respective applications, including stored keys; they are recovery or reprovisioning operations, not routine initialization.

Basics Β· Separate key protection from recovery

The computer sends an operation to the card rather than reading its private key. The PIN authorizes access. A configured touch policy requires physical interaction for key use; it does not tell you whether the requested operation is legitimate.

Neither PIN nor touch provides recovery. Without a backup of the encryption private key, losing the card can make existing encrypted data unreadable. An offline primary lets you issue replacement subkeys, but it cannot reconstruct a lost encryption private key.

Identify the application you are using

A YubiKey can support several applications. Availability depends on the model. Their credentials and recovery procedures are separate:

YubiKey
β”œβ”€β”€ OpenPGP
β”‚   β”œβ”€β”€ User PIN
β”‚   β”œβ”€β”€ Reset Code
β”‚   └── Admin PIN
β”œβ”€β”€ PIV
β”‚   β”œβ”€β”€ PIN
β”‚   β”œβ”€β”€ PUK
β”‚   └── Management Key
β”œβ”€β”€ FIDO2
β”œβ”€β”€ OATH
└── OTP
  • OpenPGP: signing, decryption, and authentication through GnuPG.
  • PIV: certificate-based smartcard authentication, with its own PIN, PUK, and management key.
  • FIDO2 / U2F: authentication to websites and other compatible services. Recovery depends on the credentials and recovery methods enrolled with each service.

A FIDO-only token cannot hold these OpenPGP subkeys. Inspect the OpenPGP application rather than assuming that any signing key is on the device:

gpg --card-status
gpg --list-secret-keys --fingerprint

ssb> means that GnuPG refers to a subkey on a smartcard. ssb means private subkey material is available locally. The card reference describes this keyring; it does not establish that no file backup or other local copy exists.

Expert Β· Inspect the device and configure access

Inspect the device before changing its configuration. Record its model, serial number, firmware, and supported key algorithms. Confirm that the chosen subkeys are compatible:

ykman list
ykman info
ykman openpgp info
ykman piv info
gpg --card-status

The OpenPGP User PIN authorizes key use. The Admin PIN controls administrative operations. The Reset Code can unblock the User PIN. Change credentials in GnuPG’s interactive menu:

gpg --card-edit
gpg/card> admin
gpg/card> passwd
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code

Set retry limits deliberately. On YubiKey NEO, changing them resets the PINs to factory defaults; change those PINs again afterwards. Yubico API reference. This example allows five User PIN attempts, three Reset Code attempts, and six Admin PIN attempts. Verify the displayed counters:

ykman openpgp access set-retries 5 3 6
ykman openpgp info
gpg --card-status

The expected order is User PIN / Reset Code / Admin PIN: 5 3 6. A blocked User PIN can be reset with the appropriate recovery credential. If administrative access is blocked and the application must be reset, its stored keys are erased.

Require touch for signing, decryption, and authentication. Use on so the policy remains configurable. Check the encryption-slot name accepted by your installed ykman; releases may use dec or enc. Reapply and verify the policies after importing the keys. YubiKey Manager OpenPGP reference.

ykman openpgp keys set-touch sig on
ykman openpgp keys set-touch dec on
ykman openpgp keys set-touch aut on
ykman openpgp info

If you also use PIV, configure it separately. Its factory PIN is 123456 and PUK is 12345678; change those and the default management key. Changing PIV retry limits resets the PIN and PUK to factory values, so set those limits first.

For the PIV management key, either store a random key securely outside the device using an algorithm supported by its firmware, or use ykman piv access change-management-key --protect to generate and store a PIN-protected key on the device. These options manage PIV access; neither backs up OpenPGP keys. YubiKey Manager PIV reference.

ykman info
ykman openpgp info
ykman piv info
gpg --card-status

Test the backup before moving subkeys

A card cannot export an imported OpenPGP private key. Complete these steps before relying on it:

  1. Export the primary and subkey private material to encrypted media.
  2. Restore the backup in a separate trusted keyring and test the required operations. A /dev/shm keyring alone does not make the computer offline or prevent swapping.
  3. Configure the card’s credentials and retry limits.
  4. Transfer the operational subkeys with keytocard.
  5. Reapply touch policies. Confirm sec# and ssb> in the daily keyring.
  6. Test the card, then disconnect it and test recovery from the backup or a second provisioned card.

Keep the encrypted backup separate from the token. Without a tested recovery path, the token remains a single point of failure.

Expert Β· Transfer each subkey to its matching slot

Use your full primary fingerprint. Check the actual subkey order before selecting an index. Work from the subkey-only keyring so the primary stays offline. Do not overwrite existing card slots unless their replacement is intentional and recoverable.

gpg --edit-key E6B0933DD47E3B2F823334F0A567B3B17C27BF6D
gpg> key 1
gpg> keytocard
Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1

key N toggles selection. Deselect the current subkey before selecting the next one. Move the signing subkey to the signature slot, the encryption subkey to the decryption slot, and the authentication subkey to the authentication slot. Verify each selection and use save when finished.

Reapply touch policies and inspect the card:

ykman openpgp keys set-touch sig on
ykman openpgp keys set-touch dec on
ykman openpgp keys set-touch aut on
ykman openpgp info
gpg --card-status

The daily keyring should show an unavailable primary and card-backed subkeys. This output is illustrative:

sec#  rsa8192/A567B3B17C27BF6D  created: 2020-01-12  expires: never
ssb>  rsa4096/51D88833772723AD  created: 2020-01-12  expires: 2030-01-12
                                card-no: 0000 00000000
ssb>  rsa4096/8C7587C86EAC2F2F  created: 2020-01-12  expires: 2030-01-12
                                card-no: 0000 00000000
ssb>  rsa4096/D13AE6B65E8BE723  created: 2020-01-12  expires: 2030-01-12
                                card-no: 0000 00000000

With the card connected, sign, encrypt, and decrypt a non-sensitive test file. Replace the recipient with your own test identity:

gpg --encrypt --sign --armor -r something@something message.txt
gpg --decrypt message.txt.asc

Test authentication against an isolated account if you use the authentication subkey. Then disconnect the original card. On another trusted machine or in an isolated keyring, import the backup and repeat signing and decryption of the same test file. Verify the signature and recovered content. If recovery uses a second card, test it with the first card disconnected.

Plan recovery for each application

Keep the primary backup and revocation certificates accessible without the daily token. If the token is lost, revoke affected OpenPGP subkeys as appropriate and distribute the updated public certificate. A replacement subkey can restore future use; only the old encryption private key can decrypt data encrypted to it.

For FIDO accounts, register a second authenticator or another supported recovery method before losing the first. Enrol the spare separately with each service. Copying OpenPGP subkeys onto it does not duplicate FIDO credentials. Check recovery for the registrar, mailbox, and Git host individually.

FIDO authentication provides phishing resistance through its binding to the service. OpenPGP authentication and touch confirmation do not provide that same property. SMS-based recovery can be vulnerable to account takeover and SIM swapping; prefer a spare authenticator or offline recovery codes when available.

Intermediate Β· Start with the functions you need

You do not need to adopt every application at once. Start with FIDO for important web accounts and enrol a spare. Add OpenPGP only if you need its signing, encryption, or authentication functions. Before transferring existing keys, verify algorithm support and backup recovery. Configure PIV when you have a specific certificate-based authentication requirement.

Verify recovery without the original token

Disconnect the daily token. Confirm that the documented backup can decrypt an existing test file and produce a valid signature. Check that a separately enrolled authenticator or recovery method can restore access to each important account. Record the steps and repeat the checks after changing keys or account credentials.

Next essay β†’Back to the beginning ↑