STM32H533 Secure Boot Regression Failure

[Elgin_Peru]

Hi Folks,

I was working on Secure Boot for the STM32H533, following the documented steps for the STiRoT boot path. I used the STiRoT boot path based on the STM32 documentation.

https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_STM32CubeMX_STiRoT_Boot_path_on_STM32H57 

I am trying to bring the device back to the OPEN state, but I am facing an issue during the process. After providing the Key File Path and Certificate and selecting Full Regression permission, the Debug Authentication step fails.

16:42:50:983 : Start Debug Authentication Sequence
16:42:50:984 : SDMOpen                       :   765 : open       : SDM API v1.0
16:42:50:985 : SDMOpen                       :   766 : open       : SDM Library version v1.4.0
16:42:50:986 : open_comms                    :   606 : open       : Asserting target reset
16:42:50:987 : open_comms                    :   614 : open       : Writing magic number
16:42:50:987 : open_comms                    :   678 : open       : De-asserting target reset
16:42:50:987 : open_comms                    :   699 : open       : No response from the target
16:42:50:988 : open_comms                    :   700 : open       : The target is unable to boot on RSS_DA or is in OPEN mode
16:42:50:988 : open_comms                    :   701 : open       : Failed to open communication with the target
16:43:09:778 : Start Debug Authentication Sequence
16:43:09:779 : SDMOpen                       :   765 : open       : SDM API v1.0
16:43:09:779 : SDMOpen                       :   766 : open       : SDM Library version v1.4.0
16:43:09:779 : open_comms                    :   606 : open       : Asserting target reset
16:43:09:779 : open_comms                    :   614 : open       : Writing magic number
16:43:09:779 : open_comms                    :   678 : open       : De-asserting target reset
16:43:09:780 : open_comms                    :   713 : open       : Communication with the target established successfully
16:43:09:780 : discovery: target ID.......................:0x478
16:43:09:780 : discovery: SoC ID..........................:0x00000000_32303639_30335110_0016005B
16:43:09:780 : discovery: SDA version.....................:1.2.0
16:43:09:780 : discovery: Vendor ID.......................:STMicroelectronics
16:43:09:780 : discovery: PSA lifecycle...................:ST_LIFECYCLE_IROT_PROVISIONED
16:43:09:781 : discovery: PSA auth version................:1.0
16:43:09:781 : discovery: ST HDPL1 status.................:0x00000001
16:43:09:782 : discovery: ST HDPL2 status.................:0xFFFFFFFF
16:43:09:782 : discovery: ST HDPL3 status.................:0xFFFFFFFF
16:43:09:782 : discovery: Token Formats...................:0x00000200
16:43:09:783 : discovery: Certificate Formats.............:0x00000201
16:43:09:783 : discovery: cryptosystems...................:Ecdsa-P256 SHA256
16:43:09:783 : discovery: ST provisioning integrity status:0xF5F5F5F5
16:43:09:783 : discovery: ST provisioning integrity status message:INVALID
16:43:09:783 : discovery: permission if authorized...........:Full Regression
16:43:09:783 : discovery: permission if authorized...........:To TZ Regression
16:43:09:784 : discovery: permission if authorized...........:Level 3 Intrusive Debug
16:43:09:785 : discovery: permission if authorized...........:Level 2 Intrusive Debug
16:43:09:786 : discovery: permission if authorized...........:Level 1 Intrusive Debug
16:43:09:786 : discovery: permission if authorized...........:Level 3 Intrusive Non Secure Debug
16:43:09:786 : discovery: permission if authorized...........:Level 2 Intrusive Non Secure Debug
16:43:09:786 : discovery: permission if authorized...........:Level 1 Intrusive Non Secure Debug

[Jocelyn RICARD]

Hello ​@Elgin_Peru ,

as you can see in the trace:

16:43:09:783 : discovery: cryptosystems...................:Ecdsa-P256 SHA256
16:43:09:783 : discovery: ST provisioning integrity status:0xF5F5F5F5
16:43:09:783 : discovery: ST provisioning integrity status message:INVALID

the device does not contain the debug authentication key allowing the reopening of your device.

Integrity status means that either nothing was provisioned or wrong data was provisioned.

As your device is in iROT_Provisioned state, you have no way to connect to the device to reopen it.

Unfortunately this means device is bricked.

When first testing things I would recommend staying in OPEN state.

Closing the device should be done when have already understood how things work.

For instance, you should be able to check that DA_Config.obk was provisioned in the obkey_provisioning.log file:

Something like:

Secure Data Provisioning Start. OBK Input file : ./../DA/Binary/DA_Config.obk
ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ 100%OBKey Provisioned successfully

Best regards

Jocelyn