stm32u5 Secure boot with RSS(root-secure-service) as starting point?

xj · ‎2024-06-19

Hi,

I am trying to write a bootloader that implements secure boot on STM32U545 or 585. Now I work on the SBSFU Example from ST on the discovery board b-u585i-iot02a as a starting point.

Questions:

Can I use a bootloader based on the SBSFU_Boot from STM32U5 as the unique boot entry point and configured as write protected, to achieve the aim of secure boot?
If the bootloader should be updatable in field, which method can be used?
1. Possiblity: boot from RSS with DFU. But I need to get to USB on Hardware, right?
2. Is there other ways than using USB?

Thanks in advance.

Jocelyn RICARD · ‎2024-06-19

Hello @xj ,

The secureboot must be the unique entry point. Otherwise it is no more a secure boot !

If you provide a way to update the secure boot, it is also no more a secure boot.

The only solution to have an updatable secure boot is to have 2 stages:

First stage is a simple, not updatable secure boot that authenticates a 2nd stage

Second stage is the updatable secure boot that authenticates the application.

There are no example of 2 stages bootloader on STM32U5.

An example exist on more recent STM32H5 but it is not easily portable on STM32U5 because it uses different security mechanisms.

Best regards

Jocelyn

xj · ‎2024-06-20

Hello @Jocelyn RICARD ,

thanks for the quick reply!

About two stages bootloader:

1) If a device is delivered with secure boot (including HDP, RDP, and write protection), is it still possible to reprogram the flash memory using the ROM-bootloader, which resides in the system memory, through an interface other than STlink(SWD)?

2) Can RSS be the first stage bootloader (STiRoT)?

In another post about this topic, you mentioned:

"RSS is not involved in checking integrity of the firmware once it has been installed.

This means STM32U5 does not provide a ROMed secure boot (as it is done on STM32H573 for instance)"

---> So, what would happen if the RSS is set as the unique boot entry in option byte, while the second bootloader and fw images already exist? Will the system still boot from RSS and then proceed to the custom bootloader?

3) Another question regarding flash size. If I use SBSFU as bootloader and two slots (primary and secondary slot) in a processor with 512KB, will there be issues regarding insufficient space? In section 8.3 "Memory Layout" of the document found here
https://www.st.com/resource/en/user_manual/um2851-getting-started-with-stm32cubeu5-tfm-application-stmicroelectronics.pdf,

it says, 512-Kbyte flash memory devices do not support this configuration with TFM.
However, would this configuration be feasible with SBSFU?

Thanks in advance!

BR, X

Jocelyn RICARD · ‎2024-06-20

Hello @xj ,

About two stages bootloader:

1) If a device is delivered with secure boot (including HDP, RDP, and write protection), is it still possible to reprogram the flash memory using the ROM-bootloader, which resides in the system memory, through an interface other than STlink(SWD)?

No this is not possible on STM32U5. The system bootloader cannot be used when device is closed using either RDP1 or RDP2.

2) Can RSS be the first stage bootloader (STiRoT)?
In another post about this topic, you mentioned:

"RSS is not involved in checking integrity of the firmware once it has been installed.

This means STM32U5 does not provide a ROMed secure boot (as it is done on STM32H573 for instance)"

---> So, what would happen if the RSS is set as the unique boot entry in option byte, while the second bootloader and fw images already exist? Will the system still boot from RSS and then proceed to the custom bootloader?

RSS on STM32U5 is not a secure boot. Unique boot entry can only address user flash.

3) Another question regarding flash size. If I use SBSFU as bootloader and two slots (primary and secondary slot) in a processor with 512KB, will there be issues regarding insufficient space? In section 8.3 "Memory Layout" of the document found here
https://www.st.com/resource/en/user_manual/um2851-getting-started-with-stm32cubeu5-tfm-application-stmicroelectronics.pdf,

it says, 512-Kbyte flash memory devices do not support this configuration with TFM.
However, would this configuration be feasible with SBSFU?

