STM32H5 with Secure Manager - non-secure application not verified during startup

[OliverScheid]

What I want to achieve:

During startup all code is verified, starting with SMiRoT (as root-of-trust) then SMuRoT, then SecureManager then non-secure application.

If the application has been modified (vberification fails) the startup shall end in system bootloader.

Unfortunately, this does not work as our tampered/modified non-secure application is still started/executed instead of jumping into bootloader.

Secure manager is installed with the provisioning script. We have modified the BOOT_UBE setting via TrustedPackageCreator from 0xB4 (OEM-iRoT - user flash) to 0xC3 (ST-iRoT - system flash) and re-generated Option_Bytes.csv

What I see is that when connecting the STM32CubeProgrammer, the value for BOOT_UBE still shows 0xB4.

And in the log during SFI flashing (provisioning.py -v --sfi-flash) it shows this:

DEBUG - Warning: Option Byte: BOOT_UBE, value: 0xB4, was not modified.
DEBUG - Warning: Option Bytes are unchanged, Data won't be downloaded
DEBUG - Time elapsed during option Bytes configuration: 00:00:00.010

So, my question is: what am I missing in order to enable the secure boot chain correctly?

[Jocelyn RICARD · Accepted solution]

Hello @OliverScheid ,

With Secure Manager from version 2 you should have BOOT_UBE set to 0xB4 (Boot from flash : SMiROT)

If you stay in TZ-CLOSED state, you are in development mode, so no jump to bootloader.

If you set product state to CLOSED then it should jump there

Best regards

Jocelyn

[OliverScheid]

Hello @Jocelyn RICARD ,

thank you for your very fast response. In fact, this "detail" solved our problem. After changing from TZ-CLOSED to CLOSED, the Secure Boot is working as expected and entering bootloader if the application is corrupt.

Now, I am wondering which part of the documentation I have missed because I could not find anywhere this hint that Secure Boot is actually disabled while in TZ-CLOSED.

The following table from RM0481 does not help here:

And additionally, it is even confusing because (as you said) with Secure Manager we have BOOT_UBE set to 0xB4 which would not boot through STiRoT/SMiRoT according to this table.

Would be great if you could also clarify above confusion. But apart from that, I am happy that Secure Boot is now working as expected (in CLOSED state).

br, Oliver

[Jocelyn RICARD]

Hello @OliverScheid ,

You are right, I couldn't find an explicit statement in the Secure Manager associated documentations: AN3254 and the wiki

Now, in this state you are able to download the non secure binary and test it without having to provide the signed image. So, you can imagine there is a bypass at this stage.

Now you can still download a signed image and you will be able to get image status. This allows validating your update mechanism.

Regarding the boot details, Secure Manager boots on SMiROT and not on STiROT. This is explained in AN3254 Rev8 chapter 1.3.1

Best regards

Jocelyn

[OliverScheid]

Hello @Jocelyn RICARD ,

Thank you. Could you please check your reference, as to me AN3254 seems to be smth about SPI.

I am afraid this is just another misunderstanding on my side. I actually thought that SMiRoT is just another naming for STiRoT. I mean, how can SMiRoT be immutable (if it is not just the STiRoT with another naming), when it does not come with the hardware on the chip (like STiRoT)? How does this work?

kind regards, Oliver

[Jocelyn RICARD]

Hi @OliverScheid ,

I'm sorry, this is UM3254 not AN.

STiROT is part of the SystemFlash that is protected against reading and writing, like other services such as RSS and DA.

SMiROT is basically the same code but located in user flash. It is also protected against any access, but it uses STM32H5 security protections: HDP and WRP. Reason for having this SMiROT in flash is because STiROT it too restrictive concerning Tamper protections and LSI/LSE configuration. Changing STiROT requires a new revision of the silicon. Changing SMiROT is a Secure Manager version update.

I hope this answers your concern

Best regards

Jocelyn