-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how to avoid the pico-hsm firmware be dumped from its flash and run on other pico boards #42
Comments
It’s impossible to avoid it due to the design of Rpi2040. Keys are encrypted with AES256 32-bytes key (master key) and this is encrypted using the hash of your PIN. Therefore, without knowing your PIN is not possible to decrypt the keys. BUT if your flash is dumped to a disk nothing prevents an attacker to do a brute force attack during hours, weeks or months. It will depend on the robustness of your PIN. All the security system depends on your PIN as the input vector. |
Just a thought - Could we hash PIN + pico_unique_board_id for encrypting the DKEK to break simple copy of flash like this? |
|
Maybe the new pico 2 contains all the needed features, atleast the arm version, but I guess the anti-fuse OTP is sufficient |
I’ve not have time to read it carefully but with a quick overview I do not see nothing related with antidumping. There’s a secure boot and an example of encrypted partition, which is great for keeping secrets and allow executing signed code (great!). It will prevent to run tampered code to get keys. In case you loose the device, an attacker will not be able to run a modified Pico HSM to debug the keys. However, this is not far from what Pico Keys do. Now we are encrypting the keys with a master key, doubly encrypted by the user PIN. With the new Pico 2 certainly it is an important improvement having OTP keys, but if it is still possible dumping it I do not see a major step forward. Do not get me wrong, having a 32-byte random key is better than a only PIN-based scheme, specially if they are just 6 or 8 bytes, but ideally, to increase notably the security, dumping should be blocked. Note that having a separate QSPI flash separated from the SoC will be always vulnerable since buses can be sniffered with a probe. Even if the communication with the flash and SoC is encrypted, in terms of security this is not enough, as a true secure enclave should be integrated into a single dice (and there’d be some non-trivial problems). If an attacker can dump the flash region, regardless if it is encrypted, it can be stored offline and try to decipher, even if you recovered the device and he does not have access anymore. This is why you should revoke all you keys if you suspect that your device has not been in your custody 24/7. There’s a version RP2354 that will have integrated a flash memory whicy might be use for security purposes. It will be a huge improvement if this flash is not dumpable but I cannot ensure right now. Besides this, a specific USB board mounting the RP2354 will also be needed and manufactures by someone, which is not sure. Said that, for sure I’ll give suport to the new Pico 2 and RP2350/4 as soon as I grab one. |
Yes, if the OTP is world readable, then this is senseless. I'm not sure if you can mask some of those OTP (similiar to the ESP32 functionality) as input to a PUF (physical unclonable function) which then generates the key. //Edit:
|
The RP2350 has other security improvements like a security mesh, better defenses against glitching, ... It will definitely be an improvment. |
does ESP32-S3 have the same problem? |
Yes, all ESP32 boards have the I am reading the RP2350 datasheet and it seems to me that now RP2350 and ESP32-S3 are equivalent in terms of security. |
FYI: https://github.com/raspberrypi/rp2350_hacking_challenge I wouldn't say that this is a security issue. Any security token should be physically protected. As long as the encryption is implemented correctly, there is nothing to worry about. The only benefit of dump-protected storage is legacy code protection and buying time for invalidating the protected data. Which attacker is capable of stealing your hsm and extracting the OTP key with power glitch attacks, cloning it to a new device, put your hsm back and running the clone? |
Of course, it is a complex threat model. But, if you loose your pico and an attacker dumps your flash, will you confident for the rest of your life that the content will not be decrypted? I would not bet on that. The standard procedure is to revoke all the keys, just in case. After reading the datasheet, I was thinking on a method to store ECC keys permanently in the OTP memory. Of course, they'd be non-deletable, but you could store almost 2k keys securely. Having a couple pages, would allow you to store up to 64 keys (256 bit each), which is a true secure approach. They will not be accessed never, just through the firmware and, combined with the secure boot with a signed firmware, will make impossible to install any other firmware that dump the OTP. But, even with this approach, you will use a private key to sign the firmware, which is in turn a security problem as you must keep your signing key secretly. This is a typical circular problem. In this scenario, an attacker will need your computer storing the signing key, know the passphrase you use to protect the key (or the methods you use to protect the signing key) and have physical access to your pico to install the malicious firmware. The good part is that this is a typical scheme employed by Microsoft or Apple, as in the end there's a key to sign the firmware. How you protect the signing key is up to you and out of scope of Pico. Just thinking loudly. |
Ok, I loose somewhere my HSM (FIDO2 or openpgp). Now someone finds it. This person needs to know that this is a security token, has to be evil and interested in my personal credentials. That would be a very good reason to use a smart card with or without an usb interface. |
Prehaps single master encryption key can be stored there, and have validated firmware (which won't allow exporting that key in any way) use that to decrypt any number of keys in writable flash, or even sent over USB and stored externally. Firmware can also "burn" OTP blocks to store failed PIN entry attempts, to have multiple of those in a row prevent access to the device secrets permanently. But all that is probably only useful when targeted physical attacks are a concern, where getting more dedicated hardware might be a better idea, as that'd likely have much lower cost/inconvenience compared to other physical security measures anyway. |
This is what is done right now. A key is stored in OTP and MKEK is hashed with the PIN and this OTP key, if available. The MKEK is the key that encrypts/decrypts all the keys in the flash memory.
I don't think this extreme solution is necessary. Having the PIN attempts in the OTP would potentially block permanently the device if excessive attempts are introduced. However, you can always dump the flash memory. It doesn't matter what you do with the PIN or keys. You have to assume that your flash is always exposed and stored offline. This is the reason of encrypting the keys. Up to RP2040 they were encrypted with a key hashed with the PIN. Now with RP2350/ESP32-S3 this master key is masked with an OTP non-dumpable key. Even the flash memory is exposed, keys are kept safe under AES256 encryption. Making PIN entry attempts would leave inutilized forever your device if, for instance, you have multiple keys and you forget which are you using. Even if you introduce the valid PIN, the counter would be increased forever; it could not be reset at any time, neither introducing a valid PIN nor using the SO-PIN. Too extreme IMHO.
|
It can be implemented in better ways. e.g.:
I agree with this being a bit extreme however, as also mentioned earlier - it seems mostly (only?) relevant for targeted "physically steal and bruteforce in a dedicated manner" attacks, and it's probably better to go with more specialized hardware at that point. |
Very clever hack. I do not see a way to mitigate it easily via software. |
the attack has some things to be fulfilled:
as said there, rpi needs to fix this in hardware. I guess they will do it. It is the same like the original esp32, which needs also a new revision to get the broken secure boot fixed. However the OTP should contain
But everyone should be aware about that cloning is possible, because in the end a virtual clone within a simulator is sufficient. But in the end, this chip was not designed to withstand hardware attacks. It would possible to read out all the values via ROM probing. The OTP should be fused after too many retries are done, this renders the secret useless. But however, this is only possible by reducing the counter before checking, otherwise a timed reboot would allow endless testing of the PIN. |
Hello,
When I want to use the pico-hsm as a security module on some specified pico boards to do ECDSA signature.
If other guys dump the pico-hsm firmware of these board and copied the uf2 file to their own pico board.
Is there any way to prevent that the copied pico-hsm can't run on their own pico boards?
The text was updated successfully, but these errors were encountered: