FIDO - How does the FIDO server verify the integrity of inbound public key during registration phase/ceremony?

Question

Trying to wrap my head around the FIDO protocol suit.

Premise

1. Authenticator has a master private key(also called attestation key)
   
2. During the registration ceremony, authenticator signs the challenge and a couple of other parameters along with the newly generated public key and sends it to the FIDO universal server via WebAuthN protocol. And the private key generated is stored in the authenticator locally.

Questions

1. How does the FIDO server verify the integrity of public key generated by authenticator (simply put how does the server validate the certificate chain back to root of trust)? This is assuming that there is scope for mitm attack between authenticator and web client.
   
2. Does the server have corresponding public key of attestation key/master private key built in (replicating a CA model)?
   
3. If so, do all the fido authenticators have same master key when they are created(be it software module or a hardware module)? If not how do manufacturers and FIDO servers keep up with huge number of physical authenticators and software modules being created and deployed?

Answer 1

FIDO servers can use the FIDO Alliance Metadata Service to get information that would help to verify the certificate chain back to a root of trust.

Step 15 of "Registering a new credential" in WebAuthn W3C Recommendation states:

If validation is successful, obtain a list of acceptable trust anchors (attestation root certificates or ECDAA-Issuer public keys) for that attestation type and attestation statement format fmt, from a trusted source or from policy. For example, the FIDO Metadata Service [FIDOMetadataService] provides one way to obtain such information, using the aaguid in the attestedCredentialData in authData.

Extract from https://fidoalliance.org/mds/:

The FIDO Alliance Metadata Service (MDS) is a web-based tool where FIDO authenticator vendors can publish metadata statements for FIDO servers to download. This provides organizations deploying FIDO servers with a centralized and trusted source of information about FIDO authenticators.

Answer 2

1. The authenticator is injected a private key (attestation key) before it is sold to user. The attestation certificate is trusted by FIDO server. That certificate will be used for verifying signature in attestation statement. Let's talk about trusting a certificate. There are 2 kinds of trust: Trust and Chain of Trust.

Trust: FIDO server directly imports (stores) a known Authenticator Vendor certificate. Let's say I trust Yubico, I download Yubico key attestation certificate from Yubico site and import to my FIDO server. That certificate will be used for verifying registration from users using Yubico keys. No one can generate a valid attestation statement without attestation private. Don't worry about man-in-the-middle because the vendors may have applied a secure chip technology to protect the private key.

Chain of Trust: FIDO server obviously trusts FIDO Metadata Service (MDS) and just stores MDS certificates. MDS issues certificates for Authenticator Vendors. So, when authenticator creates attestation statement and sends it to FIDO server, Server will verify signature using attestation certificate in the attestation statement and then combine the attestation certificate with MDS certificates to do the validation.

Note that we are talking about Full Basic Attestation Model which is the most common so far. ECDAA will be different.

2. As explain in 1. above. Server MAY or MAY NOT have attestation public key. Note that the attestation private keys in the authenticators are NOT distinct. Vendors produce security keys by batch. Each batch they inject the same attestation private, this is for user privacy. This is not a perfect solution. User privacy is solved perfectly by ECDAA which is not launched.

3. As explain by 1., 2.

Answer 3

Ok. Let's talk about attestation, mds, and metadata.

Devices have thing called attestation. It's a way to identify device model. in general scenario, like security key, i.e. Yubikey, Trustkey, etc, the manufacturer would generate an attestation batch certificate and a private key, and place then on the batch of the devices.

The root for the batch certificate is then placed in the metadata, a digital document that describes device properties(name, modelid, algorithms, security properties, etc).

The metadata is then stored in the metadata service, MDS, and FIDO Alliance managed centralised storage for the metadata.

The FIDO server, from time to time, fetches MDS, and loads all metadatas. During the registration, the device will return an attestation that can be validated by finding matching metadata using the modelid(AAGUID or AAID), and using the root certificate from the metadata, verifying the attestation signature, that is generated by the device using the batch key.

Now, here is a thing. It's all cool and dandy, but in reality, in majority of the cases, you don't actually need attestation. Most services just want to use secure passwordles authentication, so by default WebAuthn API will return you "None" attestation. None is when browser removes attestation information for privacy reasons.

If you want to learn more there is a great article that talks in depth about attestation: https://medium.com/webauthnworks/webauthn-fido2-demystifying-attestation-and-mds-efc3b3cb3651