STM32H503 cannot perform regression

[RGari]

Hello.  I am experimenting with securing a STM32H503 using password authentication, which will ultimately be an automated process.

I created a simple password for testing and created the password hash in board_password.bin and da_password.bin

(just for comparison, I also used Segger's advice and tried certutil and the resulting board_password.bin file is identical, so I'm pretty sure the password hash worked).

I set the chip to PRODUCT_STATE provisioning and programmed the chip with the password using the following:

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug  -ob PRODUCT_STATE=0x17

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug -w board_password.bin 0x8FFF000

Both of these commands succeeded with no errors

As recommended, I locked the OTP so I wouldn't accidentally damage it by overwriting by:

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug -ob LOCKBL=0x1

Again, no errors

Finally I set PRODUCT_STATE to PROVISIONED and again, no errors

STM32_Programmer_CLI.exe -c port=SWD speed=fast ap=1 mode=Hotplug  -ob PRODUCT_STATE=0x2E

The problem comes when I try to perform regression.  

STM32_Programmer_CLI.exe -c port=SWD mode=HotPlug pwd=da_password.bin debugauth=1

I believe it is acting like the password was not accepted

-------------------------------------------------------------------
STM32CubeProgrammer v2.17.0
-------------------------------------------------------------------

Start Debug Authentication Sequence

Open SDM Lib
SDMOpen : 602 : open : SDM API v1.0

SDMOpen : 603 : open : SDM Library version v1.1.0

open_comms : 495 : open : Asserting target reset

open_comms : 499 : open : Writing magic number

open_comms : 509 : open : De-asserting target reset

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

discovery: permission if authorized...........:(a/14) ==> Full Regression
SDMOpen : 602 : open : SDM API v1.0

SDMOpen : 603 : open : SDM Library version v1.1.0

open_comms : 495 : open : Asserting target reset

open_comms : 499 : open : Writing magic number

open_comms : 509 : open : De-asserting target reset

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

[00%] discovery command
[10%] sending discovery command
[20%] receiving discovery
[40%] loading credentials

please enter your password file path
[50%] sending challenge request
[60%] receiving challenge
SDMAuthenticate : 1308 : client : Error parsing password file (da_password.bin)

Error:
Debug Authentication Failed
response_packet_lock
response_packet_lock
response_packet_lock

user_password.bin is exactly 16 bytes in length

I created the da_password.bin file using ST's AppliCfg.py script, along with the board_password.bin file.  Examining the da_password file it seems to contain user_password.bin's contents with a header that was specified in the sample create_password script with the -h 0x000000800C000000 switch.  I assume that is correct.

The current state of the chip is:

STM32_Programmer_CLI.exe -c port=SWD mode=HotPlug debugauth=2

-------------------------------------------------------------------
STM32CubeProgrammer v2.17.0
-------------------------------------------------------------------

Start Debug Authentication Sequence

Open SDM Lib
SDMOpen : 602 : open : SDM API v1.0

SDMOpen : 603 : open : SDM Library version v1.1.0

open_comms : 495 : open : Asserting target reset

open_comms : 499 : open : Writing magic number

open_comms : 509 : open : De-asserting target reset

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

discovery: target ID.......................:0x474
discovery: SoC ID..........................:0x00000000_35343637_30325101_00620057
discovery: SDA version.....................:1.2.0
discovery: Vendor ID.......................:STMicroelectronics
discovery: PSA lifecycle...................:ST_LIFECYCLE_IROT_PROVISIONED
discovery: PSA auth version................:1.0
discovery: ST HDPL1 status.................:0x11111111
discovery: ST HDPL2 status.................:0x22222222
discovery: ST HDPL3 status.................:0x33333333
discovery: Token Formats...................:0x200
discovery: Certificate Formats.............:0x201
discovery: cryptosystems...................:ST Password
discovery: ST provisioning integrity status:0xffffffff
discovery: permission if authorized...........:(a/14) ==> Full Regression
To select multiple permission/actions:
Using numerical values: List the needed bit numbers, separated by commas without spaces.
Using symbolic letters: List the needed letters by concatenating them without separators.

Debug Authentication: Discovery Success
response_packet_lock

I noticed that provisioning integrity status is 0xffffffff.  What does that mean?  (I see other values mentioned in the forums but not that one).

