5 ms·

A very important issue with Key Vault is: what to do when the Hardware Security Module dies? All electronics fail or stop working at some point. How do you make

by venaoy 12y ago

A very important issue with Key Vault is: what to do when the Hardware Security Module dies? All electronics fail or stop working at some point. How do you make backups of keys that were on the HSM?

helper 12y ago
The AWS HSM service supports backing to your own HSM: http://aws.amazon.com/cloudhsm/faqs/ http://aws.amazon.com/cloudhsm/faqs/
lstamour 12y ago
You don't. Keys on an HSM never leave the HSM, is how I think it should work. But your keys in the HSM can encrypt secrets, separate from the HSM's keys, but stored with the same service. You could potentially distribute secrets to multiple HSM-backed services. It's equally possible that the service itself distributes your secrets amongst multiple HSMs. YubiHSM back in the day, I recall reading, was designed so that you'd want two HSMs, one generates random secrets, the other stores the secrets using keys that never leave the device, if I recall correctly. And the reason it needed two is that the generator would leak parts of its keys with the random data it produced, I think, and so to securely store them, you needed a second device with key generating turned off. I could be out to lunch here, never bought a YubiHSM nor do I have experience with corporate ones. My point, is that there are different uses for HSMs, and it's easy enough to have an insecure use of HSMs, even as simple as generating secrets and storing secrets on the same device. As to what to do if the key is lost, I suppose it's time to re-issue. :) The goal is to not make too many backups: keeping a key secret is more important than ensuring the key is widely available, right? So it's a balance....
- Spooky23 12y ago
  I don't know about a device operating at the scale that Azure is using, but the key stores on smaller Thales HSMs can absolutely be backed up to smart cards. Security of key material is all about procedures. With a private CA I helped to setup, we used a quorum based authorization scheme, and the collection of smart cards was distributed among different reporting lines to make collusion between employees difficult.
  - lstamour 12y ago
    Makes sense. At that point it's probably easier to find another part of the software stack to attack instead of the secrets itself. E.g. instead of getting the keys to the kingdom, just exploit a weakness in some signing software. Reminds me of that Microsoft certificate signing service for remote desktop (or something like that) for the feds (okay, maybe not but still...) that ended up generating certificates that would pass Windows Update checks for from-Microsoft validity. Google reminds me it was called "Flame". Ah, here it is: http://www.securityweek.com/microsoft-unauthorized-certificate-was-used-sign-flame-malware http://www.securityweek.com/microsoft-unauthorized-certifica... And it was revealed roughly a year before we learned about PRISM and such.

by venaoy 12y ago

A very important issue with Key Vault is: what to do when the Hardware Security Module dies? All electronics fail or stop working at some point. How do you make backups of keys that were on the HSM?

helper 12y ago

The AWS HSM service supports backing to your own HSM: http://aws.amazon.com/cloudhsm/faqs/ http://aws.amazon.com/cloudhsm/faqs/

lstamour 12y ago

You don't. Keys on an HSM never leave the HSM, is how I think it should work. But your keys in the HSM can encrypt secrets, separate from the HSM's keys, but stored with the same service. You could potentially distribute secrets to multiple HSM-backed services. It's equally possible that the service itself distributes your secrets amongst multiple HSMs. YubiHSM back in the day, I recall reading, was designed so that you'd want two HSMs, one generates random secrets, the other stores the secrets using keys that never leave the device, if I recall correctly. And the reason it needed two is that the generator would leak parts of its keys with the random data it produced, I think, and so to securely store them, you needed a second device with key generating turned off. I could be out to lunch here, never bought a YubiHSM nor do I have experience with corporate ones. My point, is that there are different uses for HSMs, and it's easy enough to have an insecure use of HSMs, even as simple as generating secrets and storing secrets on the same device. As to what to do if the key is lost, I suppose it's time to re-issue. :) The goal is to not make too many backups: keeping a key secret is more important than ensuring the key is widely available, right? So it's a balance....

Spooky23 12y ago
I don't know about a device operating at the scale that Azure is using, but the key stores on smaller Thales HSMs can absolutely be backed up to smart cards. Security of key material is all about procedures. With a private CA I helped to setup, we used a quorum based authorization scheme, and the collection of smart cards was distributed among different reporting lines to make collusion between employees difficult.
- lstamour 12y ago
  Makes sense. At that point it's probably easier to find another part of the software stack to attack instead of the secrets itself. E.g. instead of getting the keys to the kingdom, just exploit a weakness in some signing software. Reminds me of that Microsoft certificate signing service for remote desktop (or something like that) for the feds (okay, maybe not but still...) that ended up generating certificates that would pass Windows Update checks for from-Microsoft validity. Google reminds me it was called "Flame". Ah, here it is: http://www.securityweek.com/microsoft-unauthorized-certificate-was-used-sign-flame-malware http://www.securityweek.com/microsoft-unauthorized-certifica... And it was revealed roughly a year before we learned about PRISM and such.