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.

[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

[TDJ]

@Jocelyn RICARD Thank you! Time to try!

[TDJ]

@Jocelyn RICARD, I have tried building both TFM and SBSFU apps, none of builds succeeded, results were described in issue #38 and issue #37.

[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