cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H503 cannot perform regression

RGari
Associate III

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.

 

 

0 REPLIES 0