U2F (Universal Second Factor) is an industry standard for general-purpose two-factor authentication, based on adapted challenge-response authentication. In addition to an access password, it is used to prove access authorization, for example for web-based services, and can also be used in combination with digital personal documents to establish identity.
The U2F specifications were developed by Google with the participation of Yubico and NXP Semiconductors. For the further development and cooperation of the U2F providers, the non-commercial FIDO Alliance was founded. On December 9, 2014, the first corresponding standard FIDO v1.0 was published. The following year, the FIDO2 initiative was launched, in which U2F was subsequently merged under the changed name Client to Authenticator Protocol (CTAP1).
In contrast to the industry initiative “Open Authentication” (OATH), which also seeks to establish solutions for two-factor authentication as an industry standard, U2F process descriptions are not subject to any confidentiality regulations of the companies involved.
---
Features of U2F
As an essential feature, the U2F standard does not have an outwardly unique identifier of a specific U2F device and thus allows the protection of privacy. Therefore, a service provider (server) to which a customer is logged in for identification with his U2F device cannot determine with which other services this U2F device is still registered. This applies even if a particular service provider also has access to or has become aware of the login credentials of the other service providers.
This feature of the U2F procedure contributes significantly to further protection if the login data stored with the service provider during registration are read by third parties in the context of data leaks and can then spread uncontrollably.
This protection is also provided when a U2F device is used by different people with one provider or by one person to log in to multiple accounts. Even in these cases, the U2F credentials stored on the server cannot be determined by the respective service provider that it is the same U2F device and that the same or different users are using this U2F device.
This is made possible by the fact that a key pair (dependent on the characteristics of the service provider such as server address, TLS certificate and other data such as randomly generated session identifiers (tokens)) is individually generated in the U2F device from a private and public key. The private and public keys are computed within the framework of an asymmetric cryptosystem. As part of the U2F procedure, the public key generated in this way, together with a so-called key handle that can be freely designed by the U2F device, is transmitted to the service provider for registration.
When you log on to a service provider for the first time, this pair of public key and key identifier data is stored on the server. In the case of subsequent authentication, the server transmits the key identifier belonging to the user, along with additional data such as the server address, a unique session identifier, and other data. In this way, the U2F device can determine the corresponding private key from the transmitted key identifier and use it to sign the data of the return response to the server. The signed return response is used by the server together with the associated public key to authenticate the customer. This method allows a certain level of protection against man-in-the-middle attacks.
The lack of unique public identification of a U2F device is in contrast to classic challenge-response authentication with asymmetric keys, such as authentication to the Secure Shell (SSH) for command-line access. With SSH authentication, the public key is stored on all servers exactly where public access is allowed. Thus, even without knowing the secret private key, it is possible to determine on which server there is access with this SSH key, if there is only access to the public key data.
Procedure Used By U2F
For authentication, the service provider asks for the username as the first factor and, if necessary, the regular password, checks this data, and – if OK – initiates the second factor in the form of U2F.
In the first step, the service provider sends a data packet to the customer’s computer (web browser). This consists of a challenge, these are some randomly chosen digits. In addition, an application ID, and the key identifier key handle, which was stored during the initial login.
The customer’s computer checks the application ID, adds additional data such as a channel ID and forwards this data to the U2F device.
The U2F device uses the key handle to determine the appropriate private key for this session, and uses it to sign the application identifier and challenge to form the signed response.
In addition, a counter can optionally be integrated into the signed response to detect duplicate U2F devices.
The customer’s computer, such as the web browser, forwards this data to the service provider, which uses the public session key to check the signature s and the data contained therein and – if OK – grants access.
Special Features of U2F
In order for the U2F device to provide an answer, it is mandatory in the standard that a user action is required directly on the U2F device. In the simplest case, all you need to do is press a button on the U2F device. However, other initiations are also possible: For example, since January 2015, the company EyeLock has been offering the myris iris scanner with USB connection, which is compatible with the U2F protocol. This policy is intended to ensure the user’s consent to an authentication request regardless of the PC and its software – if the user does not give this consent, there will be no response from the U2F device after a period of time. This requirement is intended to prevent software on the computer from requesting and subsequently evaluating responses from the U2F device in large numbers without the user’s knowledge.
The U2F device may or may not be designed as a security token in hardware with correspondingly secure storage. In principle, a purely software-based U2F application is also possible, but then with the fundamental problem that secret data such as the unique and internally used U2F primary identifier can be read and compromised more easily.
In order to minimize the cost of hardware-based U2F devices, such as USB dongles, the process is designed in such a way that no mutable data such as the generated session-based private keys need to be stored in the U2F device. The procedure leaves open how and where the secret private key data is stored for a service provider.
On the one hand, the storage can take place in a memory on the U2F device, which makes the U2F device more expensive and limits the number of logins due to the memory size. However, it is also possible to encrypt the generated session-based private keys using a device-specific method and store them on the server as part of the key handle. This is because with each subsequent login, this key handle is transmitted from the server to the U2F device, which allows this U2F device to recover its private key. For example, the U2F device can be used with any number of services because the U2F device does not store any connection-dependent key data and there is no limit on storage space.
In order to be able to distinguish between different types of U2F devices and their different trustworthiness on the part of service providers (for example, hardware-based U2F devices have a higher level of security against reading than PC-based software solutions), U2F also adds a signature of the response with a manufacturer-dependent private key. The private key is permanently stored in the U2F device and is identical for all U2F devices from this manufacturer, which prevents the identification of a specific U2F device. The corresponding public key is common knowledge and can be used by service providers to require the use of certain U2F devices for access.
Software Support of U2F
Google Chrome became the first web browser to support U2F in October 2014. Since January 2018, U2F has also been integrated into Mozilla Firefox. Apple Safari has supported U2F since September 2019.
Various internet services support login via U2F, primarily from the Google environment such as Gmail, Dropbox, GitHub. A Pluggable Authentication Module is available for logging on to a computer running Linux and macOS.
Microsoft’s Windows 10 and Windows 11 operating system supports U2F functions via hardware tokens as well as “Windows Hello”.
