FidoMetadataService#findEntries behaviour

[suren-khatana]

FIDO2 and WebAuthn support multiple attestation formats, each with its own conventions for identifying authenticators and validating trust:

FIDO U2F (fido-u2f):

• Used by older U2F authenticators (pre-FIDO2).
• Does not use an AAGUID (introduced in FIDO2).
• Relies on a certificate chain in the attestation statement, where the leaf certificate’s Subject Key Identifier (SKI) identifies the authenticator model.
• Trust is established by matching the SKI against a set of known, trusted SKIs (e.g., from the FIDO Metadata Service).

FIDO2/WebAuthn Formats (e.g., packed, tpm, android-key):

• Introduced the AAGUID, a 16-byte identifier unique to an authenticator model.
• The AAGUID is included in the attestation statement (e.g., in the authData or as an extension in the certificate).
• The certificate chain (if present) may still be validated, but the AAGUID is the primary identifier for looking up metadata or trust anchors.
• SKI is not typically used as the primary identifier for these formats.

The FIDO Alliance Metadata Service (MDS) reflects this distinction:

• For U2F, metadata entries list attestationCertificateKeyIdentifiers (SKIs).
• For FIDO2, metadata entries list an aaguid (and optionally SKIs if certificates are involved).

findEntries method searches for metadata entries in the FIDO MDS that match either the provided attestationCertificateChain or aaguid.

So in some cases, it mismatch attestation formats by using Subject Key Identifiers (SKIs) for non-FIDO-U2F cases where AAGUID should be the primary identifier.

So basically, If an attestation statement is from a FIDO2 format (e.g., packed), it provides an AAGUID, and the certificate chain (if present) is meant to prove trust, not to identify the authenticator model via SKI.
However, findEntries computes SKIs from the certificate chain and searches for metadata entries matching those SKIs, even if the attestation isn’t U2F.

If a metadata entry for a FIDO2 authenticator happens to include an SKI (e.g., in attestationCertificateKeyIdentifiers) that matches the computed SKI, the method could return that entry—even if the AAGUID doesn’t match or isn’t relevant.
This leads to a false positive when I am running FIDO2 conformance tests : a metadata entry being returned that doesn’t actually correspond to the authenticator’s intended model (as identified by its AAGUID).

Sample logs from my server highlighting this mismatch :

