The FIDO Alliance is a non-profit group that was founded in 2012 with the goal of eliminating passwords from the internet through the use of cryptographic protocols. To learn more about the Alliance, read our FIDO 101 article or visit the website.
FIDO consists of three protocols for strong authentication1 to web applications: Universal 2nd Factor (U2F), Universal Authentication Framework (UAF), and FIDO 2.0 or WebAuthn.
The first two protocols came about when, four years ago, two independent efforts to re-introduce2 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 2nd 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 have the following capabilities:
- Use Elliptic Curve Cryptography (ECC)-based public and private key pairs (56-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 authenticatorU2F 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.
FIDO 2.0 and W3C Web Authentication (WebAuthn)
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
1 Defined as the use of public key cryptography with a hardware-based authenticator.
2 The first attempt at strong authentication refers to the use of Transport Layer Security with Client Authentication (TLS ClientAuth), X.509 digital certificates and keys stored on smart cards and similar devices.