STiRoT Provisioning of STM32H573 over SPI

[RomThi]

Hi all,

we are developing a product with the STM32H573. The idea is to use the STiRoT for secure firmware update. The MCU is connected to a Linux CPU via SPI. Now we plan to do the provisioning during the production using the Linux CPU that has a ethrnet connection to the outside world. 

The question is: Is that possible? Is the boot pin required or is a jump to bootloader sufficient?

I have modified the provisioning scripts to use UART and I have tested it using the H573DK eval board, but it failed. This is because after programming the option bytes the bootloader is not starting again, as STiRoT gets activated. Maybe the sequence can be modified?

What are the detailed steps? E.g. what is the RSS doing and how?

Thx,

Roman

[Jocelyn RICARD]

Hello @RomThi ,

When enabling STiROT, you have no way to enter bootloader through the BOOT0 pin. This is a security principle to have a single entry point after reset.

Now, to update the firmware you have 2 ways.

1) Use your own application to download the new firmware in the download slot

2) Jump in the system bootloader. The examples provided in the STM32CubeH5 give you the needed implementation (See LOADER_Run() for instance). You can consider system bootloader as a non secure application running in HDPL3. So, to make it work you need to configure the platfom security (GTZC, SAU, MPU, interrupts and GPIO) so that this non secure application can work properly.

The initial provisioning that should be done in factory is a different topic. Normally there shouldn't be any issue using the system bootloader interface to do this. But in this case you need to pull BOOT0 pin up.

You setup option bytes in open state, download the signed application, switch to provisioning, provision obk files (STiROT_config.obk, STiROT_data.obk and DA_config.obk), and then switch to closed state.

If you want to stay in open state, you will need to set BOOT_UBE to 0xB4 to boot from bootloader to be able to perform the provisioning in open state. Then once provisioning is done, set BOOT_UBE back to 0xC3 and reset, the STiROT should run as long as BOOT0 pin stays up. This case is just for testing as you stay in open state!

The provisioning sequence should be basically the same as with JTAG.

Best regards

Jocelyn

[RomThi]

Hello Jocelyn,

thx for your quick response. Good to know, how to jump to the system bootloader properly. Thx for that.

But I still don't understand how the provisioning could work without JTAG or SWD.

Here is our setup, its not a big deal to connect the boot pin:

Now I show you the sequence that I understood:

In our scenario we have a basic firmware installed after production of the PCB. So some user code is running. As a first step we jump into the system bootloader. Here the first question (1), can we also jump in from the user application without the boot pin? The next four steps are clear for me marked with (OK). But than I am lost, see (2).
You wrote: "provision obk files (STiROT_config.obk, STiROT_data.obk and DA_config.obk), and then switch to closed state". How can this be done if the RSS is active due to the "provisioning" state? 

Best regards,

Roman

[Jocelyn RICARD]

Hello Roman,

You can see the RSS as a Secure Application that is launching system bootloader that is the non secure application.

You know in which boot state you are thanks to the table 26 of reference manual

So, in provisioning state you launch the RSS, meaning you will be able to reconnect to the system bootloader.

You can launch the OBK provisioning through this path

Then you can request option byte change to change product stat to CLOSED.

As BOOT_UBE is set to 0xC3, it will automatically launch the STiROT.

Regarding first jump to system bootloader to avoid controlling the BOOT0 pin I made a quick check and it you cannot do this if TrustZone is not already enabled. I mean your simple firmware is probably running without TrustZone enabled and this is required to be able to setup the secure watermarks and secure boot address.

After enabling TrustZone in option bytes you have to go through a reset to enable the RSS that will allow changing secure related option bytes.

If TrustZone can be enabled in advance, it should be possible to avoid using BOOT0 pin.

Best regards

Jocelyn

[RomThi]

Hello Jocelyn,

thank you very much for the clear answer. Now I think I understand the principle. In the provisioning state the bootloader has access to the RSS functions.

See here:

Is this correct?

Best regards,

Roman

[Jocelyn RICARD · Accepted solution]

Hello Roman,

"Switch to lock", for testing purpose I would switch to closed in order to be able to regress the device.

Also, Boot0 can be tied to VDD, no need to set it back to VSS.

Otherwise, yes it looks good.

Best regards

Jocelyn

[RomThi]

Deleted

[RomThi]

Hello Jocelyn,

I have tried to test the provisioning using the system bootloader. I figured out that the sequence of the batch files does not work. For example as a first step the trust zone will be enabled. After programming the option bytes the programmer is reconnecting and fails to connect. It seems that the system bootloader does not work anymore. 

To make my life easier I am trying a different solution. I will split the procedure into two parts. One part is done during production of the PCB the other after assembly. 

That should work better. See here:
 

Best regards,

Roman

[Jocelyn RICARD]

Hello @RomThi,

Here is what I wrote in previous post

"Regarding first jump to system bootloader to avoid controlling the BOOT0 pin I made a quick check and it you cannot do this if TrustZone is not already enabled. I mean your simple firmware is probably running without TrustZone enabled and this is required to be able to setup the secure watermarks and secure boot address.

After enabling TrustZone in option bytes you have to go through a reset to enable the RSS that will allow changing secure related option bytes"

So, it is important to have the ability to perform a reset.

I will try to check on my side a full provisioning using bootloader. But not before end of the week or beginning of next week.

Best regards

Jocelyn

[RomThi]

Hello Jocelyn,

thx for checking it.

In the meantime I have tested my two step solution and it seems to work. I have made some simple modifications to the batch files.

See here:
  

Now calling "provisionig.bat" is the first step and calling "obkey_provisioning.bat" is the second step. The keys download over UART looks good, so I think SPI will do too:

After calling "discovery.bat" i get:

Best regards,

Roman