 Hello and welcome to this overview of security features present in the STM32 U5. The STM32 U575 and U585 family of devices is designed with a comprehensive set of security features, some of which are based on standard ARM trust-one technology. These security features simplify the process of evaluating IoT devices against security standards. They also significantly reduce the cost and complexity of software development for OEM and third-party developers by facilitating reuse, improving interoperability and minimizing API fragmentation. This module describes the following key security features. Secure boot, thanks to the unique boot entry and hypertext area or HTTP features. Improved resource isolation using trust-one and privileged mode extended to secureable IOs, memories and peripherals. Enhanced lifecycle management with readout protection or RDP. It includes debug protection and optional password-based RDP regressions. Dual developer firmware distribution scheme using trust-one on the fly decryption and RDP 0.5. On the fly decryption of encrypted images stored in external flash memory with associated secure firmware installation. In other modules you find the following information. Enhanced secure storage, cryptographic acceleration including side-channel protection when manipulating secrets, active temper and protection against temperature, voltage and frequency attacks. Secure firmware installation, certification CC level 3 and PA say level 3. This line summarizes the boot options when trust-one is enabled. When boot log equals 1, the boot address is unique and defined by secure user option segboogadd0 whatever the other parameters. When RSS CMDR is non-null and boot log equals 0, boot in root security services or RSS is performed. And when RDP is greater than 0, the boot code must be located in a secure area. When trust-one is disabled, only the center of the table is relevant with non-secure nsbootadd0 replacing segbootadd0 and non-secure nsbootadd1 replacing the RSS fixed address. In embedded flash there are two write protection areas per bank controlled by non-volatile configuration bits. These bits cannot be modified when the corresponding unlock configuration bit is 0. Unlock bits can be set only when regressing from RDP level 1 to level 0. When trust-one is enabled in the device, embedded flash features the following protections. One secure area per user flash bank, defined with secure non-volatile user option bytes. Default programming is all secure. One secure hide protection or HDP area per bank, strictly hidden after boot by application. 8 kilobytes user pages on the fly defined by the application as secure using volatile secure registers. Default configuration out of reset is non-secure. Additionally, each 8 kilobytes user page can be defined on the fly as privileged only using volatile privileged registers. When a page is defined secure, only secure applications can change this property. When trust-one is enabled, the secure world can be used to protect critical code against intentional or unintentional tampering from the more exposed code running in the non-secure world. Whether trust-one is enabled or not, the cortex privileged mode can be used to protect critical code or data against intentional or unintentional tampering from the more exposed unprivileged code. These resource isolation features were instrumental to obtain the CCIP level 3 and PSA level 3 certification. CCIP stands for security evaluation standard for IoT platforms and PSA stands for platform security architecture. On top of the ARMv8-M trust-one security extension in Cortex-M33, the device has embedded complementary security features called the Global Trust-one Controller or GTCC that reinforce in a flexible way the isolation between respectively secure non-secure worlds and privileged unprivileged worlds. GTCC protects peripherals using registers in the Trust-one Security Controller or TZSC. It protects memories using the Memory Protection Controller Block Based or MPCBB and the TZSC registers. GTCC can protect against non-secure and optionally unprivileged transactions initiated by masters other than the Cortex-M33. Note that some peripherals do not require GTCC to offer secure or privileged protection because they natively trust-one aware and privileged aware. The Device Life Cycle is managed by the Readout Protection Option Byte or RDP. This RDP mechanism is a hardware feature that controls the access to the device debug, test and provisioned secrets as summarized in this table. The new features around unlocking keys are described in the following slide. Password key-based RDP regressions are available through the debug interface or via the system bootloader. They're ideal for customers that don't want to irreversibly log devices. Two 64-bit keys are defined in embedded flash to independently protect secure OEM1 and non-secure OEM2 application codes as shown. One usage of this is described in the dual developer firmware distribution scheme slide. Note that unlocking the device with a password is only possible once per power cycle. OEM1 key can always be modified when RDP is zero. It can be changed when RDP is 0.5 or 1 if OEM1 log equals zero. OEM2 key can always be modified when RDP is zero or 0.5. It can be changed when RDP is 1 if OEM2 log equals zero. Through the debug interface, a 32-bit device's specific quantity can be read to compute device-specific passwords. This method doesn't apply if IDP level is 2 and OEM2 log equals zero. Getting the password will never compromise data confidentiality. It only allows to regress the RDP protection. The device supports the STM32 dual developer firmware distribution scheme. In the single developer scheme, one OEM develops secure and non-secure applications. Both applications must be protected using RDP level 1 or RDP level 2. In the dual developer scheme, the first OEM develops the secure application. It's associated non-secure callable library and provides a predefined linker file to the second OEM that develops the non-secure application. In the dual developer scheme, the secure application must be protected using RDP level 0.5 after installation. The final non-secure application must be protected using RDP level 1 or RDP level 2. The OTF deck module decrypts on-the-fly read-only information encrypted in external SPI flash. AES 128-bit cipher encounter mode is used to achieve the lowest possible latency. Four independent and non-overlapping encrypted regions can be defined. For each region, an additional layer of protection can be added on top of the standard AES encryption algorithm requiring the encryption to be done on-chip. When such enhanced protection is selected, only instructions can be stored in the region. OTF deck also supports an encryption mode available when no decryption is ongoing. All key registers are write-only and automatically erased in the case of tempers or RDP regression. OTF deck is a trust-owner-ware peripheral. All writes to its registers must be secure when security is activated in the product by setting TZEN. When privbit is set in OTF deck, only privileged accesses are granted when accessing most of the OTF deck registers. OTF deck analyzes all AHB read transfers on the associated AHB bus. If the read request is within one of the four regions programmed, the control logic triggers a keystream computation based on the AES algorithm encounter mode. This keystream is then used to decrypt the data present on the fly in the read transfer from the OCTO SPI AHB master. Any access outside the enabled OTF deck regions belongs to a non-encrypted region. As OTF deck is used in conjunction with OCTO SPI, it's mandatory to access the flash memory using the memory mapped mode of the flash controller. The OTF deck can assert an interrupt to their NVIC for three possible causes. Security error, key error, execute only or execute while encryption error. Each of these errors has a dedicated flag and an interrupt enabled bit. Secure firmware install or SFI is a global solution for this STM32 series of microcontrollers, allowing secure and counted installation of OEM firmware in untrusted production environments such as an OEM contract manufacturer. When external flash memory is targeted by SFI, the OEM firmware code must be encrypted with a dedicated AES key. This key can be common to a family of products with OEM tools performing the encryption or unique per device with the firmware encrypted inside the device. On-chip encryption is mandatory when OTF deck enhanced encryption is selected. For more information, please refer to application node AN4992 for secure firmware install solutions. Thank you for having attended this presentation. You can now refer to the presentations that detail the operation of the STM32U5 security modules. Symmetric cryptography, asymmetric cryptography, hash and random number generation, enhanced anti-tamper, enhanced key storage.