Secure Firmware (Re)Install by the end user on STM32U5 - how to?

[TDJ]

ST undoubtedly put lots of effort in building a complete and coherent solution supporting secure firmware install (SFI), even done by contract manufacturer (CM) independent from the original equipment manufacturer (OEM). See AN5054 and AN4992.

However, how can I use this solution, or even part of it, to allow the end user to update STM32U5 firmware once a new version becomes available, preferably using firmware image downloaded from my website and stored on USB pendrive? I imagine that such image could be generated based on the actual device "license" provided (uploaded) by the end user, but it is not a must.

Are there any examples, application notes, or presentations available on this subject?

Reading firmware file from the pendrive is not a problem, but what needs to happen next is.

Please advise.

[STea]

Hello @TDJ ,

To insure firmware update by end user Via USB or another media you cna refer to the Secure Boot Secure firmware Update (SBSFU) implementation based on the open source TF‑M (Trusted Firmware for Arm® Cortex®‑M) reference implementation. This solution verifies the security triad (Confidentiality,Authenticity ,Integrity ) of the OEM firmware during boot via verification encryption isolation and many other mechanisms for more details you can refer to the AN5447 and UM2851 which gives a detailed explanation of this solution and its implementation .

An example can be found for the SBSFU on the STM32U5 series on the stm32cubeU5 package or from this github link .

Hope this answers your inquiry.

BR 

[TDJ]

@STea Thank you, this very helpful.

[TDJ]

@STea After some reading I understand that (not to mention USB DFU) there are at least three bootloaders currently supported by ST for STM32U5:

1. Open Boot Loader, probably meant to be used only by OEMs, reads SFI and other similar images created with STM32CubeProgrammer, process described in AN4992, AN5054, UM2238.
2. Trusted Firmware for Arm® Cortex®‑M (TF-M), based on this reference TF-M implementation. Solution is available as a part of the STM32Cube_FW_U5_V1.4.0 package under /Projects/B-U585I-IOT02A/Applications/TFM, but for this reason it is not available on GitHub and is described in AN5447 and UM2851.
3. Secure Boot and Secure Firmware Update (SBSFU), described in UM2262 and partially in AN5447. This solution is also based on open source TF-M, but probably on some earlier version.

If this is correct, which of the above three solutions is best suited to accomplish what I need? That is, a bootloader, reading encrypted and signed image file from pendrive thus, practically speaking, using FileX, USBX and, as a consequence, based on ThreadX?

What worries me a bit, before I invest more time, is that the last two solution seem to be using TFM while according to docs TFM does not support ThreadX, but I hope it is not exactly the case or it does not matter.

[MM..1]

Based on security level you require exist one next more simple system bootloader. AN2606

I pref miniUSB DFU

[TDJ]

@MM..1 Thank you, but I do not quite see how your preferences apply in my case.
My strict requirement is that the user (not me) is able to update firmware using USB pendrive with signed and encrypted image file on it.

[TDJ]

@MM..1 Well, if you say so..
Anyway, (mini)USB DFU solution clearly does not fulfill my requirement, cannot be considered as secure and as such is not suitable, but thank you for your advice and opinion.
In the context of my solution miniUSB DFU is good only for the one time immutable boot install, a secure (TrustZone) app responsible for the first secure boot stage, providing the most basic services and containing root of trust (RoT) data. I think USB DFU may also be used in "local loader" (TFM_Loader, SFSFU_Loader apps) in addition to or instead of UART/Ymodem.

[TDJ]

Hello @Jocelyn RICARD,

Thank you for your answer and advice. Using two slots may not be the most desired option since it limits the app size.
Hence, TFM_Loader or SFSFU_Loader app may be the best option. Even adding a simple graphics with very low memory requirements (e.g. 1bit color) is a manageable task.

I do not fully understand all the process details yet, but what I envision is a small "local loader" reading the entire firmware image to SRAM, verifying signature, integrity, decrypting it and only then replacing the existing image in flash.
U5Ax and soon U5Gx have SRAM size comparable to flash size but still smaller, hence initial or post-decryption in-SRAM image compression might be a viable solution. Is such flow supported by TF-M yet? 

