Hacker News Reader

Comment by filleokus | Hacker News Reader

I mean you could also design keys to be synchronisable by the user. Generate a key-pair inside of key (2), transfer the public key from (2) to (1). Encrypt the the root key inside of (1) with the public key, transfer it over to (2).

(Or just allow the user to generate the root key outside of the device and insert it)

I honestly think the interest from customers is just too low. I would bet the majority of Yubico's customers are enterprises where this is not really an issue for most use cases. If you loose your key used for Entra ID / SSO, just go to IT support and get a new one enrolled to your account. Much cheaper than having synchronised hot spares (at 30-50 USD a pop) for thousands of employees.

View on HN

But what stops Mallory from simply using this sync method to sync your private key to her Yubikey? I mean, look at the kerfuffle that's been kicked up by this vulnerability, and a key-sharing scheme like the above is much easier to exploit.

(The second idea seems better assuming the user nukes the private key once the import is done. Otherwise the weakest link in the security chain will continue to be the opsec you practice with the private key file, in which case why spend the money on the Yubikey?)

Yeah of course the operation needs to be (cryptographically) authenticated somehow, I edited my comment in haste while going to work and accidentally messed it up completely. Thanks for pointing it out!

The idea I thought of is to essentially use the public key of (2) to seed the generation of the root secret on (1). Meaning the sync-pairing-setup is destructive to the root secret, and can only be done at startup (or if you are willing to reset the device).

(A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)

> (A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)

You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.

I think the real issue here is that users probably don't expect having to reset/initialize a Yubikey once they take possession of it. Given the horror stories of how e.g. Amazon commingles inventory, I wouldn't be surprised if fraudsters could succeed in getting paired keys back into the supply chain.

Targeted attacks to friends/family can probably also not be ruled out ("hey, i got this spare yubikey in a black friday sale, want it?"), and unfortunately something like a family member or partner trying to take over somebody's accounts isn't unheard of.

There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.

[1] https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...

> You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.

Ah I did not know that, thanks.

> There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.

Would be interesting to see the draft. But yes of course, there are tradeoffs. Having a LED similar to on the Bio to indicate it's paired could be one way, or selling pairs in a SKU where the user actually have to initialise them (with some clear physical difference to help solve the family/friends case). But it's complicated, and I think Yubico has made the correct decision that it's simply not worth it (not that it's impossible to do in a secure way).

However, the lack of a resonable backup solution is keeping me away from Yubikey for any non-enterprise use, where a broken key would actually lock me out of an account for real.

HSMs support these kinds of scenario (high availability clusters, wrapped keys etc) but I agree. For enterprise use there's no interest or need, and for end users the feature would potentially be confusing.

I just use multiple tokens, and I knew that the infineon sle78 was an intel 80251 derivative before this report ;)

Reply on news.ycombinator.com