Yubico Forum

Q: I'd like to understand the usage and reasoning behind each of the fields in the encrypted message, so I can be sure we use them all appropriately.

A: I beleive the means of cryptoanalysis would have to rely on the fact that some 110 bits of the 128 are deterministic, although not publicly known. Again, increasing the random field at the expense of the private ID would increase the non-deterministic part and we could consider doing that.

Given that each device has its own key, we beleive the effort needed for any form of serious cryptoanalysis on one device at a time would exceed the value the key is intended to protect.

I understand that each Yubikey shipped contains a different (unique?) AES key but I wondering if this is what's recommended when a number of keys are deployed in an organization. If my company wanted to deploy a large number of keys (i.e. 1,000) should they each contain a unique AES key or a common AES key? My assumption was the Yubikey was designed to prevent hacking and contained enough randomized data fields that would prevent plain-text hacking so a common AES key could be used.

I understand keys can be ordered from Yubico with the AES keys pre-programmed or they can be programmed on-site using the configuration too so it seems it may be up to the customer depending how comfortable they are with the chosen implementation.

Regards,
Tom

An excellent question - It has been up several times and I beleive we have not described excatly the intention.

I'll give it a shot - please let me know if there are any outstanding questions after it...

- The string outputed by the Yubikey consists of a fixed OTP part and an optional "public id" prefix
- The OTP is always the last 16 bytes (32 characters)
- The public id is as said optional and can consist of 0..16 bytes (0 - 32 modhex characters). If present, it is a prefix to the OTP
- The public id is typically used to identify which AES key to use for the Yubikey in question
- The public id is sent in clear text and can be spoofed. However, if anyone spoofs it, the AES key won't match and there will not be any meaningful output
- If there is no public id within an organization, all keys must share the same key as there is no way for the server to determine which AES key to use to decrypt/verify the OTP
- Alternatively, a different unique id or username can be used if no public prefix is used. One can argue that a key found on the street without a valid username/id is somewhat more secure than one with the public id string.
- The keys supplied by Yubico are configured by default to work towards our authentication server
- All keys have a randomized AES key and an uniquely randomized public id of 6 bytes, i.e. the OTP is 16 + 6 = 22 bytes = 44 modhex characters
- Given that the AES key is randomized, there is no guarantee that it is unique although the probability that it is not is very low, i.e. not worth trying
- The private id is a 6 byte identity stored inside the OTP that can be used to further verify the key. This can for example hold the user's real id for the application in question, and when the OTP is decrypted, that id is matched to a database record as well.

I hope these statements clear some open questions. If not, please let me know.

With the best regards,

JakobE
Hardware- and firmware guy @ Yubico