Yubico Forum

...visit our web-store at store.yubico.com
It is currently Tue Jan 30, 2018 10:36 am

All times are UTC + 1 hour




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Mon Jan 11, 2016 3:09 pm 
Offline

Joined: Fri Oct 02, 2015 8:44 am
Posts: 4
The documentation here and here gives a very eloquently written explanation of how Yubico implements FIDO U2F. There is one thing I don't completely understand yet; what gets written to the device during the registration and authentication flows?

Am I correct in concluding that the device can deduce the service-specific private key from the AppId, the key handle, and its on-board private key? So what (if anything) is stored on the device? Counters for each key-handle?

Is there a way to show how many key-handles are used on a device? Is there a way to reset a device?

What I'm wondering about is if a key used for testing and development can be reissued to someone else safely, and if there is a practical limit to the number of services registered (I got the impression that there is no practical limit).


Top
 Profile  
Reply with quote  

Share On:

Share on Facebook FacebookShare on Twitter TwitterShare on Tumblr TumblrShare on Google+ Google+

PostPosted: Tue Jan 12, 2016 12:38 pm 
Offline
Site Admin
Site Admin

Joined: Mon Mar 02, 2009 9:51 pm
Posts: 83
For U2F the registration step makes no modification to the state stored on the YubiKey. The nonce which is generated (together with a MAC to ensure integrity) is output as the key handle, to be stored by the server. Thus nothing is changed on the device at this point.

For authentication, the key handle is passed to the YubiKey again, and it is verified. The MAC ensures that it has not been modified, and that the credential belongs to the given appId. Together with the master secret stored on the YubiKey, this is everything that is needed to derive the specific private key used for the credential. There is a global use counter which gets incremented upon each authentication, and this is the only state of the YubiKey that gets modified in this step. This counter is shared between credentials.

Because there is no credential-specific data stored on the YubiKey it is not possible to list the number of "stored" key handles (as they are not actually stored on the device). There is also no way to reset the device.

The only risk in re-issuing a key to someone else is if the key is already registered to some service where the previous owner forgets to remotely revoke the credential. For example if I were to give you my old YubiKey forgetting that it's currently associated to my Gmail account, etc.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jan 12, 2016 12:51 pm 
Offline

Joined: Fri Oct 02, 2015 8:44 am
Posts: 4
Thank you Dain, that makes sense — it seems like an elegant solution. I'll suggest an edit for the documentation as well.

Just out of curiosity; is there a theoretical limit to the counter? Or does it simply overflow back to 0 after reaching the limit of its storage?


Top
 Profile  
Reply with quote  
PostPosted: Wed Jan 13, 2016 5:26 pm 
Offline

Joined: Thu Oct 16, 2014 11:51 pm
Posts: 82
jdhoek wrote:
Just out of curiosity; is there a theoretical limit to the counter? Or does it simply overflow back to 0 after reaching the limit of its storage?


One of the benefits previously touted for U2F is that there's no serial # associated with the key, and that it should be difficult/impossible for two accounts data, either in the same services or a different service to be correlated in such a way as to point to a particular key.

How does the existence of a externally-readable global counter factor into this?

B


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 14, 2016 1:30 pm 
Offline
Site Admin
Site Admin

Joined: Mon Mar 02, 2009 9:51 pm
Posts: 83
jdhoek wrote:
Just out of curiosity; is there a theoretical limit to the counter? Or does it simply overflow back to 0 after reaching the limit of its storage?


I don't recall at the moment if it overflows or not, but in practice it doesn't matter. It's a 32 bit unsigned counter that is initialized to 0, so it would take over 100 years to happen even if you were to authenticate non-stop every second.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 14, 2016 1:31 pm 
Offline
Site Admin
Site Admin

Joined: Mon Mar 02, 2009 9:51 pm
Posts: 83
brendanhoar wrote:
One of the benefits previously touted for U2F is that there's no serial # associated with the key, and that it should be difficult/impossible for two accounts data, either in the same services or a different service to be correlated in such a way as to point to a particular key.

How does the existence of a externally-readable global counter factor into this?

B


It is possible that someone capable of eavesdropping on different authentications performed by the same device may be able to use the counter to connect different key handles with the same key. The recommendation in the U2F spec is that this counter starts with a value of 0. Assuming most devices use this recommendation, then the higher the value the more identifying it becomes. Taking an extreme scenario: Given a U2F device with this type of counter that has been used 1,000,000 times more often than the second most used device in existence will be clearly identifiable when it is used, as no other devices will produce counter values that high. To prove that these belong to the same device may still prove hard though, as you would have to disprove the existence of another similar device with an as high counter.

Important to note is that this in no way impacts the security of the protocol, but does potentially have ramifications for the privacy aspects of it.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group