how to avoid the pico-hsm firmware be dumped from its flash and run on other pico boards #42
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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?
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?
It could still be attacked, but this would make it harder than simply copying the firmware.
pico_unique_board_idis not a secret number, it can be retrieved easily so it would not add any level of added security. At the end, the input of the whole system is your PIN. If it mixes letters and numbers and is long (>=8), it will take decades.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:
src: https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf
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
esptool read_flashcommand, which is pretty similar topicotool save.I am reading the RP2350 datasheet and it seems to me that now RP2350 and ESP32-S3 are equivalent in terms of security.
Both contain OTP, secure boot, debug disabling and flash encryption (encrypted boot). However, both allow flash dumping which represents a security issue, even if the data is AES encrypted.
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.
If someone is interested in stealing my hsm, I have a lot of other problems. The main aspect I can see is to forbid any clone without knowledge. I guess for that the internal OTP is sufficient.
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.
And as you mentioned, the PIN is the main aspect for staying save. I guess it would be possible to add a KDF which needs a public key response challenge to unlock the specific flash key. But adding a second factor makes it maybe harder than just using the correct hardware
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.
With idea being to block an attack scenario where non-OTP flash is dumped/restored to rollback any PIN entry counters stored in writable memory, at the expense of useful lifespan of the device.
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.:
On successful attempt, "burn" a "success indication" block to reset the counter.
To not waste blocks on "success indication", keep an encrypted/authenticated (hence impossible to fake) nonce+counter on writeable flash, counting how many blocks to ignore. So on successful PIN entry it will be incremented to skip all the failure indications, but not before then.
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.
FYI: https://media.ccc.de/v/38c3-hacking-the-rp2350
Very clever hack. I do not see a way to mitigate it easily via software.
So if flash can be dumped and the OTP as well regardless the locking of the chip, we are returning to the starting point: rely on a PIN introduced by the user.
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
Manufacturing information such as unique device ID.This unique IDs can be used as a salt for the KDF. This would make it harder to dump and run it on a clone.
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.
FYI: https://www.raspberrypi.com/news/security-through-transparency-rp2350-hacking-challenge-results-are-in/
FYI: https://www.raspberrypi.com/news/rp2350-a4-rp2354-and-a-new-hacking-challenge/
I’m aware of it. I’m waiting for Pimoroni’s Tiny2354 if it’s a reality. I don’t know which vendor will offer the RP2354.
Thank you for a very good discussion.
Both the RP2350 and ESP32-S3 (earlier versions) have security risks of direct flash leakage. As a result, the security is actually the same as that of the RP2040.
Due to the low price of RP2040, it is easy to buy ready-made development boards at the production point for 1~2 dollars, and if it is a 10K bulk purchase, manufacturers are willing to customize the hardware suitable for the token at the price of 1 dollar.
Considering the cost, the RP2040 is widely adopted, and direct revocation after loss is a more affordable option. It is enough for 99% of people to do so. Hopefully, the project will continue to support RP2040 and other cheaper products.
For those who are more concerned about security, such as those who need to fight against the surveillance of large enterprises and government agents, they need hardware to boot securely.
Due to market environment issues, it is difficult for ordinary users of ESP32-S3 to judge whether to buy the repaired version. The RP2354 or ESP32-C6 (if PICO is supported) is a better choice.
In actual use, RP2354 or similar products require users to keep the key used to sign the firmware, which will bring new problems for ordinary users and small teams, which is no more secure than using RP2040, directly believing that the firmware issued by polhenarejos is a better choice, after all, the people who hurt you are the people who know you in most cases.
For large enterprises and those who pursue ultimate security, they need to protect the key of the signed firmware by themselves, and the hardware should also use a special security chip, and the minimum requirement is NXP LPC5500 hardware with PUF.
I don't speak English, this passage is processed by Microsoft Translate, I hope it won't bother you.
Thank you polhenarejos for your project is very good 💕