 Hi, and welcome to this video about Wolf Boot. And this is presented in conjunction with ST. And today we're going to show you the out-of-box experience using Wolf Boot, which is a secure bootloader developed by Wolf SSL. My name is David Garski, and I'm a software engineer with the company. We're going to go over all the aspects that you need to download, configure, build, sign an image, do some testing and debugging. I will talk about the boot update process and how you would implement it. And then I will also cover some really great STM32 security features that we support and that are available. First, we'll talk about how to configure and build it. Today, I'll be using the STM32G0, the 7.1 RB nuclear development board. This is a lightweight Cortex M0 running at 64 megahertz. It has 128K flash and 36K of RAM. It's a perfect target for demonstrating Wolf Boot's small size and capabilities. So we use a make file based build system, which means you'll need some kind of Linux style environment to build with. If you're on Windows, there's a Windows subsystem for Linux known as WSL that you can use. You could also use MinGW or something like that. So all of our source code is available on GitHub or our website for download in its GPLv2. The first thing you need to do is set up a configuration, which defines the target, the type of architecture, and how you want to partition this board. We have some really great examples that are available already. And in this case, if you go and you download Wolf Boot inside the config examples directory, you will find some of these templates. In this case, what we'll do is we'll actually take a copy of this. So we'll take a copy of the config examples, STM32G0, and we'll put a file in the root of Wolf Boot called .config. You also have the option to do something called make config, which will actually prompt you for each of the settings. I'm not going to do that today. So this defines the architecture, the target, the signing algorithm. We also support ECC, so you could put ECC256 in there, or you could put RSA2048 or 4096. And we support hashing with SHA256 and SHA3. Let me go back to the slides real quick. So I covered these things, so the .config file. These are some examples of the configurations and the algorithms. One thing to note is the image header size, which is basically how much size you reserve for all of the configuration details, like the signature. And for some of the algorithms like RSA4096, but you may need to actually increase the header size to 1024 just to be able to fit the signature. So another important thing is the partition configurations. And this varies based on target. In this case, with the G0, there are two case sectors. And the way it's been set up is I reserve 32K for the boot loader, which is more than required. The boot loader itself is actually only about 11 or 12K in this case, and it can go up to 14. But with debugging symbols turned on for what I'm doing today, I want to reserve some space. Now with this 120K flash, I set up an additional 44 and 44, so the update and application partitions. And then there's one sector reserved at the end for the swap, the swapping. So we have the ability to roll back if there's a failure. So again, it's a make file based system. There are these different targets. So one thing we have is the key generation and assigning tools. By default, it'll use our Python version of those, which requires our WolfCrypt Pi module. I recommend just doing make key tools to build those C versions first. And then the default make does a factor.bin, which builds the WolfBoot binary and the signed application. And it combines those together into something you could use in the factory. Right, and this is an example of the output. So I want to go back to the console right here real quick. And I want to do a make key tools first. So it'll build a signing tool and the key gen tool, which I'll go into a little bit more detail next. And then I usually like to do a make clean and I'll just do a make clean and make. And so you can see in this example, the output of the WolfBoot image was 11.5. But, you know, almost 12K. Now, one thing that is interesting is it's really easy to actually change the signing algorithm. So let's say we wanted to change it to ECC 256. And we'll do another make clean and make. And I just wanted to compare the difference, so 11.5 to 14. And the ECC one is faster in this case. RSA is actually the fastest, but the code size goes up a little bit more. I'll show you that one real quick. RSA, 2048, if I type it right. We'll do a make clean make. So this one is, oh, it's actually a pretty good compromise. It's pretty fast and it's only 13K flash, so. As you can see, our WolfBoot image is really quite small. I'm not going to test with the RSA because I believe that the memory on this may have an issue. So I'm going to go back to 25.19 and I'll fire off a make clean and make. And then we'll go back to the slides. Okay, so another thing I want to talk about is the key generation in signing. So again, we have a C version of the tools and the Python version of the tools, which are both equally capable. It's just that the Python one did not run very well on Windows. And so we wrote the C version and we set up a Visual Studio project for that, which is available. For the key generation, WolfBoot expects there to be a private key in the root for signing. That's just the way it does it by default if you use the make. If you wanted to generate your own key and put that public key into the bootloader, you could do that. If you wanted to use your own external HSM for signing, you can do that as well. And there are instructions in this signing markdown file. So if we go into the docs directory, there's all kinds of documentation. Those two that are most commonly used, I would say it would be targets, which describes each of the boards that's supported and how to use them. And then the other one is the signing tool documentation. And towards the bottom here, there's a section specifically for how to sign with an external HSM. So it's something else that it has a private key where WolfBoot doesn't directly have access to it. It's basically just signing the hash of those things and then putting that signature into the signed firmware image. So I wanted to go into how to program, test and debug it here. I would recommend using the SDM32 cube programmer tool. They have a command line version of that tool. And you can just specify the binary file in the destination address. So what that looks like here and don't have the copy paste handy. This is what the targets.md looks like. And I'm gonna go to the G zero section and it covers all of these steps about how to program it. And some of the other things we're gonna talk about in debugging. So this is the command that does the programming. And you can't see it, but the LED four lit up basically indicating that the boot was successful. And I'm gonna move on here. It says LED three, but yeah, it's LED four actually. Another thing is testing. So the normal update flow basically looks like you make changes to your application, you build your application, and then you would sign it against that key and you would specify a version number in the signing tool and that all gets embedded into the header which goes on the front of your application. Now a couple of things to note is Wolf boot also supports things like encryption of the update and Delta update. So you can actually provide it the old and the new version. It'll create a differential file and it'll sign the version going both ways that allows you to do rollbacks still even with the differential updates. I'm not gonna demonstrate this, but you would sign that new version and you would program it down and it would update and you'll be able to test that yourself. So with debugging, we have a make debug equals one which basically includes the debug symbols. You'd go ahead and program that factory dot in down again and then you would start up a GDB server. You have a couple options. So ST has their official ST link GDB server inside the QBiDE and by default that GDB uses port three through three. So that's all you're specifying there. There's also some open source ST link tools where there's a GDB server. For me on my Macintosh here, it's actually a little easier to use the ST new tools that are open source. This is what the command ends up looking like for me to start a GDB server. Let me make that a little bigger. So I can fire up GDB and it's basically listed on that port. The next thing I can do is I make clean and make debug equals one and you'll see the size of this image is a little, the boot loader is a little larger, it's 23 K. And then the next thing I'll do is go ahead and program that. I did this in the wrong order. We'll do this one more time. We'll program that, start up the GDB server. And then the next thing we do is basically load up GDB. I'm using one of the ones I already have on my system here. And another thing you can do is add the symbol file from the elf of the application that was built, which is handy. And then I could do something like mon reset init and continue. Yeah, yeah, that's right. So you can see it's running here. So right now it's actually going through the ed 25519 verification process and eventually it'll finish. So I'll wait till the LED, yeah, the LED's on and there it is. I'm at the application, you know, LED on wait loop. So that's an example of how you do the debugging on it. You shouldn't have to do it very much, but sometimes during initial setup and partitioning that can be handy. So now I wanna describe for you a little bit more what's going under the hood when you do a boot and I wanna tear down a little bit on what that image header looks like. So in that space, there's basically a magic sequence that's, you know, ASCII wolf boot or something like that. And then there's the size of the actual firmware file. And then you get a tag and tag length and data. And that just repeats in that pattern. It'll include things like the version timestamp, the hash of the partition and the signature of it that's expected. And the signature, you verify it using that public key that gets embedded into the boot loader. So this kind of describes the mechanism here, which is basically, you know, over the year updates come down. We put them in the update partition and then the boot loader itself will handle the verification and the swapping. So normally, you know, at the factory, we program our initial factory dot bin, just like this, we'll sign it, deploy it and then we'll lock down the JTAG, right? And the regular process of booting after that will verify the signature of that current firmware. So the next thing would be an over the year update. So, you know, when you're in your application code, you would download new firmware, you would program it into the update partition. Now that update partition could actually be external spy flash as well. We support using that on all these targets. The next thing is that wolf boot is notified about the update and it checks, and this is actually on reboot. It actually checks the new image, make sure the version's valid, it does the whole signing, you know, it verifies the signature on that update and then it'll do the swap. So, and then it'll swap the two partitions. The cool thing about that is that the integrity of both of those partitions are fully remained intact and you can roll back if there's a failure with the update. So once the next boot happens, the application will actually call an API that says wolf boot success and it'll flag that that update was done completely and is okay. Otherwise, if that flag isn't set on reboot, it'll do rollback, you know, and this is one of those great features. Yep, so it would roll back and retain the old version. So, yeah, and it could boot normally again. Okay, so I went through those slides pretty well, but you know, the whole idea is that you have the ability to never break the device. So you have at least the last known working configuration is always available. So some of the SCM32 security features, we support some of them and specifically the secure user memory feature, which is really neat because you can basically program what you would define as the bootloader region and as soon as the bootloader jumps out of that region, the application no longer can read the memory from the bootloader space until the next reboot, which is pretty cool. And this can be programmed using the CUBE programmer and it's programming the SEC underscore size option bits. And it's basically programming it with a value of 10, which is saying offset the start address by 16 2K sectors, which is 32K that we defined in the configuration. And like I said, WolfBoot will actually say that it's done and it'll fire off the application and then that address space where the bootloader resides will no longer be accessible. So these are some additional features that the SCM32G0 has that we're compatible with, but we haven't built in support for. And after you, if you develop a product and then you want to put it in the field, these are some things you want to do, right? So write protection, readout protection and bootlock, all these things, right? So you want to make sure you disabled internal boot ROM, the JTAG, the ability to debug in the RDP level two, what that means is that you disable debug and the ability to program the option by specifically the one with a secure user memory that cannot be cleared. And that is a irreversible operation. So once that gets programmed to that level two, then that device is all locked down and no more configurations can be changed. So I hope you enjoyed this. This is part three of the video series that we're doing with ST. There will be another video coming soon. I believe it will be for the SDM32 U5. So stay tuned. Thank you very much.