Secure firmware updates from USB Stick on STM32U5 - how to? (2)

[TDJ]

@Guillaume K, @Jocelyn RICARD 
Since my previous question on the same topic (see here) I have reviewed probably all the MCUboot/TF-M-based solutions available for ST MCUs. There are currently four options that I am aware of:

1. TrustedFirmware-M (TF-M) using the latest MCUboot, implements well-documented PSA-API, actively developed and maintained by community.
   Regretfully, this solution appears to be no longer actively supported by ST, STM32U5xx HAL version is 1.0, so no support for new ST MCUs.
2. ST's TFM, described in AN5447 and UM2851, still available as a part of the STM32Cube_FW_U5_V1.4.0 package under /Projects/B-U585I-IOT02A/Applications/TFM folder, probably abandoned, removed from GitHub for this reason.
3. Secure Boot and Secure Firmware Update (SBSFU), described in UM2262 and partially in AN5447, STM32U5G9 supported, based on relatively old TF-M 1.3 (current version is 2.0, version 2.1 to be released in 3 wks).
4. X-Cube-Azure example aimed at B-U585I-IOT02A board, no STM32U5G9xx support yet but STM32U5A9xx seems to be handled, based on TF-M 1.3, there are many important updates since then - e.g. MCUboot upgrade to v2.0.0, see release history.

What I need to implement is a very typical real-live scenario - a device (let's imagine it is a fancy coffee machine) based on STM32U5G9 MCU which will be periodically updated by a qualified service technician from USB stick (Y-modem etc. is not considered a modern/convenient hence acceptable solution). Therefore, only the boot loader and the USB Local Loader apps require 100% secure updates (two slots) since any update failure would brick the device. As long as Local Loader is healthy, failure to update the Main App is not a problem, another attempt, e.g. using another USB stick can be easily made.

On the contrary, the Main App, which will be loaded from USB stick by Local Loader and updated the most frequently, does not require primary/secondary slot since the ability to utilize the maximize remaining flash area is way more important.

Needless to say, the Main App image has to be encrypted and signed thus Local Loader needs to be able to verify the signature of the firmware image temporarily placed in SRAM and decrypt it. I do not mind if Secure FW or Local Loader update wipes out the Main App - probably it will have to be updated anyway. Likely Main App image will have to be compressed before it is encrypted and delivered and then decrypted because otherwise it may not fit into available SRAM, unless decryption is done on-the-fly but this is less of the problem.

Conceptually, what I described above is Trusted Client scenario, defined in PSA-API, section 3.3.3.

I am afraid that only the first solution listed above (TrustedFirmware-M) guarantees that recent fixes and security updates can be quickly applied. The only downside is that probably I will have to update HAL to a recent version myself and maintain it. I already know it is not a simple task since among STM32U5xx MCUs only STM32U585 is supported and many things are hardcoded.

1. Is it possible to implement the above-described scenario with SBSFU? Although SBSFU does not incorporate the latest TF-M and MCUboot versions, it may be the quickest way forward since SBSFU receives current ST updates the most frequently.
2. Is there any chance SBSFU will be updated to a new TF-M version soon or ST will truly support current TrustedFirmware-M (TF-M) solution? It seems that today the choice is between either new MCUs and old TF-M or new TF-M but no recent MCUs.

Please comment/advise.

[Jocelyn RICARD · Accepted solution]

Hello @TDJ ,

the secureboot solution we propose is based on the mcuboot version used in TFM 1.3, which starts to be old I agree.

This version is certified PSA-L3 and SESIP L3. This means that it is robust to board level (glitch attack). This could be obtains thanks to the adaptation made by ST to make mcuboot robust enough on the STM32U5. What is maintained by ST is this adaptation regardless of the further evolutions made inside mcuboot. I guess you can imagine the time and money needed to analyze the code, implement the necessary countermeasure to possible attacks, have all this certified. We are not here in a "feature" environment where you want to get latest evolution but rather in a controlled environment where we don't add new features if they are not needed.

You can check the history of mcuboot changes here  https://github.com/mcu-tools/mcuboot.git

The mcuboot version that was adapted is the 1.7.2

All this to say that if you need a robust sercure boot you can use the SBSFU solutioni provided in the cube:

https://github.com/STMicroelectronics/STM32CubeU5/tree/main/Projects/B-U585I-IOT02A/Applications/SBSFU

You will see it can be adapted to your target STM32U5 because all derivatives are supported (check readme.md).

For me this is the best secure boot solution you will get.

Best regards

Jocelyn

[TDJ]

Hi @Jocelyn RICARD, Thank you, I see your point. I can only say that more transparency on STs' part like publicly available software product roadmaps would probably help to eliminate at least some of the wasted time and frustration that inevitably comes with software engineering, especially when it comes to new ST MCUs.

[TDJ]

@Jocelyn RICARD Just one more comment. For my current project I will proceed with TrustedFirmware-M (TF-M) solution, despite its folder structure is a nightmare. It took me several days but I just got it working with STM32U5A9, with gtzc config commented out for now all tests pass. On reason for this choice is strategic: it is difficult to see SBSFU future in bright colors. Another one is technical: I prefer to have MCUboot as a separate image and the rest of the secure firmware updatable.

Probably there is really nothing which precludes ST from relaying on TrustedFirmware-M (TF-M), marking only certain releases as LTS and getting them certified, other than the lack of political will of course.

[Jocelyn RICARD]

Hello @TDJ ,

I gave you my advise from information you shared. From my understanding you don't need TFM, just a secure boot. If you don't use TFM services you have at least 400KB of flash that will never be used.

Besides, I don't understand your statement: " I prefer to have MCUboot as a separate image and the rest of the secure firmware updatable."

MCUBoot image is always a standalone image. This is a secure boot whatever the way you build it.

Best regards

Jocelyn

[TDJ]

Hi @Jocelyn RICARD, Unless I am missing something, SBSFU consists of two applications: secure and non-secure. At least this is what docs state all over the place. Only two images: bootloader combined with secure services running in trust-zone and the main non-secure user application.

By default, TrustedFirmware-M (TF-M) uses 3 images: MCUboot (BL2) which is NOT updatable (at least not easily), updatable secure services image (runs in TZ) and the main non-secure application image. Needless to say, ability to update secure services is a very nice feature. Ofc, I may never need it but if I do and it is not an option the product has a problem. It is all about risk mitigation (e.g. currently unknown vulnerabilities) and flexibility to add new features hard to foresee initially. The product hopefully will live for many years and will continue receiving software updates.

Since my first user application (local loader) needs to be able to at least verify signature of the image it downloads in order to early report new firmware problem to the user, I need TF-M secure services very much. Otherwise, I would have to use (and store) another set of keys etc. in non-trust zone. This simply is not an option.

[Jocelyn RICARD]

Hi @TDJ ,

I feel some misunderstanding. Let me explain.

SBSFU project provides:

1) One Secure boot project called SBSFU. It is the first application running after reset and is immutable. Cannot be updated in any way. This is the root of trust.

