WebAuthn/FIDO2: Verifying Packed Attestation

Please note that this is an advance post, and requires prior understanding of the FIDO2 attestations. You can read more about them here.

2014 is outside. Pharrell Williams’s Happy is top chart. Obama is still President. And U2F just was released with simple merged buffer response structure. Then everyone decided that CBOR was the new cool kid in town, and slapped it on top of U2F creating FIDO2 Packed attestation.

A sample of FIDO2 packed attestation response. The fields are hexed for simplicity

Verifying packed attestation is probably the simplest of all attestation. There are two modes: FULL and SELF(SURROGATE) attestations:

FULL Attestation

If you check attStmt and it contains “x5c” then its a FULL attestation. FULL basically means that it’s an attestation that chains to the manufacturer. It is signed by batch private key, who’s public key is in a batch certificate, that is chained to some attestation root certificate.

To verify FULL attestation you first need to check that “x5c” is present. If it is not, then it is either SELF(SURROGATE) or ECDAA. Then you need to check certificate and verify attestation:

Checking certificate

1. Extract leaf cert from “x5c” as attCert
2. Check that attCert is of version 3(ASN1 INT 2)
3. Check that attCert subject country (C) is set to a valid two character ISO 3166 code
4. Check that attCert subject organisation (O) is not empty
5. Check that attCert subject organisation unit (OU) is set to literal string “Authenticator Attestation”
6. Check that attCert subject common name(CN) is not empty.
7. Check that attCert basic constraints for CA is set to FALSE
8. If certificate contains id-fido-gen-ce-aaguid(1.3.6.1.4.1.45724.1.1.4) extension, then check that its value set to the AAGUID returned by the authenticator in authData.

Verifying attestation

1. Concatenate authData with clientDataHash to create signatureBase
2. Verify signature “sig” over the signatureBase with the public key extracted from leaf attCert in “x5c”, using the algorithm “alg”
3. If you are supporting metadata or MDS: Locate corresponding metadata using the AAGUID returned in that authData. Parse authData, and verify that authData.publicKey algorithm set to the corresponding algorithm to the one set in metadata statement.
4. Parse authData, and verify that authData.publicKey algorithm set to the corresponding algorithm to the one set in metadata statement.
5. For each attestationRoot in metadata.attestationRootCertificates, generate verification chain verifX5C by appending attestationRoot to the x5c. Try verifying verifX5C. If fail try next attestationRoot. If no attestationRoots left to try, return error.

SELF(SURROGATE) Attestation

Self attestation is simple proof of key ownership, that is produced by signing attestation with user’s freshly generated private key. It used by the authenticators that don’t have memory to store batch certificate and key pair. If attStmt missing “x5c” and “ecdaaKeyId”, then it is a SELF(SURROGATE) attestation.

Verifying attestation

1. Concatenate authData with clientDataHash to create signatureBase
2. Parse authData and extract COSE public key
3. Verify signature “sig” over the signatureBase with the previously extracted public key.
4. If you are supporting metadata or MDS: Locate corresponding metadata using the AAGUID returned in that authData.
5. Parse authData, and verify that authData.publicKey algorithm set to the corresponding algorithm to the one set in metadata statement.
6. Check that metadata.attestationRootCertificates is set to an empty sequence.

Snippets

License

This article is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0). So you are free to read, share, etc. If you are interested in commercial use of this article, or wish to translate it to a different language, please contact ackermann(dot)yuriy(at)gmail(dot)com.

The code samples are licensed under MIT license.