Tenement Farming and Cloud HSMs(unmitigatedrisk.com)
unmitigatedrisk.com
Tenement Farming and Cloud HSMs
http://unmitigatedrisk.com/?p=771
19 comments
The design pattern of maximal separation of thing that holds private keys from thing that needs access to secrets is great. That's my main lesson learned from this article.
I think this space is ripe for significant evolution.
Authors point re hashicorp vault being marginally better than checking keys into source control hits home. Eg often infra is one stolen ssh key away from having code committed that can select * from vault. That also comes with crappy provenance that doesn't integrate well with gitops.
My hopeful view is that we can incrementally fix this bottom-up:
1. ssh should use the mobile phone biometrics as HSM and expose that via ssh-agent
2. From there simple projects should use sops to commit their ssh encrypted secrets to git. I wrote https://github.com/tarasglek/github-to-sops to make it easy to share secrets this way. One can even use sshd private keys to separate secrets for infra from dev ones.
3. For more complex projects one can loop aws kms type hsms.
4. For more complex orgs we then need to borrow some cleverness from crypto ecosystem as they actually made a lot of progress in various tricks to derive trust/ownership...but instead of stupid blockchain one should keep using git.
5. This then can be extended down to database level mods where one could extend row-level ACLs with signature-based provenance checks in 4
Note I am in no way a security person. Just have a desire for someone to make this problem go away for us mere mortals.
I think this space is ripe for significant evolution.
Authors point re hashicorp vault being marginally better than checking keys into source control hits home. Eg often infra is one stolen ssh key away from having code committed that can select * from vault. That also comes with crappy provenance that doesn't integrate well with gitops.
My hopeful view is that we can incrementally fix this bottom-up:
1. ssh should use the mobile phone biometrics as HSM and expose that via ssh-agent
2. From there simple projects should use sops to commit their ssh encrypted secrets to git. I wrote https://github.com/tarasglek/github-to-sops to make it easy to share secrets this way. One can even use sshd private keys to separate secrets for infra from dev ones.
3. For more complex projects one can loop aws kms type hsms.
4. For more complex orgs we then need to borrow some cleverness from crypto ecosystem as they actually made a lot of progress in various tricks to derive trust/ownership...but instead of stupid blockchain one should keep using git.
5. This then can be extended down to database level mods where one could extend row-level ACLs with signature-based provenance checks in 4
Note I am in no way a security person. Just have a desire for someone to make this problem go away for us mere mortals.
Termux-API lets you access the Android HSM with a "how recent was the last unlock" limit attached to the key and a screen it can pop up to let you "unlock" without first locking.
Via PKCS11 libtergent.
Via PKCS11 libtergent.
I don't think the term "HSM" really carries much meaning, and if you're familiar with the space, you probably won't find it too shocking to hear someone claim that Amazon has put more cryptographic expertise to bear on KMS than has been embedded in any of the well-known rackmount HSMs.
I’m still not totally convinced that the HSMs are tamper evident. I’ve read (ok perused) the compliance reports, and they just say ‘yeah we have HSMs and they’re secure’, but what assurances can consumers have with the integrity of the hardware, short of being able to walk into a datacentre (never going to happen), install their own product, and lock the rack with their own key?
It’s unreasonable, expensive, and probably unnecessary and irrational for the vast majority of customers, but it still niggles at me from time to time.
It’s unreasonable, expensive, and probably unnecessary and irrational for the vast majority of customers, but it still niggles at me from time to time.
I lately dealt with some infrastructure issue, involving HSM. Literally "we have HSMs and they're secure", except they don't work, and audit logs are non-existing. And if you enable them, they sometimes work (mostly not), and give output in some undocumented binary format. Not fun experience.
I am personally involved in procurring HSMs for regulatory reasons. I would be more than happy to deploy an alternative solution that's demonstrably better suited for threats in todays typical cloud environments and fight it out with the regulator. The author sadly doesn't answer that question. Anyone having an idea?
How about confidential computing, e.g. AWS Nitro enclaves, Intel TDX etc?
HSMs make most sense when they’re performing high-level operations (“Is this credit card CVC valid?”); when used as signature or decryption oracles (“Hi, I’m a trusted application server, now sign this email!”) their security gain rapidly diminishes.
Sometimes they get used for key storage alone (“Hi, I’m an application server booting up, give me the RSA signing key for account x!” or even worse “Hi, I’m an application server booting up, give me the key wrapping all the user keys in our database!”), with obvious implications.
Getting an HSM vendor to implement your use case can get very expensive; confidential computing lets you do it yourself, i.e. draw a much larger “trusted” box in your architectural diagram than otherwise feasible.
HSMs make most sense when they’re performing high-level operations (“Is this credit card CVC valid?”); when used as signature or decryption oracles (“Hi, I’m a trusted application server, now sign this email!”) their security gain rapidly diminishes.
Sometimes they get used for key storage alone (“Hi, I’m an application server booting up, give me the RSA signing key for account x!” or even worse “Hi, I’m an application server booting up, give me the key wrapping all the user keys in our database!”), with obvious implications.
Getting an HSM vendor to implement your use case can get very expensive; confidential computing lets you do it yourself, i.e. draw a much larger “trusted” box in your architectural diagram than otherwise feasible.
What's the reg you're up against that says your need an HSM?
E.g. this: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisati...
I am aware of industry talks of lobbying on behalf of HSM manufacturers that led to these requirements and that's just sad.
I am aware of industry talks of lobbying on behalf of HSM manufacturers that led to these requirements and that's just sad.
Pretty sure ETSI demands it for trusted service providers https://portal.etsi.org/TB-SiteMap/ESI/Trust-Service-Provide...
With rack mount HSM, I can monitor for physical access with security camera.
When it is on cloud, who knows what?
When it is on cloud, who knows what?
The obvious solution is to use a cloud security camera! It might even be showing a real server rack somewhere.
...and many of the cloud providers with HSM-backed services (Azure KeyVault, AWS KMS) don't give you any verifiable proof. At least with GCP you can download the attestations and verify them with the HSM vendor. With Azure you pay more for HSM-backed keys with no evidence the HSM exists or is in use. Trust, but verify.
The drawback is that they are very expensive, so you have to be really paranoid to want to use them, and they are new enough and complicated enough that you have to trust us and our auditors to have done everything right.