Yubico Forum

Well, that's surprising and disappointing. I had just gotten into YubiKey (including implement OTP verification functions in erlang).

I was particularly impressed that I could write my own AES keys for OTP, and thus control the entire process, no need to trust a third party. Now it seems I have to trust that Yubico don't have a copy of the embedded and unchangeable key used to encrypt all my U2F keyhandles? Wow, I'm astonished at this mistake, can it really be true? Yubico obviously needs a copy of the AES key it installs in slot 1 for OTP, but it has absolutely no reason at all to care what key is used for the U2F. "No shared secrets"... except this one, the most important one!

Will this change in a future update?

Somewhat moot, given the above, but is the encrypted private key in U2F keyhandles also signed or MAC'ed?

Answering the second half of my own question with a "yes" (https://developers.yubico.com/U2F/Proto ... ation.html)

But I still need to be able to overwrite the 'device secret' in that diagram to use U2F over OTP.

Note that, if yubico ever gave you the ability to do such a thing (and I doubt they would), the attestation certificate would be void. Some sites, like banking websites, will likely balk at using a U2F key with a self-signed (or totally bogus even) attestation certificate. They could theoretically allow you to wipe the "device master secret" and generate a new key in the secure element, but someone could tamper with the device during this process to lower the entropy of the resulting key (glitching, etc), so I doubt they would ever do that, either --- at least not for their consumer-oriented products.

That being said, Yubico should probably elaborate on how the U2F "device master secret" is generated. Is it generated in the secure element when the device first starts up (which has pros and cons, but as long as the on-chip RNG is verified as operating properly then it should be ideal)? Or is it generated by a computer on the assembly line and loaded onto the device(Less ideal because yubico could theoretically be storing the keys without our knowledge)?

Keep in mind that the only identifying information in the registration info is which batch the key came from, so someone would have to have *all* of the security key "device master secrets" for that particular batch in order to be able to identify which secret is associated with some random registration info. This doesn't seem like an easy attack vector unless Yubico is a total push-over, which I find doubtful.

It is absolutely in yubico's best interest to not have any physical access to the "device master secret" in their U2F security keys. They are too much of a liability to the company's reputation.

Also, read this post for more info: https://www.yubico.com/2014/11/yubicos- ... -wrapping/

I'm new to these forums, but I'm correct that you don't represent Yubico?

As a consumer or as an administrator considering using YubiKey's U2F to secure access to a server farm, I'm not comfortable with Yubico having (or potentially having) the ability to decrypt all my private keys (aka keyhandles), and that ability is not stated (indeed, the opposite is implied in the U2F datasheets as "no shared secrets"). In both cases, the OTP feature appears more secure than U2F.

As for whether banks would allow third-party access tokens anyway, I am somewhat skeptical. My bank used to issue its own physical devices, but now uses its own smartphone app instead. I don't see them supporting a device where the secret key was generated by someone else.

I hope to hear from Yubico themselves. They've clearly recognized that the OTP mechanism can be repurposed from the default settings to wholly (and verifiably) private ones.

As for attestation certificates, I don't understand all the details or ramifications but it would appear to be the same category of validation that we get from the pre-installed OTP in slot 1 (namely, that Yubico know that AES key too). Validation, of course, that the personalization tools let us blow away (and later restore with an upload button).

Perhaps the point is that U2F support in YubiKey is aimed firmly (solely?) at the mass market, making the typical Web user's life a lot safer and that I'm barking up the wrong tree. I can get what I want from the OTP protocol (and, heck, I already implemented the verification code) but I remain a little puzzled that U2F here means that someone else knows the device secret besides the device. If that's really true, then I won't be using U2F myself.

To finish a long post (to an already [SOLVED] thread), I'd love to hear Yubico's explanation of how device secrets are kept secret even from Yubico (if they even are). And, if they're not, how we're supposed to reconcile that with the claim that U2F is superior to OTP by no longer sharing a secret value, when it clearly does in this case.

Correct, I don't represent, nor am I affiliated with, Yubico. I speak only for myself.

And, for the record, I agree that we need to hear from Yubico on how the keys are generated, as evidenced by me saying '"Yubico should probably elaborate on how the U2F "device master secret" is generated'.

That being said, I believe the idea is that the secret is intended to only exist on the token and nowhere else. I wouldn't be surprised if it is actually a FIDO U2F certification requirement.

The attestation certificate is actually to address this very issue. The idea is that the attestation certificate is a certification of the security of the device. If you trust who signed the attestation certificate (who presumably has performed a full security audit for that batch), then you can have an equivalently high trust that the U2F token has not been compromised. It is expected that certain types of services will only accept U2F tokens with attestation certificates signed by known trusted attesters.

The U2F attestation certificates used in Yubico's U2F tokens are signed by Yubico's own attestation CA, so we should hear from Yubico about how they audit their manufacturing process and secure element code per batch.

U2F is superior to OTP in a number of ways.

1. Using a U2F token is unphishable. OTPs can be phished. This isn't just a theoretical attack: such attacks are now occurring relatively frequently in the field.
2. Using a U2F token makes it almost impossible to execute a man-in-the-middle attack, even if Malory has control of a trusted CA and can forge trusted certificates. An OTP will offer zero defense for such an attack.

Not saying your concerns aren't valid, though. Let's see what Yubico says.

One thing to note: I see for privacy reasons that the attestation certificate does not identify a single token, but a particular (large?) batch of them. It therefore can't be directly coupled to the unique per-device secret. I wonder if those two things are entirely uncoupled? That is, it's possible to verify you have a legitimate signed-by-yubico key independently of the device secret.

Your two notes are very helpful, thanks for those.

To Yubico: rather than respond to the tail of this thread, I'm going to start a new one with a better title, coalescing what's been said here. It'll make it easier to find.

Thanks, please do! This is an interesting discussion.

done

[Edited by moderator]: The new topic can be found here.

Will lock here then.