 Welcome to this brief demonstration of how to implement TrustZone security on ST's L5 family of secure, low-power microcontrollers using IAR and SecureThings turnkey security solutions. My name is Aaron Bouch and I'm a field applications engineer for IAR covering the eastern United States and Canada. With the introduction of TrustZone technology for ARM Cortex-M microcontrollers, we have the hardware protections needed to truly secure intellectual property and information on IoT and in fact all embedded microcontroller systems. The Cortex-M23 and M33 cores implement this protection and the ST Microelectronics ST-M32 L5 family uses the Cortex-M33 core to leverage this technology in a family of high performance, low-power devices. Of course, with this kind of security power, some complexity is introduced in managing the two worlds of secure and non-secure code and resources. IAR's security products provide the software side of the hardware security pair needed to ensure secure operations. In addition, embedded trust and C-Trust make implementing the security framework and developing a truly secure environment painless and turnkey. As you'll see shortly in the demo, IAR provides wizard created secure boot manager code and a security context containing all the needed secret keys and policy information to secure your IP and product. All the code is provided with full source so that any additional modifications that might be required by specific applications can be added as needed. In addition, the secure boot manager implementation out of the box provides completely protected secure update capabilities in the field, production volume control as well as a secure API so that the application can request services from the secure trust zone code for functions that need to use the secure keys and secret data stored and protected on the part. ARM's trust zone architecture adds a new level of protection over the existing modes in which the Cortex-M core can already operate. Once trust zone is enabled, it provides a mechanism for running in either secure or non-secure modes. When the processor is running in secure mode, it has access to all resources on the part, including the ability to set up the model for what memory spaces and IO resources will be available to any code running in non-secure mode. Once this is set up, it can jump to the non-secure application where all resources that the secure boot manager has not provided access are completely invisible. In this way, any secret information such as encryption keys and the SPM code itself cannot be accessed even by code running on the chip to give away the secret immutable boot path information. Once in non-secure mode, however, there are times when an application may need to validate incoming encrypted data or respond to security challenges by a third party, or it may need to access a number of other functions that would require the use of the secret information stored on the device and managed by the secure boot manager. To facilitate this, the ARM trust zone architecture implements the concept of non-secure callable code gateways. This is a mechanism by which a non-secure application can make a call to a secure function which it cannot see and only has knowledge of how to call and make use of it through an API. The secure function can then run process data using secret keys and return the results without violating the security of any secret information. This is all managed in a turnkey fashion by the IAR secure things secure boot manager API, which is simply linked to the user's application. On the left, you can see an example of an entire flash memory space of a microcontroller that would use the solution that we're describing. The bottom section of memory is an area that would be protected as secure mode access only. It's expanded on the right to show that this area would contain the secure boot manager code, the startup code and secure interrupt vector table, providing the only way to start the chip which gives the SBM control of the boot process. Above the SBM code is secure memory allocated to storing keys and secret data that only the SBM can access. Above this section in the memory map on the left, there are two blocks of memory used in the secure boot process. The first block is the execution slot where the user application will actually run once installed. The second higher block of memory is a load slot where a new encrypted application package can be loaded. In operation, when the SBM starts up at reset, it checks the upper load slot for a new installation package. If it finds one that is correctly encrypted and signed and meets the versioning policies of the device and is determined to be correct and uncorrupted, the SBM will decrypt it and load the executable code into the execution slot to run. Because the package of data in the load slot is always encrypted, this slot can exist in either on chip or in unprotected memory such as an external QSPY flash chip. This provides a completely secure mechanism for code updates in the field where a new image can only be created by the trusted OEM owner of the devices that were originally provisioned. This is true because only the OEM can create new correctly mastered and signed images that will be checked by secret information residing on the chip and only accessible to the secure boot manager. For the normal case where there is no new application to load, the SBM will perform integrity checks on the application execution block to ensure that it has not been modified since it was first installed. The SBM will then jump to the start of the application, which is unaware of the startup code that is run and getting to its main function entry point. Now I'll do a brief demo of how all of this works in a real system. I'm using a Nucleo STM32L552 board where the secure boot manager will be provisioned and run in secure mode. Then you'll see the developer's view. They can develop their application running in non-secure mode. However, the chip that is being used for development has been provisioned with an SBM running in trust zone secure mode. This means that every time the application is downloaded to be debugged, it is mastered or encrypted, loaded into the load slot, and the SBM runs to check it, decrypt it, and load it into the execution slot as if it were a firmware update in the field. In this way, the debug environment mimics the actual target execution environment, avoiding surprises when the code is completed and released for manufacture. Okay, so first we're going to take a look at creating a secure boot manager from scratch. This is an empty workspace and I'm simply going to go to the project pull down, select create a new project, and you can see that there is a secure boot manager option here for a type of project that I can create, as well as the already existing project. So I'll select a folder to place it in and give it a name, SBM new, and say save. And by doing that, the wizard will create me a new secure boot manager project. Now notice that we've got the IPCF file here, but the project itself has not been expanded out into actual source code. When I open the options here, notice that it doesn't know what chip I'm planning on using because I just created this SBM project from whole cloth. So what I'll do is I'll select a device, the STL5 family, the L552 ZE, and now that a device is selected, I can go to the security page, and it will allow me to enable security, and I'm going to create a new security context with identity and production control and IP protection so that I can protect my environment. When I do that, it brings up this page for me to fill in some information, which I'll magically fill in very quickly, and then move on to the next step. So here it gives me some other settings that I need to set, but you can see the wizard is giving me choices and defaults on things that will become part of the security context. We will set the security policies for this environment. So I'm just going to select all of the default options and select create to make myself a new security context. It's going to ask me, do I want to use the security context for the project that I'm working on, and I'll say yes. So it's now creating the context. There it is, my contracts profile default. I can then edit this context and change some of the parameters in it if I choose to. Here's the memory map of how it lays out in the part. Here is some logging options that I can switch to true if I want to get some status of what's going on as the device is booting up. And then finally, I have some options on whether I want to encrypt this information or just use signing for the information I'm creating. So here I'll simply say OK and OK. And when I do that, it's now going to take this IPCF file with the security context information I just entered and create me a whole project for a secure boot manager that I can then use in my system. I'm now going to switch to a project that has a secure boot manager and an application that we're already created so that we can move forward. Now you can see in this workspace I have a secure boot manager project and an application project that I'm going to download shortly. The first thing that needs to be done is the part needs to be provisioned with the secure boot manager. Now if we take a look at the options of the secure boot manager, what you'll see is that the secure boot manager itself has trust zone enabled and the trust zone is enabled and the mode that it's in is secure mode. So when this provisions onto the part, it will put the secure boot manager into the load area of the boot manager. It will be the startup code for the chip and it will be in secure boot mode when it operates. In order to provision the part, we simply select the security menu and click provision and that will download the secure boot manager to the part and provision the device. Once that's done, we can switch to the application section and the application will then be loadable on the part using the secure boot manager to boot it. Now the application options, unlike the secure boot manager, are set to use trust zone but the application will run in non secure mode. So the secure boot manager has set up the environment so that the application resources that are needed, its memory areas as well as any IO and interrupt resources are configured in the secure boot manager. So notice that trust zone here is enabled but we're in non secure mode. So now when we download to debug, the chip has been provisioned, it has the secure boot manager running where its loading is actually into the load slot, not into the executable area of the device. And once we load into the load slot, then when the device is reset, it will run the secure boot manager and load the executable. Now as the application has been loaded into the target, we can see that the secure boot manager is running here and it says it's installing the new version 00005. And once it's installed, it actually starts running the executable. I'm going to pause this just to take a look at it. Now what we can see is that we've gotten some status information logged out by the secure boot manager running before the actual application ran. And now once the application runs, I can see on the timeline, I can trace all kinds of interesting information like interrupt activity, task switching, a variable that's changing in real time. And if I zoom in on some of this task switching activity, I might see some more interesting things where I've got several tasks running here. Friartas measuring some timing of some code and my interrupts start spreading out with my A to D conversion happening every five milliseconds. So the details here are not important. What is important is that I have all the functionality of the standard debugger when running in this mode. So to summarize, the addition of TrustZone to the ARM Cortex-M microcontroller family provides the hardware locking mechanisms needed to ensure truly secure devices. ST utilizes this advance in their STM32L5 family as a foundation for full security. IAR and SecureThings Embedded Trust and CTrust security products provide a simple turnkey solution that takes advantage of this technology from ARM and ST, implements the security required by your products in a way that is simple to manage and is comfortable to use as our standard IDE. Naturally, due to the short nature of this overview, it only scratches the surface on a much larger topic. If you have additional questions or would like to see a live demonstration of IARs and SecureThings security products, please contact your IAR account manager or send an email to the IARFAE team at fae.iar.com. Thank you for your time and attention.