How FIDO Makes Passwordless Authentication Possible

By /

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 to solve the password problem. The technology behind FIDO2 is based on asymmetric cryptography. A private key and a public key each generate a key pair. The recipient’s public key can be exchanged at any time with communication partners to encrypt messages. To decrypt the message, the recipient’s private key is required; the recipient must keep it safe, as third parties could decrypt the message if they intercepted it.

Every authenticator available for FIDO2 has an X.509 certificate, also called an attestation certificate, stored during device manufacturing. The private key is etched into the device and cannot be exported or otherwise interfered with. In addition, the device is cryptographically attested. For example, attackers may attempt to intercept a registration request and replace it with their own. However, they cannot swap the generated public key with another key. This is because the attestation signature does not match.

This is the first part of a two-part blog post explaining the details of FIDO2. The first part covers:

  • the basics of passwordless authentication,
  • the components of FIDO2
  • the registration and authentication process in detail.

The second and final part focuses on planning, implementing, and auditing a FIDO2 implementation in Azure AD.

Components of FIDO2

Principle

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

  • WebAuthn is a platform-independent, browser-based JavaScript API within the W3C Web Standard. The API allows users to authenticate to Internet services without a password. It does this using asymmetric cryptography based on a public key method.

CTAP2 controls the communication between the client and the 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 that have implemented CTAP2. Thus, passwordless login is not limited to Internet services. But it can be used in a variety of ways, such as logging in to standalone or domain-joined Windows 10 devices.

FIDO2 Architecture
Figure 1: FIDO2 Architecture

The components

There are several other important components of FIDO2, illustrated in Figure 2, that we need to understand:

FIDO2 Components (source: Microsoft)
Figure 2: FIDO2 Components (source: Microsoft)
  • The Platform Authenticator and Roaming Authenticator act as a secure entity embedded in or attached to the user’s end device.
  • The FIDO Metadata Service (MDS) helps prove authenticator authenticity by periodically retrieving authenticator certificate chains. Manufacturers randomly generate and store an Authenticator Attestation Globally Unique ID (AAGUID), which identifies the Authenticator model.
  • The WebAuthn client implements the WebAuthn API and consists of an operating system and a web browser. It serves as an interface between the authenticator and the relying party so that authentication is performed using the WebAuthn API.
  • The relying party consists of the web server and the FIDO server. As a single construct, it provides access to a secure resource. It accepts requests from the server or web application to register and authenticate users. No specific protocol is required for communication between the server or web application and the relying party. However, they are often implemented as a REST API. TLS secures all communication; otherwise, the WebAuthn API will not allow any communication.
  • Relying party and authenticator certification can be granted by the FIDO Alliance. This validates product conformity and interoperability. Each product has different security requirements, which are labeled from Level 1 to Level 3+. It should be noted that all authenticators must meet at least Level 1 security requirements to obtain FIDO certification.

Registration

Definition

Registration means that the relying party creates a user account. A user calls the service via a WebAuthn client, transfers data from an Authenticator, and deposits a public key with the Relying Party. Later, the user can authenticate to the service using the same Authenticator. Figure 3 describes the registration process.

FIDO2 Registration (source: W3C)
Figure 3: FIDO2 Registration (source: W3C)

The steps

The steps to follow are as follows:

  1. A user navigates to a WebAuthn-enabled service (e.g. outlook.com) in the web browser and makes an authentication request.
  2. The relying party returns a response to the WebAuthn client. This consists of parameters that the WebAuthn client must fill in to register. For example, the relying party can specify which authenticator to use. Local authentication can consist of entering a PIN, biometric features such as a fingerprint, or confirmation by an NFC reader.
  3. The WebAuthn client receives the relying party’s parameters and checks the available authenticators connected to the WebAuthn client. The special feature of this procedure is that the relying party ID is based on the domain name. The domain name (Origin) must be encrypted by TLS and can only be accessed via https://. The relying party ID is only valid if it matches the relying party’s origin. Assuming that 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 verifies whether the Relying Party performs a user interaction before registration occurs. When registering with an Internet service, this generates a new asymmetric key pair. This key pair is not shared between Internet services. This key pair is called an identification key pair or simply a key pair (Figure 4).
