I've been following some discussions on WebApp Security mailing list regarding WebCrypto and SOP policies (100+ messages). One of the things that kind of sprang out was keys held in WebCrypto were not enumerable because they could be used as super cookies, and that could have negative consequences for privacy. This was discussed on the WebCrypto list a while back, so its not new news. The leap is then usually made that its bad in all cases (which it often is).

(As a counter example to "it is always bad", I usually "don't care" about all the bug trackers I am subscribed to. If I can use one public key for all of them to authenticate, then great.)

WebCrypto is essentially a software layer, and it has infinite number of keys (some hand waiving). I then started thinking about my Yubikey... A Yubikey has finite space, so it only has a limited number of keys.

How many public keys can a Yubikey generate and hold?

How does a YubiKey protect privacy given organizations (origins) can collude and compare public keys registered with them?

(It wouldn't surprise me if a government or one of its authorized agents or partners started collecting the public keys and made them searchable in a database, much like Little Black Blox does for private keys).

  • Jww - can you edit this down to one question. "How many" is not a useful question here, so I'd focus on there collusion question. Please clarify. – Rory Alsop Sep 27 '15 at 13:40
  • @Rory - I'll leave it to your judgement. One of the reasons I was curious about the number of key slots available on a Yubikey is its often cited as the solution to nearly all authentication problems on the web. But it if only has room for two or four of them, then there's a problem in practice. – user29925 Sep 27 '15 at 14:14

Please refer to documentation which says that it can support "unlimited number of U2F credentials". I am assuming you are referring to U2F credentials since that is based on public/private key while the other OTP is based on symmetric key (which is limited to 1-2 slots). Now the obvious limitation of this is the memory and age of yubikey.

In most of standard deployment scenarios, you are going to generate unique public-private key for each site you are going to register the yubikey. This way the key for google and dropbox is going to be different. If google & dropbox want to identify "you", it may be easier for them to to identify "you" using user id and behavioural data (IP address). If yubikey is working properly (i.e. it has not been compromised to add device specific information in public key either explicitly or implicitly due to algorithm, PRNG weakness and other known public/private issues), there is no way for them to trace the two public keys back to single "you".

Update: The link explaining how U2F can support "infinite" public private/public key pairs without sharing the same key across sites AND storing the details locally.

  • I might be missing something obvious, but I don't believe a public key and a credential are the same thing in this context. – user29925 Sep 28 '15 at 20:26
  • AFAIK the U2F is what is being used by Google and Dropbox There seems to be disconnect between the yubikey documentation and U2F in terms of where the private key is stored. I – jhash Sep 29 '15 at 7:54

Your Answer

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