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 · Accepted solution]

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.

[MM..1]

When user can do download file for flash, then user too can download exe file to run some secured flash process on PC. But as i write exist many security levels.

[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.

[Jocelyn RICARD]

Hello @TDJ,

First regarding SFI, this mechanism only made for secure production. SFI is Secure Firmware Install  .. in factory. No more. SFI mechanism cannot be used for updating your product.

As I understood you want to be able to securely update your device through a USB stick.

The open bootloader is definitely not a solution because it does not provide such USB host interface.

The 2 next points you mention are similar. The TFM is a secure framework that comes with a secure boot (we call it SBSFU) based on MCUBoot. We also provide the SBSFU without TFM framework.

The SBSFU used in TFM is nearly the same as the SBSFU provided "standalone".

In your case, I would suggest using the SBSFU project as base.

STM32Cube_FW_U5_V1.4.0\Projects\B-U585I-IOT02A\Applications\SBSFU\

This secure boot will provide all needed secure features.

The loader part is using Ymodem to transfer the firmware. This is where you need to adapt the provided example.

You can either implement the connection to USB stick in your application or in the separate loader project provided.

If you implement the loader in your application you will need to have 2 slots configuration: One active slot where your application is running and one download slot where you will transfer the file from the USB stick. Then SBSFU will take care of the secure update by checking authenticity of the downloaded file and installing the new firmware in the active slot.

Other solution is to implement USB host in the loader project. This way you don't need a download slot. The old firmware is first erased and loader writes new firmware in internal flash. SBSFU will then check and install it. It will involve decryption of the firmware in place.

I hope this clarifies what you can do

Best regards

Jocelyn

[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.