Closing STM32H533 debug ports with no TZ enabled

[ste2108]

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

[Khaled_DHIF · Accepted solution]

Hello @ste2108 ,

The OBK encryption example you found in ST’s hotspot is only valid when TrustZone is enabled. It relies on secure‑side access to the correct DHUK/EPOCH, which is not available when TZ is disabled. On non‑TZ H5, the firmware cannot reliably select and use the same DHUK context that is used by our provisioning tools.

As a result, on current non‑TZ H5:

• You cannot safely encrypt a DA OBK from your own application code.
• Any attempt to reproduce the hotspot DHUK‑based encryption on a non‑TZ device may produce an OBK that the device cannot decrypt, leading to a Closed state that cannot be reopened.

The only supported solution today is:

• Generate and encrypt the DA OBK using the official provisioning mechanism (STM32CubeProgrammer / Segger, etc.).
• Provision this OBK into the device during manufacturing (using alternate OBK bank + swap as the tools do).
• Your firmware may manage lifecycle transitions (Open → Provisioning → Closed), but must not try to re‑encrypt or regenerate the DA OBK on a non‑TZ H5.

This limitation is planned to be removed in a future chip revision. 

Similar issue has been faced here: Solved: STM32H533 unable to do a full regression with newe... - STMicroelectronics Community

Kind regards

[ste2108]

Dear Khaled,

thanks a lot for your answer. I believe this limitation should be better highlighted in the AN6008 document, especially in paragraph 2.1.  Just an additional question: I locked and unlocked the same device many times with the same pair of obk/bin file. Does your last point mean that the device would be locked forever had I tried to lock it with a different but legit pair of files after I first locked/unlocked it with the former pair? 
Any time estimate on when this revision could take place? Debug port safety is an issue for us, as well as enabling TZ at this stage of the project.

Thanks.

Regards,

Stefano