[HN Gopher] The Backbone of Cybersecurity: Hardware Security Mod...
___________________________________________________________________
The Backbone of Cybersecurity: Hardware Security Modules
Author : 5n00py
Score : 102 points
Date : 2024-06-10 07:46 UTC (1 days ago)
(HTM) web link (www.join.tech)
(TXT) w3m dump (www.join.tech)
| throw0101d wrote:
| If anyone wants their own HSM, Nitrokey and Yubikey sell them:
|
| * 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)
| RobotToaster wrote:
| 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)
| throw0101d wrote:
| * https://www.nitrokey.com/products/nethsm /
| https://github.com/Nitrokey/nethsm/
|
| * https://security.stackexchange.com/questions/246547/open-
| sou...
| madduci wrote:
| Also worth mentioning EJBCA from PrimeKey. They also sell their
| own HSM appliance
| throw0101d wrote:
| > _They also sell their own HSM appliance_
|
| 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).
| ThePowerOfFuet wrote:
| If @dang wouldn't hand me my arse, I'd be tempted to create
| accounts to upvote this multiple times.
|
| 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.
| nonrandomstring wrote:
| 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.
| coretx wrote:
| * https://www.nordicsemi.com/Products/Development-
| hardware/nRF... Only 10 bucks and can run OpenSK/Tock, FIDO2
| code, among other things. This way you save money and learn
| something.
| horeszko wrote:
| I built my own key-vault/HSM since I wanted to use various
| cryptographic algorithms (argon2 and signing JWTs) not supported
| by typical HSMs.
|
| repo for the software:
| https://codeberg.org/ChristopherChmielewski/cns
| nimbius wrote:
| 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/
| filleokus wrote:
| > Operation Time
|
| > 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?
| woodruffw wrote:
| That does seem exceptionally slow, although RSA key
| generation is also notoriously slow.
|
| (In most settings where an HSM is used, you shouldn't be
| generating keys all that often. So these times are often
| acceptable.)
| lossolo wrote:
| Just be aware of this https://github.com/polhenarejos/pico-
| hsm/issues/28
| wslh wrote:
| 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.
|
| [1] https://en.wikipedia.org/wiki/1-Click
| troyvit wrote:
| Good call. OnlyKey talks a little about it:
| https://docs.onlykey.io/security.html
| lobster2342 wrote:
| 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.
|
| Or dont i get it?
| throwway120385 wrote:
| It's a whole "chain of trust" kind of problem just like
| X.509.
| axoltl wrote:
| Two small notes on definitions:
|
| ---
|
| "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.
| throwaway256346 wrote:
| 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.
| p_l wrote:
| Any comments you could share about Luna HSM ones?
|
| Recall seeing a lot of them as reasonably accessible in cloud
| and not only setups, thus my interest.
| riskable wrote:
| 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!
| bdamm wrote:
| 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).
| client4 wrote:
| 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.
|
| * https://www.bunniestudios.com/blog/2020/introducing-precurso...
|
| * https://www.bunniestudios.com/blog/2024/iris-infra-red-in-si...
| dfox wrote:
| 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...
___________________________________________________________________
(page generated 2024-06-11 23:01 UTC)