2024-10-02 05:42 PM
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.
Solved! Go to Solution.
2024-10-14 03:45 AM
Update: I heard back from ST support, it was a bug in their software, the bug is now resolved in a newer version of the Cube Programmer (v2.18). I tested it and it works as intended :)
2024-10-03 10:12 AM
Hello @RGari ,
The provisioning status is not significant on STM32H503 because the password hash is provisioned in OTP.
The da_password.bin should not contain the hash of the password but a header and the password itself in clear
Please check content in the STM32CubeH5 package here:
STM32Cube_FW_H5_V1.3.0\Projects\NUCLEO-H503RB\ROT_Provisioning\DA\
Best regards
Jocelyn
2024-10-03 11:22 AM
Yes I confirmed that da_password.bin contains the header plus the actual password (PasswordPassword in this test)
(note this is just my test password and won't be used in any released product, so I will post the exact contents here):
2024-10-04 05:31 AM
Hello @RGari ,
OK thank you. What you did looks correct.
I need to get access to virgin STM32H503 to be able to reproduce your issue.
I have seen that other customers have faced similar issue. I will come back to you when I have more information and details.
Best regards
Jocelyn
2024-10-08 06:30 AM
Hi, I observed the same issue on the same chip:
The parsing error seems to go away if you change the header to match the password lenght and remove the 8.
I changed 0x00 00 00 80 0C 00 00 00 (default password lenght is 0x0c) to 0x00 00 00 00 0F 00 00 00 (my password is 16 bytes long) and the parsing is successfull and the Debug auth is successfull but the chip doesnt do the regression? So still not a solution but at least the parser is happy :)
Hope we can resolve this soon, as this is blocking an inportant production run.
Best regards,
Mataj Zandona
2024-10-08 10:33 AM
MaTz,
Thanks for that. I made that change and like you, the parsing error went away but DA authentication still failed. So I guess this is progress....
Where did you get details on what that header is supposed to contain? I've looked all over and cannot find any reference to it other than it being applied via the -h switch during creation of the da_password.bin file. (although there is so much security documentation scattered all over the place that I very well may have missed it).
Also like you, this is holding up a production project of ours. I have also opened a ticket on the same issue, so I'll post if I get any answers there, too.
2024-10-08 10:41 AM
RGari,
I got that hint from a ticket, but I'm still waiting for further explanations and instructions. Also will post here as soon as I learn something usefull.
Just to clarify, my DA auth is a success (based on CLI output) but the chip still remains in the Closed state.
Have a good one!
2024-10-10 07:17 PM
Update: I was able to perform a regression using a Segger J-Link instead of ST-Link (using the Segger software, of course). So this now appears to be a bug in the STM32 Programmer software and not the chip, itself (nor the DA password programming procedure).
With Segger, the procedure I used was:
C:\Program Files\SEGGER\JLink_V810a>devpro -operation DbgAuthDiscover -if SWD -speed 4000 -ScriptFile script\PCode_DevPro_ST_STM32H5.pex
SEGGER Device Provisioner V8.10a
Compiled Oct 2 2024 14:15:38
'q' to quit '?' for help
Command line: -operation DbgAuthDiscover -if SWD -speed 4000 -ScriptFile script\PCode_DevPro_ST_STM32H5.pex
Opened script file: 'script\PCode_DevPro_ST_STM32H5.pex'
J-Link log: Found device with ID: 0x00000474
J-Link log: Product state:
J-Link log: PROVISIONED
C:\Program Files\SEGGER\JLink_V810a>devpro -operation DbgAuthRegression -if SWD -speed 4000 -SetConfigVal "PASSWORD=PasswordPassword" -ScriptFile script\PCode_DevPro_ST_STM32H5.pex
SEGGER Device Provisioner V8.10a
Compiled Oct 2 2024 14:15:38
'q' to quit '?' for help
Command line: -operation DbgAuthRegression -if SWD -speed 4000 -SetConfigVal PASSWORD=PasswordPassword -ScriptFile script\PCode_DevPro_ST_STM32H5.pex
Opened script file: 'script\PCode_DevPro_ST_STM32H5.pex'
J-Link log: Device unlocked
C:\Program Files\SEGGER\JLink_V810a>devpro -operation DbgAuthDiscover -if SWD -speed 4000 -ScriptFile script\PCode_DevPro_ST_STM32H5.pex
SEGGER Device Provisioner V8.10a
Compiled Oct 2 2024 14:15:38
'q' to quit '?' for help
Command line: -operation DbgAuthDiscover -if SWD -speed 4000 -ScriptFile script\PCode_DevPro_ST_STM32H5.pex
Opened script file: 'script\PCode_DevPro_ST_STM32H5.pex'
J-Link log: Found device with ID: 0x00000474
J-Link log: Product state:
J-Link log: OPEN
2024-10-10 07:19 PM
The documentation on Segger's site for the above procedure is here: https://wiki.segger.com/ST_STM32H5_Security_Product_Lifecycle
2024-10-14 03:45 AM
Update: I heard back from ST support, it was a bug in their software, the bug is now resolved in a newer version of the Cube Programmer (v2.18). I tested it and it works as intended :)