YubiKey 5 NFC - HMAC Challenge-Response and FIDO2

YubiKey 5 NFC - HMAC-SHA1 and FIDO2 Hardware Key

On the YubiKey 5 NFC, hardware executes HMAC, not software. The YubiKey 5 NFC stores a secret key in tamper-resistant hardware and computes HMAC-SHA1 challenge-response authentication entirely on-device. Your application sends a 64-byte challenge; the YubiKey returns a 20-byte HMAC-SHA1 response computed using the stored 20-byte secret key¹. Because the secret never leaves the device, an attacker who compromises your application server cannot extract it - the key is physically protected.

Yubico positions the YubiKey 5 NFC as the consumer and enterprise standard, and with approximately $58 USD retail pricing it is the most widely deployed hardware security key in the market as of 2026². It supports HMAC-SHA1 challenge-response in two programmable slots (slot 1 and slot 2), FIDO2/WebAuthn for browser authentication, TOTP and HOTP for time and counter-based OTP, OpenPGP 3, PIV (smart card), and Yubico OTP. The NFC antenna enables tap-based FIDO2 authentication on Android and iOS devices in addition to USB-A; note that HMAC challenge-response requires a physical USB or Lightning connection and does not operate over NFC.

Configure HMAC-SHA1 challenge-response using the Yubico Authenticator app or the YubiKey Manager CLI (ykman). Each slot stores one HMAC secret up to 20 bytes. The challenge-response mode is well-suited for KeePass database encryption, VeraCrypt two-factor authentication, and custom applications that need hardware-bound HMAC without network round trips.

Compared to a software HMAC implementation, the YubiKey provides two guarantees software cannot: the key is stored in hardware that resists physical extraction, and the computation happens in an environment isolated from the host operating system. For threat models that include a compromised OS or stolen disk image, hardware HMAC eliminates the attack vector that software HMAC cannot address.

Specifications²

YubiKey Manager programs and manages challenge-response slots

The ykman command-line tool programs HMAC-SHA1 secrets into either YubiKey slot over USB, and it is the recommended way to provision challenge-response credentials because it handles key generation, slot selection, and verification in a single workflow³. To write a random secret to slot 2, run: ykman otp chalresp -generate 2. The -generate flag creates a random 20-byte key and stores it without displaying the key material to the terminal, which is the safest approach since the secret is never exposed in shell history or log output. Slot 1 activates on a short button press; slot 2 requires a long press of two to three seconds. This distinction matters when slot 1 holds a Yubico OTP configuration, because accidental short presses would produce OTP output rather than a challenge-response interaction.

Choosing a slot for daily use

Select the slot you touch least often for sensitive challenge-response workflows. A long-press requirement reduces accidental activation, which matters when the same key also handles OTP or FIDO2 actions throughout the day and you do not want an unintended challenge-response output mixed in with your regular authentication flow. Programming both slots with different secrets is also possible when you need one slot for daily KeePass access and another for a separate VeraCrypt volume, giving you hardware-enforced separation between two independent encrypted resources on a single physical device.

For resilience, program a second YubiKey with the same HMAC-SHA1 secret using ykman otp chalresp -key <hex_secret> before deploying the primary key. Store the backup key at a separate physical location such as a locked drawer, a safe, or a trusted family member's home. If the primary key is lost or damaged, the backup restores full access without reprovisioning any dependent service, which is the recovery scenario that justifies the extra five minutes of setup time before you start relying on the primary key in production.

For offline password managers and encrypted volumes, HMAC provides hardware-bound protection

For applications that protect a database or volume with hardware challenge-response, the HMAC interaction functions as part of a two-factor unlock: something you know (master password) and something you have (the YubiKey). KeePassXC sends a challenge derived from the database file to the YubiKey and requires the correct HMAC-SHA1 response before allowing access, which means the key derivation process involves both a human-memorized secret and a hardware-protected secret simultaneously⁴. Without the physical key, the database does not open even if an attacker has both the master password and the database file, because the HMAC step cannot be completed without the hardware-stored secret.

Keeping offline access independent from the host

The protection matters most when the host is untrusted. A stolen laptop, infected operating system, or copied disk image still lacks the physical key, so the HMAC step remains outside the compromised environment and the attacker cannot derive the correct response even with full disk access. This threat model is the primary reason organizations deploy hardware-backed HMAC rather than software-stored secrets, because a software secret can be exfiltrated from a running process or a memory dump while a hardware secret cannot.

VeraCrypt can also use a YubiKey for volume protection, though through a different mechanism: Yubico's official guide imports a 64-byte keyfile into the PIV "Printed Information" slot (object 0x5fc109) and configures VeraCrypt to read from that slot⁵. Unlike KeePassXC's HMAC-SHA1 challenge-response, this is a static keyfile approach where the YubiKey acts as a secure storage medium rather than an HMAC computation partner.

Verifying slot output consistency after provisioning and firmware events

Verifying that a YubiKey slot produces consistent output after firmware updates or reprovisioning catches silent configuration loss before it locks you out of dependent systems. Use ykchalresp -2 <hex_challenge> to send a known 64-byte challenge to slot 2 and compare the response against a reference value you recorded at initial setup. HMAC-SHA1 is deterministic: the same challenge always produces the same 20-byte response for the same stored key¹. Any deviation indicates the slot was cleared or reprogrammed.

Recording deterministic reference pairs

Record reference challenge-response pairs for all deployed keys, and work out the expected HMAC-SHA1 response yourself so a known-good value exists before you ever touch the physical key, then run the comparison check after any ykman operation that modifies slot configuration. Store at least three challenge-response pairs per slot in a secure location separate from the YubiKey itself, because if a firmware update or accidental reprovisioning clears the slot, these reference pairs are the only way to confirm whether the key material changed. A fixed challenge such as 64 bytes of zero produces a deterministic response that serves as a fingerprint for the stored secret, making it trivial to detect silent configuration loss before it causes an authentication failure in production.