An In-depth Guide to FIDO Protocols: U2F, UAF, and WebAuthn (FIDO2)

To learn more about the Alliance, read our FIDO 101 article.

Read our FIDO 201 article to learn how FIDO2-based authentication can be deployed using StrongKey's PKI2FIDO web application, and move beyond PKI or replace PIV authentication.

FIDO consists of three protocols for strong authentication¹ to web applications: Universal 2^nd Factor (U2F), Universal Authentication Framework (UAF), and FIDO2 or WebAuthn.

The first two protocols came about when, six years ago, two independent efforts to re-introduce² strong authentication for web applications joined together to form the FIDO Alliance. For the sake of expediency, the FIDO Alliance standardized both protocols to deliver mostly similar benefits:

• The Universal 2^nd Factor (U2F) protocol was primarily intended to be a simple protocol and used as a second factor authentication scheme in addition to the first factor (the user's password); while
• The Universal Authentication Framework (UAF) was defined as a password-less protocol for mobile devices only

Despite perceived differences, there is a lot in common between them. Both protocols, U2F and UAF, have the following capabilities:

• Use Elliptic Curve Cryptography (ECC)-based public and private key pairs (256-bit) and the Elliptic Curve Digital Signature Algorithm (ECDSA) for the digital signature scheme
• Use hardware devices on the client side to generate and protect private keys
• Mandate the requirement for the hardware device to ensure a human is present at the client side to confirm protocol message exchanges between client and server
• Require a one-time Registration event, generating a unique key pair for the web application origin, and submit the public key to the FIDO Server (integrated with the web application)
• Use Attestation Certificates (X.509 digital certificates) to digitally sign newly minted user public keys and metadata about their origin during Registration
• Use the registered key for all Authentications with that site, digitally signing nonces (numbers used once) to prove they have the private key to the FIDO credential
• Do not release the cleartext (unencrypted) private key from the Authenticator during the message exchange with the web application (as stated earlier, some implementations may choose to release an encrypted key pair for storage on the FIDO server as part of the message/exchange)
• Generate and use unique key pairs for web origins with unique Domain Name Service (DNS) site domains while preserving the user's privacy, so web applications do not discover other keys on the Authenticator
• Are integrated into web applications either as a back-end module in the application, or as an application programming interface (API) or web service request from the web application to a FIDO server

There are some differences between U2F and UAF; primarily:

• UAF allows the web application to specify a policy in the protocol, requiring the Authenticator to meet specified requirements before continuing with the Registration or Authentication, or otherwise reject the transaction. The policy may specify things like:
  • The type of biometric capability that must be used to authenticate the human locally to the Authenticator device: finger, iris, voice, etc.
  • The number of local authentications to perform before generating/unlocking keys: PIN, password, pattern, biometric, etc.
  • The acceptable global positioning system (GPS) location of the user
  • U2F does not have such capability defined in its protocol
• UAF can take advantage of a “secure display” (should one exist on the mobile device), displaying transaction information and prompting the user to accept the transaction by digitally signing a digest of the displayed contents with their private key
• UAF allows applications to query a metadata service available from the FIDO Alliance to learn dynamic information about Authenticators, enabling them to make risk-management decisions on user registrations and authentications. While this is currently available only with the UAF protocol, the metadata service is in transition to accommodate all three FIDO protocols
  • A Human Interface Device (HID) in the USB port, where the U2F authenticator must be inserted into a USB port on the computing device to work with the CTAP1-aware browser
  • A Bluetooth Low Energy (BLE) connection, where the computing device and the U2F authenticator must be paired prior to registration and/or authentication
  • A Near Field Communications (NFC) system, where the computing device—generally a mobile device with an NFC reader—must be compatible with a supported NFC-aware authenticator
  • U2F has the ability to work with browsers on all devices that support a U2F-aware web agent. The low-level messages between the browser and the U2F authenticator are standardized in the Client To Authenticator Protocol 1.0 (CTAP1). CTAP1 works over three transport protocols:
• While U2F is promoted as a second-factor authentication mechanism, where U2F implementations may have incorporated other “local” authentication schemes to the device (such as biometric template matching using a fingerprint, iris/facial recognition, etc.) they have the potential to be used as a first-factor authentication scheme.

FIDO2 and W3C Web Authentication (WebAuthn)

Members of the FIDO Alliance, recognizing that the market would logically be better served with a protocol that carried features of U2F and UAF, decided to create a new protocol. This third protocol—referred to as FIDO 2.0 or FIDO2—has JavaScript elements that were submitted to the World Wide Web Consortium (W3C) for standardization, so it can be uniformly implemented in all W3C-compliant browser agents. The JavaScript API specification, named “Web Authentication” (WebAuthn) at the W3C, is winding its way through the Consortium's standards process currently.

While WebAuthn is different from U2F and UAF, it embodies capabilities from each of its predecessors to deliver similar benefits, and even has a compatibility mode with U2F, where U2F authenticators will work with FIDO2 servers when using the WebAuthn specification.

In addition to all the capabilities of the U2F and UAF protocols, WebAuthn's capabilities include:

• Use of Rivest-Shamir-Adelman (RSA) encryption public and private key pairs for the digital signature scheme
• Use of platform authenticators (cryptographic modules built into the computing devices, such as the Trusted Platform Module (TPM) on a desktop/laptop computer, or a Secure Element built into a mobile phone) to generate and protect private keys
• Use of external (or roaming) authenticators such as smart cards, Subscriber Identity Module (SIM) cards, or USB-based cryptographic hardware with HID and BLE transport support