Hi,
In the past we've always produced 'release' firmware for STM32F4 which checks the RDP level (memory read / debug protection) at boot up, and ensures it's automatically set to RDP1 (read protection enabled). This ensures that our code can't be easily read out of the device by 3rd parties, but if necessary I can connect a debugger, reset the option bytes (which performs a full erase), and reprogram the chip. This works well. We also have our own secure bootloader which deals with encrypted firmware updates and which is well supported by our production equipment and staff.
I'm now working on porting a design to STM32H523, which has an enormously more complicated security system.
What I've figured out so far is that:
- I think the closest behaviour it's capable of would be to have TrustZone disabled, to set a password for Debug Authentication, and to have the product in the "CLOSED" state when shipped.
- This would ensure the product is read protected, but it can be fully erased and set back to the "OPEN" state provided the password is known.
- To make this happen, I need to start with it in the "OPEN" state, somehow transition to "PROVISIONING" because the OBKeys can't be written when it's "OPEN", then write the OBKeys to set the password hash, then transition to "CLOSED".
I've worked through these steps using the STM32CubeProgrammer, and only managed to completely brick one device. I'm honestly pretty happy with that. However, it's an involved, fiddly process that won't work in production.
(Also, if anyone can suggest a way to recover my Nucleo board then I'd appreciate it - it's stuck in the PROVISIONING state, it won't authenticate because the OBKeys aren't programmed, and I can't connect in order to to program them).
Instead, I'd like to have the application itself make the necessary changes as part of its first time boot sequence, ie. on boot-up:
- if the state is "OPEN", change to "PROVISIONING"
- if it's "PROVISIONING", write the OBKeys and change to "CLOSED"
- if it's "CLOSED", run the application as normal.
I've already written code to calculate the OBKeys from the password, and it works (ie. its output matches the OBKeys that are generated by TrustedPackageCreator. However, since I don't want to make a habit of bricking CPUs, there's some things I'd like to check before continuing...
- when I write FLASH_OPTSR_PRG to change PRODUCT_STATE, does this cause a reboot?
- Table 23 in RM0481v3 says that in the PROVISIONING state, it will always boot to RSS instead of my code. Does this mean I need to write something to SBS_RSSCMDR to make it jump back to my code to continue the sequence? I can't find anything that documents what the RSS commands actually are - and, of course, if I issue a reboot and never get back to my application code, the chip is bricked.
- is there a way to test writing the OBKeys area that doesn't involve putting the chip into a state where debugger access is restricted? I'd really like to know this is working before changing PRODUCT_STATE to something from which I can't recover.
- this does all feel convoluted and difficult, compared to just setting RDP = 1. Have I missed something?
Thanks!
Andy.
