 Now we have standalone bootloader that is able to launch a target application. The next thing we need to do is to make this bootloader trustworthy. There are two conditions for secure boot code to work properly. The first condition is to ensure the unique boot entry. That means the MCU boot mechanism has to make sure that the secure boot code is always executed after reset. The second condition is the immutability condition, which means the secure boot code and the public key that it will use for the authentication of the application cannot change in any way. If those two conditions are fulfilled, then you can trust the secure boot code you have. Then next we will see how to secure the boot entry on STM32. The secure bootloader relies on the first code to be executed after boot. On STM32, this is mandatory to set up the option byte so that boot from Flash is selected. On some STM32 families, this requires RDP level 2 to be activated. On more recent STM32 series, some other security mechanisms can also ensure the booting from internal user Flash with only RDP level 1. Here is the general principle of STM32 boot. All STM32 are able to boot from at least three different regions. User Flash, system bootloader and internalized RAM. And the selection can be done with option byte and possibly with boot 0 pin as well. As STM32F series, RDP level 2 can ensure that the MCU always boot from internal user Flash. The only exception is F1 because on F1 only RDP level 1 is supported so a secure boot cannot be guaranteed on F1. F7 introduces also the boot address 0 and 1. Those option bytes can also be set both to the same user Flash address. And this will improve the boot entry robustness using RDP 2. This is the general boot principle of STM32F series. So in case RDP level 2 is not set, then the boot 0 pin level will first decide whether the system will boot from internal Flash or not. In case it is low level, then the system will boot from user Flash. Otherwise the boot 1 pin level will further determine whether the system will boot from internal RAM or the system will loader. But in case RDP level 2 is set, then the booting from user Flash will be forced. On F7 series, there are two more option bytes introduced. Then the boot pin will decide whether to use the address coming from boot address 0 or boot from 1 option byte. Both address could be programmed to point to the internal RAM or system boot loader or internal Flash. But when RDP level 2 is set, it's not possible to boot from RAM anymore. So those address could only be programmed to boot from user Flash or the boot loader. But in such case, only very limited features will be provided from the system boot loader. So in such case, we should enforce both address to point to the user Flash address. But the low power series L1 is the same as F family. On L0 and L4, there is additional software configuration option introduced in the option byte. So on L0, it is input select option byte and on L4, there is the in software boot option byte. And associated with this selection, there is an additional input 0 option byte instead of boot 0 pin. For L5, we will detail it further later on. So here is the boot principle of L0 and L4 series. When RDP is not set to level 2, then depending on the configuration of the boot pin selection, the next decision is made by either the boot 0 pin or the boot 0 configuration. Both could lead to boot from internal user Flash or could be further determined by unboot 1 option bit to boot from either system boot loader or SRAM. But when RDP is set to level 2, the system will always boot from internal user Flash only. As same as 32L5, as described in MOOC part 2, it provides more configuration options for securing the boot entry. The configuration depends on TZEN option bit setting. When TZEN equals to 0, the boot options are a mix of between L4 and F7 using in software boot 0 and boot address 0 and 1. When TZEN equals to 1, then the boot option enable only two possible targets. One is the secure boot address 0, the other one is the secure system boot loader, which is also known as RSS. On L5, there is also one additional boot log option. This will bypass the boot 0 configuration. First, let's take a look at the boot principle when TZEN is 0. So similar to L4, there is the unboot and software boot 0 configuration bit to determine whether to look at the configuration from boot 0 pin or boot 0 option. And both could be configured to use the boot address coming from boot address 0 and boot address 1 option byte. Both option bytes could be configured to point to the internal user Flash address or to the system boot loader or internal SRAM. But when RDP is set to level 2, then the boot will be forced to the address from user Flash. Then let's take a look at the case when TZEN is enabled on L5. When boot log is not yet activated, again, this unsoftware boot 0 option bit will decide whether to take the configuration coming from the boot 0 pin or the boot 0 option. And both could lead to the booting from RSS directly or to use the address coming from the secure boot address option byte. And this option byte could be programmed with an address coming from the user Flash or RSS or internal SRAM. But an address in SRAM is only allowed when RDP is set to level 0. As long as RDP is higher than level 0, then valid address in the secure boot address option bytes can only be an address from user Flash or RSS. There's no more chance to boot from SRAM in that case. And that is the same when boot log is activated. Boot log will bypass any configuration from the other boot options or boot pins. The boot mechanism of SM32WB is the same as L4, so I will not repeat the same here. The boot mechanism on SM32GFamily is similar to L0, so there is also the unboot select bit which can force the configuration coming from software. But GFamily also introduced the boot log option, which will bypass all the other boot settings in option byte or boot pin and force the boot from user Flash, regardless of the RDP level. And the boot log can only be deactivated when RDP stays in level 0 or with a RDP regression from level 1 to level 0. That means activation of boot log plus RDP 1 makes the boot from Flash immutable. It is almost the same as RDP level 2. The debug port will automatically be disabled after reset in such kind of configuration. Of course, RDP level 2 can still force the boot from Flash. So on G0Z4, similar to L5, there is the boot log option. When this option is not activated, the rest mechanism is similar to L0. So there will be the option to select boot pin or boot 0 option bit, whether to select the user Flash to boot or to boot from system bootloader or RAM depending on the configuration in boot 1 option bit. But when boot log is selected, is activated, then the only possible boot source is the user Flash. That is the same when RDP is set to level 2. Similar to F7, SM32 H7 family also has two boot addresses defined in boot address 0 and boot address 1 option bytes. And both could be configured to boot from user Flash, system bootloader or RAM. Selection of the two addresses is done by a boot pin. On some of the H7, which has the additional security features, there is also an additional secure bootloader area embedded. This is also known as RSS, root secure service. When security is activated on those devices, boot is forced to RSS instead of normal system bootloader. When security bit is activated, a secure user memory area can also be defined. RSS will always jump to an address within the secure user memory as long as the secure user memory is defined. Here is the boot principle of H7 series. As long as security is activated, the system will always boot from RSS. And in such case, if secure user memory is also defined, then the RSS will always jump to the secure user memory address in the user Flash. If there is no secure user memory defined or if security is not activated on H7, then the boot pin will determine whether to use the boot address coming from boot address 0 or boot address 1 option bytes. And both could be configured to point to an address from internal user Flash or system bootloader or SRAM. But in case RDP level 2 is set, then the boot address will be forced to user Flash. We have talked a lot about how to make sure the unique boot entry on SDM32. Now let's take a look at how to ensure the immutability on SDM32. The first step for immutability is the use of write protection mechanism. This mechanism always apply on a per flash sector basis and WRP mechanism can be activated by option bytes. However, option byte can be modified if RDP is not in level 2. So RDP level 2 is also required to make sure option byte will not change. On some recent chips, including secure user memory, the immutability can also be ensured as long as RDP level 1 is activated. SDM32 G0, G4, H7 and L5 have the ability to define a secure user memory. When running code inside secure memory, it is possible to erase flash inside this secure memory area. But when running code outside secure memory, the flash erase is not possible anymore. That means, for example, if we put the secure boot code inside the secure user memory area, after jumping to the application, the application will not be able to make any modification of the bootloader code area anymore. In case there is still the concern of any possible modification happen within the secure boot code inside the secure user memory area, then the WRP can still be applied inside the secure memory area. In that case, to get the immutability, it is the same as the other SDM32, WRP plus RDP level 2. Summary of the secure boot protection. In order to trust the secure boot code that we have, there are two conditions to be met. First, we need to ensure the single boot entry on SDM32 that could be achieved by the mechanism of RDP level 2, boot log and secure memory on H7 for instance. And the second is to ensure immutability. That can be achieved by RDP level 2 plus WRP and partially with RDP 1 and secure memory. The association of single boot entry and immutability makes the secure boot as if it was ROM code. This is what we call root of trust. We trust that the code excluding off the reset is always the same. Secure boot protection variations. Depending on the environment constraints, it is not always necessary to have the maximum protection. RDP level 2 for instance. But in that case, a detailed analysis has to be done to understand the weakness of a setup. For instance on SDM32 H7, using secure memory plus RDP 1 plus WRP inside the secure memory can be enough as long as code inside this area is not able to change this configuration. Such setup could be useful to still have the ability to change option byte if this is necessary. Now let's have a hands on of the boot loader immutability. The goal of this hands on is to show the different steps to add immutability protection to the simple boot loader, build the binary of both boot loader and application and program to the board, run the device and run a test from application of the immutability of the boot loader. Thank you for watching.