STM32H573 Debug Authentication FAILED in CLOSE state

[TetrasLyre]

Hi,

I am working on the wiki "How to start STiRoT".
Actually, my board in in CLOSE state and the DA returns the error "Debug Authentication failed" after Discovery (see below). The key and certificate used is the deafult ones.

The connection through STLink returns the error "No STM32 target found" (BOOT0 on System "1").

The connection through UART returns the error : " Activating device KO. Please verify the boot mode configuration and check the serial port configuration. Reset your device and try again..." (BOOT0 on Flash "0").

How can I recover the connection to the board and the state OPEN ?

Discovery:

12:15:09:766 : Start Debug Authentication Sequence
12:15:09:766 : SDMOpen : 609 : open : SDM API v1.0
12:15:09:766 : SDMOpen : 610 : open : SDM Library version v1.1.0
12:15:09:766 : open_comms : 501 : open : Asserting target reset
12:15:09:766 : open_comms : 505 : open : Writing magic number
12:15:09:766 : open_comms : 515 : open : De-asserting target reset
12:15:09:766 : open_comms : 567 : open : Communication with the target established successfully
12:15:09:766 : discovery: target ID.......................:0x484
12:15:09:766 : discovery: SoC ID..........................:0x00000000_35353537_3332510A_00350047
12:15:09:767 : discovery: SDA version.....................:2.4.0
12:15:09:767 : discovery: Vendor ID.......................:STMicroelectronics
12:15:09:767 : discovery: PSA lifecycle...................:ST_LIFECYCLE_CLOSED
12:15:09:767 : discovery: PSA auth version................:1.0
12:15:09:767 : discovery: ST HDPL1 status.................:0x1
12:15:09:767 : discovery: ST HDPL2 status.................:0xffffffff
12:15:09:767 : discovery: ST HDPL3 status.................:0xffffffff
12:15:09:767 : discovery: Token Formats...................:0x200
12:15:09:767 : discovery: Certificate Formats.............:0x201
12:15:09:767 : discovery: cryptosystems...................:Ecdsa-P256 SHA256
12:15:09:767 : discovery: ST provisioning integrity status:0xf5f5f5f5
12:15:09:768 : discovery: permission if authorized...........:Full Regression
12:15:09:768 : discovery: permission if authorized...........:To TZ Regression
12:15:09:768 : discovery: permission if authorized...........:Level 3 Intrusive Debug
12:15:09:768 : discovery: permission if authorized...........:Level 2 Intrusive Debug
12:15:09:768 : discovery: permission if authorized...........:Level 1 Intrusive Debug
12:15:09:768 : discovery: permission if authorized...........:Level 3 Intrusive Non Secure Debug
12:15:09:768 : discovery: permission if authorized...........:Level 2 Intrusive Non Secure Debug
12:15:09:768 : discovery: permission if authorized...........:Level 1 Intrusive Non Secure Debug

[Jocelyn RICARD]

Hello @TetrasLyre ,

you can see in the trace:

12:15:09:767 : discovery: cryptosystems...................:Ecdsa-P256 SHA256
12:15:09:767 : discovery: ST provisioning integrity status:0xf5f5f5f5

First line says that you have enabled TrustZone, so ECDSA Crypto is involved

Second line says that Debug Authentication key was either wrongly provisioned or not provisioned at all.

This is just an integrity check of the Debug Authentication credentials stored in OBK.

So, in this state, if you have code in the device that is able to download an application (typically a kind of bootloader) you can download a firmware that performs a regression (Change product state to regression).

If you don't have this capability, you cannot reopen the device.

How did you provision the device before switching to CLOSED state ?

Best regards

Jocelyn

[TetrasLyre]

Hi Jocelyn,

Thank you for your message.

I think that the device is lost. I have performed the provisioning manually to understand in depth the successive steps automatically done by the script. However, I forgot the DA_Config.obk .

But, tools should not allow changing the product state to CLOSE if the DA OBkeys memory area is empty.

Best regards

[Jocelyn RICARD]

Hello @TetrasLyre ,

I'm sorry for that.

There are actually some warning messages provided by STM32CubeProgrammer GUI.

But when using CLI, there is no specific check as far as I know.

Also, the first thing I would recommend when discovering this feature is to try to regress the device when you are in PROVISIONING state. This way, you are sure you will not brick the device because even if for any reason the provisioning didn't work you can try again until you are able to perform the regression.

Once regression could be performed, you know the steps to make it work properly, and can then go to CLOSED state using same provisioning files.

Regarding your proposal to check if DA OBKeys are already provisioned when going to CLOSED state, this is a good idea. I will share internally.

Best regards

Jocelyn