Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Backbone of Cybersecurity: Hardware Security Modules

join.tech

Post reply on HN
Print view View original

21–30 of 38 posts

Re: The Backbone of Cybersecurity: Hardware Security Modules

#21

Post by riskable »

throwaway256346 wrote: post #14

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 usuall…

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!

Re: The Backbone of Cybersecurity: Hardware Security Modules

#22

Post by lobster2342 »

wslh wrote: post #7

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

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?

Re: The Backbone of Cybersecurity: Hardware Security Modules

#23

Post by throwway120385 »

lobster2342 wrote: post #22
wslh wrote: post #7

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

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,…

It's a whole "chain of trust" kind of problem just like X.509.

Re: The Backbone of Cybersecurity: Hardware Security Modules

#24

Post by ThePowerOfFuet »

throw0101d wrote: post #3

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://git…

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.

Re: The Backbone of Cybersecurity: Hardware Security Modules

#25

Post by nonrandomstring »

throw0101d wrote: post #3

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://git…

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.

Re: The Backbone of Cybersecurity: Hardware Security Modules

#26

Post by coretx »

throw0101d wrote: post #3

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://git…

* 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.

Re: The Backbone of Cybersecurity: Hardware Security Modules

#27

Post by bdamm »

riskable wrote: post #21
throwaway256346 wrote: post #14

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 usuall…

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).

Re: The Backbone of Cybersecurity: Hardware Security Modules

#28

Post by s4mw1se »

security starts at the shipping port

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.

Re: The Backbone of Cybersecurity: Hardware Security Modules

#29

Post by hedora »

bdamm wrote: post #27
riskable wrote: post #21

Earlier quoted context omitted.

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).

Re: The Backbone of Cybersecurity: Hardware Security Modules

#30

Post by lormayna »

lobster2342 wrote: post #22
wslh wrote: post #7

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

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,…

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.

Post reply on HN