io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Registration Result: Is Attestation Trusted ? = true
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Registration Result: Attestation Type = BASIC
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Registration Result: Attestation Format = packed
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Registration Result: Attested Credential AAGUID = ByteArray(2b2ecbb459b444fa868da072485d8ae0)
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Registration Result: Attestation Statement = {"alg":-7,"sig":"MEYCIQDQz6upyl1Dvu0hO0S60YHYI+WAqz7PTLAp3vmCN1uaCgIhALU2A13zuI8DQSCO2KfyVFG68pId/402eJ9cnS7ObrS7","x5c":["MIIEQTCCAimgAwIB .....<redacted>
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Registration Result:  Attestation Trust Path Certs Chain: 
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: x509Certificate Subject= L=Wakefield,ST=MY,C=US,OU=Authenticator Attestation,O=FIDO Alliance,1.2.840.113549.1.9.1=#1622636f6e666f726d616e63652d746f6f6c73406669646f616c6c69616e63652e6f7267,CN=FIDO2 BATCH KEY prime256v1
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: x509Certificate Issuer= L=Wakefield,ST=MY,C=US,OU=CWG,O=FIDO Alliance,1.2.840.113549.1.9.1=#1622636f6e666f726d616e63652d746f6f6c73406669646f616c6c69616e63652e6f7267,CN=FIDO2 TEST ROOT
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: 
com.yubico.fido.metadata.FidoMetadataService: findEntries(certSubjectKeyIdentifiers = [564df7c0f8c655b6a11f6c4d19f3bf41e2fd0179], aaguid = Optional[AAGUID(2b2ecbb4-59b4-44fa-868d-a072485d8ae0)], nonzeroAaguid= Optional[AAGUID(2b2ecbb4-59b4-44fa-868d-a072485d8ae0)])
com.yubico.fido.metadata.FidoMetadataService: findEntries(certSubjectKeyIdentifiers = [564df7c0f8c655b6a11f6c4d19f3bf41e2fd0179], aaguid = Optional[AAGUID(2b2ecbb4-59b4-44fa-868d-a072485d8ae0)], nonzeroAaguid= Optional[AAGUID(2b2ecbb4-59b4-44fa-868d-a072485d8ae0)])
com.yubico.fido.metadata.FidoMetadataService: findEntries(certSubjectKeyIdentifiers = [564df7c0f8c655b6a11f6c4d19f3bf41e2fd0179], aaguid = Optional[AAGUID(2b2ecbb4-59b4-44fa-868d-a072485d8ae0)]) => 2 matches
com.yubico.fido.metadata.FidoMetadataService: findEntries(certSubjectKeyIdentifiers = [564df7c0f8c655b6a11f6c4d19f3bf41e2fd0179], aaguid = Optional[AAGUID(2b2ecbb4-59b4-44fa-868d-a072485d8ae0)]) => 2 matches
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Metadata Service Matched Entries Size= 2
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: ----------- Matched Metadata Entry ----------
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Description = Optional[Virtual Secp256R1 FIDO2 Conformance Testing CTAP2 Authenticator with Self(surrogate) attestation]
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Metadata Statement : AAGUID = Optional[AAGUID(2b2ecbb4-59b4-44fa-868d-a072485d8ae0)]
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Metadata Statement : AttestationCertificateKeyIdentifiers = []
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Authenticator Version: = 2
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Root Certificates: 
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: -----------------------------------------------------
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: ----------- Matched Metadata Entry ----------
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Description = Optional[Virtual Secp256K1 FIDO2 Conformance Testing U2F Authenticator]
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Metadata Statement : AAGUID = Optional.empty
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Metadata Statement : AttestationCertificateKeyIdentifiers = [564df7c0f8c655b6a11f6c4d19f3bf41e2fd0179]
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Authenticator Version: = 2
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper: Root Certificates: 
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper:   - Subject: = L=Wakefield,ST=MY,C=US,OU=CWG,O=FIDO Alliance,1.2.840.113549.1.9.1=#1622636f6e666f726d616e63652d746f6f6c73406669646f616c6c69616e63652e6f7267,CN=FIDO2 TEST ROOT
io.curity.identityserver.plugin.passwordless.common.PasswordlessHelper:   - Issuer: = L=Wakefield,ST=MY,C=US,OU=CWG,O=FIDO Alliance,1.2.840.113549.1.9.1=#1622636f6e666f726d616e63652d746f6f6c73406669646f616c6c69616e63652e6f7267,CN=FIDO2 TEST ROOT

As you could probably notice from the logs above, it matched 2 entries from the MDS, one with correct aaguid and other one with certSubjectKeyIdentifiers.

The attestation in this test case was supposed fail since the aaguid matching metadata doesn't contain the trust anchors but the attestation passed since the it also matched U2F metadata due to certSubjectKeyIdentifiers which contains the trust anchors.

I was trying to use filters in the FidoMetadataService but couldn't find a way to use attestation format in there.
Shouldn't the library only match using AAGUID when it's available in the attestation statement and fallback to SKI when fido-u2f format is used ?

Do you have any insights on this problem ?

[emlun]

Hi! Thank you for the detailed description of the problem. I see what you mean. But as far as I can tell, those test cases violate the MDS3 specs. Both FIDO Metadata Service 3.0 and FIDO Metadata Statement 3.0 state in their definitions of the attestationCertificateKeyIdentifiers field:

[...] Setting this field implies that the attestation certificate(s) are dedicated to a single authenticator model.

so I find it odd that the conformance tests include test cases with distinct authenticator models reusing the same attestation certificate, despite one of the metadata statements naming that certificate in its attestationCertificateKeyIdentifiers.

I also don't see any restriction, or even guidance, in the specs on when to match by which of aaid, aaguid or attestationCertificateKeyIdentifiers. I certainly don't see any explicit restriction against matching FIDO2 devices by attestationCertificateKeyIdentifiers (quite the opposite per the quote above), but I'd be glad to have it pointed out if there is one (explicit or implicit). All I see is the practical limitation that U2F devices cannot be matched by aaid or aaguid simply because they don't have one, but I see no such restriction for FIDO2 devices.