The FIDO2 protocol is a passwordless authentication mechanism for the web which is widely adopted. In previous blog posts, we have talked about its security assurances and our post-quantum secure end-to-end open-source implementation. As part of the protocol, FIDO2 offers different attestation mechanisms to ensure the hardware devices used to log into a web service – called ‘authenticators’– comply with certain security requirements that might have been requested by the web service (AKA relying party). The FIDO2 protocol offers different modes of attestation with seemingly different security and privacy guarantees. In our recent research paper we are the first to analyze the advantages and disadvantages of the different attestation modes systematically using rigorous cryptographic security models and proofs.

This blog post gives a short introduction to the paper “To attest or not to attest, this is the question – Provable attestation in FIDO2” by Nina Bindel, Nicolas Gama, Sandra Guasch, and Eyal Ronen, published and presented during Asiacrypt 2023. For more details check out the paper and our recorded conference presentation!

Attestation in FIDO2

The FIDO2 protocol allows attestation of the authenticator during its registration at a web service by a user and via a client. Depending on the attestation mode, a certificate authority that issues attestation certificates might be necessary. For example, this can be the authenticator manufacturer or a third party (see figure below).

During registration of an authenticator at a web service, the FIDO2 protocol offers essentially four different attestation modes:

As our research shows, there is a tradeoff between security and privacy for each of the attestation modes, meaning that the attestation mechanisms providing stronger security guarantees also leak more information (and as such provide less privacy), and the other way around.

But what do we actually mean by different ‘security and privacy guarantees’?

Security and Privacy Goals in FIDO2

In previous works, security is defined in the following terms. Once I registered ‘my’ authenticator to be used in a web service, nobody should be able to authenticate on my behalf without the very same authenticator. This implies that we ‘assume’ there wasn’t an adversary hijacking the communication between my authenticator and the web service during the registration. However, once the registration has been successful, adversaries won’t be able to hijack the communication during authentication. This is also known as ‘Trust On First Use, or TOFU for short.

How does this translate in the real world? Imagine the authenticator is registered in the safety of your home with your own laptop, but then authentication might be needed in different situations, like travel abroad, or even from untrusted devices like shared computers. Since the authenticator was registered in a trusted environment, it can also be used securely in these cases.

However, can we always assume that the browser or the operating system of your personal computer can be trusted during registration? We don’t think so, and this is why in our analysis we considered that the client may be malicious at any time, and still nobody should be able to impersonate the authenticator. This can be achieved to some extent using attestation.

At the same time, attestation should not lessen the user’s privacy. The privacy objectives of the FIDO2 protocol require that a coalition of web services are not able to link registration and authentication requests they received to a particular authenticator [1]. Put differently, an attacker should not be able to create a list of all web services used by the same authenticator over time.

Security and Privacy Guarantees of Different Attestation Modes

In our paper we define a mathematical model that can capture both the privacy and security goals above. This model enables us to then systematically analyze the different attestation modes in FIDO2 regarding the security and privacy properties we will now summarize at a high level.

None. As the default mode, FIDO2 does not provide any attestation. As can be expected, this is the least secure mode. Since no additional information is sent, it also means that it is (together with the attestation mode ‘self’) the most private mode.

Self. When self attesting, the authenticator itself guarantees for its own properties. In more detail, during registration, a credential key pair is generated by the authenticator: a secret credential key that stays on the authenticator and is never shared, and a public credential key that is shared with and stored at the web service. When the user logs in with the hardware authenticator, a proof using a digital signature generated with the secret credential key is sent to the server. When self attestation is used, the same secret credential key is used to generate a proof (via a digital signature) of the authenticator’s properties. As the proof is generated by the authenticator itself, it can lie about its own properties and as such the attestation mode ‘self’ offers little more security guarantees than using no attestation. The advantage is that also the privacy guarantees are the same as for no attestation because the credential key pair is freshly generated for every web service and as such, authenticating with the same authenticator at different web services cannot be linked.

Basic. In basic (or batch) attestation, a batch of at least 100,000 devices (for example authenticators from the same model or brand) share an attestation certificate generated, e.g., by the manufacturer. As long as no authenticator in the entire batch is compromised, this mode provides better security than the modes ‘none’ or ‘self’ since the properties are guaranteed by a third party. As such, one authenticator cannot mimic being from, e.g., a different brand as long as the attestation certificates are trustworthy and cryptographically secure. The large size of the batch of at least 100,000 ensures some privacy – albeit less than ‘none’ or ‘self’, more than the ‘attestation CA’ mode explained next.

Attestation CA. In this mode, a certificate authority issues certificates to the authenticators on-demand, describing their properties. Ideally, the authenticator will request a new certificate from the authority every time it registers in a new web service to ensure that using the authenticator for different services cannot be linked. To prove that it has certain properties, the authenticator will authenticate to the certificate authority using a pre-installed secret. However, this means that the attestation certificate authority must be trusted to keep the assignment of attestation certificate to authenticator secret and to be available to issue a certificate whenever needed by any authenticator.

A New Approach

As we found none of the offered attestation modes described above to be fully satisfying, we went one step further to introduce a new mode. The new mode is based on the ‘basic’ attestation mode but introduces a recovery mode in case one of the 100,000 authenticators in the batch has been compromised. That means only authenticators which are not compromised can get new attestation keys regularly. We hope that this opens a new direction to further strengthen the advantage of attestation within FIDO2.

More concretely, we extended the basic attestation mode such that the keys used for attesattion are only valid for a limited time and new keys for the entire batch are periodically provisioned. As such this protocol allows the entire batch to “heal” after one of the authenticators from that batch was compromised. For more technical details, we invite you to check out the full paper.