← Privacy Guides

Encryption

Hardware-backed keys: keep the secret off the disk

Move your encryption, signing and login keys onto a hardware security key so the secret never touches the disk, generate the long-term key offline, and protect it with a PIN and a physical touch — with a tested backup so one lost key does not lock you out.

  • High threat
  • Time Half a day, including generating keys on an offline machine and setting up a backup key
  • Difficulty Advanced
  • Last verified against 0 YubiKey 5 series, firmware 5.2.3 or later (ECC support for the OpenPGP application)

What this protects, and what it doesn't

Protects

  • Against a key stolen off the disk: when the private key lives in the hardware chip, malware or a seized disk cannot copy it. NIST SP 800-57 and SP 800-63B treat a key that "cannot be removed from the device" as the strong case.
  • Against a cloned or imaged machine: a key that exists only inside a security key is not in any backup, snapshot or memory dump of the computer.
  • Against silent use: with a touch policy set, each signing, decryption or login needs a physical tap on the key, so malware cannot use it in the background while it is plugged in.
  • Against a weak or reused login secret standing in for the key: a PIN unlocks the hardware, but the PIN alone is useless without the physical device.

Does not protect

  • It does NOT protect data after you unlock. Once you touch the key and decrypt a file or authenticate a session, a compromised host sees the plaintext, the open session and anything you do with it. Hardware keys protect the key, not the running machine.
  • It does NOT help if you lose the only key with no backup. A key generated on a FIDO2 authenticator cannot be exported; if that is your only device and it breaks or is lost, the accounts bound to it, and anything encrypted only to it, are gone.
  • It does NOT stop coercion. Someone who can make you enter the PIN and touch the key gets the same access you would.
  • It does NOT secure the backup by itself. An off-card backup of a key, or the offline machine you generated it on, is now a copy of the secret and must be guarded like the key.
  • It does NOT make you anonymous. It is about key custody, not hiding who you are or what you send.

Prerequisites

  • A written threat model (see the "Threat modeling: start here" guide). Hardware-backed keys are a High-threat measure and are only worth the effort if a capable adversary is in your model.
  • At least two hardware security keys of the same kind: one to use and one to keep as a backup. One key is a single point of failure.
  • For an offline key: a computer you can take fully off the network (ideally one that never goes back online), removable media for transfer, and a safe place to store an offline backup and its passphrase.
  • Comfort with a command line (GnuPG, ykman, or age), and the vendor documentation for your specific key open while you work.

Step by step

  1. Know the three open standards you will use

    "Hardware-backed" is not one product. Three open standards cover almost every case, and a single security key often speaks all three:

    • FIDO2 (WebAuthn + CTAP) for website and app login. The FIDO Alliance describes it as "standard public key cryptography" that is phishing-resistant, where the credential "can only be exercised by the user with a biometric or PIN". The key pair is created on the authenticator.
    • The OpenPGP card for email/file signing and decryption and for SSH. GnuPG talks to it with gpg --card-edit. The private key lives in the card; your keyring keeps "only a pointer indicating that it's stored on a smart card".
    • PIV (smart-card certificates) for certificate-based login and, through the age-plugin-yubikey project, for file encryption with age: "files to be encrypted to age identities stored on YubiKeys".

    Pick the standard that matches the job. The rest of this guide shows each one, and the two custody choices that apply to all of them: generate offline, and protect with PIN plus touch.

  2. Decide: key generated on the device, or generated offline and imported

    There are two ways a key ends up on the hardware, and they trade off against each other:

    • Generated on the device. The secret is created inside the chip and, by design, can never leave it. This is the strongest custody — NIST SP 800-63B requires that a single-factor cryptographic device's keys "SHALL NOT be exportable (i.e., cannot be removed from the device)". FIDO2 credentials always work this way. The cost: there is no backup of that exact key. If the device dies, you must have a second device already enrolled.
    • Generated offline, then imported. You create the key on an air-gapped machine, keep an encrypted offline backup, then copy it onto the hardware. This lets you restore the same key onto a replacement device, at the cost of a backup copy you must guard forever.

    Use on-device generation for login (FIDO2) and for signing keys you can simply re-issue. Use offline generation for an encryption key, where losing the key means losing access to everything ever encrypted to it.

  3. Generate the long-term key on an air-gapped machine

    When you need a backup of the key (typically your OpenPGP encryption key), generate it on a computer that is disconnected from all networks, so the secret is never exposed to an online system.

    • Boot a clean, offline system. Disconnect Wi-Fi and unplug the cable before you start, and keep it off the network for the rest of this step.
    • Create the key pair there with GnuPG. Yubico's OpenPGP guide generates a key with gpg --gen-key and, for an authentication subkey, uses gpg --expert --edit-key <KEYID> then addkey.
    • A common stronger layout keeps the primary key offline and puts only day-to-day subkeys on the hardware, so the primary can certify a replacement if a device is lost.
    • Pick current, strong key parameters per the GnuPG documentation for your version. (Older Yubico pages show RSA 2048 examples; do not treat an example size as a recommendation — check what your key and GnuPG support today.)

  4. Make and store the offline backup before anything else

    Back up the offline key before you move it to the hardware, because once it is on the card you cannot read it back out.

    • Export the secret key: Yubico's guide uses gpg --export-secret-key --armor <KEYID> and advises, in its words, to "store the backup offline in a secure place".
    • Store that export on encrypted removable media (see the full-disk-encryption guide), kept physically separate from the hardware key. Guard it like the key itself — anyone with the backup and the passphrase has the key.
    • If you instead let the card generate the encryption key, GnuPG's generate command offers "Make off-card backup of encryption key? (Y/n)" and defaults to yes; it writes a copy into your .gnupg directory, which you must then move to separate storage and securely delete the on-disk copy. Say yes for an encryption key, or you can never recover data if the card is lost.

  5. Move the key onto the OpenPGP card

    With the backup made, transfer the key to the hardware. Yubico's OpenPGP guide uses keytocard inside gpg --edit-key <KEYID>:

    gpg --edit-key <KEYID>
