U2F
U2F ( U niform S econd F actor, universal second factor ) is an industry standard for a generally applicable two-factor authentication based on an adapted challenge-response authentication . In addition to an access password, it serves as proof of 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 . The non-commercial FIDO alliance was founded for the further development and cooperation of the U2F providers . On December 9, 2014, the first corresponding standard FIDO v1.0 was published.
In contrast to the industry initiative " Open Authentication " (OATH), which is also trying 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
As an essential property, the U2F standard does not have an externally unambiguous identifier for a specific U2F device and thus allows privacy to be protected. A service provider (server) with whom a customer is registered with his U2F device for the purpose of identification cannot therefore determine which other services this U2F device is still registered with. This applies even if a certain service provider also has access to the login data of the other service provider or has been given knowledge of this login data.
This property of the U2F method makes a significant contribution to further protection if the login data stored with the service provider when registering is read out by third parties as part of data leaks and can then spread in an uncontrolled manner.
This protection is also given if a U2F device is used by different people at a provider or by one person to log in to several accounts. In these cases, too, based on the U2F login data stored on the server, the respective service provider cannot determine 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 key is calculated within the framework of an asymmetrical cryptosystem . For registration of the public key thus generated, together with a content from any custom U2F device so-called key identifier (is within the U2F method English key handle ) transmitted to the service provider.
When you log on to a service provider for the first time, this data pair consisting of the public key and key identifier is stored on the server. In the case of a subsequent authentication, the server transmits the key identifier belonging to the user together with additional data such as the server address, a unique session identifier and other data. The U2F device can determine the associated private key from the transmitted key identifier and thus appropriately sign the data of the return response to the server. The signed return reply is used by the server together with the assigned public key to authenticate the customer. This method allows a certain degree of protection against man-in-the-middle attacks .
The lack of unambiguous public identification of a U2F device is in contrast to the classic challenge-response authentications with asymmetric keys, such as the authentication in the Secure Shell (SSH) for command line access . With SSH authentication, the public key is deposited on all servers exactly where public access is permitted. 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
The diagram on the right shows the process of authentication at U2F; the initial registration with the service provider is assumed to have already taken place.
- For authentication, the service provider asks the user name as the first factor and, if necessary, the regular password, checks this data and - if OK - introduces the second factor in the form of U2F:
- In the first step, the service provider sends a data package to the customer's computer (web browser). This consists of a challenge , these are some random numbers. In addition, an application identifier, referred to in the diagram as app id , and the key identifier key handle , which was stored during the initial login.
- The customer computer checks the application ID , adds additional data such as a channel ID, and forwards this data to the U2F device.
- With the help of the key handle, the U2F device determines the private key k priv that is suitable for this session , and uses this to sign the application identifier and the challenge c , thus forming the signed response s .
- In addition, a counter (can optionally Counter ) can be integrated with the signed response to be able to detect duplicate U2F devices.
- The customer computer, such as the web browser, forwards this data to the service provider, who uses the public session key to check the signature s and the data it contains and - if OK - grants access.
particularities
In order for the U2F device to provide an answer, it is mandatory in the standard that a user action is necessary 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, the EyeLock company has been offering the iris scanner myris with USB connection, which is compatible with the U2F protocol, since January 2015 . This specification is intended to ensure that the user agrees to an authentication request regardless of the PC and its software - if the user does not agree, there is no response from the U2F device after a time has elapsed. This requirement is intended to prevent software on the computer from requesting large numbers of replies from the U2F device and subsequently evaluating them without the knowledge of the user.
The U2F device can be designed as a security token in hardware with correspondingly secure memory, but does not have to. In principle, a purely software-based U2F application is also possible, but with the fundamental problem that secret data such as the unique and internally used U2F primary identifier can be read out and compromised more easily.
In order to minimize the costs for hardware-based U2F devices, such as USB dongle, the method is designed in such a way that no changeable data such as the generated session-based private keys have to be stored in the U2F device. The method leaves open how and where the secret private key data is stored for a service provider.
The storage can on the one hand take place in a memory on the U2F device, which makes the U2F device more expensive and limits the number of registrations due to the memory size. However, it is also possible to encrypt the session-based private keys generated using a device-specific method and to save them on the server as part of the key identifier ( key handle ). This is because this key handle is transmitted from the server to the U2F device with each subsequent login , which means that this U2F device can recover its private key. The U2F device can be used for any number of services, since no connection-dependent key data is stored on the U2F device and there are no storage space restrictions.
In order to be able to differentiate between different types of U2F devices and their different levels of 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), the response is also signed with a manufacturer-specific one within the framework of U2F private key. The private key is permanently stored in the U2F device and is identical for all U2F devices from this manufacturer, which prevents identification of a specific U2F device. The corresponding public key is well known and can be used by service providers to require the use of certain U2F devices for access.
Software support
Google Chrome became the first web browser to support U2F in October 2014. Since version 57 (January 2018) U2F has also been integrated in Mozilla Firefox . Apple Safari has supported U2F since version 13 (September 2019). The functionality can be checked on Yubico's U2F test page.
Various Internet services support registration via U2F, primarily from the Google environment such as Gmail , Dropbox , GitHub . To log on to a computer running Linux and macOS is a Pluggable Authentication Module is available.
The Windows 10 operating system from Microsoft supports the U2F functions not only for its own services, but also within the system when logging into several thousand third-party services.
Web links
- FIDO Alliance Overview (English)
- U2F , Yubico (English)
- Explanations for beginners to FIDO1 / U2F and FIDO2 , FIDO Alliance (English)
Individual evidence
- ↑ FIDO 1.0 Specifications are Published and Final Preparing for Broad Industry Adoption of Strong Authentication in 2015. FIDO Alliance, December 9, 2014, accessed April 11, 2018 .
- ↑ a b U2F Specifications. Retrieved November 28, 2016 .
- ↑ Universal 2nd Factor (U2F) Overview , FIDO Alliance, April 11, 2017, PDF file, accessed April 24, 2019
- ↑ EyeLock's myris Is First and Only Iris Authenticator for New FIDO Open Industry Standard , EyeLock, accessed January 5, 2015
- ^ Google Launches Security Key, World's First Deployment of Fast Identity Online Universal Second Factor (FIDO U2F) Authentication. Retrieved April 16, 2020 . , fidoalliance.org, October 21, 2014
- ↑ Security / CryptoEngineering. Retrieved November 15, 2017 .
- ↑ Safari 13 Release Notes. Retrieved February 17, 2020 .
- ↑ Test your U2F device. Retrieved November 15, 2017 .
- ↑ pam-u2f. In: developers.yubico.com. Retrieved May 25, 2016 .
- ↑ yubico-pam. In: developers.yubico.com. Retrieved May 25, 2016 .
- ↑ Windows 10 for companies: Maximum security for all devices and scenarios - Innovative security: two-factor authentication , technet.microsoft.com from March 19, 2015, accessed on November 30, 2016.