5

Is there any risk, if a database of U2F device key handles are leaked?

Enrolling a key works by:

  • Send Enroll request with "AppID" to U2F device.
  • U2F device answers with "Key Handle, Public Key".

Authentication works by:
Send Auth request with "AppID, Key Handle, Challenge" to U2F device. U2F device signs this and returns "Signed Challenge" to server.

"Key handle" is a opaque item, that might be a encrypted private key, that is encrypted by the U2F smart card controller, but it might also be information that is only usable for the smart card controller to regenerate the private key, like a seed that is put into a deterministic RNG that is unique for that U2F device, a HMAC generation routine (Yubico U2F uses this), or it might just be a simple ID that Points to internal storage in the U2F key, but that would limit the number of websites the U2F key can be enrolled with.

According to the standard, the user should be authenticated by username+password Before starting U2F authentication.

But lets say we omit the password completely, and instead allow the user to put in their username, then they are taken to the U2F authentication, and voilá, they are in.

This however, would mean a malicious user could enumerate out all key handles, thus leaking all key handles in database.

Would leaked key handles be a security risk? It seems that it should not be, but since key handles could contain encrypted private keys, they could be (?). A key handle would not be useable by a Another site than its designated AppID anyways, since the U2F device would reject any authentication attempts that uses a "stolen" key handle. However, this is enforced by the client software/browser, since a malicious client software/browser could simply fake the AppID.

2

Bottom line: If by "risk" you mean risk of exposing your service to the potential for remote attack, then no, there is no additional risk as long as the FIDO U2F tokens have been implemented properly.

However, access to this information does allow someone with physical access (via NFC, for example) to the token to easily confirm whether a given token is associated with a specific account or not. For example, if I suspect an association between a specific person (who uses an NFC U2F token, like a Yubikey NEO) and a user on your website, then I could quite easily verify this suspicion without their knowledge if I can get physically close enough to their token.

Different tokens may also have different lengths of the key handle. If the user uses a token with an unusual key handle length, then this may be be a method for helping to rule out token models.

If there happens to be a weakness in the FIDO U2F implementation on the token a user is using, then there is a chance it could be taken advantage of—but in that case the token's implementation is probably the larger issue.

Ultimately I think the decision to do something like this depends on your security requirements. What are the implications of someone associating one of your accounts to a specific token/person?

Also keep in mind that eliminating the password requirement reduces you back to single factor authentication.

  • I would say that it would be no security issue if someobody with physical access to the token would be able to associate the token with a specific account. Yes I know it would reduce to single-factor authentication. The security model should be evaluated with the attacker having no physical (or remote access) to a physical token. However, there might be the case where a user might have temporarly access to a U2F token while not near a verifying device. Thus the token must be uncopiable. But that is already considered by using the challenge/response model of authentication. – sebastian nielsen Jan 21 '15 at 10:50
  • The security issue I talk about here, is if a attacker might be able to decrypt or otherwise compromise the key handle in such a way that the attacker could authenticate to the very same site using the compromised key handle. Since using the above scheme specified in my question, it would allow anyone to get anyone's key handle for that particular site. If the key handle could be compromised without having access to the token, in a way that the site-specific private key is leaked, the attacker would reduce authentication to zero. However, I know the core key is impossible to extract or deduce. – sebastian nielsen Jan 21 '15 at 10:53
  • If your concern is exposing your service to the potential for a remote exploit, then I agree with you that there is no additional risk as long as the FIDO U2F token is implemented properly. – darco Jan 22 '15 at 17:34
0

Yes, leaking U2F "AppParam / KeyHandle" pairs should be considered as a security Risk. According to FIDO privacy concern: "identifying devices would reveal a unique identifier for a device across unrelated origins, violating the user’s privacy." (c) FIDO specs. So this leakage will at least allow an attacker to be able to identify the particular device.

Also note that a malware on Windows host can easily enumerate a 1000 of pairs (AppParam,KeyHandle) with an inserted U2F device without user iteraction. After the valid KeyHandle is identified, a malware then can easily simulate some UI action and make user to press a button on U2F to generate a Signature. And now suppose there will be a 0-day vulnerability discovered in U2F allowing to Sign any Digest without user iteraction?

And yes you are right, KeyHandle is an encrypted Private Key from ECDSA key pair. Here is FIDO designers statement regards KeyHandle: https://research.google.com/pubs/pub45409.html

It should be noted that key wrapping is an optional optimization vendors may employ, and that our implementation is one approach. The FIDO U2F specifications allow device manufacturers to choose any approach for key wrapping.

enter image description here

I never seen any open-source implementation of FIDO U2F device, even yubiko decided to keep this confidential: https://www.yubico.com/2016/05/secure-hardware-vs-open-source/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.