| Yubico Forum https://forum.yubico.com/ |
|
| What gets stored on the keys? https://forum.yubico.com/viewtopic.php?f=33&t=2158 |
Page 1 of 1 |
| Author: | jdhoek [ Mon Jan 11, 2016 3:09 pm ] |
| Post subject: | What gets stored on the keys? |
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). |
|
| Author: | dain [ Tue Jan 12, 2016 12:38 pm ] |
| Post subject: | Re: What gets stored on the keys? |
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. |
|
| Author: | jdhoek [ Tue Jan 12, 2016 12:51 pm ] |
| Post subject: | Re: What gets stored on the keys? |
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? |
|
| Author: | brendanhoar [ Wed Jan 13, 2016 5:26 pm ] |
| Post subject: | Re: What gets stored on the keys? |
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 |
|
| Author: | dain [ Thu Jan 14, 2016 1:30 pm ] |
| Post subject: | Re: What gets stored on the keys? |
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. |
|
| Author: | dain [ Thu Jan 14, 2016 1:31 pm ] |
| Post subject: | Re: What gets stored on the keys? |
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. |
|
| Page 1 of 1 | All times are UTC + 1 hour |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|