 Hello and welcome to this presentation describing the Secure Firmware Install or SFI feature offered by the Root Security Services. The Root Security Services or RSS are the secure part of the STM32U5 Immutable Bootloader. They're available only when Trustzone is activated on the device. RSS provides Immutable Root Security Services used, for example, to run the STM32 Secure Firmware Install or SFI solution in an untrusted environment. For more information on Trustzone and protected memories, please refer to the online training module STM32U5 Security Overview. A hardware security module or HSM is in charge of securely storing OEM AES secret key, checking the STM32 device certificate that is used to authenticate STM32 device, generating and providing the license to the Secure Bootloader to securely install the encrypted firmware on the STM32 device, and counting the number of produced STM32 devices. When Trustzone is enabled, RSS is the secure immutable firmware supplied by ST during the production of the STM32U5 along with a unique key pair dedicated to the device. 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 the STM32 Secure Firmware Install solution. Boot time services of the RSS include Non-Secure Bootloader Resource Allocation, SRAM, Flash, Peripherals, IOs, Interups, Functions to get or set Flash Secure Option bytes, used by the bootloader, and Functions to get the STM32U5 device certificate and its size, also used by the bootloader. RSS also provides services for both secure and non-secure running firmwares. One of those secure services allows secure firmware running in the Flash-HDP area to safely jump to a given address outside the protected area. All of these services are detailed in the next three slides. Secure hide protection or HDP is an additional protection mechanism within the Trostone Secure domain. The code embedded in HDP is executed first, and at the end of its execution, it jumps to the secure user application. The code and data protected by HDP is longer accessible until the next system reset. The HDP area is activated by secure code, setting the HDPen option bit. Let's now explain how RSS helps jumping outside the HDP area. The boot code embedded in HDP executes after reset. See step 1 in the figure. At the end of its execution, it calls RSSLibsecCloseExitHDP. This is step 2. Then, this RSSLibsecCloseExitHDP function closes the Flash-HDP secure memory area, this is the step 3, and jumps to the reset handler pointed to by the vector table whose address is passed as input parameter. This is the step 4. This function resets the STM32U5 in case of failure due to bad input parameter value for example. Secure firmware install or SFI is a global solution for STM32U5 series of microcontrollers allowing secure and counted installation of OEM firmware in untrusted production environments such as OEM contract manufacturer. SFI is implemented using the secure RSS and the non-secure immutable boatloader. OEM firmware protected by SFI can be stored in the device's embedded flash or encrypted in external flash connected via OctoSPI. 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. The STM32U5 SFI solution consists in having the entire OEM firmware and option bytes encrypted with an AES secret key thanks to STM32 Trusted Package Creator Tool. This is done during the development of OEM firmware. Confidentiality of this AES secret key is ensured using a unique key pair dedicated to the STM32 device with a private key readable only by RSS. Refer to AN5391 and title STM32L5U5SFI tools, boatloader and RSS interface for more details. When external flash memory connected via OctoSPI is targeted by SFI, the OEM firmware code must be encrypted with an external firmware and the 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. Note that on the flight decryption of the encrypted firmware stored in SPI flash memories is only available on STM32U5 devices. For more details please refer to the end of this module or the application node AN4992 for secure firmware install solutions. The installation of secure firmware in internal flash memory goes as follows. 1. The encrypted SFI image is available from STM32 Trusted Package Creator. 2. The OEM program's the HSM with the AES secret key. 3. Start of the SFI process. 4. Device certificate retrieval. 5. STM32 device authentication in the HSM. 6. The HSM provides the license to the STM32 device. 7. The RSS retrieves the OEM AES secret key encrypted in the license. And 8. Encrypted firmware and option bytes are transferred, decrypted, then programmed. The cryptographic engine responsible for on-the-fly external flash memory decryption named OTFDEC supports the AES standard cryptographic algorithm. Thanks to this standard algorithm the OEM can encrypt the external firmware and data on the host before programming it into the external flash memory without using the STM32 secure bootloader. This slide shows that the secure programming of internal flash memory in 1 and the encryption plus programming of the external firmware and data in 2 can be done in 2 separate flows. The first flow uses the secure bootloader, while the second uses the OEM host to program the external flash memory. Then during each secure boot the secure internal firmware first copies the AES firmware and data keys into write-only OTFDEC key registers, then activates the OTFDEC region tied to those keys. At this point the CPU can seamlessly read data and fetch code from 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 shown in the diagram. Step one, create an SFI image with internal firmware and data including external flash memory drivers, external firmware and the data AES key and external firmware and data. Step two, internal flash memory programming as described on the previous slide. Step three, external firmware and data AES key programming in the OTFDEC peripheral. Alternatively to what is drawn on the slide this key can be managed locally in the device not globally in the flashing tools. Step four, external flash memory chunk encryption required if the image wasn't encrypted by the STM32 trusted package creator. Step five, external flash memory programming by the user's firmware. Then during each secure boot the secure internal firmware first copies the AES firmware and data keys into write-only OTFDEC key registers then activates the OTFDEC region tied to those keys. At this point the CPU can seamlessly read data and fetch code from external flash memory once the Okto SPI driver has been initialized. For more details please refer to application note AN2606 about the STM32 microcontroller system memory boot mode, application note AN4992 about the overview of secure firmware install, user manuals for the STM32 cube programmer and STM32 trusted package creator are also available on the ST website. Thank you for attending this presentation. You can also refer to the following presentations on STM32 U5 security features, security overview, enhanced anti-tamper, enhanced key storage, hash and random number, symmetric crypto, asymmetric crypto, cryptolib and security certification.