 Hello, everyone, and welcome to the STM32-L5 Hands-On Virtual TruzZone Activation Webinar. Wow, that's a mouthful. My name is Bob Waskiewicz, and I'm a staff field applications engineer with ST Microelectronics. I've been doing STM32 embedded design support for the past 15 years. Recently I've had the opportunity to champion the release of the STM32-L5 within the United States and gotten very familiar with the TruzZone. Who would have thunk it? A virtual hands-on webinar in these crazy times which we are all experiencing. I guess this is par for the course. This original webinar was released in May of 2020 as a continuous two-hour webinar. It is being re-released as a nine-part series of videos for the ease of following the material. The nine-part series consists of four lectures and five hands-on, which demonstrate the ease of using and activating the TruzZone in an STM32-L5 device. The nine videos vary in length from 10 minutes to a maximum of approximately 15 minutes. The structure of the series is such that each of the lectures is followed by a hands-on, which further emphasizes the principles described in the previous lecture. In part one, we introduced the STM32 current family isolation features, which do not contain the TruzZone. There are some pretty good physical features, but we then introduced the STM32-L5 and the ARM Cortex M33, which houses the TruzZone. Part two is then a hands-on introducing the user to the STM32-L5 nuclear board. We use a blinky example and the colored LEDs on the device to introduce the user to some programming tools and some different features of the nuclear board with the TruzZone disabled. Part three is then a little deeper dive into the ARM Cortex M33 core, which is housing the TruzZone and the specific features within the M33 that allow you to have a TruzZone. Hands-on number two, which is part four, then actually activates the STM32-L5 TruzZone with a singly secure application. Part five will then introduce the TruzZone as from a practical user application of where you have a secure zone and you also have a non-secure zone. The part six video will install the non-secure blinky application into the previously installed secure blinky application. So once the secure has started, it'll jump to the non-secure. You'll notice the difference in the flash rate of the LEDs, so you know you have two separate type applications running. Part seven will then show the user how to configure the secure and the non-secure project for debugging to be able to go back and forth under a single IDE workspace. In the case of the TruzZone, it's not a dual core type of debugging environment. It's a single core with protections going back and forth, and we'll show you how to configure that. Part eight then gets into additional flash features, which supplement the TruzZone to make the device safer, more secure. We'll also get into faults, how they're handled, and then we'll get into the TruzZone deactivation. How do you revert back in case you want to change the debugging that you're doing? And then hands-on number four, which will be part number nine, will actually go through the deactivation and the two methods to revert the TruzZone-enabled bit. What do you need to perform the next four hands-ons? Well, you need the nuclear board, which you should have received, along with the type B cable and the type C cable. So also I just found out that all 100 boards that we had sent to Digikey have been given out, so that's good news. The CUBE Programmer runs under Windows 10, so you should have that CUBE Programmer version 2.3 already installed. In the download file there was some subfolders. There was a doc folder, has the user manual for the CUBE Programmer and the nuclear board. There was also a subfolder for the hex files, and we'll use those hex files one, two, three over the next two hours for the hands-on. And then, of course, this PPT presentation. We'll make a suggestion if you haven't done so yet. If you don't have dual monitors where you can look at what's going on and what you need to do, you just split your monitors somehow screen-wise and have the session up on one and maybe doing the hands-on side-by-side or something like that. As I tried to develop this, it's hard to do on one monitor, or it's impossible to do on one monitor. I want to start by discussing some STM32 isolation mechanisms. I don't mean social distancing that we're all currently experiencing. As we go through the slide deck, you'll see a color code sequence. Green representing secure, pink representing non-secure functions. Why build a device with a trust zone in it? The underlying assumption? There's something in the device that needs to be protected. Those protections didn't just start today. From day one, since code has been put into micros, there's been certain things that need to be protected. In the past, ST has built STM32s with other physical features, and I'll discuss those in the next few slides. If this were a security seminar, I'd be discussing the three prevalent types of attacks in today's world on MCUs or MPUs. Those three types being a physical attack on a chip, a board layer attack to an assembly, or a remote hack through a port into the device. Believe it or not, 95% of the hacks today are through remote ports into devices. The STM32L5 with the trust zone cannot protect against physical attacks. That's not the intent. Those are secure micro devices. ST is a leader in those. We have our ST safe products. We have our TPM products. We have our secure micro products that are in credit cards throughout the world. The STM32L5 was built to protect against remote hacks. By enabling the trust zone. So when the device boots, it's going to authenticate itself, check things out, make sure you are who you are. It will then call or not call a user project. The project could all be secure, or just the portion of it that authenticate itself is secure. That's what the STM32L5 was designed for. ST Microelectronics released its first STM32 device back in 2006. It was the STM32F1 family. That family was based upon the Cortex M3 core, which had the option for an MPU. ST has included the MPU in all of its Cortex devices that has an MPU. There is one family, the F0 family, which is built upon the Cortex M0, which does not contain an MPU. Memory Protection Unit is a physical protection feature. It allows you to define access rights based on a memory map. And SRAM, flash, and peripherals all can have different access rights. A couple constraints. One, the MPU needs to be configured in Privilege mode only, and the handlers are always in Privilege mode. So that means that everything is assumed to be trusted if you're going to use interrupts. Second drawback is that the STM32 family's, a lot of micros today are built on DMA. The DMA masters out on the AHB bus are not constrained by the MPU. So one common attack internal would be to configure a DMA to read from flash or SRAM and dump it maybe out to a physical port, to a UART or so. So there's limitations as far as what the MPU can do. However, it's better than not having an MPU at all. In 2010, don't quote me, maybe it was 2011, ST Release, the STM32L0, which was based on the Cortex M0 plus core. And then a couple years later, 2015, I think, the STM32L4 based on the Cortex M4 core was released. The Cortex cores themselves did not have a firewall. ST developed a piece of IP called the firewall, which is a physical hardware snooping of the transactions out on the AHB bus between SRAM and flash. So you allocate a section of flash, you do a start and stop address, you allocate a section of SRAM, start and stop, and you put your proprietary code, your keys behind there. And if there's any intrusion into that firewall, a reset is generated automatically. The improvement of the firewall actually protected against that DMA hack because, yes, it was based on the AHB memory map. And if the DMA was trying to access, quote, that physical region of flash or SRAM, it would generate a reset. The drawback of the firewall, my opinion, and others concur, you can't, processing of interrupts when you're behind the firewall has to stop, so you have to disable interrupts. The way around that is to do batch processing and you get all your interrupt data and then you go back behind it and you do your calculations. So the firewall can then also coexist with the memory protection unit because things outside the firewall are then protected by the MPU. So securing peripherals is not possible by the firewall because it's only protecting a region, but the MPU can secure peripherals. Around 2018, ST released the STM32G0 family and the G4. He's had a new physical security feature called Hide Memory. The Hide Memory was also added to the STM32H7 release in 2019. The Hide Memory allows you to allocate a section of flash, runs only at reset, authenticates the device, then jumps to the user application. So it's called once, never again entered until a reset occurs. These devices also had the MPU on them, so you could still do some physical memory map protections as well, but they don't have the firewall. So in January of 2020, we officially released the STM32L5, was the first ST device with the Cortex M33 core in it. The L5 contains an MPU, the trust zone is a much better firewall, and it also has Hide Memory in it as well. And over the next hour, 50 minutes, we're going to discuss the trust zone. What makes up an STM32L5? For those who have not seen or used an STM32 device previously, this is what one looks like. The dark blue is what we get from ARM, basically the Cortex M33 with the trust zone, with the floating point unit, with the memory protection unit, with the external trace module. These are all optional IPs. We add them to the L5. And then the light blue stuff is what ST does. So we add our own DMA controllers, the flash, the SRAM, the connectivity, encryption, analog, IOS, time, redigital, parallel interfaces, that's all the STIP that we add to this, so that's unique to us. The light blue to the L5 is the instruction cache, which allows this thing to run pretty good at 110 MHz. We also added the OctoSpy interface, which can do on-the-fly decryption, zero weight states, reading from external NOR SPI flash. It's got a public key accelerator that's very quick as well. The new feature for security on this device as well is that dynamic tamper. Previously, all of our devices had static tamper, ground or VDD for a switch closer. This is now PWM out and a capture back in. So you can run a frequency much harder to jumper around. Cortex M33 from ARM. The M33 has always been a large user of ARM cores predating the Cortex M. Starting in 2006, we released our first Cortex M3 core, which was the F1 family. Since then, we've used the M0, the M0 plus core, the M3 as well as the M4 core, the M7 core. In January of 2020, we released the STM32L5, which was our first Cortex M33 core. In the ARM Cortex Trust Zone series, there's the M23 core and the M33 core. ST is only using the M33 core. So in the L5, that's what you have. It's a higher performing core, more interrupts. We've got the DSP option as the floating point option, which we do include more break points. So this is in the L5, and you'll see that in additional devices being released in the future. Thank you for taking the time to view part one of the nine videos. I encourage you to continue with part two, which will introduce the STM32L5 nuclear board. Use later for the non-secure and the secure applications. Also, take note of this YouTube comments. The site, the link to where the hex files can be obtained for hands-ons number one, two, and three will be listed.