> I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets.

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.

> Ledger (whose CEO was, before creating Ledger)

You mean their CTO aka btchip, right? Current CEO is non-techie and was not directly part of founding team.

How is that seed any different from a password then?

It never comes into contact with the memory of a network connected system, therefore putting it beyond the reach of phishing or malware thus solving the overwhelming majority of risks actual passwords are exposed to.

For one, it's only ever seen once: during initialization.

In addition, I believe it is not stored on the device. So it can't be exhilarated.

I, too, find devices prevent exhilaration these days.

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.

The ability to have a backup does not imply any ability to exfiltrate the master secrets.

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.

> 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.

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).

iPhones can do wipe on too many failed attempts as well:

https://osxdaily.com/2021/05/27/set-iphone-erase-automatical...

If I’m the one entering the master secret in, then the device is a glorified password manager. The point of an HSM is that nobody, not even the user, can access the secrets. I’m not saying there isn’t a use case for such a device, or that it isn’t possible, only that the security guarantees you get from it are different. The security model you’re describing is the same as someone entering their secret key in the “notes” app in a phone, leaving it in Airplane mode with FDE and wipe after a certain number of incorrect PIN entries. You can call that a “HSM”, but it’s not what I’d consider one.

A password manager that does not allow one to log in to the wrong site is still very useful. Also, just because you're entering a master secret in doesn't mean it's any easier to get it out. The user could simply be required to generate the master secret herself and back it up on her own.

Sounds basically like a key store/loader like this one: https://www.cryptomuseum.com/crypto/usa/kyk13/index.htm. I have a little experience with its successor. There’s a legit purpose for it but it’s a different animal then an HSM in my opinion.

The device that you name "HSM" is the kind of device that is suitable for a company to distribute to its employees to login into the company network or servers.

It is not a device useful to have for an individual user. On the other hand, hardware password managers are useful for individual users.

For HSM with FIPS140 Level 3 certification the master key can only enter and leave in encrypted form. Backup/restore and cloning is possible, but there are mechanisms like hardware and firmware validation to ensure only the same type device and certified venfor software can make use of it.

compliance != security

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.

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.

But is that a problem though? I generated my own HSM/U2F keys throwing dice and the seed is basically just one 256 bit numbers. I did have, indeed, to compute a matching checksum (for the scheme I used represented the 256 bit numbers as a list of 24 words, out of a dictionary of 2048 words, where some bits of the last number acts as a checksum).

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.

> booting an old computer with no wifi capabilities and no hard disk from a Linux Live CD.

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.

You can generate the keys inside the yubikey. Then just have two keys instead of a shared key. That’s actually better IMHO since that allows you to revoke one of you lose it instead of having a compromised backup.

Ah, sure, if your use case allows registering multiple keys that is indeed a good way to solve it. Unfortunately that's not always the case (as pointed out in other threads).

Yeah, for the paranoid you’d have an air-gapped box with your PGP tools on it that you’d plug the hardware key into for setup.

A backup key could have ability to reject original one, problem solved...

How would that work in practice? Key/certificate revocation is notoriously hard.

Here's how YubiCo proposes to address this: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... Revocation is done RP side, but it essentially allows a primary authenticator to register itself and the secondary on a given RP

With GitHub, you just remove it from your account. For 2fa, same story.