About attestation

Attestation is a step in the FIDO registration ceremony in which the FIDO relying party can verify the make and model of the FIDO Authenticator that is about to register.

  • During the registration ceremony, the FIDO Authenticators public key is signed with an (authenticator model-specific) attestation key.
  • Attestation keys have associated attestation certificates, that chain to a root certificate. All authenticators of the same make and model share the same attestation certificate.

A FIDO Authenticators make and model can be verified by Airlock IAM by consulting the configured trust store.

The FIDO Alliance Metadata Service (MDS) is not supported in Airlock IAM.

What does attestation accomplish?

  • The terms assertion and attestation are not synonymous:
  • Assertion occurs every time when authenticating.
  • Attestation occurs during registration once.
  1. Attestation accomplishes three things:
  2. If attackers manage to intercept a registration message with their own, they would not be able to swap out the new public key with their own. The attestation signature wouldn’t match.
  3. The FIDO relying party can verify the origin (e.g. manufacturer) of the authenticator being used but can't identify or track the individual user. This preserves the privacy of the user.
  4. A service can be configured to only accept a specific type or group of device types based upon:
    • -One or more FIDO Authenticator makers/vendors.
    • -FIDO Authenticators with trusted security.
    • -Authenticators with specific features of user verification i.e. with biometrics of a certain level of accuracy.

The FIDO attestation step enables the relying party to trust that the registration request is from a specific make and model of FIDO Authenticator.

Example: Full basic attestation

Our example explains a simplified full basic attestation with a roaming FIDO Authenticator.

FIDO_MDS lookup
  1. During the registration ceremony, the FIDO Authenticator creates a new credential key pair. The credential public key, that is sent to the relying party, is signed with the attestation private key.
  2. The FIDO relying party may verify that the attestation signature on the newly created public key came from the device, by looking up the attestation key chain in the configured trust store.
  3. This is hstablishes its trust in the authenticity of the credential public key.

Surrogate basic attestation (aka self-attestation)

Registration of FIDO Authenticators typically requires that a user already has a sufficiently authenticated session and communication is already secured over SSL/TLS.
Thus, replacing the attestation key is not possible for attackers. For this reason, many services will accept FIDO Authenticators that are using surrogate attestation/self-attestation.

  • Surrogate basic attestation model is typically used for:
  • FIDO Authenticators that don't have any specific attestation key.
  • FIDO Authenticators without meaningful protection (e.g. strong biometric authentication) measures for an attestation private key.

With surrogate basic attestation, the authentication key self-signs the surrogate attestation message instead of using a burned-in vendor-signed attestation certificate.

It is important to understand that FIDO Authenticators should not generate new attestation keys with every instance of a device. Instead, the FIDO's privacy principles require sufficient user anonymity that can only be accomplished when an attestation key is used for a sufficiently large number of authenticators. This mitigates the risk that users can be tracked based upon a unique attestation certificate.