 Hello, my name is David Garski and I'm a software engineer at Wolf SSL. Today we're going to be talking about WolfBoot with the STM32. This is a multi-part video series starting with an overview of Wolf SSL and the WolfBoot library. Wolf SSL was founded in 2004 with the need at MySQL for a SSL library that matched the licensing, which is GPL. As a result of that, our co-founders Todd and Larry decided to write this. It was called Yazzle and C++ and in 2006 they wrote an embedded C version of it called CYazzle. In 2014, we changed the name to Wolf SSL and that's what you see today. We have over a thousand OEM customers and 17 resale partners and at any one point in time we're securing over 2 billion connections because of the products that we're in. ST is a really great partner of ours and I'm really proud today to present this video series about WolfBoot in conjunction with them. These are our Wolf SSL products. The Wolf SSL library itself is a TLS library that provides client and server functionality for all the latest standards. It's built upon our Wolf Crip library, which is a FIPS 140-2, 140-3 certified crypto engine. It's also certified for aeronautics use with a DO178C certifications. We have a Wolf MQTT client library for cloud broker connections. We have an SSH client and server also supports SCP and SFTP. Our Wolf TPM library is based on the TCG's 2.0 specification and allows use of crypto chips like the ST33 TPM. And today we'll talk about WolfBoot, our secure bootloader. It can also support major boot when used in conjunction with Wolf TPM. We also have wrappers for Java, C-sharp, Python, and we have some other tools like command line utilities. Something that's not mentioned here is we also have a TLS-13 sniffer which supports a key manager. And there's also an intrusion detection prevention system called Wolf Century that's being released. So WolfBoot is a generic secure boot solution. It runs on virtually any microcontroller. It is designed to run in bare metal and it's very easy to port additional platforms with our hardware traction APIs. There's no dynamic memory used so it's all static or stack based and we've also designed it to be the code to be safe so that it can be used for aerospace, medical, and automotive. The WolfBoot library is based on the IETF suite draft which is a firmware update architecture for internet things and it defines things like that the actual swapping of partition should happen in the bootloader and there should be mechanisms to roll back on failures things like that which you fully support. We also have examples available in our WolfBoot examples repository and we have key generation and signing tools that have been written in Python and C. So the firmware partition image can be hashed and signed using these algorithms. These are very common asymmetric key algorithms where you have a public-private key. Public key is a root of trust that's embedded into the bootloader and the private key is what's used to sign the image. We also support encryption of the partitions using Cha Cha Poly. Additionally you can offload the verification of these images to secure elements like the STSafe A110 or the ST33 TPM. You can also use those to pin the root of trust, that public key that's trusted for the signed firmware. WolfCrypt is what's used for the verification underneath and we support assembly optimizations that are incredibly fast for these platforms. So our partition scheme is very flexible and it's determined at build time. The bootloader usually takes 10 to 30 kilobytes. There's one flash sector that's reserved for swap and then the remainder is split between application and update partitions. The firmware update mechanism, it will prevent a fallback to a previous version. So if let's say somebody tried to install an older version, it will prevent that. If the update fails, so if you send down an update and it fails to boot the application successfully, on the next reboot it will actually roll back. Additionally, it's PowerFailSafe, so during the swapping of the partitions, if there's a power failure on resumption of power, the process will pick up exactly where it left off. There will be no lost data. Some platforms support hardware assisted bank swapping and if that's available we leverage it. We support external spy flash memory for the update partition and the swap sector and it's important to note that the update mechanism where the transport mechanism that the OTA image comes down is actually in your application, it's not in the bootloader. So this is a list of supported STM32 microcontrollers with Wolf boot that have currently been ported and are supported. It's the STM32 G0, L0, L5, WB, F4, F7 and H7. There are more being added all the time and we're happy to help support or port these for you. Here's a comparison of Wolf boot with STSBSFU and ARMS trusted firmware TfM. Wolf boot is highly optimized with the memory footprint and processing time. It's also based on proprietary and efficient HAL interfaces and it uses our WolfCrypt optimized cryptographic engine which is validated. This supports all the STPKA which is the ECC hardware acceleration. The SBSFU and TfM, they offer a full coverage of the STM32 families, demonstrate how to combine STM32 features and reach a high level of security. It has TfM secure services framework for trust zone and the system level certification on slick micros. Next I'm going to show you a comparison slide of the three. The code base for Wolf boot is proprietary but it's open source GPLv2. I believe you can get the source code for the other ones as well. Wolf boot, you have the ability to do two partitions or it's required for the update procedure. The other ones you can do one or two. With Wolf boot you can sign with ed25519 or ECC or RSA and you also support encryption of the partition using Cha Cha Poly and soon we'll add AESGCM as well. Let's see, obviously ours uses WolfCrypt underneath which is a certified very robust WolfCrypt library. There's secure elements support for things like the STSafe or the ST33 and it's also possible to support external flash. Our Wolf boot is fully make file based while the others have some examples for EWRM, Kyle and STM32Q by DE. So we're going to dive a little bit into the Wolf boot implementation details. So these are the software components. Your application sits here, it can be on an RTOS or not. There are two APIs that the library can, that your application can call into Wolf boot from your application side. So you can call an API that says perform an update on the next reboot. You can also call an API that says I successfully booted my application, do not roll back on the next reboot. So those are important. And the state of those is maintained in the flash which I'll show you later. So there's only a couple of public APIs in the sense from the application the rest is all internal in the Wolf boot library. There's a route of trust, which is the public key that is specific to you that can be pinned into the firmware for the bootloader. And that's what's used for the verification of the partitions. We do support multiple keys and we support offloading its other hardware if the platform supports it. And then our FIPS certified WolfCrypt engine is over here. Important to note that WolfCrypt itself supports all the secure elements like the ST safe and it's what's responsible for handling that. So these are the how APIs for a new platform. The most important are the flash erase and write functions. The init usually what we do is we'll speed up the clock to the fastest so you can have the quickest boot time. If you're using external spy flash, you'll need a spy driver ported as well. This example for partitioning of an STM32F4, this one's a little unusual and they're all a little different depending on the sector size. This one happens to have large sectors of 128KB. You can see in this example how we partitioned it. Wolf boot sits in the first few small sectors, usually with less than 32K. And then there's a primary partition and update partition and a swapping partition. This shows you where, you know, an upgrade from a version 1 to a version 2 and how it swaps. This state of the update process is stored in the last, the end of the last sector of the update partition because usually there's free space there, hopefully. And this swap sector is what makes sure that we can do it in a power fail safe way. And with our support for external spy flash memory, there's a couple more how APIs as I mentioned and the firmware update partition and the swap space can be offloaded to the external spy flash, giving you more onboard flash space available for your application. This slide covers a few useful resources. One is a GitHub link to our Wolf boot repository and other is the examples repository. This is a link to the IETF Suite draft standard. There are also a couple of useful YouTube videos that have been posted. And I'll go over this in the next video where the documentation is, but it's in the Wolf boot docs directory in markdown format. So if you have any questions about Wolf boot or are interested in adding any additional platforms, you can email us at faxatwolfhussesale.com. And thank you for your time and I look forward to presenting the next video for you.