FIDO2 CBOR Attestation Parser

Understanding FIDO2 Attestation

FIDO2 attestation is the process by which an authenticator (security key, platform authenticator) proves its identity to a relying party during registration. The attestation object contains the credential public key, signed by an attestation key that chains to a manufacturer root certificate. This allows the relying party to verify that the credential was created by a genuine authenticator from a trusted manufacturer.

authData Structure Breakdown

The authenticator data (authData) is a binary blob with a fixed structure. The first 32 bytes are the SHA-256 hash of the Relying Party ID (e.g., the hash of "example.com"), which the server compares against its expected RP ID hash to confirm the credential was created for the correct origin. The flags byte indicates what happened during authentication: bit 0 (UP) means user presence was verified (user touched the security key), bit 2 (UV) means user verification (biometric or PIN) was performed, bit 6 (AT) means attested credential data (AAGUID, credential ID, public key) is included, and bit 7 (ED) means extension data is present. The 4-byte signature counter is a replay protection mechanism — it should increment with each assertion, and the server should reject if a counter value is lower than a previously seen value for that credential.

Attestation Formats and Trust Model

The fmt field determines how the attestation statement is structured. packed is the most common format for FIDO2 security keys — it uses COSE-encoded signatures with an optional X.509 certificate chain. tpm is used by Windows Hello with TPM-backed authenticators, carrying TPM-specific structures (TPMS_ATTEST, TPMT_SIGNATURE). u2f is the legacy U2F format used by older YubiKeys — it uses a simple ECDSA signature over the credential public key, challenge, and RP ID hash. android-key and android-safetynet are used by Android platform authenticators. apple is used by iCloud Keychain and Touch/Face ID. none indicates no attestation — the relying party cannot verify the authenticator's authenticity but still gets a valid public key.

AAGUID and Authenticator Identification

The AAGUID (Authenticator Attestation GUID) is a 128-bit UUID that identifies the authenticator model. During registration, the relying party can look up the AAGUID in the FIDO Metadata Service (MDS) to determine the authenticator's capabilities (biometric support, TPM-backed, transport protocol), certification level (L1, L2, L3), and security status (whether it has been revoked or compromised). Our parser includes a built-in lookup table for common authenticators (YubiKey, SoloKeys, Feitian, Windows Hello, Chrome, Apple). When building a WebAuthn server, use the MDS to validate that the AAGUID corresponds to a certified authenticator and to enforce policy (e.g., only allow L2+ authenticators for high-value transactions).

COSE Key Encoding in FIDO2

The credential public key in FIDO2 is encoded as a COSE_Key — a CBOR map with numeric keys. Key 1 (kty) is the key type: 2 for Elliptic Curve (EC2), 3 for RSA, 1 for Octet Key Pair (OKP, used by Ed25519). Key 3 (alg) is the algorithm: -7 for ES256 (ECDSA with P-256 and SHA-256), -257 for RS256 (RSASSA-PKCS1-v1_5 with SHA-256). For EC2 keys, key -1 (crv) specifies the curve (1=P-256, 2=P-384, 3=P-521), keys -2 (x) and -3 (y) contain the public coordinates. The server stores this COSE_Key and uses it to verify assertion signatures during authentication. ES256 (P-256) is the most widely supported algorithm across authenticators and is the recommended default for new applications.

Signature Counter and Replay Protection

The signature counter in authData is a monotonic counter that increments each time the authenticator generates an assertion for a credential. The relying party stores the highest counter value seen for each credential and rejects assertions with a counter value less than or equal to the stored value. This prevents replay attacks where an attacker captures a valid assertion and resends it. However, not all authenticators support global counters — some use a per-credential counter (which may start at 0 for each credential), and some always return 0 (indicating the counter feature is not supported). When the counter is always 0, the server cannot detect replays via this mechanism and must rely on challenge-response (the server sends a unique challenge that the authenticator signs).