NOTE that I did NOT flash a bootloader yet--at this point, we are not ready with our bootloader and just want to ship some samples to a customer with our firmware read-out-protected and then if they need to get a new revision they will need to return the sample for regression/reprogramming.  We do intend to eventually use a bootloader and allow for encrypted firmware updates and set to a CLOSED state but our code for that is not ready yet.  So we are attempting to utilize this similar to the normal Readout protection available on other chip models as a temporary measure.

For the test I didn't actually flash any firmware into this chip (just the DA password)--just wanted to get familiar with moving between product states and performing regression first.

[MaTz]

Hi Neuman,

AFAIK you can't make a regression with a password from PROVISIONED state, only from CLOSED state.
Did you try the regression with GUI or trough CLI? How long is was your password? If is isn't 16 bytes long the header value might be wrong (as I THINK it indicates the length of the password).
Also, to not loose boards in the future, you can program the MCU with regression code (triggered by user action like a button, UART or else) while you figure out a reliable way to unlock the chip.

I hope this helps you :)
 

[Neuman]

Oh, I made a password with only 14 bytes. Probably thats what messed it up for me. Did I loose my board or can it be fixed, you think?

[MaTz]

I think you should be able to save your board, just need to make a correct password file, try to play with the header values, the bit that was initialy missing indicates the password lenght of 16 bytes (i think). You can also open up a support ticket with ST, they should be able to tell you how your header should look. Your board isn't lost as long as a correct hash of the password has been written in the OTP area.

When you find a fix, please put it here for other people to find, happy unlocking :)

[MarcelP]

If your password header indicated a password length of 16, but the actuall password was only 14 bytes, then try to fill up your password.bin with zeroes until it reaches 16 bytes and try to perform the regression with this new password.bin again. This might do the job. I think the password hash is a sha2-256 with a block length of 64 bytes, which indicates that padding with zero is used to fill up the remaining block space.

[Jocelyn RICARD]

Hello,

The format of the password file that needs to be provided to reopen a STM32H503 using DebugAuthentication is the following!

4 bytes : 0x08000000 : This tells debug authentication protocol that we use a proprietary protocol (the password)

4 bytes: The size of the password : here 14 bytes :0x0000000E)

N bytes: the password in clear

So for a 14 bytes password you should have something like (we are using little endian)

0x00 0x00 0x00 0x80 0x0E 0x00 0x00 0x00 [Remaining are the 14 bytes password ]

I hope this will help

Best regards

Jocelyn

[Neuman]

Thanks,

I edited the da_password.bin file according to your specs and now it parses the password file.

SDMOpen : 625 : open : SDM Library version v1.2.0

open_comms : 513 : open : Asserting target reset

open_comms : 517 : open : Writing magic number

open_comms : 537 : open : De-asserting target reset

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

[00%] discovery command
[10%] sending discovery command
[20%] receiving discovery
response_packet_lock
[40%] loading credentials

please enter your password file path
c:\temp\da_password.bin
[50%] sending challenge request
[60%] receiving challenge
response_packet_lock
SDMAuthenticate : 1391 : client : Found 1 certificates

Error:
Debug Authentication Failed

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>

But seems the password is wrong.

Seems like som spaces was put in between my password characters before, I wonder which password it has locked my unit with :(

[Jocelyn RICARD]

Hello @Neuman ,

You need to remember what actions you have done.

At some point if you used the provisioning script, the target was provisioned with the hash of the user_password.bin which is called board_password.bin.

So source is user_password.bin

Create_password.bat generates :

1) board_password.bin : hash of the password to write in otp

2) da_password.bin : The script just adds the header to the clear password (user_password.bin). The header is hardcoded with a size of 0x0C. So, needs to be changed manually using a binary editor (HxD for instance) to fit the actual password size. 

Best regards

Jocelyn

[Neuman]

Thanks for your efforts @Jocelyn RICARD ,

I see my clear text password in user_passwrod.bin. When running create_password.bat I get a new da_password.bin. But, instead of having the password "1234567" at the end, it has "1 2 3 4 5 6 7 " {#00 in between}

I tried correcting the header for both option "1234567" and "1 2 3 4 5 6 7 " but none of them allows me to get access.