- U2F Tokens cost $8-$25 and are significantly cheaper than full-blown Yubikeys
- U2F Tokens do not have a key limit, which enables using a unique public key per server for privacy/anonymity
[1] https://github.com/openssh/openssh-portable/blob/master/PROT...
They must have some limit. EC Keys are roughly 32 (256 bit) or 48 (384 bit) bytes (x2 to store the public half, right?), and most of these devices don't have MB of storage afaik... I think they have security chips with like 64-256kb of secure storage. So once you get into the range of thousands of sites, wouldn't you run out of room?
ETA: thanks akerl, I didn't realize that's what they (or most of them) were doing; I didn't even realize deterministically generating an EC key from a seed was efficient enough to do it quickly on a tiny embedded chip.
The OpenSSH protocol doc alludes to this requirement when they talk about why U2F needed a custom method for interfacing with SSH: the site’s handle needs to be provided as input to the key, so that it can re-derive the site-specific private key, and that communication channel didn’t already exist in ssh-agent.
The handle (IIRC the FIDO spec calls it a cookie but that doesn't matter) is NOT chosen by the relying party (in this case a SSH server you're logging into). It's chosen by the token itself during the enrollment process and given to the relying party with the other results of enrollment to be stored.
The token will use local random data in addition to random data supplied by the relying party for choosing a private key (and thus in the design you describe, the handle). This is a common design choice in cryptographic systems because it means if either Alice OR Bob really used random numbers the results are truly random, things only go badly if both parties defect.
In WebAuthn this means if you use your token to enroll with Google, and Facebook, and say Twitter, so long as the people who built the token did a good job it won't matter if both Google and Facebook are trying to betray you and deliberately didn't use random data, they can't attack your Twitter account this way.
Edit: refer to the device as a "token" not a key for clarity
Nothing in my comment implied that if google betrayed you, it would leak your facebook token.
One example way you can do this goes like this:
* Token has a Secret Key S baked inside it
* During enrollment the token makes a random private key P1 and a corresponding public key K1
* It makes a Cookie C1 by encrypting P1 using S
* It signs a message Ma with P1 to produce Za
* It sends C1, K1 and Za
The relying party gets to influence Ma but they do NOT get to pick any of these other values like P1, C1, K1.
The relying party verifies that Za is indeed a signature of Ma with K1 and if so enrollment worked, store C1 and K1
Now, after enrollment the relying party can produce new challenge messages Mb Mc Md and so on for ever, and each time it supplies the token with C1.
Given C1 and Mb, the token can decrypt C1 with S to get back P1, and then it can sign Mb with P1 to produce Zb. It sends that back.
The relying party can confirm that Zb is a signature of Mb with K1 and so this must be the genuine token that was enrolled previously.
AFAIK It does not.
And if it does not, your explanation contains bigger errors about enrollment/process.
@akrel described it much better.
You've become fixated on the part akerl_ (not @akrel) got right, that tokens don't store the private key but missed the _essential_ element they got wrong which is how this key is generated.
One really obvious consequence of things working as I explained rather than as akerl_ (presumably mistakenly not maliciously) explained is what happens if we do enrollment again with the same token for the same Relying Party, for example maybe Alice and Bob are a couple sharing a token.
In reality, as in my explanation, these enrollments produce completely different results, the token will pick a random P1 (thus K1, C1, etc.) when Alice enrolls and a different random P2 (thus K2, C2, etc.) when Bob enrolls, and for the Relying Party everything is different between these two enrollments, just as if the token was different.
In akerl_'s description Alice and Bob would get the same application ID, same results, and now a Relying Party can tell that Alice and Bob are using the same token.
(a) you can exclude those explicitly with a tiny amount of effort
AND
(b) probability of picking any such number for a 128-bit key is insignificant
This is also available on PKCS/OpenPGP for some tokens (and not only for auth keys). See: https://developers.yubico.com/PIV/Introduction/PIV_attestati... and https://developers.yubico.com/PGP/Attestation.html
On top of that, U2F tokens have no memory.
This makes them more durable and make the chipset even smaller.
I don't know whether FIDO2 has the same design.