Hello,
in our application, running on a H533RET6 and with no TZ enabled, we need to close debug ports in production.I preliminarly did some tests using CubeProgrammer: I generated password-based credentials (obk+bin files, which as far as I understand from AN6008 is the only option when not in TZ) and successfully managed to lock the device by moving from PRODUCT_STATE Open (0xED) to Provisioning (0x17), supplying the .obk file and then lock the device (PRODUCT_STATE = 0x72). After verifying that debug ports were closed, I unlocked the device by making a discovery and providing the bin file, with the device returning into Open state. Note that the first 3 32-bit words of my obk file are:
0x00, 0x01, 0xfd, 0x0f, 0x60, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00
Showing that the address base is the secure OBK base address and that the encryption is on (as it should be in my device, again as far as I understand).
So far so good, but know I would like to move at least the encryption process in my application: once the production code starts the first time, it should close debug ports, which will be subsequently reopened at the cost of a mass erase.
What I am doing is the following:
1) Check that the device is in Open state and, if so, go into provisioning state. This does what I expect and, at the end of it, my device is in provisioning state (double-checked with CubeProgrammer)
2) Within OBKProvisioning_ProvisionDA I do the following:
This code has been mainly taken from ticket https://community.st.com/t5/stm32-mcus-products/stm32h5-getting-the-provisioned-state-from-within-the-firmware/td-p/836233 (thanks!) and as far as I understand does the following:
a) unlock flash and flash option bytes
b) erase the OB flash space (alternate sector)
c) Program the flash by copying the OBK file bytes after the 12th to HDPL1 base address (whether this base address should be secure or non-secure is a critical point, see below. In the code I show it is secured, but I tried both), in the alternate sector
d) Swap alternate sector with official one
Regarding point c, the example I took the code from used non-secure address (0x0BFD0100) as OBK dfile destination, but it may be because they used a H5 where secure area is not present. I also saw that if I try to use secure base address (as the first 4 bytes of my OBK would suggest) without -mcmse compiling option (which we do not have by default) an assert is triggered when tryng to write flash at secure OBK address, here:
In my understanding I should run the code with -mcmse option and addressing secure OBK memory, but if I do and then I lock the device I am not able to unlock it through CubeProgrammer, even though in principle I supplied the same OBK file (I already locked two boards :) ). Also, I don't see a way to check whether a provisioned OBK file is valid when in provisioning state, as the DA (Debug Authentication) method is available only after I Close the device
Apart from the aforementioned ticket, I also read https://community.st.com/t5/stm32-mcus-security/obk-unusable-in-non-tz-stm32h5/td-p/869333 , which seems to address a potential problem with secure/non secure OBK address.
Thank you for your help.
Regards,
Stefano
