Understanding How FIDO Makes Passwordless Authentication Possible

Solving the World’s Password Problem

FIDO stands for Fast IDentity Online. It is an open industry alliance founded in 2012 with the aim of solving the world’s password problem. The technology behind FIDO2 is based on asymmetric cryptography. In this process, a private and a public key each generate a key pair. The recipient’s public key is not a secret and can be exchanged or published at any time with communication partners to encrypt messages. To decrypt the message, the recipient’s private key is required; it must be kept secure by the recipient, since third parties could decrypt the message if they intercepted it.

Each Authenticator available for FIDO2 has an X.509 certificate, also known as an Attestation Certificate, stored when the device is manufactured. The private key is burned into the device and cannot be exported or otherwise interfered with. Furthermore, the device is cryptographically attested, which means if attackers try to intercept a registration request and replace it with their own, they cannot exchange the generated public key with another key because the Attestation Signature does not match.

This is the first part of a two-part blog post explaining the details of FIDO2. Part one covers the basis of passwordless authentication, which components FIDO2 contains, and how registration and authentication takes place in detail. The second and final part focuses on planning, implementing, and auditing a FIDO2 implementation in Azure AD.

FIDO2 components

WebAuthn and the Client to Authenticator Protocol 2 (CTAP2) are two important components of the FIDO2 architecture (Figure 2):

• WebAuthn is a web browser-based, platform-independent JavaScriptAPI in the W3C web standard. The API allows users to authenticate themselves to Internet services without a password, using asymmetric cryptography based on a public key method.

CTAP2 controls the communication between client and Authenticator. For example, the client can be a computer with a web browser and the Authenticator can be a mobile device. The CTAP2 host is part of the client, which communicates with the Authenticator via the CTAP CBOR API.

Figure 1 shows that the CTAP2 protocol can communicate with applications or operating systems that have implemented CTAP2. Thus, passwordless logon is not limited to Internet services, but can be used in a variety of ways such as logging into standalone or domain-joined Windows 10 devices.

There are several other important FIDO2 components shown in Figure 2 which we should understand:

