An Overview of U2F security keys’ capabilities: Principle of Operation and Details of the Protocol
Research on Security Keys
There is every reason to believe that the development of U2F was initiated by Google engineers and it was carried out in collaboration with representatives from other companies. In their publication “Security Keys: Practical Cryptographic Second Factors for the Modern Web” [1] they perform a survey and comparison of the one-time key technology OATH OTP with a certain “Security Key” (i.e. U2F). This publication shares the experience that Google gained in using OTP codes, as the second authentication factor, over several years and involving hundreds of people inside the company. Only in this publication can we find an example of the cryptographic protocol that U2F probably uses for encrypting data, realized on the basis of the 3DES encryption algorithm in two-key mode.
However, in the U2F standard it is clearly stated that the cryptographic protocol is chosen and implemented by the device manufacturer itself. For example, a famous producer of U2F devices, Yubico, limited itself to merely publishing a approximate schema of how it implemented the protocol, but it did not publish any details, the algorithm by which the secret key is encrypted, or the source code of its protocol. In any event, we have not yet been able to find this out. The company’s position is that it will not discloses the means by which its devices work or their security features. We note that in 2015, the community found an uncritical vulnerability in the Yubikey key [2].
U2F stands for universal second factor, i.e. the device which should serve as the second factor in protocols or implementation of two-factor authentication along with the participation of a human being. For example, in addition to a password, a system should also ensure that the user possess the given U2F device. Its principle of operation is based on storing a challenge-response type of authentication, by means of a digital signature, and the obligatory participation of a human user. According to the intention of the developers, the cryptographic model should be known to all, as well as how the device protects the secret key.
Functions of a U2F device/security key:
Let us examine here the actual functionality of a U2F device in version 1 of the standard.
- It stores within itself the manufacturer’s certificate, which contains a public and private key. This keypair is used for the ECDSA digital signature (a digital signature based on Elliptic Curves) in step 2.
Keys are generally stored in ROM and they cannot be deleted or changed. The security of the secret key depends entirely on the manufacturer’s implementation. The device will never “give up” the secret key or allow it to be changed.
The certificate of the key’s manufacturer allows one to determine who exactly manufactured the device.
– The device uses the secret key from the certificate to create an ECDSA signature, as well as for the encryption (the algorithm is unknown) that the device uses in its protocol.
– Google engineers mention in their work [1] also an additional secret key on the device which is used for encryption. - An Authentication System (AS) is registered
Summary: The device, within itself, generates an ECDSA keypair, it encrypts the secret key (using its Secret and the AS Parameter) and all this + the signature + its certificate is returned from the device.
The authentication system ought to contain the following: Parameter, Public Key, and Encrypted Secret Key (Key Handle).
The operation requires the presence of a user – he/she must touch the device’s case or press a button.
– This operation also involves the Challenge parameter which works on a “challenge-response” principle.
– The device uses its internal random-number generator, therefore the same key will never be returned a second time during registration even if all other details entered remain the same;
– Note that the protocol for encrypting the key is chosen (perhaps even custom-designed) and implemented by the device manufacturer, it is not part of the standard. The Google engineers give an example of how this can be done using 3DES with two keys. We would suggest that at present 90% of devices use 3DES and the protocol that Google suggests in order to encrypt the Secret Key. - It checks the Encrypted ECDSA Secret Key and Parameter for the system.
This operation does not require the user to be involved. The key tries to decrypt the Encrypted Secret Key using its internal Secret (perhaps Secret #2) and the CA Parameter.
Through this operation, the Authentication System can determine which user the key belongs to. - It digitally signs the Challenge
This function also checks the authenticity of the Encrypted ECDSA Secret Key (step 3).
If everything is correct, the device continues to process the request and it will return a digital signature for the following digest: “Challenge”, AS Parameter, Counter. This allows the System to verify the authenticity of the use of the key at a given moment in time. Thanks to the additional parameter that is used in the signature, the system can also ensure that the Signature was made by the given key specifically for it in the presence of the user. - A counter is kept for all created signatures.
This value is always returned in step 4 and is also used in the signature. It can be used by the AS system for additional checks. For example, if the new value returned by the key is less than the value the system remembers, the user may have recovered a lost token or this is a copy of the device. This may be a means of protection from software implementations of U2F which will soon appear on the net. Thanks to this counter, the signature that is created will always be different, even if all details entered are the same;
We have passed over some details here for the sake of simplicity. Note that engineers should treat the Encrypted ECDSA Secret Key (Key Handle) and Authentication System parameter as secret values. In the event that these are compromised, a number of attacks will become possible, and if they are lost it will no longer be possible to identify or authenticate the device.
We would like to point out some unknown or critical aspects of the implementation of a U2F device:
- The quality and security of the secret key for the manufacturer’s certificate;
- The random-number generator;
- The protocol for generating the public keypairs, the algorithm and protocol for encrypting the secret key, as well as the role of the Authentication System parameter in that protocol;
- The way that the human presence sensor works;
In our opinion, if the human presence sensor can be fooled by software or physical means and it can make the device generate and sign data very quickly, this will make it possible to analyze the security protocol for the given device.
Comparing U2F with one-time OATH TOTP passwords (Google Authenticator):
- When registering (configuring) a U2F key, there is no need to do anything with its secret key, as in the case of TOTP when it is necessary to provide the Colleague/User with the secret key in order to install it in a smartphone with Google Authenticator). Further, you must store the secret key on the server side with very strict security.
- Protection against unauthorized copying of U2F keys.
The presence of a duplicated TOTP configuration cannot be determined. One can set up two phones with Google Authenticator and they will both generate correct codes and they cannot be distinguished from one another. Even in instances of HOTP that involve a counter, one cannot with certainty confirm that this is a ”copied” counter and not the result of the User repeatedly making the device generate a Code without it being supplied to the authentication system. - Protection against repeated use of the One-Time Code or using an “old” code.
In authentication systems using one-time passwords, it is theoretically possible to create a situation in which a code generated earlier (used or not used) will be accepted by the system. For example,in H/TOTP configuration it is possible to simulate an attack with time desynchronizations, when a Senior Employee calls/writes to the Administrator and says e.g. “I am traveling and my one-time password doesn’t work, clearly because I’m two time zones behind the office. Do something, please, I need access.” In this case the Administrator synchronizes the T/TOTP parameters in the software, and in turn, depending on the quality of the authentication system implemented, this can lead to the history of all codes used earlier being completely discarded.
In this case the system, upon the first authentication of a given user, will synchronize times (i.e. it will search for a time shift by searching for all possible one-time passwords at an interval several hours off from the local time). At this time, it will detect that the supplied code corresponds to a time shift of 5 hours (the code which in fact was already used 5 hours ago and intercepted or eavesdropped from a smartphone screen but not used). Again, depending on the implementation, the system may find such a situation to be normal and as a result it will accept this code and approve the authentication of the user.
In the case of U2F, this is not possible thanks to the “challenge-response” mechanism. - Offline authentication is possible.
Since we plan to use U2F for authentication in Windows/Linux network infrastructure, there may be situations when the PC or laptop is not connected to the enterprise network and it is not possible to verify the key without the domain being involved. In the case of T-OTP, the Rohos Logon Key program can be configured to store TOTP settings (including the secret key) also on the workstation, which naturally limits the level of security and the probability that the TOTP key is cloned. In the case of U2F, the only thing that must be saved on the workstation are key configuration details that are not so secret.
Comparing U2F with PKCS#11 tokens
- U2F lacks a mandatory PIN code for the User and Administration to shield access and protect the configuration.
- U2F takes action to authenticate only with the consent of the user (i.e. the user interacts with the device). Third-party software cannot perform any operations with the device.
In the case of PKCS#11, any program, without the user’s knowledge, can block the token’s PIN code, for example, or read from the key using one of the factory PIN codes for the administrator or user, or intercept the PIN code (keylogger) and then read all data from the token. - If a U2F key is lost, it can be used for authentication by a malicious actor, but a PKCS#11 key with its PIN code is protected against this.
- When setting U2F up, it does not require installing drivers or utilities to format/configure the device like PKCS#11 does.
- The protocol for communicating with a U2F device resembles the APDU commands for smartcards. For PKCS#11 one must use the manufacturer’s library.
- When using an U2F device (key), it is possible to prove that authentication was made with the given key at a given point in time. However, this may need to be implemented on the authentication system side. With PKCS#11 keys, there is no such possibility. The key returns a certificate or a block of details, but these are often not linked to the key’s serial number.
Possibilities of using a U2F security key
In addition to directly authenticating, what other options and ways of using U2F could be found?
- Storing secret data or obtaining a secret key and then using it for encryption?
No.
The U2F registration function always returns fresh details for the same input values. When generating a key, the random-number generator is used. When signing, the counter value is used in the digest. - Storing keypairs for crypto-currency wallets?
Yes, but one has to change the digest/communication protocol in the wallet to a U2F digest.
All crypto-wallet programs, such as Bitcoin, are ECDSA keypairs. Here the secret key is of crucial importance. If you lose the secret key, you lose all your bitcoins, while if a malicious actor gets the secret key then he actually owns your bitcoins. However, the secret key is only used if a new block was found (you mined a unit of Bitcoin) or if you buy/sell bitcoins. Consequently, it makes sense to store it in a secure/encrypted place and use it only when necessary. In this case one can use a PKCS#11 key + the device PIN code to store the bitcoin wallet’s secret key in the device’s memory. With U2F, it is not presently possible to do this, as the digest that it uses for signatures does not match the wallet’s digest. However, if this is fixed, then a U2F key will become the most accessible and secure device for keeping bitcoins and other cryptocurrencies safe. - A key for establishing trust in an OS or antivirus. Trust Provider Key.
Yes.
This is a rather new idea and it resembles how TPM hardware modules work. The idea is that the OS or antivirus asks the user to sign with a U2F key every new executable/installed package.
In such a case, the antivirus can determine, with 100% confidence, the level of trust for each application and determine if executables are being created on a disk without authorization. To put this idea into practice, a U2F key should allow generating signatures while the user holds U2F button pressed, which would allow signing many modules at one time. - Implementing continuous authentication in industrial systems (ICS/SCADA/SmartGrid)
Yes.
In industrial systems, the issue of trust and authentication are deeply intertwined, requiring that the continuous authentication principle be implemented. The implementation of this principle using the method of User Behavior Analysis/Biometrics has still not been crowned with great success. But use of a U2F key for confirming trust and authentication also works with the obligatory presence of a human being and it gives a number of advantages:
– no false positives, -fast confirmation of operations, -ability to listen in on confirmations, – out of band multi-factor authentication.
References:
[1] Google, Security Keys: Practical Cryptographic Second Factors for the Modern Web
[2] Yubico, SecurityAdvisory 2015-04-14.