 Hello, welcome to this presentation about Wolf Boot on the STM32U5. This is part four of a series we're doing with ST. We're going to talk about how to configure and build Wolf Boot for the U5. We'll talk about how to do the key generation and signing for your firmware and how to test and debug in the security features that are on it as well. So this is the development board target that we'll be using today. This is a U585 and it's called the IoT02 development board. This is a Cortex-M33 running at 160 megahertz. It has 2 megabyte of flash, 786 kilobytes of RAM. So with Wolf Boots, there are a couple of things that you would need to get set up to build correctly. Everything is generally done from a Linux style environment where you have Mac and GCC. Here's a couple of ways you can install the essential items needed. All the source code for Wolf Boot, which it's a secure boot loader, I've talked about this in detail in some of the earlier videos, but it's a secure boot loader. It's out there on GitHub. It's as a GPLv2, you can download it. And I'm going to walk you through the steps to use it on the STM32 U5. Okay, so first thing after you clone it is to basically define the configuration. And we have some templates underneath the config examples directory. And there's actually one, I think there might be two out there for the STM32 U5. There's one with trust zone, one without. You could optionally do make config, which will list you through like 20 different options, but using one of these templates is the best way to move forward. Here's an example of some of the settings. So, you know, the architecture's arm, the TZEN, which is trust zone enable is one. The target is the STM32 U5. This example uses ECC 256 bit for the signing, but we also support 3A4 bit, 521, add 25519, RSA 2048, 3072, 4096. So those are all asymmetric algorithms that you can use for signing firmware. And we have a few different hash options as well. That's the digest that's computed over the firmware image. And then that digest is what gets signed. The image header size is the amount of space we reserve at the beginning after we apply our signature to it, which contains information like the hash and the signature of the type version. And you could enlarge that to a different size and add additional values if you need. So this example sets up the partitions. So the sector size is 8K. That's just defined by the onboard flash. We reserve some space for the boot loader and the application and update partitions. And then we reserve a little bit of space for the swap. So you can swap between these two partitions at the end. This is just an example setup that we do. And let's see. So then after you've done the config, you basically just go make. And it will build all these things. It'll build the, well, it won't build the key tools. You should do a make key tools to build the C version. Otherwise, it'll try to use the WolfCritpy version of the signing and key gen tools, which is fine if you've installed it. But if you do a normal make, it'll build WolfBoot. It'll build a test application. It'll sign it and then it'll assemble all that into what we call a factory bin, which is just something you can flash all together onto the onboard flash as a test. So this is what it looks like to copy the example configuration to a .config file and do a make. And you'll see it builds both boot and the test app. And the next step it'll do is if there isn't a key to sign with, it'll generate one and then it'll do the signing. Like I said, we have two versions of the key tools. One is the C version and the other is Python. You can use either one. They're both maintained. The C version is a little bit more portable, in my opinion, which I know sounds weird, but it's true. So make key tools builds those two applications. And then those are examples of how you would call them. Although when you do a make, it actually will do this automatically, right? So it'll build a it'll create a private key if it doesn't exist. So it'll do this key generation and then it'll export the public key into the key store. And actually, I think this is a little bit different now. Yeah, because we have a key store file that contains all the keys because you can do multiple public keys in a key store. And the signing is an example for what a sign looks like. Of course, this is using ed25519. But normally, that would be the ECC256. Let's see. And then we do support using an external HSM if you wanted to sign with that. It supports a way to export the hash that you would sign on the HSM. And then you import the signature. And there's arguments for the sign tool for that. And you can see with that link that the steps to do that. So testing and debugging. Flashing is done with the STM32 Cube Programmer tool. And that's a there's a command line interface tool. And these are the examples of how you would actually program it. So one is, you know, the option bytes for trust zone. But then flashing the WOLF boot.bin and the test app that serves you what you would do for that. You could also flash the factory.bin if you wanted on a successful boot with this board, you'll actually get the boot LED number nine. The red one will be turned on. If you wanted to do a test, you could sign that same firmware with a version two. So like this last argument is the version number. That's a 32-bit value. And WOLF boot is looking for a newer version to install, right? So if you sign with a newer version, it'll try to update that. And you can flash to it and reboot. You can see that it'll actually use that one instead. For debugging, you can build WOLF boot in the test app with debug symbols included if you use the make debug equals one. And then you could program that and attach the GDB server. And you could use GDB to actually walk through the code. You can add the symbol file as well for the test app. There's actually a GDB init in WOLF boot specified right here that actually points to where the symbols are for WOLF boot. And then you can supplement the symbols for the test app so you can set break points and jump around between the source code on both. So the U5 has quite a few security features built in. Let's see, there's the Secure Firmware Install SFI, which is in the reference manual section 3.2. It is Secure Encounter Installation of the OEM firmware using immutable root of trust code sort and system flash. It's a procedure that ST came up with for provisioning which is quite good. This chip also has trust zone and that basically has secure and non-secured version areas of the chip, so flash and memory that can isolate from each other. And WOLF boot does have some trust on support that's out there in a pull request and that's still a work in progress. But you're welcome to explore it. There's also temporal isolation, which uses this secure hide protection mechanism. So after you jump out of WOLF boot, the areas that WOLF boot resides in flash are inaccessible from the user application. And we have some support for that that's for similar architecture, the G0, which can be adopted. There's also the write protection. So this would be to prevent illegal or unwanted flash writes or erases on certain pages. There's also the readout protection, RDP. And this is when you're at the end stages of production, you would lock down your device. And these are the methods you would do that. For example, RDP level two would be set to prevent modification of the option bytes. So it's really important things to consider when you're building a device and you're putting that into production. Anyway, thank you for your time about WOLF boot, our secure boot loader. And thank you for ST for allowing us to do these videos.