Secure Boot and Read Out Protection

[merakian]

Hi all,

I'm designing a product that will have a USB boot-loader.

I would like to choose a micro-controller that supports secure-boot as well as an ability to completely lock down the micro-controller such that no flash can be read from it. I understand this to be read out protection. Please correct me if I'm wrong.

What's the best way to sort ST's micro-controller offerings based on the criteria above? 

If anyone has recommendations for micros, that would be greatly appreciated.

Thank you!

[TDK]

So your own USB bootloader?

Regardless, most (all?) chips that support USB also have a system USB bootloader, so that doesn't narrow anything.

Similarly, all chips have RDP level 2 which locks out flash entirely.

That leaves the requirement "micro-controller that supports secure-boot" as the remaining criterion. You can use SBSFU on many chips:

https://www.st.com/en/embedded-software/x-cube-sbsfu.html

https://www.st.com/content/st_com/en/ecosystems/stm32trust/security-services.html

Some newer families of chips have built-in security features that you may find preferable to SBSFU.

STM32H5 series - STMicroelectronics

[merakian]

I don't have a preference on rolling my own usb-bootloader or using one that's prebuilt into the ROM of a processor.

RDP level 2 sounds like the type of flash read-out protection that I'm looking for, thank you!

I've read over SBSFU, and I think it fits my needs(Trustzone isn't on my radar at the moment). The problem is that there are so many processor variants available that it's not feasible to look through the reference manual of each one to see if they support SBSFU, or if they do but they have sneaky differences through errata. Is there a way to filter for SBSFU functionality, if say I choose the U5 series?

[tjaekel]

Try the STM32N6xx: it is a very "secure chip".

The U5 is not really secure: it allows to read back still the flash ROM (via debugger). Unless, it has an option to burn a fuse to disconnect a debugger forever.

If you want to make your system really so secure: against what?
- reading back the code (from flash)?
- writing a new MCU FW image? (with a key and validation needed)
- disable debugger interface?
- avoid snooping the external memory interface?
- separate code into secure and non-secure part (TrustZone)
- power and clock glitches to hack?
- X-ray-ing your ROM?

Just be aware of: developing your FW might be done in a "not locked environment", afterwards you "move" it as secure (e.g. burning fuses). If this is done - you might be still able to update the FW, e.g. with a secure bootloader and authentication, but maybe you cannot debug anymore.

You could also consider to use RP2350 which allows you to keep anybody (even yourself) away from hacking your system. But it is almost possible with very fancy tricks to get access to a very secure chip, e.g. via power glitches, clock manipulation or even doing Xray on your flash memory.

A chip which uses internal flash ROM is a bit more secure: you cannot snoop the flash read transactions on external interface.
With an external flash - you might consider to encrypt the code, so that snooping external interface does not allow to see the "plain code" (decrypted internally, before execution - but it might need a larger internal SRAM and key management).

All possible, just a question how "safe" you want to make it.

The STM32N6 (or RP2370) would be my best candidates.

[merakian]

Hi @tjaekel,

Out of curiosity, why is reading out the flash ROM insecure? I thought flash ROMs typically only contain bootloaders designed by the vendor, which I'm fine with being read out. I'm under the impression that if you had implemented flash RDP at its highest level, you would lose access to debuggers reading flash out (which I am 100% OK with).

I'm interested in securing against losing software IP immediately to lower-level threats((if an adversary dumps the flash, or flash an binary that dumps flash) . If they have the means to use more sophisticated means like hardware glitching, or x-raying, I'm fine with losing my IP. At that point, they deserve it haha.

Just for some context, I need to support MCU FW updates over a usb-bootloader and my idea is to partition flash into a image swap space like:

Flash start
Bootloader
Image 1
Image 2
Flash end

I want to prevent any reads to flash, yet still update Image 1 and Image 2 partitions. I understand flash RDP to mean that the bootloader on the system can still write to flash, but no external actors have access to flash. I'll be using secure-boot to verify images coming across the bootloader are valid.

I've found a couple of processors that look promising to me, because they fit both my power + $$$ budget:

STM32U535RBI6Q

STM32L552CCT6

STM32L412CBT6

STM32U031F8P6

Would you still recommend the RP2350 over any of the four above? I saw this : https://www.raspberrypi.com/news/security-through-transparency-rp2350-hacking-challenge-results-are-in/
and the only place to actually get a RP2350 for a design is on JLCPCB. I'm more confident that STMicroelectronics has updated their micro-controller security to fix flaws than a processor, which if I chose right now, would not be the version that have fixed publicly described security risks. This might not be the case, so please correct me if I'm wrong.

[tjaekel]

If external ROM does not contain an encrypted FW: snooping ROM interface signals with a logic analyzer, de-soldering the ROM chip, read it, manipulate it, ... is not a fully secure approach.

[TDK]

> I'm interested in securing against losing software IP immediately to lower-level threats((if an adversary dumps the flash, or flash an binary that dumps flash) .

All STM32 chips will have this capability in RDP level 1 mode which will prevent the flash from being read while still letting the chip be erased if firmware needs updated.

Let your other criterion drive the decision, faster/cheaper/smaller, etc.