Disabling TrustZone on the STM32H5

[jens-vdb]

Hi,

I have been experimenting with secure boot on the STM32H573I-DK, but I can't perform a regression anymore.

While adapting the example code (OEMiROT) to my own version, I am currently in the situation where the device is "provisioned" (0x2e), but I have lost the keys/certificates because they were accidentally overwritten during my experiments. So I can't open up the debug access port anymore. TrustZone is enabled (0xb4).

Currently with the STM32CubeProgrammer I can connect to the device in hotplug mode:

And I can read out the registers:

After doing some research for other ST platforms (the STM32U5 for example), it seems to be possible to "unprovision" the device using the STM32CubeProgrammer. However, changing both the PRODUCT_STATE and TZEN registers to 0xED and 0xC3 respectively results in an error:

Additionally, the STM32CubeProgrammer manual documents a possibility to disable TrustZone via CLI (https://www.st.com/resource/en/user_manual/um2237-stm32cubeprogrammer-software-description-stmicroelectronics.pdf:(

Alas, this method does not work as well as the command does not seem to be supported for the interface:

STM32_Programmer_CLI -c port=SWD mode=HotPlug -tzenreg

Is there any possibility to revert the product state and/or disable TrustZone on the STM32H5?

[Jocelyn RICARD · Accepted solution]

Hello @jens,

First, STM32H5 is different from STM32U5 and TZ regression will not work.

In fact, on STM32H5, you can simply disable TrustZone in option bytes when in OPEN state.

Here you are in iROT-PROVISIONED state. In this state you cannot use OBK provisioning for debug authentication credentials anymore.

According to your description you should be have a correct provisioning integrity :

of directly with command line:

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD debugauth=2
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.15.0
      -------------------------------------------------------------------


Start Debug Authentication Sequence

SDM 1.0.0 Init Sequence
Open SDM Lib
open_comms                    :   506 : open       : Asserting target reset

open_comms                    :   510 : open       : Writing magic number

open_comms                    :   518 : open       : De-asserting target reset

open_comms                    :   564 : open       : Communication with the target established successfully

response_packet_lock
discovery: target ID.......................:0x484
discovery: SoC ID..........................:0x280057  0x33325117  0x38363236  0x0
discovery: SDA version.....................:2.4.0
discovery: Vendor ID.......................:STMicroelectronics
discovery: PSA lifecycle...................:ST_LIFECYCLE_IROT_PROVISIONED
discovery: PSA auth version................:1.0
discovery: ST HDPL1 status.................:0xffffffff
discovery: ST HDPL2 status.................:0xffffffff
discovery: ST HDPL3 status.................:0xffffffff
discovery: Token Formats...................:0x200
discovery: Certificate Formats.............:0x201
discovery: cryptosystems...................:Ecdsa-P256 SHA256
discovery: ST provisioning integrity status:0xeaeaeaea
discovery: Available Permissions...........:(a) ==> Full Regression
discovery: Available Permissions...........:(b) ==> To TZ Regression
discovery: Available Permissions...........:(c) ==> Level 3 Intrusive Debug
discovery: Available Permissions...........:(d) ==> Level 2 Intrusive Debug
discovery: Available Permissions...........:(e) ==> Level 1 Intrusive Debug
discovery: Available Permissions...........:(f) ==> Level 3 Intrusive Non Secure Debug
discovery: Available Permissions...........:(g) ==> Level 2 Intrusive Non Secure Debug
discovery: Available Permissions...........:(h) ==> Level 1 Intrusive Non Secure Debug

Debug Authentication: Discovery Success

This discovery provides the status of the device through the Debug Authentication channel.

If you have the ST provisioning integrity status value equal to 0xeaeaeaea this means that debug authentication is provisioned.

Now, if you have overwritten the keys, it may have been done using the TrustedPackageCreator by regenerating the key using "Regenerate" button. In that case, the old key is saved in a .bak file containing also the date and time in the file name.

The only thing you need it the root private key you used when provisioning the device.

Also, if this is the default one provided in the package there is no issue.

If you generated your own private key, provisioned the device with associated public key and completely lost this private key, you will not be able to recover in any way. This is the purpose of the debug authentication to be able to authenticate ...

Best regards

Jocelyn