FIDO U2F security keys’ review: authentication, digital signature or blockchain?
Research on Security Keys
While integrating FIDO U2F key as a new authentication method to Rohos Logon Key, we have reviewed it’s features. In this article we outline the origin and history of U2F, how it works on low level, the list of capabilities and possible applications that beside authentication includes also document signature, crypto-currency, blockchain and change management.
U2F origin and history
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 kind of “Security Key” devices (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, and implemented by using 3DES encryption algorithm in two-key mode.
However, in the FIDO U2F standard it is clearly stated that the cryptographic protocol is chosen and implemented by the device manufacturer itself. For example, a famous manufacturer 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 stop discloses the means by which its devices work or their security features. We should note that in 2015, the community found an uncritical vulnerability in the Yubikey device [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 security key:
The list of U2F key functions:
1) Generate a ECDSA Key pair, return back a Public Key and encrypted Secret Key (named as Key Handle). This operation requires user touch the key.
2) Verify that Key Handle value belongs to it (thus decrypt it). Does not requires user touch.
3) Is able to sign the provided digest with the provided Key Handle. Confirmed by user touching the device.
Let us examine in a more detailed way 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 features of random-number generator;
- The protocol for generating the ECDSA 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 OTP 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.
Other applications where it is possible to use FIDO U2F
In addition to authentication purpose, what other use cases, options and ways of using FIDO U2F keys could be found?
Is it possible to use FIDO U2F keys to store secret data or obtain a secret key and then using it for encryption?
No. The U2F registration function always returns different data even for the same input values. When generating a key handle, the random-number generator is used. When signing, the counter value is used in the digest. On of the idea behind U2F is a privacy and anonymity, if you find a lost U2F key , you will not be able to identify the owner. But owner will be able to do it by proofing with a Key Handle possession.
Is it possible to use FIDO U2F keys to store keypairs for crypto-currency wallets?
Yes in a way, but the digest/signature protocol in the crypto-wallet scheme should be adjusted to a U2F digest format.
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 crypto-currencies safe.
Is it possible to use FIDO U2F as a key for configuration management?
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 each change in OS or Application configuration. U2F will allows to perform signature and two-factor authentication for every new modification/executable/installed package on a system.
In such a case, the antivirus can determine, with 100% confidence, the level of trust for each application and determine if executable are being created on a disk without authorization by an administrator.
Is it possible to use FIDO U2F keys to implementing continuous authentication in industrial systems (ICS/SCADA/SmartGrid)
Yes. In industrial systems, the issue of trust and authentication are deeply interconnected, 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.
Using FIDO U2F keys for digital signature and verification
Yes it is possible. Actually the thing U2F does is a digital signature of provided digest. It is also possible to implement signature schemes with multi-factor authentication when an Operator need to provide a Key and a Password in order to sign the documents. Using additional elements such as : time stamp, password, computer ID, last document signature, supervisor signature, location IP in a digest allows to create a blockchain like signature for smart contracts. This will allow to implement complex purposes like multiple peers confirmation, multi-amendments, community and location-aware. Electronic signature with U2F may completely replace PKI schema and thus simplify management of trusted-parties repository.
Using FIDO U2F key for blockchain
Yes it is possible. Since blockchain data structure is a data blocks coupled by a signed digest of hashes that also includes hash of each previous block. It preserves the order, integrity and authenticity of transactions that may be formed by many parties. The unique feature of U2F signature is that signature operation should be confirmed by a real human (U2F produce digital signature only after user touch the device thus it also includes a human factor involvement. Blockchain based on U2F may contain two types of transactions: created by system and by operator (user). The transaction of operator cannot be made by the system since private key is not extractable from U2F device, thus plausible deniability of the blockchain transaction is not possible. With each U2F signature the U2F key owner also assures the possession of the device. This features can be used in smart contracts as well, where user identity should be coupled with data.
References:
[1] Google, Security Keys: Practical Cryptographic Second Factors for the Modern Web