3 ms·

If there is one thing I learned working with dedicated and eventually advocating for shared hsm (kms, managed hsm, etc) it's that HSM routinely have zero days t

If there is one thing I learned working with dedicated and eventually advocating for shared hsm (kms, managed hsm, etc) it's that HSM routinely have zero days that invalidate the ability to prove the key never left. I'm curious what folks feel like they are really getting when they buy a physical hsm in 2023? Do we really believe HSM vendors have a greater incentive to patch vulnerabilities than cloud providers who build services on top of them? I 100% trust google more than Thales to keep things patched, and provide the most trustworthy logs.

lxgr 3y ago
I agree that for low-level key operations (“wrap this key”, “sign that hash” etc.), there isn’t a lot of difference between trusting Thales or AWS/Google: If you just use them as glorified key derivation/unwrapping functions and expose the resulting keying material to your application servers, you don’t gain much from using either a hardware or cloud HSM (since your trusted domain includes your cloud-hosted application servers anyway). But for high-level operations, e.g. “validate whether the CVC of card 1234 really is 987” or “generate a signed command to top up this stored-value smartcard by $5” (or the equivalent in your domain), I’m not aware of any alternative that is as secure as a physically managed HSM. And arguably, that’s where HSMs make most sense.
- beardedwizard 3y ago
  Thanks for this - I have to admit I've never really seen an HSM doing the two operations you mention. The two cases I have seen are bulk crypto operations for SSL offload (costly, performance critical) and key wrap/unwrap/derive (less costly, less perf impact, but keys exposed to app). I guess the cases you mentioned are similar to bulk crypto in the sense you just get the answer back, rather than the ability to compute it yourself?
candiddevmike 3y ago
Everything regarding encryption keys, certificates, passwords, etc is really only as effective as how quickly you can replace them. Sure a HSM is really secure and powerful, but if it will take you a year to replace everything it generated after a breach, it's not an effective solution IMO. Build and implement this stuff with change and iteration in mind.

lxgr 3y ago

I agree that for low-level key operations (“wrap this key”, “sign that hash” etc.), there isn’t a lot of difference between trusting Thales or AWS/Google: If you just use them as glorified key derivation/unwrapping functions and expose the resulting keying material to your application servers, you don’t gain much from using either a hardware or cloud HSM (since your trusted domain includes your cloud-hosted application servers anyway). But for high-level operations, e.g. “validate whether the CVC of card 1234 really is 987” or “generate a signed command to top up this stored-value smartcard by $5” (or the equivalent in your domain), I’m not aware of any alternative that is as secure as a physically managed HSM. And arguably, that’s where HSMs make most sense.

beardedwizard 3y ago
Thanks for this - I have to admit I've never really seen an HSM doing the two operations you mention. The two cases I have seen are bulk crypto operations for SSL offload (costly, performance critical) and key wrap/unwrap/derive (less costly, less perf impact, but keys exposed to app). I guess the cases you mentioned are similar to bulk crypto in the sense you just get the answer back, rather than the ability to compute it yourself?

candiddevmike 3y ago

Everything regarding encryption keys, certificates, passwords, etc is really only as effective as how quickly you can replace them. Sure a HSM is really secure and powerful, but if it will take you a year to replace everything it generated after a breach, it's not an effective solution IMO. Build and implement this stuff with change and iteration in mind.