Yes you have enough space. SBSFU is taking less than 100 KB all included.

If you use a STM32U535 for instance, the flash layout of the SBSFU is automatically adapted.

Best regards

Jocelyn

xj · ‎2024-06-20

Hi @Jocelyn RICARD ,

1) I want to keep the possibility to reprogram the whole flash, but not by JTAG/SWD-Programmer. In my understanding, I should use a normal boot (not a secure boot) via ROM-bootloader in order to achieve this, correct?

2) It also may be desired to introduce secure boot later on in the field (e.g. when the MCU is updated at customer). Is it possible to use the normal boot via the ROM-bootloader to reprogram the flash to a secure boot image?

I am asking this, because it may be necessary, to set option bytes when applying secure boot later on, correct?

Best Regards

Jocelyn RICARD · ‎2024-06-21

Hello @xj ,

I understand you want to have a first version of your device that does not use secure boot and then later provide a secure boot through an update.

This is possible, but not secure !

The file you will provide that contains the secureboot will contain the keys used for the secureboot.

Any hacker can read the keys, and also replace the authentication key by his own. This way, when receiving a new update he will be able to decrypt it, resign it with his own key and update it, after making some modifications in the code for instance. This means you will not have the insurance the device is running a genuine firmware.

So, the secureboot will not be able to do what it was made for.

If you accept this risk there is no technical limitation. You can provide a full firmware image containing the secureboot and the application. Secureboot can setup the device to secure everything. And next update will require an signed and possibly encrypted image.

Best regards

Jocelyn

xj · ‎2024-06-25

Hello @Jocelyn RICARD ,

thanks a lot for the reply!

As previously mentioned, I am developing a concept that can update the 1st Bootloader, but it still has several open issues.

The brief process is shown in the following picture and includs two steps:

1. transition to ROM loader;

2. update either the 1st Bootloader or the whole image depending on demands.

Questions related to step1:

a) Are the following two methods of forcing the system into ROM loader correct? Assuming BOOT_LOCK option byte is not set.

(1) Change the boot entry to ROM loader using boot0 pin and trigger a reset.

(2) Jump to ROM loader from application using the solution at:

https://community.st.com/t5/stm32-mcus/how-to-jump-to-system-bootloader-from-application-code-on-stm32/ta-p/49424

b) Can the above two methods always be used successfully, regardless of the TZEN and RDP configurations?

Questions related to step2:

c) Can the Regression of RDP from 1 to 0 via ROM loader (through a non-JTAG interface) ONLY be done without OEM1 key, i.e., in rdp legacy mode?

General Questions :

d) Am I correct in understanding that the 1st bootloader, when BOOT_LOCK is not set, isn't secure boot, even though it can verify the integrity and authentication of the next stage image?

Thank you in advance.

Best regards

Jocelyn RICARD · ‎2024-06-26

Hello @xj ,

Questions related to step1:

a) Are the following two methods of forcing the system into ROM loader correct? Assuming BOOT_LOCK option byte is not set.

(1) Change the boot entry to ROM loader using boot0 pin and trigger a reset.

(2) Jump to ROM loader from application using the solution at:

https://community.st.com/t5/stm32-mcus/how-to-jump-to-system-bootloader-from-application-code-on-stm32/ta-p/49424

Yes with TZ disabled. When TZ is enabled the 1) is OK but the 2) can only be done from secure application and after setting up the platform so that ROM loader that is unsecure can run. I don't know if is was already done.

Questions related to step2:

c) Can the Regression of RDP from 1 to 0 via ROM loader (through a non-JTAG interface) ONLY be done without OEM1 key, i.e., in rdp legacy mode?

OEM1 key when provisioned is mandatory to be able to perform the regression. And it that case, regression can only be done through JTAG. So, answer is yes

General Questions :
d) Am I correct in understanding that the 1st bootloader, when BOOT_LOCK is not set, isn't secure boot, even though it can verify the integrity and authentication of the next stage image?

As long as you can change the boot address, you can bypass this verification.

Best regards

Jocelyn