The open authentication standard FIDO2 (Fast Identity Online 2), which enables passwordless login using biometrics, for example, essentially consists of two standardized components. The first is the API authentication protocol WebAuthn (Web Authentication), which manages the connection between the user’s system (client) and the website (server) on which the user is to identify themselves. The second is the Client to Authenticator Protocol (CTAP), which manages the connection between the user’s system (client) and an external authenticator, such as a hardware token. However, FIDO2 can only function when the two components, WebAuthn and CTAP2, are combined.
CTAP is currently available in two different versions. CTAP1, also known as U2F (Universal 2nd Factor), is an industry standard primarily for two-factor authentication, while the newer CTAP2 protocol relates to authentication using the FIDO2 standard.
For passwordless login to work, there must be a form of authentication. This ensures that only authorized users can access their online accounts. FIDO2 uses devices for this purpose, known as authenticators, which users can use to identify themselves to the online platform. There are two types of authenticators: internal (platform), which are built directly into the user’s device, such as a laptop or smartphone, and external (roaming).
For internally built-in authenticators, such as fingerprint scanners in smartphones, no separate communication protocol such as CTAP is required, as they are not external hardware. In this case, WebAuthn is sufficient for communication between the client and server.
CTAP comes into play when an external authenticator is connected to the actual device (client), such as a PC or laptop, via USB, NFC, or Bluetooth. The name Client to Authenticator Protocol (CTAP) was coined in reference to these external authenticators. In addition to CTAP, WebAuthn is also required for communication between the external authenticator, client, and server.
It is important that authentication data such as fingerprints never leave the authenticator. Instead, public key cryptography is used. For this purpose, a cryptographic key pair (private and public key) is created during the initial setup. The private key is stored securely in the authenticator and never leaves it, while the public key is sent to the service with which the user wishes to register.
In addition, the challenge-response procedure is used. In the first step, the service to which the user wishes to log into sends a challenge via the browser to the authenticator. The user then confirms their identity, for example by placing their finger on the fingerprint scanner, and the authenticator signs the challenge with the private key stored in the authenticator during initial registration. The signed challenge is then sent back to the service (response) and checked against the public key previously stored there. If authentication is successful, the user can access the service.
Since no sensitive information is transmitted during authentication, man-in-the-middle attacks and phishing attacks are pointless. Social engineering is also ineffective, as there is no sensitive information (e.g., passwords) that can be revealed.