 In this part, I would like to introduce you the STM32WL hardware and software security mechanism available. STM32WL single core or dual core have some common security mechanism that you can also find on other STM32 family. We've got the boot lock mechanism, readout protection, damper detection, proprietary code readout protection, also named PCROP, write protection and the memory protection unit. Those mechanisms can address different types of attacks. For example, readout protection and damper detection will address some outer attack, while PCROP and write protection will address outer and inner attack. The MPU is an isolation mechanism and will address inner attack. All those mechanisms combined together allow you to achieve a certain level of security. On the STM32WL single core, ST delivers a code example of secure boot and secure firmware update, which rely on some of those mechanisms. It allows to ensure firmware authenticity and integrity. It allows also to update the firmware in a secure way, thanks to local loader which rely on wild modem protocol. Two main security features are using, ADP press write protect, but those ones are not activated by default. This is the first level of security which allows you to protect against any attack via GTAG. But beware, as we don't have any isolation in our example, it means the surface of attack includes all the internal flash, application and restack. This example is delivered in the CUBE firmware and the name is BFU underscore 1 underscore image. Underscore 1 image is because it's a single slot and there is a local loader on KMS included in this example. On this slide, I want to give you some details about the memory organization and the different security mechanisms that are active on this example. As you can see on the user flash, we've got the secure engine keys, which are the static key. The Q-engine code, BFU and KMS code are protected by the write protection. Then we've got the region of KMS data storage where you can, you will store your updateable keys. The download blob slot which allows to download a new blob and provision new keys. Then you've got the active image editor, where is located the metadata of the installed firmware. And then your firmware, which is a Laura 1 application. The different security mechanism activable or activated in this example are the independent watchdog, the temperature detection, the write protection combined with the ADP level 2, which ensure the immutability of your code and also the boot lock mechanism. STM32W held while core brings some additional mechanism, isolation of the core M0 plus for memory and peripheral, the privilege protection for memory and peripheral, the secure memory also called HDP, the debug core M0 plus access and the boot lock mechanism on the core M0 plus also. I will detail all those mechanisms in the next slide. New core TXM0 security feature bring a strong isolation. Portion of flash and RAM could be assigned to the core TXM0. We can also assign QBGIRS, IOS, PK and RNG to the core TXM0 and also some DMA channel. Some resource protection could be based on privilege. And we'll see also that we can restrict debug to certain portion of memory. We have a boot lock mechanism now for the core TXM0 and also for the core TXM4. Core TXM0 plus security flash isolation. To define this portion of flash that could be exclusively accessed by the core TXM0 plus, we need to define two options by it. The first one is to enable the security. FSD, flash security disable. If you set it to zero, then you will enable the security. Then you just have to define the secure flash start address. And from this address until the end of the flash, everything will be assigned to the core TXM0 plus. Another feature for security flash isolation is HDP, hide memory protection. It allows to make disappear memory from the system after its execution. You just need to activate it thanks to one option by it, hide protection disable, that you should set to zero. Then you define the hide protection start address. And from this address until the end of the flash, it will be the secure hide protected region. As for the flash isolation, we have RAM isolation. We can define portion of SRAM that could be only accessed by the core TXM0. To configure this feature, first you need to have the security enable. To do this, you need to have the option by it FSD set to zero. Then you have to activate the RAM security. For this, you've got one option by it for the SRAM 1, NBRSD, and one for the SRAM 2, BRSD. NBRSD stands for non-backup SRAM security disable and BRSD backup SRAM security disable. As you can see, the logic is negative. That means you need to set to zero to activate this feature. The last point is to define the SRAM start address to define the location of the SRAM 1 or SRAM 2 that would be protected. Zubjigar's radio system could be also exclusively accessible by the secure Cortex-M0. This is configured again thanks to an option by it. Some peripherals could be assigned to the secure CM0 or the non-secure CM4. This is done on the security controller part of the global security controller. So, secure IPR, iOS, PK, and through RNG. The location is done dynamically. That means based on your need, you can assign them to the secure CM0 or the non-secure CM4. You can do the similar things with the GMA channel, but this time, it's not saying the security controller, but directly in the IP of the GMA. Here, it's also done at runtime. Privilege protection is an additional isolation mechanism that you can configure inside the global security controller. It applies on memories, flash, SRAM, on its configured songs, watermark for them, and also on the Zubjigar's radio, iOS, PK, through RNG, and DMH channel. Any legal access to the secure and or privileged resources can be signaled to the Cortex-M0. This is done thanks to the secure illegal access controller part of the global security controller. Then, it's up to the Cortex-M0 firmware to take the action. Any illegal access will wake up the Cortex-M0 from any operating state. Another security feature is the capability to disable the debug power access of the Cortex-M0+. By default, the value is set thanks to the option by EDS. Then, it can be dynamically changed by the software embedded. One of the key requirements for security is to ensure you're always booting on an immutable code. To ensure the code location that is executed after boot, we've got some additional option bytes that have been defined. We've got a boot lock for the CPU-1 and the C2 boot lock on the CPU-2. This will guarantee our chain of trust. As on the single core, ST delivers code examples of secure boot and secure firmware updates which rely on those new security mechanisms and in such a way increase the security level of your system. The additional mechanisms are HTTP, MPU, and Cortex-M0+. There is two examples, one with a SBSFU plus a KMS and a local loader. On another one with a FUTA, firmware update over the air with a lower one stack. The diagram shows the memory organization on the associated protection of a full SBSFU. On the CM0+. in privileged mode, the most sensitive code and data. If you have a look in the top address of the flash, which is a bottom on this diagram, you'll find first the header or the metadata of each firmware that's running on each core. Then you've got the static cryptographic keys. Then you've got the secure engine, which will operate all the cryptographic operations. In addition to the secure privilege protection, HTTP is used to protect the key and the headers. In un-privileged mode, we have SBSFU on KMS interface code, the KMS data storage, and the lower one middleware on radio. This last firmware could be updated. Isolation between the KMS storage and the lower one middleware on radio is at RedSync's MPU. All the S-RAM2 is dedicated to the CM0+, with a similar split between privileged and un-privileged. On the CM4, a secure boot is also needed to ensure about the secure boot process on this core. This one will be right protected and bootlock mechanism will be activated. The lower one application on the downloading slot will be located in this non-secure un-privileged area. This slide is somehow complex because you've got a lot of information. The purpose is really to show you the different isolations that have been activated in this example, but you can find much more detail in the SBSFU documentation. This slide sum up the different protection on the hardware and software availability in the context of secure boot and secure firmware update. I will not comment in detail this array. The main message is that on the single core, secure boot and secure firmware update mainly rely on RDP and write protection. This allows you to address only outer attack via debugging link. Activating the MPU isolation will be possible, but due to the complexity, it has not been considered as a mass market solution. PCrop mechanism has not been used to ease the KMS integration. This is the first level of security, but if you need also to address inner attack, the STM32WL dual core is a ready to use solution from the hardware and software point of view. As conclusion to this comparison, I want to insist in the fact that on the single core, any successful inner attack can lead to the loss of the confidentiality of all assets inside your device. This could be mitigated using MPU mechanism, but this would increase the implementation complexity. On this slide, you can find links to the user manual on the integration guide of SBSFU in the STM32WL. Thanks for your attention.