Key pairs (source: FIDO)
Figure 4: Key pairs (source: FIDO)

Verification

The authenticator’s private key signs the newly created public key with the relying party’s information. It is returned to the relying party and stored there for later authentication. Finally, a signature counter must be run by the authenticator to increment a positive value after each registration. Then the counter sends it to the relying party. This counter is used to identify and reject a cloned authenticator.

  1. The new public key generated and signed in the previous step and other necessary attestations are returned to the WebAuthn client. It is important to note that the authenticator must perform some form of attestation before delivery to verify authenticity. Typically, attestation includes:
    • a public authentication key digitally signed by the private attestation key and a challenge,
    • along with a certificate or similar data that can confirm the relying party’s provenance information for the public key. This packaged element is called an attestation object.
  2. Among other things, the WebAuthn client returns the attestation object to the relying party so that they can verify the response.
  3. The Relying Party stores the public key and verifies the attestation object data and any extensions. Authenticator validation can be performed by the relying party itself or by the FIDO metadata service. Once the registration process is complete, the user can authenticate without a password using the authenticator used.

Authentication

For authentication, a user proves their identity to the relying party through a WebAuthn client using an Authenticator. Figure 5 provides an overview of the authentication process:

The FIDO Authentication process (source: W3C)
Figure 5: The FIDO Authentication process (source: W3C)
  1. When a user authenticates to a WebAuthn service, the client makes an authentication request to a relying party.
  2. The relying party receives the authentication request and returns it to the WebAuthn client. As was already done during registration, a new challenge is generated, among other things. As much information as possible, also known as an authentication assertion, should be returned to the WebAuthn client. This limits the user’s choice of authentication methods. This is based on the data present in the Authenticator.
  3. The WebAuthn client receives the options contained in step 2 and begins validating and calling the Authenticator. Then, the Authenticator receives the relying party’s ID parameters.
  4. The authenticator receives data from the WebAuthn client and checks whether the relying party ID from the record matches. Then it generates an assertion signature. Then, the private key generated by the authenticator verifies the authenticity of the data from the relying party ID. But before that, it may be necessary to re-authenticate the authenticator locally.
  5. Among other things, the authenticator returns the signed data of the assertion signature to the WebAuthn client.
  6. The WebAuthn client sends the authenticator data and assertion signature to the relying party.
  7. The Relying Party verifies the availability of the public key in the database. It also verifies the assertion signature with the public key (public identification key) stored during registration.

Summary and outlook

The FIDO2 standard and the W3C have successfully increased authentication security for Internet services and applications. Automated key management by the authenticator eliminates the need for time-consuming administration. The CTAP2 protocol allows for both embedded and external authenticators, which can be addressed via USB, NFC, and BLE interfaces. This ensures that the secret never leaves the authenticator.

However, the FIDO2 standard is constantly evolving:

  • Enterprise Attestation (EA) allows you to link a credential to an account using a persistent identifier. This is something you might be familiar with from smart cards. EA is designed for environments where a trusted relationship exists between the devices and the relying party. The FIDO privacy standard requires that “a FIDO device not have a global identifier visible on websites.”
  • CTAP 2.1 enables the management of resident keys on an authenticator. This means that you can
    • manage your PIN code,
    • display the credentials to be discovered,
    • add or remove fingerprints and reset the authenticator via a browser, operating system control panel, application, or CLI tool. In addition, CTAP 2.1 allows user verification to always be required on the authenticator, even if the relying party does not request it.

So, the next part of this two-part series will be about how to:

  • to plan,
  • to configure
  • to audit passwordless authentication in Azure AD.
How to achieve passwordless authentication in Azure AD?

Perform passwordless authentication in Azure AD

Related Posts

Scroll to Top