5 ms·

I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets. Having said that, on certain Yubikeys you can store PGP keys on

by _vdpp 4y ago

I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets. Having said that, on certain Yubikeys you can store PGP keys on them, and put the same secret key on several different Yubis. If you’re relying on a hardware key it’s probably a good idea to have a backup key and make sure both are registered with whatever system you’re accessing. LastPass and GitHub at least support adding several different security keys.

sheerun 4y ago
A backup key could have ability to reject original one, problem solved...
- lxgr 4y ago
  How would that work in practice? Key/certificate revocation is notoriously hard.
  - withinboredom 4y ago
    With GitHub, you just remove it from your account. For 2fa, same story.
  - sdfgdfgbsdfg 4y ago
    Here's how YubiCo proposes to address this: https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ 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
lxgr 4y ago
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.
- withinboredom 4y ago
  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.
  - lxgr 4y ago
    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).
- _vdpp 4y ago
  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.
- TacticalCoder 4y ago
  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.
deleted 4y ago
[deleted]
adrian_b 4y ago
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.
- TacticalCoder 4y ago
  > 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).
  - miohtama 4y ago
    iPhones can do wipe on too many failed attempts as well: https://osxdaily.com/2021/05/27/set-iphone-erase-automatically-failed-passcode/ https://osxdaily.com/2021/05/27/set-iphone-erase-automatical...
- _vdpp 4y ago
  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.
TacticalCoder 4y ago
> 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.
- _vdpp 4y ago
  How is that seed any different from a password then?
  - Kab1r 4y ago
    For one, it's only ever seen once: during initialization.
    - jjeaff 4y ago
      In addition, I believe it is not stored on the device. So it can't be exhilarated.
      - rodgerd 4y ago
        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.
yuav 4y ago
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.
- thinkmassive 4y ago
  compliance != security

by _vdpp 4y ago

sheerun 4y ago

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

lxgr 4y ago
How would that work in practice? Key/certificate revocation is notoriously hard.
- withinboredom 4y ago
  With GitHub, you just remove it from your account. For 2fa, same story.
- sdfgdfgbsdfg 4y ago
  Here's how YubiCo proposes to address this: https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ 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

lxgr 4y ago

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.

withinboredom 4y ago
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.
- lxgr 4y ago
  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).
_vdpp 4y ago
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.
TacticalCoder 4y ago
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.

deleted 4y ago

[deleted]

adrian_b 4y ago

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.

TacticalCoder 4y ago
> 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).
- miohtama 4y ago
  iPhones can do wipe on too many failed attempts as well: https://osxdaily.com/2021/05/27/set-iphone-erase-automatically-failed-passcode/ https://osxdaily.com/2021/05/27/set-iphone-erase-automatical...
_vdpp 4y ago
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.

TacticalCoder 4y ago

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

_vdpp 4y ago
How is that seed any different from a password then?
- Kab1r 4y ago
  For one, it's only ever seen once: during initialization.
  - jjeaff 4y ago
    In addition, I believe it is not stored on the device. So it can't be exhilarated.
    - rodgerd 4y ago
      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.

yuav 4y ago

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.

thinkmassive 4y ago
compliance != security