# select each subkey with: key N
# then: keytocard  (choose the matching slot: signature / encryption / authentication)
# then: save
    • After save, Yubico notes the local keyring holds "only a pointer indicating that it's stored on a smart card" — the real secret is now on the card.
    • Confirm with gpg --card-status, which should list the key fingerprints as present on the card.
    • Do this on the air-gapped machine if the key is your long-term one; only the pointer and the public key need to reach your everyday computer.

  6. Set a PIN and require a physical touch

    A key on the hardware is only as good as the two gates in front of it: the PIN that unlocks it, and the touch that proves a human is present for each use.

    • Change the default PINs. OpenPGP cards ship with a default user PIN and admin PIN; change both (for example with passwd inside gpg --card-edit). Never keep the factory values.
    • Require touch for OpenPGP operations. Yubico's ykman sets this: ykman openpgp keys set-touch KEY POLICY, where KEY is sig, enc, aut or att. Policies: on (touch for each use), fixed (touch required and it "can't be turned off without deleting the private key"), cached (touch remembered for 15 seconds), and the default off. For a High threat model use on or fixed.
    • Check the current state with ykman openpgp info.
    • For FIDO2 and PIV, set the PIN and touch policy at enrolment time (FIDO2 PIN) or when you generate the PIV/age key.

  7. FIDO2 login keys: generated on the device, so enrol a second one

    FIDO2 (passkeys on a security key) is the login case. The key pair is created on the authenticator and the private key is never exported — which is exactly why it has no backup.

    • Register your security key as the second factor, or as a passkey, on each important account. The FIDO Alliance notes the credential "can only be exercised by the user with a biometric or PIN" and is phishing-resistant by design.
    • Register your backup key on every account at the same time. There is no way to copy a FIDO2 credential between keys, so if you do not enrol the spare now, a lost key can lock you out permanently.
    • Keep a few one-time recovery codes from each account offline, as a last resort if both keys are unavailable.

  8. File encryption on hardware with age + PIV (optional)

    If you want files encrypted to a key that lives on the hardware rather than a passphrase, age-plugin-yubikey stores an age identity in the YubiKey's PIV applet.

    • Generate the identity on the key with age-plugin-yubikey --generate, which "accepts PIN and touch policy options" per its project page. The secret stays in the PIV slot; you distribute only the public recipient string.
    • It supports the YubiKey 4 and 5 series (not the NEO) and works with the age and rage clients.
    • Because this key cannot be exported either, the same rule applies: generate a second identity on your backup key and encrypt files to both recipients, so one failed key does not lock the files.

  9. Verify the secret really moved, and test the backup

    Do not trust the setup until you have checked both ends of it.

    • Confirm the secret is on the hardware. For OpenPGP, gpg --card-status shows the key on the card and gpg -K should show it as a card-backed (stub) key, not plain secret material on disk.
    • Confirm nothing is left on disk. On your everyday machine, make sure no exported secret key or .gnupg backup copy remains; securely delete any transfer copies.
    • Test the backup key for real. Unplug the primary and authenticate, sign, or decrypt with the backup — on the actual accounts and files. A backup you never tested is not a backup. For an offline OpenPGP key, do a dry-run restore of the encrypted export onto a spare device.
    • Write down, in your password manager, which key is primary, which is backup, what each is enrolled on, and where the offline backup and its passphrase live.

Common mistakes

  • Owning only one hardware key. When it breaks or is lost, FIDO2 credentials and on-device keys are gone for good. Buy and enrol a backup before you rely on the first.
  • Generating a long-term encryption key on an online computer, so a copy of the secret existed on a networked machine before it reached the hardware.
  • Leaving the exported backup, or the off-card backup GnuPG wrote into .gnupg, sitting on the everyday disk instead of moving it to separate encrypted storage and securely deleting the copy.
  • Keeping the factory default PINs, or leaving the touch policy off, so a plugged-in key can be used silently by malware or by anyone who grabs the PIN.
  • Believing the hardware protects your data. It protects the key. After you touch the key and decrypt, a compromised host reads everything.
  • Never testing the backup key, then discovering on the day it is needed that it was never enrolled.

Going further

For the strongest layout, keep your OpenPGP primary (certification) key offline and put only sign, encrypt and authenticate subkeys on the hardware, so the offline primary can certify a replacement key if a device is lost. Pair hardware keys with full-disk encryption and a solid threat model — see the "Full-disk encryption" and "Threat modeling" guides. Security keys can also hold your SSH authentication key (through the OpenPGP or FIDO SSH key support), so your server logins are hardware-backed too. If you operate at AAL3 in NIST terms, note that SP 800-63B requires "a hardware-based authenticator" together with a verifier-impersonation-resistant (phishing-resistant) one — which FIDO2 provides.