• Platform Authenticator and Roaming Authenticator act as a secure entity integrated into the user’s end device (e. g. a TPM module as a Platform Authenticator or be attached to it (e. g. an USB hardware token as a Roaming Authenticator).
• FIDO Metadata Service (MDS) helps to prove the authenticity of the Authenticator by regularly retrieving the certificate chains of the Authenticator. Manufacturers generate and store a randomly Authenticator Attestation Globally Unique ID (AAGUID), which identifies the Authenticator model.
• WebAuthn Client implements the WebAuthn API and consists of an operating system and web browser (for desktop PC, notebook, or mobile device). It serves as an interface between the Authenticator and the relying party so that registration and authentication can be performed using the WebAuthn API.
• Relying Party consist of the web server and the FIDO server, which as an overall construct provides access to a secure resource. It accepts requests from the web server or application to register and authenticate users. No specific protocols are required for communication between the web server or application and the Relying Party, but they are often implemented as a REST API. All communication must be TLS secured, otherwise the WebAuthn API will not allow any communication.
• Certification of a Relying Party and an Authenticator can be granted by the FIDO Alliance to validate product compliance and interoperability. For each product, there are different security requirements, which are labeled as Level 1 to Level 3+. All Authenticators must meet at least Level 1 of the security requirements in hardware or software to obtain FIDO certification.

Registration

Registration means that a user account is created by a Relying Party. A user calls up the service via a WebAuthn client, transfers the data of an Authenticator and deposits a public key with the Relying Party. Later, the user can authenticate with the service using the same Authenticator. Figure 3 outlines the registration process.

The steps involved are as follows:

1. A user navigates to a service with WebAuthn support (e. g. outlook.com) in the web browser and makes an authentication request.
2. The Relying Party sends a response back to the WebAuthn client, which consists of parameters that the WebAuthn client must fulfill to register. For example, the Relying Party can specify which Authenticator may be used or whether local authentication must be performed on the Authenticator. Local authentication can be a PIN entry, biometric features such as fingerprint, or confirmation with an NFC reader.
3. The WebAuthn client receives the parameters of the Relying Party and checks available Authenticator connected to the WebAuthn client. The special feature of this procedure is that the Relying Party ID is based on the domain name, among other things. The domain name (Origin) must be TLS-encrypted and can only be accessed via https://. The Relying Party ID is only valid if it matches or is a suffix of the Origin of the Relying Party. Assuming the login URL of an Internet service is https://login.example.com, the following Relying Party IDs are valid: login.example.com (default) and example.com. But not m.login.example.com and not only .com.
4. The Authenticator checks whether a user interaction for local authentication has been passed by the Relying Party before registration can be performed. When registering with an Internet service, a new asymmetric key pair is generated and not shared across Internet services. This key pair is called a credential key pair or just a key pair (Figure 4).

In this process, the newly generated public key with information from the Relying Party (Credential Public Key) is signed with the Authenticator’s private key (Attestation Private Key) (Attestation Signature), sent back to the Relying Party, and stored there for later authentication. Finally, a signature counter should be run by the Authenticator – if supported – to increment a positive value after each registration and send it to the Relying Party. This counter can be used to identify and reject a cloned Authenticator.

5. The new public key generated and signed in the previous step (Public Key Credential Source) and other necessary attestations are returned to the WebAuthn client. It is important to note that the Authenticator must perform some form of attestation prior to delivery to verify authenticity. Typically, the attestation statement includes a credential public key digitally signed by the attestation private key and a challenge, as well as a certificate or similar data that can confirm the public key’s provenance information by the Relying Party. This packaged item is also referred to as an Attestation Object.
6. Among other things, the WebAuthn client sends the attestation object back to the Relying Party so that it can verify the response.
7. The Relying Party stores the public key and verifies the data of the Attestation Object and possible extensions. The validation of the Authenticator can take place at the Relying Party itself or through the FIDO Metadata Service. This completes the registration process, and the user can authenticate without a password with the Authenticator used.

Authentication

For authentication, a user proves their identity to the Relying Party via a WebAuthn client using an Authenticator. Figure 5 gives an overview of the authentication process:

1. When a user navigates to an Internet service that supports WebAuthn (e. g. outlook.com) and wants to authenticate, the first step is for the WebAuthn client to make an authentication request to a Relying Party.
2. The Relying Party receives the authentication request and sends – as already during registration – among other things a newly generated challenge back to the WebAuthn Client. As much information as possible should be returned to the WebAuthn client, also called Authentication Assertion, to limit the choice of authentication methods for the user. This can be based on the stored data in the Authenticator or a username is passed, depending on whether a username was requested during registration or not.
3. The WebAuthn client receives the options contained from step 2 and starts the validation and the call of the Authenticator. Among other things, the parameters of the Relying Party ID and the hashed data of the Challenge and Origin, as from the registration, are passed to the Authenticator.
4. The Authenticator receives the data from the WebAuthn client and checks whether the Relying Party ID from the registration matches, and then generates an assertion signature. In the process, the data from the Relying Party ID is checked for authenticity with the generated private key of the Authenticator during the registration process (Credential Private Key) and signed. Before this can be done, local authentication may have to be performed on the Authenticator again.
5. Among other things, the Authenticator sends the signed data from the Assertion Signature back to the WebAuthn client.
6. The WebAuthn client sends the Authenticator data and the Assertion Signature to the Relying Party.
7. The Relying Party checks the availability of the public key in the database and verifies the assertion signature with the public key (credential public key) stored during registration.

Summary and Futures

The FIDO2 standard and the W3C has succeeded in increasing the security of authentication for Internet services and applications, making it as convenient as possible for users. Automated key management by the Authenticator eliminates the need for time-consuming administration. The CTAP2 protocol allows integrated as well as external authenticators, which can be addressed via the USB, NFC and BLE interfaces. The secret never leaves the authenticator, regardless of whether it is unlocked by a secret or a biometric feature.

The FIDO2 standard is constantly evolving, and I would like to mention some features that will be released in the future:

• Enterprise Attestation (EA) enables binding of an authenticator to an account using a persistent identifier, what you may know from smart cards. EA is designed for enterprise-like environments where a trust relationship exists between devices and/or browser and the Relying Party, as the FIDO privacy standard require “that a FIDO device must not have a global identifier visible across websites”.
• CTAP 2.1 allows management of resident keys on an authenticator. That means you can manage your PIN, view discoverable credentials, add or remove fingerprints, and reset the Authenticator via a browser, an OS setting panel, and app, or a CLI tool. Furthermore, CTAP 2.1 allows to always prompt for user verification (PIN, biometrics, etc.) on the Authenticator, even if the Relying Party doesn’t request it.

The next part of this two-part blog series will cover how to plan, configure, and audit passwordless authentication in Azure AD.