Lots of folks sell appliances, but if you want to homelab, DIY, or do a small-scale deployment then the above items are simply USB keys so that be put into any server (or VM, via pass-through).
A very helpful and practical reply, thank you. Good to see how this
getting more practical for everyone. Sure, there are 'issues' with
HSMs, but in general they make for better security for operators that
fully control them in the ways you've shown how.
Do you know where I can find the source for the nitrokey HSM 2 hardware? It claims to be OSH but I can't find the schematics on their github? (Probably I've just overlooked it, they have a lot of repos)
I work with industrial HSMs (those expensive ones) on a daily basis and their SDKs are a bugfest (both client side and in-device). They are audited (FIPS140-2 and now 3 approved even!) but apperantly testing the firmware against the test vectors from the RFCs is too much too ask for...
Contacting support about broken firmware or broken documentation is a trip to tartarus in itself. Decompiling the libraries is usually faster to figure out what is wrong.
Don't put too much trust in them unless you really have to.
The problem is that certification takes SO LONG and they're not allowed to change the firmware while it's being certified or afterwards. What this means that FIPS certification is an indication of an inherently insecure device.
It literally means it hasn't been receiving regular security patches/updates!
Nobody actually runs HSMs in FIPS mode anyway. FIPS certification just means it can be run in a FIPS mode, and that it did at one time pass the certification. So while it is a very useful hurdle to jump over, it is impractical to use (for the same reasons you mention, and others).
The only time I've paid close attention to a FIPS certification process, they forced us to substantially weaken the security posture of our product by making it easier for attackers to exfiltrate keys in certain circumstances (the product was designed to be run in trusted environments, and there were many less-theoretical attack vectors, but the FIPS process didn't care about those).
Anyway, it hasn't been a useful hurdle to jump over in my experience. At this point, if a system has a FIPS compliance mode, that lowers my opinion of its real-world security properties. If someone voluntarily insists on using FIPS-compliant stuff, I assume they're completely incompetent in all matters, professional and personal (that heuristic has worked for me 100% of the time).
A tangential topic studies how you can actually trust the hardware. Andrew "Bunnie" Huang has done a lot of great work in the area, first with Precursor, and lately with Infra-Red, in situ (IRIS) inspection of silicone.
"Secure Elements / Hardware Roots of Trust: Embedded within chips, these elements provide a secure base for trusted operations and are often used in mobile devices and IoT applications."
SEs (Secure Elements) are discrete components. Smartcards and SIM cards are examples of SEs. They are different from a root of trust. When talked about in a cryptographic context a 'hardware root of trust' is usually a public key embedded in an immutable ROM.
---
"Secure Enclaves: These provide isolated execution environments within a CPU..."
Not necessarily within a CPU. Apple has the SEP (Secure Enclave Processor) which is a discrete core on the die.
I see many people here recommending products without the caveats included in the article such as tamper-resistant features. It is a warning for 1-Click [1] users.
Yeah, there is one flaw that I recently noted: how does the HSM authenticate legitimate users?
Like "I am an app, dear HSM, please perform following crypto operation for me."
If an attacker can pretend to be a legitimate HSM user, then she does not need key access, she just asks the HSM to perform a crypto operation on her behalf.
On the other hand, if the HSM needs secrets in order to authenticate legitimate users, then those secrets are prone to those attacks, against an HSM shall protect.
You're absolutely right: If a HSM is just used as a signing/decryption oracle, it doesn't add much value.
They're most useful if they can perform high-level operations, such as "please validate whether the entered card PIN <encrypted PIN block> here matches <PIN verification value on file>, given <credit card number>". The output of that example operation would only be a single bit of information (yes or no), rather than e.g. leaking the entire correct PIN, or even just the decrypted PIN that was entered at the POS.
But even just a signing/decryption oracle can be a step up from just storing long-lived private and secret keys on your application servers, where you'll never know for sure whether they were exfiltrated at some point.
Disclaimer: I have worked in the past for one of the major HSM vendors, but things can be changed in the last years.
To authenticate an application, you should generate a client certificate and share to the application, in order to create a mutual authentication trust. When you request some operations to HSM you need to authenticate yourself with the certificate. Of course the certificate must be kept as a secret and not shared with anybody.
There is also a sort of RBAC scheme related to client certificate.
Not really, since that would just be kicking the can down the road. Yes, you can have authentication between application servers and HSMs, but ultimately, whatever credential is used for that can be stolen from the application server, and then whoever has it can talk to the HSM.
The real benefit of HSMs is that they can make low-level keys accessible via a high-level interface that restricts the type of operations that can be performed at all. For example, an HSM will never just hand raw keys to application servers, but rather only let them perform various operations (based on their permissions). The higher level and specific these permissions are, the better.
if anyone wants an open source HSM on the cheap based on a raspberry pi that is pkcs11 compatible, check out the picohsm project https://www.picokeys.com/pico-hsm/
This definitely seems useful, but it's arguably not an HSM. It's literally downloadable software! (You wouldn't download an HSM.)
HSMs of course also run software, but they usually provide at least some level of hardening against physical attacks. In other words, it shouldn't be possible to just extract key from them. Is that the case here?
I think it would be more honest to call this a (possibly hardened) key server/service. Often, that's all people want from an HSM! But sometimes it isn't (whether for compliance or other reasons).
Just seeing a flood of comments of everyones cheap $10 dollar devices got me thinking…
How do you actually check the integrity of the HSM, both at the software level and hardware level?
The companies hosted open source repo is only worth a shit if you can verify the integrity of the software on the device.
Do any vendors ship with verifiable Hardware Bill of Materials and Software Bill of materials? How do you know the device you got 2 years ago didn’t have a zero day in a common library disclosed a year after?
Because if you can’t continuously check the integrity of your device… well you don’t know if it’s actually secure.
There's no way around trusting your hardware vendor (and often the software they ship it with as well; at least the OS is usually closed source and not user-installable, at least in the case of smart cards, which are arguably just HSMs in a different form factor).
Traditionally, the industry has been addressing this via audits and commercial agreements.
I particularly like the Luna USB HSM 7 that the DNSSec root is in the process of switching to. But price of the thing is truly ridiculous, especially for its handheld form-factor.
For a long time (10 years?) I'm thinking about how I would design an (possibly open source) HSM and I'm pretty sure that I have reasonably secure and tamper proof design (including external tamper input, which was the obvious feature for the original application I had in mind). But well, the idea of putting all that into handheld device with no battery…
* https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7
* https://www.yubico.com/product/yubihsm-2-series/yubihsm-2/
Consider buying two to have backups ((encrypted) export/import-backup/restore is supported).
Creating your own CA:
* https://docs.nitrokey.com/hsm/mac/certificate-authority
Considering using 'helper software' for running a CA:
* https://github.com/smallstep / https://smallstep.com/docs/step-ca/
* https://github.com/OpenVPN/easy-rsa
* https://hohnstaedt.de/xca/
* https://github.com/FiloSottile/mkcert (good for on-one-host dev stuff)
If you want to save some cash, get the Smartcard-HSM; the Nitrokey HSM is exactly that inside a different housing.
https://www.smartcard-hsm.com/features.html
Don't trust software with secrets.
Newb question, how do use opensk/tock as an hsm? A quick search points back at this thread.
Lots of folks sell appliances, but if you want to homelab, DIY, or do a small-scale deployment then the above items are simply USB keys so that be put into any server (or VM, via pass-through).
* https://security.stackexchange.com/questions/246547/open-sou...
Contacting support about broken firmware or broken documentation is a trip to tartarus in itself. Decompiling the libraries is usually faster to figure out what is wrong.
Don't put too much trust in them unless you really have to.
It literally means it hasn't been receiving regular security patches/updates!
Anyway, it hasn't been a useful hurdle to jump over in my experience. At this point, if a system has a FIPS compliance mode, that lowers my opinion of its real-world security properties. If someone voluntarily insists on using FIPS-compliant stuff, I assume they're completely incompetent in all matters, professional and personal (that heuristic has worked for me 100% of the time).
Recall seeing a lot of them as reasonably accessible in cloud and not only setups, thus my interest.
repo for the software: https://codeberg.org/ChristopherChmielewski/cns
* https://www.bunniestudios.com/blog/2020/introducing-precurso...
* https://www.bunniestudios.com/blog/2024/iris-infra-red-in-si...
---
"Secure Elements / Hardware Roots of Trust: Embedded within chips, these elements provide a secure base for trusted operations and are often used in mobile devices and IoT applications."
SEs (Secure Elements) are discrete components. Smartcards and SIM cards are examples of SEs. They are different from a root of trust. When talked about in a cryptographic context a 'hardware root of trust' is usually a public key embedded in an immutable ROM.
---
"Secure Enclaves: These provide isolated execution environments within a CPU..."
Not necessarily within a CPU. Apple has the SEP (Secure Enclave Processor) which is a discrete core on the die.
Arguably especially not within a CPU. When I hear "isolated execution environments in a CPU", I think TEE (e.g. ARM TrustZone), not Secure Enclaves.
[1] https://en.wikipedia.org/wiki/1-Click
Like "I am an app, dear HSM, please perform following crypto operation for me."
If an attacker can pretend to be a legitimate HSM user, then she does not need key access, she just asks the HSM to perform a crypto operation on her behalf.
On the other hand, if the HSM needs secrets in order to authenticate legitimate users, then those secrets are prone to those attacks, against an HSM shall protect.
Or dont i get it?
They're most useful if they can perform high-level operations, such as "please validate whether the entered card PIN <encrypted PIN block> here matches <PIN verification value on file>, given <credit card number>". The output of that example operation would only be a single bit of information (yes or no), rather than e.g. leaking the entire correct PIN, or even just the decrypted PIN that was entered at the POS.
But even just a signing/decryption oracle can be a step up from just storing long-lived private and secret keys on your application servers, where you'll never know for sure whether they were exfiltrated at some point.
To authenticate an application, you should generate a client certificate and share to the application, in order to create a mutual authentication trust. When you request some operations to HSM you need to authenticate yourself with the certificate. Of course the certificate must be kept as a secret and not shared with anybody. There is also a sort of RBAC scheme related to client certificate.
The real benefit of HSMs is that they can make low-level keys accessible via a high-level interface that restricts the type of operations that can be performed at all. For example, an HSM will never just hand raw keys to application servers, but rather only let them perform various operations (based on their permissions). The higher level and specific these permissions are, the better.
> RSA key length (bits) Average time (seconds)
> 1024 16
> 2048 124
> 3072 600
> 4096 ~1000
That must be a typo, that they mean milli seconds - right? Otherwise this seems too slow to do anything useful?
(In most settings where an HSM is used, you shouldn’t be generating keys all that often. So these times are often acceptable.)
HSMs of course also run software, but they usually provide at least some level of hardening against physical attacks. In other words, it shouldn't be possible to just extract key from them. Is that the case here?
I think it would be more honest to call this a (possibly hardened) key server/service. Often, that's all people want from an HSM! But sometimes it isn't (whether for compliance or other reasons).
Just seeing a flood of comments of everyones cheap $10 dollar devices got me thinking…
How do you actually check the integrity of the HSM, both at the software level and hardware level?
The companies hosted open source repo is only worth a shit if you can verify the integrity of the software on the device.
Do any vendors ship with verifiable Hardware Bill of Materials and Software Bill of materials? How do you know the device you got 2 years ago didn’t have a zero day in a common library disclosed a year after?
Because if you can’t continuously check the integrity of your device… well you don’t know if it’s actually secure.
Traditionally, the industry has been addressing this via audits and commercial agreements.
For a long time (10 years?) I'm thinking about how I would design an (possibly open source) HSM and I'm pretty sure that I have reasonably secure and tamper proof design (including external tamper input, which was the obvious feature for the original application I had in mind). But well, the idea of putting all that into handheld device with no battery…