FIDO2 Authentication

Overview

FIDO2 is a combination of the W3C Web Authentication (WebAuthn) specification and Client-to-Authenticator Protocols (CTAP2) from the FIDO Alliance.

WebAuthn defines a standard web API that is built into browsers (WebAuthN Client) and platforms to enable support for FIDO authentication.  CTAP2 allows the use of external authenticators (FIDO Security Keys, mobile devices) for authentication on FIDO2-enabled browsers and operating systems over USB, NFC, or BLE.  CTAP1 (the new name for FIDO U2F),  allows the use of existing FIDO U2F devices  for authentication on FIDO2-enabled browsers and operating systems over USB, NFC, or BLE  for a second-factor experience.

FIDO2 authenticators can either be in-built in a user device or a separate external device.  When an authenticator is in-built in the consumption device it's called Internal (Platform) Authenticator. When the authenticator is an external device it's called External (Roaming) authenticator.

Platform Authenticators leverages secure cryptographic hardware such as Trusted Platform Module(TPM), Secure Enclave/Element (SE) or Trusted Execution Environment(TEE) on platforms (as computer and smartphones) to manage cryptographic keys used for authentication. Roaming authenticators are independent of the platforms. They’re usually a standalone device such as USB security keys capable of cryptographic operations as per FIDO2 specifications.

Platform Authenticators communicate with the Relaying Party via the WebAuthN Javascript API built into browsers on different platforms (Windows, MacOS and Smartphones). However, FIDO2-enabled browsers/platforms require an additional transport channel to be able to communicate with Roaming Authenticators  via USB, NFC and BLE. Hence, CTAP2.

Unique Characteristics of FIDO2 Authentication

All FIDO authentication are based on challenge-response public key cryptographic protocol between a relaying party(RP) server and an authenticator.  The RP sends a challenge to the authenticator via the WebAuthN API (implemented on a device’s browser/operating systems), the authenticator returns a signed response to the RP. The RP verifies the signed response to allow the user access.

FIDO2 authentication are phishing-resistant authenticators.

How FIDO2 Works

Registration

1. The RP application (service) prompts the user to register via the Webauthn client (browser) on the user’s device
2. The user confirms their intention to register with the RP service.
3. The browser using the Webauthn JS API requests the authenticator to create a key pair for the user. In the case of Roaming Authenticators, CTAP2 is used to communicate with the authenticator.
4. The user provides a PIN or their biometric. This is used during authentication to verify that the user is in control and possession of the cryptographic credential on that device.
5. The authenticator creates the key pair and ties  it with the identity (identifier) of the RP service .  This ensures that the created credential cannot be used on a different service.
6. The public part of the key is sent to the RP server via the browser

‍

Authentication

Here’s a detailed depiction of FIDO2 authentication flow. In this flow the Identity Provider (IdP) is handles the user authentication. The Relaying party depends on the IdP to authenticate its users. This approach is referred to as Federated or delegated authentication.

As with all authentication process, it starts with the user.

1. The initiates access request  to the RP service
2. The RP service/browser sends the access request to the RP server
3. The RP redirects the request to an IdP who handles its users' authentication
4. The IdP challenges the user to authenticate via FIDO authentication protocol
5. The Webauthn client embedded on the platform’s browser locates the authenticator via Webauthn JS API or CTAP2 in the case of a roaming authenticator and prompts for user verification. The job of CTAP2 is to pass the authentication challenge from the Webauthn client to the roaming authenticator.
6. The user verifies by unlocking with PIN or biometric. This verification makes the user-service unique private key available. This also, ensures that the user who registered the authenticator with the RP service, it the same person using the registers device to access the service.
7. The activated user-service unique private key is then used within the authenticator’s secure environment to digitally sign the received authentication challenge. Prior to signing the challenge, the authenticator ensures that challenge originated from the exact service the user is trying to authenticate to. If not, the authentication will be rejected. This authenticator assures this by validating the relaying party identifier (i.e. the domain name of the relying party service). This is why it's phishing-resistant.
8. The authenticator sends the digitally signed response to the Webauthn client (browser). as you may already guessed, the authenticator doesn’t communicate directly with the RP (or IdP as in this flow), it must go through the Webauthn client which can be implemented in the platform’s browser, in the operating system.
9. The Webauthn client sends the the digitally signed response from the authenticator to the IdP.
10. The IdP verifies the signature and authentication data as per FIDO specifications.
11. The IdP sends an authentication status to the RP.
12. The RP checks the  authentication status received from the RP
13. The RP establishes an authenticated session with the browser, if the authentication was successful. if not, no session is established.
14. The RP then grants the user access to the intended service
15. The user can then access the intended service.

‍

The Authentication Challenge

• The challenge from the IdP to the webauthn client (browser) contains a unique random number and optional extensions.
• The webauthn client forms the client data which comprises the  challenge from the IdP, relaying party identifier(in this case the fully qualified domain of the IdP) and Tlsdata for channel binding.
• The webauthn client sends a hash of the client data, the challenge and rpid to the authenticator. Irrespective of whether the authenticator is platform or roaming, the request is the same. The only difference is that for roaming authenticators, CTAP2 is used to transport the request to the authenticator via USB, NFC or BLE.

‍

The Authentication Response

• The authenticator signs the challenge and sends the signature with the authentication data to the webauthn client
  • The authentication data is contains the hash of the rpid, counter and credential attestation data
  • The signature contains the hash of the client data, counter
• Again, irrespective of whether authenticator is platform or roaming, the response is the same. The only difference is that for roaming authenticators, CTAP2 is used to transport the response back to the webauthn client.  
• The webauthn client sends the response to the RP (in this case IdP).

‍

Verification

The IdP uses the public key of the user to verify the signature on the authentication response.  The user private key can only be used to sign the response only if the user entered the second factor (PIN or biometric). And because the private key is securely protected that it cannot be stolen, then the IdP can believe that the authentication was actually done by the user and not by an imposter.

Similarities between Platform and Roaming Authenticators

• Both Platform and Roaming Authenticators depends on the WebAuthN client implemented in a browser and/or in the operating system and  on the  WebAuthN client device (platform) to work.
• Both relies on the platform to communicate with the authenticator
• Both uses exactly the same challenge-response public key cryptographic protocol
• Both are phishing-resistant
• Authentication ceremonies are resistant to man-in-the-middle attacks.

‍

Differences between Platform and Roaming Authenticators

The main different between Platform and  Roaming Authenticators is the additional transport (CTAP2) required by Roaming Authenticators to transport the request and reponses to and fro the Webauthn client.

Platform Authenticators are embedded in the platform where as Roaming Authenticators are independent of the platform.

Conclusion

The primary function of the authenticator is to provide WebAuthn signatures, which are bound to various contextual data. These data are observed and added at different levels of the stack as a signature request passes from the server to the authenticator. In verifying a signature, the server checks these bindings against expected values. Any modification of the expected values would lead to authentication failure.

Reference

• User Authentication Specifications Overview - FIDO Alliance

• Web Authentication: An API for accessing Public Key Credentials - Level 3