2) A secure application that is launched by SBSFU

3) A non secure application that is launched by secure application

The important part for secure boot is ONLY the SBSFU.

The secure application is already YOUR application. Secure application is responsible for configuring the security of the platform. So, it mainly setups the split of peripherals between secure and non secure.

Secure application can also offer secure services available from non secure application through a secure API. You have an example in the code.

Then once secure application had finished the initializations, it jumps to the non secure application.

Non secure application is the main application running.

SBSFU can update secure and non secure application. Depending on configuration, you can have one binary containing both secure and non secure for the update or you have one binary for secure and another one for non secure. In this last case, you can have a different key to authenticate secure and non secure. This could be useful if secure and non secure are not owned by same entity.

On top of this basic secureboot configuration, if you add TFM, then TFM completely replaces the secure application you had before. Non secure application will then be able to call secure API through PSA API defined by TFM.

In term of update by default, the mcuboot is setup so that you will update TFM and non secure application separately.

So, both solutions are very similar except with TFM you get secure services already implemented.

If you need TFM use it, if not use SBSFU solution.

Last point, the only entity able to verify the signature is the secure boot (mcuboot) because is owns the public key used for that. The loader that transfers the new update image in the flash has not this ability (or you duplicate the key but what for ?)

I hope this clarifies things

Best regards

Jocelyn

[TDJ]

Hi @Jocelyn RICARD,

Thank you for this clarification. It did not immediately occurred to me that UM2262 publication describing SFSFU solution is probably very outdated. STM32U5, Cortex-M33 with TrustZone and MCUboot are not even mentioned.

Secure TF-M app I need exactly to be (e.g.) able to verify downloaded image signature from unsecure app without access to secure keys which, of course, cannot be exposed to unsecure app. Ability to handle scenarios like the one I described, best to my knowledge, is the very reason why countless hours have been spent to build TF-M solution, although it takes extra flash space and it is not just several kB. This is the area where SBSFU clearly falls short.

SBSFU solution deserves credit for being much easier to grasp, but TrustedFirmware-M (TF-M) has the functionality I need. Actually, way more than I need which, as you rightly pointed out, does not come free. ST's TFM solution was probably intended to bridge this gap. Too bad it appears to be abandoned.

Kind regards,

Tomasz

[Jocelyn RICARD]

Hello @TDJ ,

UM2262 Title is Getting Started with the X-CUBE-SBSFU STM32Cube Expansion Package. STM32U5 is not mentioned because this package does not target this chip. This is a ST solution.

The secure boot solution we support for STM32 using ARM Cortex-M33 is based on mcuboot.

Regarding your statement: 

"Secure TF-M app I need exactly to be (e.g.) able to verify downloaded image signature from unsecure app without access to secure keys which, of course, cannot be exposed to unsecure app"

TFM provides Firmware Update PSA API that helps with new firmware installation. But TFM has no capability to check your firmware. The only entity able to check a firmware is the secure boot. This is its main purpose.

Last point, TFM is no abandoned by ST. Latest TFM 2.0 runs in 3 CM33 based STM32 : STM32L5, STM32U5 and STM32H5. 

Best regards

Jocelyn

[TDJ]

Hi @Jocelyn RICARD,

I admit, initially I was quite confused. There are at least two much different SBSFU solutions for U585I-IOT02A board and two TFM solutions (community/arm driven and ST's - the one just removed from Github).
Maybe community TFM is not abandoned by ST, but it is not actively supported. Probably it never worked. ST's common postbuild.sh and TFM_UPDATE.sh scripts had syntax errors. I reported it recently and it had been fixed thanks to Ahmad El Jouaid's help.

Following your advice, I gave SBSFU another chance and, all in all, it seems to me that the version available on Github here (vs the one available from "example builder" in CubeMX) is the best option to start with. CubeIDE solution shows only the needed files which makes it incredibly easier to analyze and understand how the solution works under the hood. Actually, it is not that complicated. I was even able to build it in VS Code, the only environment I use, with my favorite cppbuild tool. Not to mention that the full build took 25s vs ~5 min for the full TFM build.

"But TFM has no capability to check your firmware" - probably it is not exactly the case. Although I have not tested it yet, I believe it can be accomplished by calling psa_fwu_start() optionally followed by psa_fwu_write() function call if no PSA_ERROR_INVALID_SIGNATURE or any other error is returned.

Thank you,

Tomasz