* 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://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).
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!
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.
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.
> 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…
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.
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).