FIDO2 keyslots

YubiKey, Google Titan, Nitrokey, Windows Hello - hardware-backed unlock.

FIDO2 keyslots use the CTAP2 hmac-secret extension to derive a deterministic per-credential secret from your hardware authenticator. That secret derives the wrap-KEK that unlocks the vault.

Supported devices

LUKSbox treats every CTAP2 + hmac-secret authenticator the same way at the protocol level. We split the device list into what we have actually exercised end-to-end in our lab and what should work by spec but we have not yet personally tested.

Tested in our lab

These are exercised end-to-end (enroll -> unlock -> revoke -> re-enroll) on the example binaries under crates/luksbox-fido2/examples/ on every release that touches the FIDO2 path.

Planned / expected to work but not yet exercised

Anything CTAP2-compliant with the hmac-secret extension should work even if it's not in either table, those are the only protocol features LUKSbox actually requires. If your device produces cred IDs above 352 bytes, file an issue and we'll bump the cap (no production device we know of exceeds 300 B). If you successfully use a device that's not in either table, please tell us so we can move it to the "Tested" row in the next release.

Two FIDO2 modes, and the backup-passphrase nuance

LUKSbox exposes two SlotKind values for FIDO2 enrollments:

The interesting question is what a backup keyslot does to each mode. Both modes can have other keyslots added to the same vault; those slots wrap the same MVK under their own KEKs. Once any passphrase slot exists, the offline-disk-stolen attack surface is identical between the two modes:

So the design rule is:

• Pick Fido2HmacSecret for the conventional setup (multi-slot, recoverable). Adding a passphrase or second-device backup AFTER create is the standard pattern.
• Pick Fido2DerivedMvk without a backup if the no-wrapped-MVK property matters more than recoverability, for example, an ephemeral or high-paranoia vault where the cost of losing the vault is acceptable.
• Filling the backup-passphrase field on FIDO2-direct silently removes the no-wrapped-MVK property. A passphrase keyslot is enrolled after the vault is created, wrapping the same MVK under a passphrase-derived KEK; the on-disk attack surface then matches Fido2HmacSecret + passphrase backup. The GUI's create form spells this out next to the field; the wizard prompts for explicit confirmation. We surface the trade-off because it's a silent demotion of the slot's strongest property, not because having a backup is wrong.

Choosing a hardware key

LUKSbox treats every CTAP2 + hmac-secret authenticator the same way at the protocol level. The choice between vendors is a function of price, maturity, public audit history, NFC support, and whether the vendor's silicon is known to have a published side-channel attack against an obsolete firmware. The table below is a snapshot from 2026; prices are EUR approximations from the vendors' official EU stores and do not include shipping or VAT where applicable. Always check the vendor's current page for the authoritative number.

What we'd pick (and why)

• Cheapest acceptable single device: a current-firmware Yubico Security Key Series with NFC (USB-A "Security Key NFC" or USB-C "Security Key C NFC"). around €29-€35. Same Infineon silicon and same FIDO2 stack as the full YubiKey 5; the only thing missing is the protocols LUKSbox doesn't use. Vendor maturity is identical to YubiKey 5 (it's the same vendor and the same firmware family). This is the device we'd hand to a non-technical user without caveats.
• Cheapest non-Yubico alternative: a Google Titan v2/v3 USB-C (around €35, NFC on most variants). Different silicon family from Yubico, which is exactly the property you want for the second slot of a multi-vendor pair.
• Daily driver if you also use other tools: a current-firmware YubiKey 5 NFC. Worth the price premium over Security Key Series ONLY if you're also paying for PIV / OpenPGP / OATH / YubiOTP for tools outside LUKSbox. For LUKSbox alone the Security Key Series is the same protocol surface at half the price.
• Open-firmware preference: a Nitrokey 3 (NFC variant if you need it). German vendor, Rust firmware, smaller deployment than Yubico but actively maintained.
• Multi-vendor backup pair: enroll two different vendors' devices into the same vault. Recommended for high-value vaults: if a side-channel attack is later disclosed against one silicon family, the other slot still protects you. A common pairing is Yubico Security Key + Google Titan v2, or YubiKey 5 + Nitrokey 3. Note that pairing two Yubico devices (Security Key + YubiKey 5) does NOT give you silicon-family independence, they share the same Infineon SE.
• What to avoid for daily-driver use: USB Armory + custom firmware (use case is research, not "encrypt my files"); any device whose firmware you can't update and whose vendor has not publicly responded to the 2024 EUCLEAK / 2021 Side Journey to Titan advisories. Pre-2024 Yubico (FW < 5.7.0, both Security Key Series and YubiKey 5) and 2018-2021 USB-A Google Titan are the two "replace it" cases.

General principles

• A current-generation hardware key is meaningfully better than no hardware key, and meaningfully better than a 2018-vintage one. Side-channel attacks documented in docs/HARDWARE_SIDE_CHANNEL_NOTES.md all require continuous physical possession + lab equipment; none is remote.
• Pair two different vendors' devices in any vault you care about. The cost is one extra €30-€40 device; the upside is independence from any single silicon family's failure mode.
• NFC is worth paying for if you have a phone or tablet you also want to authenticate from. Without NFC the device is USB only.
• Pin counters are part of the security story. Every modern authenticator wipes the credential after a low number of wrong PIN attempts (typically 8). A device-without-PIN is meaningfully weaker; LUKSbox respects whatever PIN policy the device enforces.
• The hybrid-PQ keyslot is the easiest defence-in-depth to layer on: any future side-channel cloning of one of your FIDO2 devices alone doesn't unlock the vault, the attacker also needs the .kyber seed file. See post-quantum keyslots.

