SFI without TrustZone on STM32U5 is possible?

[paolog]

I need to perform SFI on an STM32U599 MCU, so following the wiki article "SFI Step-by-step on STM32 boards" I prepared the firmware and programmed the HSM V2 smartcard.

I'm sending the command

STM32_Programmer_CLI -vb 1 -c port=SWD mode=HOTPLUG -sfi xxx.sfi hsm=1 slot=1

Command execution seems ok, but the final message:

Reconnecting...

Reconnected !
Error: Database: There's no active configuration for this device. All the 8 configurations are disabled!

What's the problem? Most of all, I found that now the TrustZone of the CPU is enabled, while it was not set in the option bytes file used to prepare the SFI.

Other option bytes differnet from the settings in my option bytes file are nSWBOOT0 and nBOOT0

As a note: if I use the GUI to program the SFI I have to specify an RSSe file, while using the CLI seems like this file is not required. Im sure I'm missing some information... TrustZone has to be set to perform SFI on the STM32U5?

[Jocelyn RICARD]

Hello @paolog ,

yes SFI usage requires TrustZone to be enabled.

SFI is a secure mechanism that switches the U5 to RDP 0.5 during the installation process in order to make sure nothing will leak.

So, if you have a final option byte setting that disables TrustZone it will not work.

nSWBOOT0 and nBOOT0 are used to make sure that during SFI installation you will boot on RSS.

But at the end you can change them back to default values in your OB config

Best regards

Jocelyn

[paolog]

Thank you, @Jocelyn RICARD .

As I'm new to the mechanism, is there any guide I can follow to do what you suggest? My application doesn't use TrustZone, I would just need to enable RDP2 and leave a chance to update firmware thru SWD if necessary, applying the RDP regression before downloading the updated SFI to the board.

When you say that I can change nSWBOOT0 and nBOOT0 after SFI installation you mean I can just use STM32 Programmer to restore the original values? TZEN bit can't be reset withour regressing RDP, so the firmware would work even if it's not using the TrustZone?

Best regards,

Paolo

[Jocelyn RICARD]

Hello @paolog ,

you can find documentation on SFI in the wiki here

You also have a X-CUBE-SFI to make experiments

SFI is secure firmware install. This mechanism is only for production.

If you need to update your device, you should implement a loader that manages this update and even better a secure update using SFI.

If you don't care about security, no need to use SFI. And in this case, no need to enable TrustZone.

You can set RDP Level 1 and perform regression to update your device.

If you use RDP Level 2 you will need to first provision a password called OEM2KEY, and provide it when you want to perform this regression.

This mechanism is described in this application note.

Best regards

Jocelyn

[paolog]

Hi @Jocelyn RICARD , thank you for the explanation.

Yes, both RDP1 and RDP2 regressions are password protected with OEM keys so the MCU can be rewritten with the new firmware. So what would be the best way to perform a firmware update? I thought about SFI and HSM so I could send the updated firmware in a safe (as SFI would be encrypted) and controlled way (because of the license counter) to be downloaded using the SWD. Do I have other chances not making me use the TrustZone? Or should I implement a minimal trusted firmware?

Best regards,

Paolo

[paolog]

I've been reading a lot and found out that SBSFU might be the solution I'm looking for. I then looked at the example in the STM32CubeU5 firmware, and I couldn't adapt it to the STM32U599 (not the required encrypt/decrypt module). Is there a way to adapt the example to the STM32U599 (maybe using the software encription of the standard mcuboot module) or is it just impossible to use SBSFU with this MCU?

[Jocelyn RICARD · Accepted solution]

Hello @paolog ,

I'm sorry I missed your previous post.

Yes SBSFU is the way to go.

The SBSFU solution on STM32U5 enables crypto hardware acceleration by default because SAES and PKA ips are resistant to side channel attack.

For STM32U5 derivatives not providing these accelerators, you just need to disable their usage.

For this, open config-boot.h in SBSFU project inc, and comment the line

#define BL2_HW_ACCEL_ENABLE

Also, you should adapt in each project by replacing STM32U585xx by STM32U599xx

Best regards

Jocelyn

[paolog]

Hi @Jocelyn RICARD , thank you for your explanation. I start working on this solution then, maybe we'll switch to the STM32U5A9 in the future to have crypto hardware acceleration.

Just a note: in case of STM32U599 in file User/stm32u5xx_hal_msp.c the instruction at line 103:

.SaesClockSelection = 0,

should be guarded by 

#if defined(SAES) / #endif

Best regards,

Paolo