 Hello and welcome to this online training module dedicated to the advanced security features of the STM32L5, the Root Security Services, or RSS. It is strongly advised to have already viewed the online training module memory protections. The Root Security Services, or RSS, is the secure part of the STM32L5 immutable bootloader. It is available only when Trust Zone is activated on the device. RSS provides immutable Root Security Services used, for example, to run STM32 secure firmware install solution in an untrusted environment. For more information on Trust Zone and protected memories, please refer to the online training module STM32L5 memory protection features. When Trust Zone is activated, RSS is the secure immutable firmware provisioned by ST during STM32L5 production, along with a dedicated device unique key pair. After reset, this immutable firmware is used as a unique entry point, featuring a set of security services that are available at boot time and sometimes also at run time. RSS includes the necessary features to run STM32 secure firmware install or SFI solution. See following slides. Boot time services of the RSS include non-secure bootloader resources allocation, SRAM, flash, peripherals, IOs, and interrupts. Functions to get or set flash secure option bytes, usable through bootloader. Function to get STM32L5 device certificate and certificate size, also usable through bootloader. RSS also provides services for both secure and non-secure running firmwares. One of those secure services allows secure firmware running in flash-HDP area to safely jump to a given address outside the protected area. All those services are detailed in the next three slides. On STM32L5, the user connects to the device thanks to the communication port supported by the on-chip immutable bootloader. Those ports are the USART 1, 2, and 3, the I2C 1, 2, and 3, the SPI 1, 2, and 3, the FD CAN, and the USB DFU. Once connected, non-secure user firmware can call RSSLibSetSecOB, respectively RSSLibGetSecOB function, to set, respectively get, flash secure option byte register. This function is only available when the device RDP level is equal to zero or open state. The list of secure option bytes available in STM32L5 can be found in the reference manual. For more information, please refer to application note AN5428 for RSSLibAPIs and application note AN2606 for bootloader usage. On STM32L5, the user connects to the device thanks to the communication port supported by the on-chip immutable bootloader. Those ports are the USART 1, 2, and 3, the I2C 1, 2, and 3, the SPI 1, 2, and 3, the FD CAN, and the USB DFU. Once connected, non-secure user firmware can call RSSLibGetCertificate function to get pointer to the STM32L5 device certificate as depicted on the slide. Each certificate is unique per device. Similarly, non-secure user firmware can call RSSLibGetCertificateSize function to get the size of the STM32L5 device certificate above. For more information, please refer to application note AN5428 for RSSLibAPIs, the application note AN2606 for bootloader usage, and AN4992 for device certificate usage in secure firmware install or SFI. Secure hide protection or HDP is an additional protection mechanism within the trust zone secure domain. The code embedded in HDP is executed first, and at the end of its execution it jumps to secure user application. The code and data protected by HDP can no longer be accessed until the next system reset. The HDP area is activated by secure code, setting the HDPEN option bit. How does RSS help jumping outside the HDP area? The boot code embedded in HDP executes after reset. At the end of its execution it calls RSSLibSecCloseExitHDP to close flash HDP secure memory area and jump to the reset handler embedded within the vector table, the address of which is passed as input parameter. This function resets STM32L5 in case of failure, such as bad input parameter failure. For more information, please refer to the application note AN5428 for RSSLibAPIs. Secure firmware install or SFI is a global solution for the STM32L5 series of microcontrollers, allowing secure and counted installation of OEM firmware in untrusted production environment, such as OEM contract manufacturer. SFI is implemented using the secure RSS and the non-secure immutable bootloader. OEM firmware protected by SFI can be stored in the device's embedded flash or encrypted in external flash connected to the OctoSPI. The STM32L5 SFI solution consists in having the whole OEM firmware and the option bytes encrypted with an AES secret key, thanks to the STM32 Trusted Package Creator Tool. This is done during OEM firmware development. Confidentiality of this AES secret key is ensured using an STM32 device's unique key pair, with the private key readable only by the RSS. When external flash memory connected via OctoSPI is targeted by SFI, OEM firmware code must be encrypted with an external firmware and data AES key. This key can be common to all devices, in this case tools could perform the encryption or unique per device. In this case, firmware is encrypted inside the device. NB. On-the-fly decryption of encrypted firmware stored in SPI flash memories is only available on STM32L56XX devices. For more information, please refer to application note AN4992 for secure firmware install or SFI solutions, or the STM32L5 OTF DEC training module for encrypting and decrypting external flash firmware. Only genuine STMicroelectronics STM32L5 microcontrollers can install the protected firmware via SFI. It can be done in a non-trusted environment or facility. The number of STM32 devices on which the firmware has been installed can be counted inside the hardware security module or HSM associated with the SFI process. See next slide. OEM firmware and the option bytes are encrypted thanks to STM32 trusted package creator tool during OEM firmware development. OEM also uses this tool to program the hardware security module or HSM with its AES security key, its nonce, and a maximum installation counter. An OEM contract manufacturer uses STM32 cube programmer plus provisioned HSM to initiate SFI process and send the encrypted SFI image to the STM32L5 device. Authenticity, integrity, and confidentiality of the OEM internal firmware and option bytes are checked before embedded flash is programmed with decrypted firmware and option bytes. When the external flash memory is targeted by SFI process, RSS can re-encrypt OEM external firmware using an AES key dedicated to the OTF DEC peripheral. Those OTF DEC keys can be globally managed by the tools or they can be device specific. In other words, locally computed using the true RNG peripheral. A mix of both is possible. Secure firmware install to internal flash memory goes as follows. Numerical steps are represented on the schematic. 1. SFI image encrypted available from STM32 trusted package creator. 2. OEM programs HSM with AES secret key. 3. SFI process launch. 4. Device certificate retrieval. 5. STM32 device authentication in HSM. 6. HSM provides the license to STM32 device. 7. RSS retrieves OEM AES secret key encrypted in the license. 8. Encrypted firmware and option bytes are transferred, decrypted, then programmed. The cryptographic engine responsible for the on the fly external flash memory decryption or OTF DEC supports AES standard cryptographic algorithm. Thanks to this standard algorithm, OEM can encrypt external firmware and data on the host before programming to the external flash memory without using STM32 secure bootloader. This slide shows that the secure programming of internal flash memory 1 and the encryption plus programming of external firmware and data 2 could be done in two separated flows. The first flow uses secure bootloader while the second uses the OEM host for programming the external flash memory. Afterward, during each secure boot, the secure internal firmware first copies the AES firmware and data keys in write-only OTF DEC key registers, then activates the OTF DEC region tied to those keys. At this point, the CPU can seamlessly read, fetch data and code from the external flash memory once the Octo-SPI driver has been initialized. This slide represents the sequence where the STM32 secure bootloader handles both internal firmware installation and external firmware installation with a global external flash memory AES key and the help of an external flash memory loader. The numerical steps are represented on the schematic. 1. Create an SFI image with A internal firmware and data including external flash memory drivers, B external firmware and data AES key, and C external firmware and data. 2. Internal flash memory programming as described in the slide before. 3. External firmware and data AES key programming in OTF DEC peripheral. Alternatively, to what is drawn on the slide, this key can be managed locally to the device, not globally in the flashing tools. 4. External flash memory chunk encryption. And 5. External flash memory programming by the user's firmware. Afterward, during each secure boot, the secure internal firmware first copies the AES firmware and data keys in write-only OTF DEC key registers, then activates the OTF DEC region tied to those keys. At this point, the CPU can seamlessly read, fetch data and code from external flash memory once the Octo-SPI driver has been initialized. Please refer to memprotect, flash, boot or trust zone training if you want to know more on those topics. Also, find a list of peripherals related to the RSS and the SFI. Please refer to GTZC, RNG, Octo-SPI or OTF DEC trainings for more information if needed. For more details, please refer to application note AN2606 about STM32 microcontroller system memory boot mode. See in particular STM32L552XX562XX configuration in section 59.1 and bootloader selection in section 59.2. Application note AN5428 about STM32L5 series microcontroller memory RSS services. Application note AN4992 about overview of secure firmware install or SFI. And user manuals for STM32 CUBE programmer and STM32 trusted package creator are also available on the ST website.