Why SBSFU is recommended over TFM? Is it because it is simpler? TFM seems to be more capable, more secure (SESIP/PSA Level) and newer, although READMEs do not explicitly specify base TF-M version used. I think they should.

[Jocelyn RICARD]

Hello @TDJ ,

If you use the SBSFU in one slot configuration, with an external loader (loader project provided in SBSFU), the loader task in ONLY to transfer the signed/encrypted binary to internal flash. Once new firmware is transfered in internal flash, the loader just needs to launch a software reset. The secure boot (SBSFU) will detect the new firmware, check integrity, authenticity and if everything is ok, will install it in place at same flash location. If the check fails, the firmware is erased and secure boot jumps to the loader to get a new firmware.

So, no RAM size constraint here.

TFM is related to TrustZone environment coming with CortexM33. TrustZone is a hardware isolation mechanism that can isolate a secure area from a non secure area. Secure area is where you typically put your secret assets, services, secure storage. Non secure area is typically where you put your application and communication protocols.

TFM provides a framework for this SecureArea. TFM is not a secure boot but requires the usage of a secure boot.

So, if your requirement is to have a secure boot and secure firmware update, TFM is not needed. 

Best regards

Jocelyn

 

[TDJ]

@Jocelyn RICARD To clarify; this thread question is in the context of STM32U5 (CM-33) so it can be assumed that TrustZone can be configured and used.
Then when is TFM solution required? Is it required only when the main (non-secure) app needs to update itself without using the "local loader" and/or when it needs to update the "local loader"? Did I get it right?
It is important for me to understand it correctly because I may need to be able to update the "local loader" as well (not the immutable bootloader). I hope there is a way the "local loader" can safely/securely update itself and the main (non-secure) app does not need to implement this functionality and simpler SBSFU solution can actually be used.

[Jocelyn RICARD]

Hi @TDJ ,

Today the SBSFU example requires enabling TrustZone.

The reason is that HDP feature is only available when TZ is enabled. This HDP feature allows hidding the secureboot code and data (keys) when application is running.

There is no need to have TFM when enabling TrustZone. You can have your own secure application. 

In the SBSFU example, the local loader (called external loader) is supposed to be write protected, so not updatable.

If you want that loader updates itself you should implement it. Not sure this is very simple ...

Best regards

Jocelyn

[TDJ]

@Jocelyn RICARD Something tells me that I may need TFM solution then.
Ymodem boot loader probably will never need update, but it may not be the case with USB boot loader.
Back to my question, when TFM solution/example would be preferred over SBSFU solution?
Why would I want to use TFM?
HDP feature and, consequently, security level may be important - even (particularly?) if it is just a selling point.

[Jocelyn RICARD]

Hello @TDJ ,.

TFM provide secure services such as cryptography and secure storage.

TFM also provides a firmware update services just to be able to "hide" the download slot in a secure area.

TFM requires dual slot and has been developed to address IOT where you use remote update (OTA)

Here you want to perform "local" update in one SLOT. So, TFM is not needed.

If you want an updatable USB loader, one simple way could be to use a dual slot configuration and implement the transfer from USB stick to flash inside your application. As you already noticed, in that case, you will need bigger flash size because you need a second slot with same size of your firmware.

Best regards

Jocelyn

[Jocelyn RICARD]

Hello @TDJ ,

yes, this is a known issue in STM32CubeIDE 1.14.0 I raised internally already some time ago but fix was not delivered.

Root cause is an issue in busybox resulting in pwd command retuning nothing.

So, prebuild and postbuild script using pwd will most probably fail.

Simple solution is to use older version of STM32CubeIDE 1.13.2 until fix on 1.14.0 is available.

Best regards

Jocelyn

 

[TDJ]

@Jocelyn RICARD Thank you. Do you maybe know why TFM app does not build at all? It is actively maintained?

[Jocelyn RICARD]

Hi @TDJ ,

I checked yesterday with STM32CubeIDE 1.13.2 and didn't face any issue.

About your question, TFM porting on U5 is using version 1.3 of TFM which is now quite old. There is no plan to update TFM porting inside the CubeU5. But it should be maintained in the TFM github.

Best regards

Jocelyn

[TDJ]

@Jocelyn RICARD STM32U5 TFM App is no longer available on GitHub for this reason.
I am looking into the original, ARM-maintained TF-M.