You're getting it backwards though. You are right that the whole point of an HSM is to not leak secrets when connected to a compromised computer. However there's nothing wrong with a HSM device that can be initialized with a "seed" of your liking, as long as that initialization step is done in a fully offline / airgapped way.
Ledger (whose CEO was, before creating Ledger), one of the member of the team working on the FIDO specs, make a "hardware wallet" for cryptocurrencies that can run a FIDO app. And it's totally possible to initialize the seed of your liking for your U2F device.
Now I did test this a while ago (out of curiosity) and it all working but I'm not really using it atm: I don't know where it's at regarding the latest FIDO2 specs.
But the point is: what GP asked for can totally be done.
I understand some may want to move the goalpost and say: "ok but then the problem now is not losing your piece of paper where you wrote that seed". But that is another topic altogether that does change nothing to the fact that you can have an HSM used for U2F that can be backed up.
Seriously, though, paper is better for most people that managing device cloning or the like. Most people can have a notebook in their house as a backup-of-last resort. Asking folks to become HSM managers seems unlikely to lead to better outcomes.
You mean their CTO aka btchip, right? Current CEO is non-techie and was not directly part of founding team.
It is enough to have a means to wipe out any information contained in the device, including any master secret.
At that point, there should be a means to enter a new master secret in the blank device, before proceeding to use it normally.
If a device provides this feature and it does not contain any other secret information introduced in it by the manufacturer, then it allows the owner to have any kind of backup that is desired.
I am also one of those who would never use a security device that contains any kind of secret information that is not under my control.
Precisely. The Ledger Nano S (and probably the Nano X too) allows to do exactly what you describe, the very way you describe it (three wrong PINs, on purpose or not, and the device resets itself to factory default and, as you wrote, at that point it's unusable until you enter again a master secret (either your old one or a new one: the device has no way to know and doesn't care).
https://osxdaily.com/2021/05/27/set-iphone-erase-automatical...
It is not a device useful to have for an individual user. On the other hand, hardware password managers are useful for individual users.
As far as I understand, "real" HSMs (i.e. the expensive, rack sized type of security key) sometimes offer the ability to export their root key to other models by the same manufacturer using a specific ceremony.
Arguably this also significantly weakens the security of the keys protected in the HSM, but at least it does not automatically expose it to software.
This only needs to be done once. For example by booting an old computer with no wifi capabilities and no hard disk from a Linux Live CD.
> You'll need to generate the key on a less secure host to do that, though, which partially defeats the purpose of a hardware key in the first place.
I kinda disagree with that. I generated my key by throwing physical dice. No random number generator to trust here. I only needed an offline/airgapped computer to compute the checksum and that program cannot lie: I know the first 256 bits out of the 264 bits so the program computing the checksum cannot lie to me, it's only giving me 8 bits of checksum.
Then I only need to trust the specs, not the HSM vendor.
Now, sure, my old Pentium III without any hard disk and without any WiFi, without any physical ethernet port, may be somehow compromised and exfiltrate data through its fans or PSU or something but what are the odds here? Especially: what are the odds compared to the odds of having a rogue HSM vendor selling you U2F keys for which it fully knows the secret?
I'd argue this requires less trust than the trust required in buying a pre-initialized HSM device.
By doing that, you are increasing your trusted code base by several orders of magnitudes doing that. This might be fine for your purposes, but in a corporate environment, it might very much not be.
> Then I only need to trust the specs, not the HSM vendor.
You do trust the HSM (vendor) no matter how you use it. Ironically, the more modern a cryptographic protocol is, the more opportunity for surreptitious key exfiltration there is. This could be in the form of predictable (using a shared secret) initialization vectors, wrapped keys and much more.
You also trust an HSM to be more tamper-resistant and/or more hardened against logical attacks than a regular computer, or there would not really be a point in using one in the first place.