STM32 TrustZone implementation... considering just hiring it out

Site Feedback
1

I kind just don’t have the time for this. I need to ship product soon, and have basically saved the bootloader for last.

I have 2MB flash, and it’s split into two soft banks of 1024kb each.

Having trouble navigating all the M33 TrustZone bs.

All I want to do is firmware OTA updates, and on boot check which bank is “active”, check it against it’s hash, and if it’s good load it.

There seems to be a ton of stuff I don’t want or need. Has anyone deployed STM32 trustzone in a way they’ve been happy with?

2

I’ve done my own implementation on STM32F7 and F4 mcus for my company. Used MbedTLS library to do signature verification. Also did the dual bank OTAs, with a unified binary having firmwares for both banks and the fw will write the correct version to the correct bank. I didn’t bother with ST’s trustzone implementation. Hit me up if you’d like more details.

3

Hi, it’s unclear whether you need dual-bank secure boot, or trustzone separation after boot.

Check wolfBoot, it’s a ready-to-use secure bootloader solution. It already supports your target, and does what you described when activating the DUALBANK_SWAP option on the targets that support that:

https://github.com/wolfSSL/wolfBoot

If you want a more complex setup with TrustZone-M separation after boot, and isolating the crypto calls used in the application, also check this blog post, using wolfBoot as domain separation and providing a crypto-engine in secure world (accessible via PKCS#11):

https://www.wolfssl.com/wolfcrypt-in-trustzone-m/

4

My concern is that the F7 and F4 are M7 and M4 right? The M33 seems to be a little jerk.

I’m already using mbedTLS on the application side, so nothing too difficult there. Yea, I considered not messing with the TrustZone stuff, except for two things…

It looks like some STM32 parts get OTP memory, which would be super handy, but I only see it referenced to trustzone.

And ST does a terrible job of not explaining the difference in read memory protections when not using trustzone as the full suite.

All I want to do is disable SWD, enable read protection, block out a bootloader flash area, and ideally re-enable SWD with a “password” input. But I would give up that last one.

5

Yea, this is by far some of the best advice I’ve recently received.

  • TrustZone

  • Hardware assisted swap (uses built-in bank switch)

  • Delta OTA… this is HUGE! Their tools and firmware writer are already set for small deltas plus rollback from it! Crazy, I thought I was going to have to do this myself. HUGE undersold feature!

  • Allows one crypto routine in bootloader to be accessed (securely in TZ) by the application. So now my app won’t need a separate crypto routine. Although I will need to learn more about PKCS#n.

  • Rollback, downgrade check, signatures, choice of ciphers, using chachapoly like I am anyhow.

Dude… Great advice.

6

Yes, M4 and M7, I suspect M33 has the same options to disable read protection and let you enable MMU if you wish. The only concern I would have with using mbedTLS in M33 would be the verification time of image signature. But if boot time is not a factor for you, then it should be ok.

In my case when I was using M4 and was trying to setup DTLS connections, the connection setup time was more than I would have liked.

7

wolfboot depends on a few submodules. You should ensure those are also checked out.

git submodule update --init

8

following RFC9019, the bootloader is not responsible for transferring the update. In other words, you can use any transport mechanism to download the (signed) update to your device from your application/RTOS, then notify wolfBoot a new update is available by setting a flag