↓ Skip to main content
Le Site de François
  1. Index/

FIDO (Fast IDentity Online) / FIDO2

Security Authentication Cryptography Pki Webauthn Mfa Zero-Trust

FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.

The protocol architecture has three participants. The Relying Party (RP) is the application or service requesting authentication — a web server, an identity provider, or a native application. It calls the WebAuthn API to initiate two ceremonies: registration (navigator.credentials.create() — the RP sends a challenge, allowed algorithms, RP ID, and attestation preference; the authenticator generates a new key pair, stores the private key in its secure element, and returns the public key, credential ID, and optional attestation statement; the RP stores the public key and credential ID) and authentication (navigator.credentials.get() — the RP sends a fresh challenge and the credential ID; the authenticator performs user verification, signs the challenge and authenticator data with the stored private key, and returns the signed assertion; the RP verifies the signature with the stored public key). The client is the browser or OS layer that calls CTAP2 to communicate with the authenticator. The authenticator is the hardware or platform component that holds private key material — either a platform authenticator (Touch ID, Face ID, Windows Hello, Android biometric — built into the device and not accessible over USB/NFC/BLE) or a roaming authenticator (YubiKey, Google Titan, SoloKey — a portable hardware token connected over USB, NFC, or BLE, implementing the CTAP2 protocol; on Linux, accessed via libfido2). Private keys generated inside an authenticator’s secure element never leave it in plaintext; authentication requires both the key and local user interaction — a PIN, biometric, or touch confirmation that proves user presence or user verification.

Three operational concepts define how FIDO2 is deployed in practice. Discoverable credentials (passkeys) store the credential on the authenticator indexed by RP ID and user ID so that no username need be typed — the authenticator can surface which accounts it holds for a given origin and begin authentication without a username prompt. Discoverable credentials on hardware security keys consume on-device storage (typically 25–100 slots depending on the model); synced passkeys replicate the credential via a platform cloud (iCloud Keychain, Google Password Manager, Windows Hello with Microsoft account), solving account recovery for consumer flows at the cost of the key leaving the hardware boundary — NIST considers synced passkeys single-factor since the cloud account becomes a recovery path. Attestation is the authenticator’s signed statement about its own model and manufacturer, rooted in the FIDO Metadata Service (MDS) — a FIDO Alliance registry of authenticator models, their public keys, and any known vulnerabilities. A RP that enforces attestation can verify not just that a valid credential was used, but that it was generated on a specific, certified hardware model (e.g., YubiKey 5 Series), enabling hardware-bound credential policies for high-assurance deployments; the attestation certificate’s AAGUID (Authenticator Attestation GUID) uniquely identifies the authenticator model. SSH integration is covered in the SSH entry: the ed25519-sk and ecdsa-sk key types bind an SSH key pair to a FIDO2 hardware token so that SSH authentication requires physical presence of the token, with the private key resident on the hardware and never extractable. In the PAM context, FIDO2 hardware tokens replace or complement TOTP and push MFA as the phishing-resistant factor for privileged access; in a break-glass scenario, hardware token loss is the primary recovery concern, making spare token pre-registration and recovery code procedures an essential operational requirement alongside the tokens themselves.

Related

HMAC (Hash-based Message Authentication Code)

Cryptography Security Integrity Authentication Primitives
HMAC (Hash-based Message Authentication Code), standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a Message Authentication Code (MAC) by combining a cryptographic hash function with a shared secret key. A plain hash function provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key K can produce a valid HMAC(K, message), and only a party who knows K can verify it. The construction is HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)) — two rounds of hashing with the key XOR’d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive H(K ∥ m) constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.

HSM (Hardware Security Module)

Security Hardware Cryptography Key-Management Pki Fips
A Hardware Security Module (HSM) is a purpose-built, tamper-resistant hardware device that holds cryptographic keys and performs cryptographic operations — signing, encryption, decryption, random number generation — entirely within its own protected boundary. The defining property is that private keys generated inside an HSM never exist in plaintext outside it: operations that need the key are sent into the HSM and the result is returned, but the key material itself cannot be extracted. This property is enforced both logically (the firmware refuses export in plaintext) and physically (the device detects and responds to tampering by erasing key material before an attacker can read it). HSMs come in several physical forms: network-attached appliances (rack-mounted devices accessed over the network by many clients), PCIe cards (embedded in a server), and compact USB devices for lower-throughput use cases like protecting CA root keys offline.

OpenPGP / GPG

Cryptography Security Signing Pki Supply-Chain Email
OpenPGP is an open standard for encryption and digital signatures of arbitrary data, defined in RFC 4880 (2007) and substantially revised in RFC 9580 (2024, adding Ed25519, X25519, and modern AEAD encryption). GnuPG (GPG) is the dominant open-source implementation, maintained by Werner Koch and the GnuPG project, and the tool most users interact with. OpenPGP predates the PKI/CA model and takes a fundamentally different approach to trust: rather than a hierarchy of certificate authorities that users must trust transitively, OpenPGP uses a Web of Trust in which individual users sign each other’s public keys, and trust is established through chains of personal endorsements. In the Web of Trust model, Alice trusts Bob’s key because she verified it in person and signed it; Carol trusts Bob’s key because Alice (whom Carol trusts) signed it. This decentralised, peer-to-peer trust model made sense for email encryption between individuals who could meet at key-signing parties, but does not scale to automated infrastructure verification, which is why OpenPGP’s role in modern infrastructure is primarily supply chain signing — package repositories, Git commits, and release artifacts — rather than interactive authentication.