Sure, but in general the expected value of a HSM is that (especially in FIPS mode) it prevents extraction and accidental leakage of the keys (and maybe at appliance levels has explicit logging).
If you're sure you never do a plaintext backup or anything else that might leak the key, then it may not matter. But it is a decent defense in depth measure for high assurance operations.
I heard a story once about a CA (public? private? not sure!) that had an airgapped root CA in a basement lab, only for an enterprising admin to run an Ethernet cable between their desk and the basement lab to save themselves a few trips... An online HSM may allow effective leakage (by allowing arbitrary signing operations), but hopefully would prohibit export by a crypto user and retain audit logs of all operations to identify scope of the compromise.
At some point, you end up reinventing an HSM from first principals. :-) My 2c.
If you use git-maintenance with a cronjob, and you like that the device ask you each time for more security, how do can you tell that the request is from git-maintenance?
You're a high-rep user, but this doesn't appear to be a valid Show HN[0] (unless you're Pol Henarejos)
Show HN is for something you've made that other people can play with.
The project must be something you've worked on personally and which you're around to discuss.
I don't think rp2040 has any protected storage. HSM is supposed to store keys securely, so even with physical access an attacker would require very advanced methods to extract keys. With typical raspberry pi's, all you need is to connect to the SPI flash and you'll get access to all its contents.
May be I didn't understand something about this project.
Also 124 seconds for RSA2048 sounds awfully slow. Is rp2040 really THAT slow? I feel something's wrong here.
It says it encrypts the SPI flash with a PIN provided over USB on every boot...but if you can trust the host to store/handle the PIN, why can't the host do the rest of the cryptography too?
AIUI the RP2040 has -- as a deliberate design choice -- no security features: no secure boot, and no debug protection. That means it is incapable of offering any firmware integrity, or keeping any data secret at runtime.
This looks really nice as a hobbyist project. That being said - I can't see this being usable in an enterprise space. There's no TPM requirement so someone able to get access to the HSM could dump the keys from memory.
The worst part of using HSMs in enterprise env's is when you're forced to use something certified for FIPS 140 Level 2 or 3 requirements.. Then you're paying for what amounts to a shiny foil "anti-counterfeit / tamper-evident" sticker. This could probably easily meet level 1 via a certified openssl module, but alas, with most enterprise HSMs you're not paying for the _HSM features_.
This looks like a nice piece of work but worth noting that as it uses a stock RP2040 Pico board any hardening against physical attacks will be done purely in software so cloning the HSM entirely or extracting keys may not be too complex for an attacker. Hardening against physical attackers and significant resistance against them is normally seen as a key component of an HSM.
Indeed from a very quick glance at the source, it's using the mbedtls library (from arm) and I think this is an unmasked implementation. This means key extraction, if you have physical access to the device, will be trivial.
> PKI Attestation for every key generated in the device
Either that attestation is meaningless and can be easily faked, or this is only as open-source as the TiVo was. Looking around a bit, it looks like it's the former.
17 comments
[ 2.8 ms ] story [ 53.8 ms ] threadIf you're sure you never do a plaintext backup or anything else that might leak the key, then it may not matter. But it is a decent defense in depth measure for high assurance operations.
I heard a story once about a CA (public? private? not sure!) that had an airgapped root CA in a basement lab, only for an enterprising admin to run an Ethernet cable between their desk and the basement lab to save themselves a few trips... An online HSM may allow effective leakage (by allowing arbitrary signing operations), but hopefully would prohibit export by a crypto user and retain audit logs of all operations to identify scope of the compromise.
At some point, you end up reinventing an HSM from first principals. :-) My 2c.
May be I didn't understand something about this project.
Also 124 seconds for RSA2048 sounds awfully slow. Is rp2040 really THAT slow? I feel something's wrong here.
Anyway it's a nice project!
The worst part of using HSMs in enterprise env's is when you're forced to use something certified for FIPS 140 Level 2 or 3 requirements.. Then you're paying for what amounts to a shiny foil "anti-counterfeit / tamper-evident" sticker. This could probably easily meet level 1 via a certified openssl module, but alas, with most enterprise HSMs you're not paying for the _HSM features_.
Indeed from a very quick glance at the source, it's using the mbedtls library (from arm) and I think this is an unmasked implementation. This means key extraction, if you have physical access to the device, will be trivial.
Either that attestation is meaningless and can be easily faked, or this is only as open-source as the TiVo was. Looking around a bit, it looks like it's the former.