Vendor security-advisory feeds (subscribe to these)

Hardware-key vendors publish CVE-style advisories on their own schedules. Subscribe / bookmark the right page per device you own; the headline 2024-2026 items per vendor are summarised below.

Operational note for LUKSbox users: the LUKSbox project does not re-publish vendor advisories, we don't have visibility into silicon supply chains. We do track the upstream libfido2 library for advisories that affect our Linux/macOS FFI link path, and we update the bundled version on the next release after any relevant upstream fix lands. Windows builds talk to webauthn.dll directly and do not link libfido2, so libfido2-specific advisories (YSA-2026-01 above) only affect the Linux/macOS surface.

Enroll a hardware key

For an existing vault:

luksbox enroll my-vault.lbx --fido2
# Touch the device when prompted (TWICE: once for makeCredential,
# once for getAssertion).

For a fresh FIDO2-only vault:

luksbox create my-vault.lbx --kind fido2
# Same two-touch enrollment + you'll be asked for a backup passphrase.

Multi-device setup

Best practice for any vault you care about:

# Day-1 setup with primary YubiKey
luksbox create my-vault.lbx --kind fido2 --fido2-device /dev/hidraw3

# Add a backup YubiKey kept in a safe deposit box
luksbox enroll my-vault.lbx --fido2 --fido2-device /dev/hidraw4

# Add an emergency passphrase as the third slot
luksbox enroll my-vault.lbx --passphrase

Use luksbox list-fido2-devices to see the path strings to use with --fido2-device. This matters when more than one authenticator is plugged in (otherwise libfido2 picks the first one it sees, which might not be the one you meant).

Windows Hello

luksbox create my-vault.lbx --kind fido2 --fido2-device windows://hello

Routes through webauthn.dll. The OS prompts for your PIN / fingerprint / face. Behaves identically to a hardware key from LUKSbox's perspective - same hmac-secret derivation, same wrap.

Unlocking

luksbox open my-vault.lbx -m /tmp/v --fido2
# Touch your key once.

If your vault has multiple FIDO2 slots and multiple devices are plugged in, LUKSbox tries each slot in turn until one device returns a matching cred_id. Devices that don't have the credential return FIDO_ERR_NO_CREDENTIALS immediately (no touch needed); the matching device prompts for a touch.

What happens cryptographically

For the full enroll + unlock ceremony with sequence diagrams, see docs/CRYPTO_SPEC.md Section 19 in the source repository. Short version:

enroll:  (cred_id, hmac_secret) <- device (2 touches)
         KEK = Argon2id("lbx:fido" || passphrase || hmac_secret, salt)
         wrapped_ct, tag = AEAD_seal(KEK, MVK)
         store: cred_id, hmac_salt, wrapped_ct, tag

unlock:  hmac_secret <- device (1 touch, with cred_id + hmac_salt)
         KEK = Argon2id(...)  # same inputs as enroll
         MVK = AEAD_open(KEK, wrapped_ct, tag)

The hmac_secret is deterministic - same (cred_id, salt) always returns the same 32 bytes from the same device. That's what makes the unlock reproducible without storing the secret anywhere.

Hardware-side risks (what LUKSbox can't fix)

Public security research has demonstrated physical-possession side-channel attacks that extract the secret material from specific FIDO2 silicon. These are the two most impactful published attacks:

• NinjaLab "A Side Journey to Titan" (2021): EM side-channel against ECDSA on the NXP A700X chip used in original USB-A Google Titan keys (sold 2018-2021). 10 hours of physical access

  • lab equipment recovers the long-term private key for one FIDO account, enabling device cloning. Paper | Project page

• NinjaLab EUCLEAK (2024): Timing + EM side-channel against ECDSA in Infineon's crypto library, used by all YubiKey 5 series with firmware before 5.7.0 (sold 2017 to May 2024). A few minutes of EM measurements can extract the ECDSA private key. The same Infineon library ships in many TPMs, smart cards, and crypto hardware wallets. Project page | Plain-English summary

Practical takeaway:

LUKSbox's threat model explicitly delegates secure-element security to the device vendor (see Threat model and CRYPTO_SPEC.md Section 19.5). There is no host-side defence against an attacker who can extract the per-credential master from a physical device. What we DO offer:

• The device's PIN counter (typically wipes after 8 wrong attempts) still protects against an attacker who has the device but not the PIN.
• Multi-keyslot vaults limit the damage of single-device compromise.
• Hybrid-PQ FIDO2 keyslots add a .kyber seed file as a second factor that physical-possession-of-the-device alone doesn't satisfy.
• luksbox rotate-mvk makes any previously-extracted MVK useless against the vault going forward.

Bottom line: a current-generation hardware key is meaningfully better than no hardware key, and meaningfully better than a 2018-vintage one. For the full per-paper writeup + per-vendor status matrix, see docs/HARDWARE_SIDE_CHANNEL_NOTES.md in the source repository.