how to avoid the pico-hsm firmware be dumped from its flash and run on other pico boards

[ghost]

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?

[polhenarejos]

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.

[al-heisner]

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.

[polhenarejos]

pico_unique_board_id is 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.

[coelner]

Maybe the new pico 2 contains all the needed features, atleast the arm version, but I guess the anti-fuse OTP is sufficient

[polhenarejos]

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.

[coelner]

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

RP2350 contains 8 kB of one-time-programmable storage (OTP), which stores:
• Manufacturing information such as unique device ID
• Boot configuration such as non-default crystal oscillator frequency
• Public key fingerprint(s) for boot signature enforcement
• Symmetric keys for decryption of external flash contents into SRAM
• User-defined contents, including bootable program images (Section 5.10.7

[fredlarochelle]

The RP2350 has other security improvements like a security mesh, better defenses against glitching, ... It will definitely be an improvment.

[dev-area]

does ESP32-S3 have the same problem?

[polhenarejos]

Yes, all ESP32 boards have the esptool read_flash command, which is pretty similar to picotool 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.

[coelner]

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?

[polhenarejos]

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.

[coelner]

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