What is CTAP?

inovex

CTAP stands for Client to Authenticator Protocol, as the name suggests it specifies how the applications(browser/client) and the operating system establish communication with an authentication device over USB, NFC, or BLE.

Authenticators are of two types, roaming authenticators such as smartphones, wearable devices, and FIDO security keys and platform (embedded) authenticators such as Touch ID, Face Id, and Windows Hello. CTAP is only used by roaming authenticators.

The FIDO U2F 1.2 proposed on 11th July 2017 became the starting point for CTAP specifications. The latest version came out in 2019 which is the CTAP2 protocol. CTAP and WebAuthn are the results of the FIDO2 Project which is a joint effort between FIDO Alliance and W3C. CTAP is responsible for handling communication between the client and the authenticator while WebAuthn handles communication between the client and the relying party.

Generally, CTAP refers to both CTAP1/U2F protocol and CTAP2 protocol. An authenticator that implements CTAP2 is called a FIDO2 Authenticator. CTAP1 formerly known as FIDO U2F specifies the communication between FIDO2 enabled browser and a FIDO U2F device. This enables second-factor authentication. CTAP2 defines how to establish communication between FIDO2 enabled browser and external authenticators to enable passwordless, multi-factor authentication. CTAP2 authenticators, FIDO2 authenticators, or WebAuthn Authenticators refer to authenticators that enable CTAP2.

The basic flow of CTAP Specification

1. Application (Browser/Platform) establish a connection with the authenticator.
2. Application gets authenticator information using authenticatorGetInfo command. It will return the capabilities of the authenticator.
3. Application sends a command which is supported by the authenticator.
4. Authenticator replies with the data or error

Why CTAP?

The good thing about CTAP is that the authentication data such as fingerprint data will never leave the device which ensures user confidentiality. The authenticator will send only the confirmation to the relying party through the browser. This works on public-key cryptography mechanism enabling usernameless and passwordless authentication and also defend against phishing attacks.

Deep dive into specifications

With a rough knowledge of how things work in CTAP, let’s explore how exactly specifications are defined. CTAP structure consists of 3 layers, namely Authenticator API, Message encoding and Transport-specific Binding.

Authenticator API

This level of abstraction defines operations similar to an API call which accepts input parameters and returns data or an error. Operations in Authenticator API are independent of one another and synchronous but do not enforce reliability or in-order communication. The authenticators may limit resource usage which will return a busy status when invoked.

Several methods and data structures are available under the Authenticator API.

authenticatorMakeCredential Method

Authenticator Make Credential Flow

Invoked by the browser to create new credentials in the authenticator. So this is used in the user registration process and corresponds to the authenticatorMakeCredential operation defined in WebAuthn specifications.

The parameters,

• clientDataHash — Hash of client data
• rp — relying party data
• user — user details
• pubKeyCredParams — list of preferred cryptographic algorithms
• options — contains rk (instructs the authenticator to store the key data) and uv (instructs the authenticator to request gestures such as fingerprint for user verification) fields
• excludeList
• extensions
• pinAuth
• pinProtocol

authenticatorGetAssertion Method

Authenticator Get Assertion Flow

Browser request cryptographic proof of user authentication and user consent to a given transaction. This is used in the user authentication process and corresponds to the authenticatorGetAssertion operation in WebAuthn specifications

The parameters,

• rpId — relying party id
• clientDataHash — hash of client data
• options — contains rk (instructs the authenticator to require user consent) and uv (instructs the authenticator to request gestures such as fingerprint for user verification) fields
• allowList
• extensions
• pinAuth
• pinProtocol

Apart from the above two methods, there are other methods for various operations such as,

• authenticatorGetNextAssertion
• authenticatorGetInfo
• authenticatorClientPIN
• authenticatorReset

More details can be obtained from the CTAP Specification given by FIDO Alliance

Message encoding

The browser constructs and encodes a request to be sent to the authenticator (specifically to invoke a method in the authenticator API) over the transport protocol. Normally transports such as Bluetooth are bandwidth constrained so serialization formats such as JSON are too heavy to be used in those environments. So data are encoded with concise binary encoding CBOR ( CTAP2 canonical CBOR encoding form) before sending them to the authenticators.

Example

var rp = { 
 name: “Acme” 
 }; 

will be encoded to

a1                  # map(1) 
    64              # text(4) 
         6e616d65   # “name” 
    64              # text(4) 
         41636d65   # “Acme” 
 

Commands
In this layer, a set of commands are available to run certain operations.

• authenticatorMakeCredential
• authenticatorGetAssertion
• authenticatorGetInfo
• authenticatorClientPIN
• authenticatorReset
• authenticatorGetNextAssertion
• authenticatorVendorFirst
• authenticatorVendorLast

You can correlate the methods implemented in Authenticator API to this commands. The authenticatorVendorFirst and authenticatorVendorLast are vendor specified commands mainly used for testing purposes.

Responses
Responses are the results of the aforementioned commands and are structured as Status (status of the response) and Response Data (CBOR encoded values)

• authenticatorMakeCredential_Response
• authenticatorGetAssertion_Response
• authenticatorGetNextAssertion_Response
• authenticatorGetInfo_Response
• authenticatorClientPIN_Response

Status codes
These are the error response values range from 0x01–0xff which are used to define error messages

Transport-specific Binding

Requests and responses are conveyed to roaming authenticators over specific transport technologies such as USB, NFC, or Bluetooth. Transport-specific Binding specifies message bindings for each transport technology.

If you are interested and want to explore further on these specifications please refer to FIDO Alliance specifications. With that bit of information, I would conclude my article.
See you soon!