3. System security

The STM32U5 series devices are designed with a comprehensive set of security features, some of which being based on the standard Arm TrustZone 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 the reuse, improving the interoperability, and minimizing the API fragmentation.

This section explains the different security features available on STM32U5 series devices.

3.1 Key security features

• • Resource isolation using privilege mode and Armv8-M mainline security extension of the Cortex-M33, extended to securable I/Os, memories, and peripherals
• • Secure firmware installation (SFI) with device unique cryptographic key pair
  • – leveraging the on-chip immutable bootloader that supports the download of the image through USART, USB, I ² C, SPI, FDCAN, and JTAG
• • Secure boot thanks to the unique boot entry feature and hide-protect area (HDP) mechanism
• • Secure storage, featuring:
  • – Nonvolatile on-chip secure storage, protected with secure and HDP areas
  • – Battery-powered volatile secure storage, automatically erased in case of tamper
  • – Write-only key registers in the AES engines
  • – Device 96-bit unique ID and JTAG 32-bit device-specific ID
  • – On-chip enhance storage technology, using hardware secret nonvolatile derived hardware unique keys (DHUK), and application-defined volatile boot hardware key (BHK), both loadable by hardware to the DPA-resistant SAES engine
• • General purpose cryptographic acceleration:
  • – AES 256-bit engine, supporting ECB, CBC, CTR, GCM, and CCM chaining modes
  • – Secure AES 256-bit security coprocessor, supporting ECB and CBC chaining modes with side-channel counter-measures and mitigations
  • – HASH processor, supporting MD5/SHA-1 checksums and SHA-2 secure hash
  • – Public key accelerator (PKA) for RSA/DH (up to 4096 bits) and ECC (up to 640 bits), implementing side-channel counter measures and mitigations when manipulating secrets
  • – True random number generator (RNG), NIST SP800-90B pre-certified
• • On-the-fly decryption of encrypted image stored on external flash memory connected through the OCTOSPI:
  • – Almost-zero latency with standard NOR flash memories
  • – Can be used to encrypt the image using device-unique secret keys
  • – Automatic key erase in case of tamper
• • Flexible life-cycle scheme with readout protection (RDP), including support for product decommissioning (auto-erase)
  • – Debug protection, depending on the RDP level

• – Optional password-based RDP level regressions, including for RDP level 2
• • Protected firmware distribution scheme, using TrustZone, on-the-fly decryption, and RDP level 0.5
• • Active tamper and protection against temperature, voltage, and frequency attacks
  • – Eight active inputs, eight active outputs tamper pins, available in all power modes

3.2 Secure install

The secure firmware install (SFI) is an STMicroelectronics secure service authenticated and decrypted by the immutable RSS code stored in the device. The SFI allows secure and counted installation of OEM firmware in the untrusted production environment (such as the OEM contract manufacturer).

The confidentiality of the installed images written either in the internal flash memory or encrypted in an external flash memory, is also protected, using the AES.

The SFI native service leverages the following hardware security features:

• • secure boot (see Section 3.3 )
• • resource isolation using TrustZone (see Section 3.5 )
• • temporal isolation using hide protection (see Section 3.6.1 )
• • secure execution (see Section 3.7 )
• • secure storage, with associated cryptographic engines (see Section 3.8 and Section 3.9 )

Further information can be found in the application note: “STM32 MCUs secure firmware install (SFI) overview ” (AN4992).

3.3 Secure boot

Secure boot is an immutable code that is always executed after a system reset. As a root of trust, this code checks the device static protections and activates available device runtime protections, reducing the risk that invalid or malicious code runs on the platform. As root of trust, the secure boot also checks the integrity and authenticity of the next level firmware before executing it.

The actual functions of the secure boot depend on the availability of TrustZone features, and on the firmware stored in the device. However, the secure boot typically initializes the secure storage, and installs on-the-fly decryption keys in the OTFDEC, to be able to use encrypted firmware stored in an external flash memory.

The device trusted firmware-M (TFM) application, supported by the STM32 ecosystem, provides a root of trust solution including secure boot functions. For more information, refer to the user manual Getting started with STM32CubeU5 TFM application (UM2851).

In the devices, the secure boot takes benefit of hardware security features such as:

• • resource isolation using TrustZone (see Section 3.5 )
• • temporal isolation using hide protection (see Section 3.6.1 )
• • secure execution (see Section 3.7 )
• • secure install and update (see Section 3.2 and Section 3.4 )

• • secure storage, with associated cryptographic engines if available (see Section 3.8 and Section 3.9 )

This section describes the features specifically designed for secure boot.

3.3.1 Unique boot entry and BOOT_LOCK

When TrustZone is activated (TZEN = 1) and the BOOT_LOCK secure option bit is cleared, the application selects a boot entry point located either in the system flash memory (see the next section), or in the secure user flash memory, at the address defined by SECBOOTADD0 option bytes.

When TrustZone is activated (TZEN = 1) and the BOOT_LOCK secure option bit is set, the device unique boot entry is the unmodifiable secure address defined by SECBOOTADD0 option bytes. All these option bytes cannot be modified by the application anymore when BOOT_LOCK is set.

Note: As long as it is cleared, the BOOT_LOCK option bit can be set without any constraint. But once set, the BOOT_LOCK option bit cannot be cleared when RDP level > 0.

For more information on the boot mechanisms, refer to Section 4: Boot modes .

3.3.2 Immutable root of trust in system flash memory

The immutable root-of-trust code stored in the system flash memory is first used to initiate the SFI, allowing secure and counted installation of OEM firmware in the untrusted production environment (such as the OEM contract manufacturer).

The STMicroelectronics immutable code also includes secure runtime services that can be called at runtime when a secure application sets the SYSCFG_RSSCMR register to a non-null value before triggering a system reset. This runtime feature is deactivated when the BOOT_LOCK secure option bit is set, and the secure address defined by SECBOOTADD0 is set on the secure user flash memory.

3.4 Secure update

The secure firmware update is a secure service that runs after a secure boot. Its actual functions depend on the availability of the TrustZone features, and on the firmware stored in the device.

The device trusted firmware-M (TFM) application, supported by the STM32 ecosystem, allows the update of the microcontroller built-in program with new firmware versions, adding new features and correcting potential issues. The update process is performed in a secure way to prevent unauthorized updates and access to confidential on-device data.

A firmware update can be done either on a single firmware image including both secure and nonsecure parts, or on the secure (respectively nonsecure) part of the firmware image, independently.

In the devices, the secure update application leverages the same hardware security as the firmware install described in Section 3.2 . For more information, refer to the user manual: Getting started with STM32CubeU5 TFM application (UM2851) .

3.5 Resource isolation using TrustZone

In the STM32U5 series devices, the hardware and software resources can be partitioned so that they exist either in the secure world or in the nonsecure world, as shown in the figure below.

Figure 7. Secure/nonsecure partitioning using TrustZone technology

Note: The initial partitioning of the platform is under the responsibility of the secure firmware executed after the reset of the device.

Thanks to this resource isolation technology, the secure world can be used to protect critical code against intentional or unintentional tampering from the more exposed code running in the nonsecure world.

Note: The secure code is typically small and rarely modified, while nonsecure code is more exposed, and prone to firmware updates.

3.5.1 TrustZone security architecture

The Armv8-M TrustZone technology is a comprehensive hardware architecture that proposes to developers a comprehensive, holistic protection across the entire processor and system. The device TrustZone hardware features include:

• • the Armv8-M mainline security extension of Cortex-M33, enabling a new processor secure state, with its associated secure interrupts
• • the dynamic allocation of memory and peripherals to TrustZone using eight security attribution unit (SAU) regions of Cortex-M33
• • a global TrustZone framework (GTZC), extending the TrustZone protection against transactions coming from other masters in the system than the Cortex-M33
• • TrustZone-aware embedded flash memory and peripherals

Note: The TrustZone security is activated by the TZEN option bit in the FLASH_OPTR register.

3.5.2 Armv8-M security extension of Cortex-M33

The Arm security extension of the Cortex-M33 is an evolution, not a revolution. It uses the programmer model from earlier Cortex-M subfamilies like Cortex-M4. Indeed, Armv8-M is architecturally similar to Armv7-M, using the same 32-bit architecture, the same memory mapped resources protected with an MPU. Armv8-M also uses the nested vectored interrupt controller (NVIC).

The Armv8-M TrustZone implementation in STM32U5 series devices is composed of the following features:

• • a new processor state, with almost no additional code/cycle overhead, as opposed to Armv8-A TrustZone that uses a dedicated exception routine for triggering a secure/nonsecure world change
• • two memory map views of a shared 4-Gbyte address space
• • a low interrupt latency for both secure and nonsecure domains, and a new interrupt configuration for security grouping and priority setting
• • separated exception vector tables for the secure and nonsecure exceptions
• • micro-coded context preservation
• • banking of specific registers across secure/nonsecure states, including stack pointers with stack-limit checkers
• • banking of the following Cortex-M33 programmable components (two separate units for secure and nonsecure):
  • – SysTick timer
  • – MPU configuration registers (eight MPU regions in secure, eight in nonsecure)
  • – some of the system control block (SCB) registers
• • new system exception (SecureFault) for handling of security violations
• • configurable debug support, as defined in Section 3.11

For more information, refer to STM32 Cortex-M33 MCUs programming manual (PM0264).

3.5.3 Memory and peripheral allocation using IDAU/SAU

Security attributes

As illustrated on Figure 8 , the Armv8-M nonsecure memory view is similar to Armv7-M (that can be found in Cortex-M4), with the difference that the secure memory is hidden. The secure memory view shows the flash memory, SRAM, and peripherals that are only accessible while the Cortex processor executes in Secure state.

The figure below shows the 32-bit address space viewed after the SAU configuration by the secure code.

Figure 8. Sharing memory map between CPU in secure and nonsecure state

The Cortex processor state (and associated rights) depends on the security attribute assigned to the memory region where it is executed:

• • A processor in a nonsecure state only executes from nonsecure (NS) program memory, while a processor in a secure state only executes from secure (S) program memory.
• • While running in the secure state, the processor can access data from both S and NS memories. Running in the nonsecure state, the CPU is limited to nonsecure memories.

In order to manage transitions to the secure world, developers must create nonsecure callable (NSC) regions that contain valid entry points to the secure libraries. The first instruction in these entry points must be the new secure gate (SG) instruction, used by the nonsecure code to call a secure function (see the figure below).

Figure 9. Secure world transition and memory partitioning

Programming security attributes

In Cortex-M33, the static implementation defined attribution unit (IDAU) works in conjunction with the programmable security attribution unit (SAU) to assign a specific security attribute (S, NS, or NSC) to a specific address, as shown in the table below.

Table 8. Configuring security attributes with IDAU and SAU

1. Defined regions are aligned to 32-byte boundaries.

The SAU can only be configured by the Cortex-M33 in the secure-privilege state. When the TrustZone is enabled, the SAU defaults all addresses as secure (S). A secure boot application can then program the SAU to create NSC or NS regions, as shown in the previous table.

Note: The SAU/IDAU settings are applicable only to the Cortex-M33. The other masters like DMA are not affected by these policies.

A memory space not covered by an SAU region is fixed as secure.

For more information on memory security attribution using IDAU/SAU, refer to the application note TrustZone features on STM32L5 and STM32U5 Series (AN5347) .

3.5.4 Memory and peripheral allocation using GTZC

Global TrustZone framework architecture

On top of the Armv8-M TrustZone security extension in Cortex-M33, the devices embed complementary security features that reinforce, in a flexible way, the isolation between the secure and the nonsecure worlds. Unlike the SAU/IDAU, the GTZC can protect legacy memories and peripherals against nonsecure transactions coming from other masters than the Cortex-M33.

Figure 10. Global TrustZone framework and TrustZone awareness

Securing peripherals with TZSC

When the TrustZone security is active, a peripheral is either securable through the TZSC in GTZC, or is natively TrustZone-aware, as shown in the previous figure:

• • A securable peripheral or memory is protected by an AHB/APB firewall gate, that is controlled by the TrustZone security controller (TZSC).
• • A TrustZone-aware peripheral or memory is connected directly to the AHB or APB interconnect, implementing a specific TrustZone behavior, such as a subset of secure registers, or a secure memory area.

When a securable peripheral is made secure-only with the GTZC, if this peripheral is master on the interconnect (such as SDMMC), it automatically issues secure transactions. The SDMMC is an example of securable master. TrustZone-aware AHB masters like Cortex-M33 or DMAs, drive a secure signal in the AHB interconnect, according to their security mode, independently to the GTZC.

Note: Like with TrustZone, a peripheral can be made privileged-only with TZSC (see Section 3.6.3 ). In this case, if this peripheral is master on the interconnect, it automatically issues privileged transactions.

Securing memories with TZSC and MPCBB

The TZSC block in GTZC provides the capability to manage the security and privilege for all securable external memories, programming the MPCWM resources.

The table below shows an implementation example. For all other implementations on the STM32U5 Series devices, refer to Section 5.3: GTZC implementation .

Table 9. MPCWMx resources

1. Using the OTFDEC.

2. Assuming TrustZone is activated on the device, nonsecure unprivileged otherwise.

The MPCBB resources in GTZC provide the capability to configure the security and privilege of embedded SRAM blocks.

The table below shows an implementation example. For all other implementations on the STM32U5 Series devices, refer to Section 5.3: GTZC implementation .

Table 10. MPCBBx resources

1. Blocks are grouped in super-blocks of 32 consecutive blocks, to manage the configuration locking.

2. Assuming TrustZone is activated on the device, nonsecure unprivileged otherwise.

Applying GTZC configurations

The TZSC and MPCBB blocks can be used in one of the following ways:

• • statically programmed during the secure boot, locked and not changed afterwards
• • dynamically reprogrammed using a specific application code or real-time kernel

When the dynamic option is selected and the configuration is not locked:

• • MPCBB secure blocks or MPCWM nonsecure region size can be changed by a secure software. This software must be privileged for MPCWM, can be unprivileged if the particular block is not privileged-only.
• • The secure (respectively privilege) state of each peripheral can be changed writing to GTZC_TZSC_SECCFRGx (respectively GTZC_TZSC_PRIVCFGx) registers.

Securing peripherals with TZSC

The TZSC block in GTZC provides the capability to manage the security and the privilege for all securable peripherals. The list of these peripherals can be found in Section 5: Global TrustZone controller (GTZC) .

Note: When the TrustZone is deactivated, the resource isolation hardware GTZC can still be used to isolate peripherals to privileged code only (see Section 3.6.3 ).

When the TrustZone is activated, peripherals are set as nonsecure and unprivileged after reset.

TrustZone-aware peripherals

The devices include the following TrustZone-aware peripherals:

• • GPIOA to GPIOJ, configured in LPGPIO alternate function or not
• • GTZCx_MPCBB, GTZCx_TZIC and GTZCx_TZSC (GTZC blocks)
• • OTFDEC1/2, writable only in secure if TZEN = 1
• • EXTI
• • Flash memory
• • RCC and PWR
• • GPDMA and LPDMA
• • SYSCFG registers
• • RTC and TAMP
• • MCU debug unit DBGMCU
• • ICACHE and DCACHE1

The way illegal accesses to these peripherals are monitored through the TZIC registers is described in Section 5: Global TrustZone controller (GTZC) .

For more details, refer to Section 3.5.5 .

TrustZone illegal access controller (TZIC)

The TZIC block in GTZC gathers all illegal access events originated from sources either protected by GTZC or TrustZone-aware peripherals, generating one global secure interrupt towards the NVIC.

TZIC is available only when the system is TrustZone enabled (TZEN = 1). All accesses to TZIC registers must be secured and privileged.

For each illegal event source, a status flag and a clear bit exist. Each illegal event can be masked, not generating an interrupt toward the NVIC.

Note: By default, all events are masked.

3.5.5 Managing security in TrustZone-aware peripherals

This section gives more details on how the security is implemented in the TrustZone-aware peripherals listed in the previous section.

Embedded flash memory

When the TrustZone security is enabled through option bytes (TZEN = 1), the whole flash memory is secure after reset and the following protections, shown in the figure below, are available to the application:

• • nonvolatile user secure areas, defined with nonvolatile secure user option bytes
  • – watermark-based secure only area (x2)
  • – secure hide protection (HDP) area, stickily hidden after boot (x2)
• • volatile user secure pages, defined with volatile secure registers (lost after reset)
  • – Any page set as nonsecure (example: outside the watermark-based secure only area), can be set as secure on-the-fly using the block-based configuration registers.

Note: All areas are aligned on the flash memory page granularity.

The flash memory area can be configured as secure while it is tagged as nonsecure in Cortex-M33 IDAU/SAU. In this case, nonsecure accesses by the CPU to the flash memory are denied.

Erase or program operations can be available to secure (resp. nonsecure) code only for secure (resp. nonsecure) pages or memory. A flash memory is considered secure if at least one page is secure.

Figure 11. Flash memory TrustZone protections

As shown above, when TrustZone is activated (TZEN = 1), the application code can use the HDP area that is part of the flash memory watermark-based secure area. Indeed, when the application sets the HDPx_ACCDIS bit, data read, write, and instruction fetch on this HDP area is denied until the next system reset.

For example, the software code in the secure flash memory HDP area can be executed only once, with any further access to this area denied until the next system reset. Additionally, any flash memory page belonging to an active HDP area cannot be erased anymore.

When the TrustZone is deactivated (TZEN = 0), the volatile/non-volatile secure area features are deactivated and all secure registers are RAZ/WI.

See Section 7: Embedded flash memory (FLASH) for more details.

On-the-fly encryption/decryption (OTFDEC)

When the TrustZone security is activated (TZEN = 1), the OTFDEC can only be initialized by secure applications. Each of the four encrypted regions, once the configuration is confirmed, can be write-locked until the next power-on-reset.

Note: Any application (secure or nonsecure) can verify the initialization context of each OTFDEC region (including the CRC of the keys), by reading the peripheral registers.

Key registers in each OTFDEC are write-only.

See Section 3.9.3 for more details on this cryptographic engine.

Direct memory access controllers (LPDMA and GPDMA)

When a DMA channel x is defined as secure (SECx = 1 in LP/GPDMA_SECCFG), the source and destination transfers can be independently set as secure or nonsecure by a secure application using SSEC and DSEC bits in LP/GPDMA_CxTR1.

The table below summarizes these security options available in each DMA channel.

Table 11. DMA channel use (security) ⁽¹⁾

1. 1. When a transfer is blocked, the transfer completes but the corresponding writes are ignored, and reads return zeros. Also an illegal access event to TZIC is automatically triggered by the memory/peripheral used as source or destination.
2. 2. If the source is a memory, the transfer is only possible if SSEC = 0, otherwise the transfer is blocked.
3. 3. If the destination is a memory, the transfer is only possible if DSEC = 0, otherwise the transfer is blocked.
4. 4. If the transfer is memory-to-memory, the transfer is only possible if SSEC = 0 and DSEC = 0, otherwise the transfer is blocked.

When a channel is configured as secure:

• • Registers allocated to this channel (excluding LP/GPDMA_SECCFGR, LP/GPDMA_PRIVCFGR, and LP/GPDMA_RCFGLOCKR) are read as zero. Write are ignored for nonsecure accesses. A secure illegal access event may also be triggered toward the TZIC peripheral.
  • – Writes to LP/GPDMA_SECCFGR and LP/GPDMA_RCFGLOCKR must be secure. For each bit in LP/GPDMA_PRIVCFGR, write must be secure if the corresponding bit in LP/GPDMA_SECCFGR is set.
• • In linked-list mode, the loading of the next linked-list data structure from memory is performed with secure transfers.
• • When switching to a nonsecure state, the secure application must abort the channel or wait until the secure channel is completed before doing the switch.

Note: DMA secure channels are not available when TrustZone is deactivated.

When a channel is configured as nonsecure, in linked-list mode, the loading of the next linked-list data structure from memory is performed with nonsecure transfers.

See Section 18: Low-power direct memory access controller (LPDMA) and Section 17: General purpose direct memory access controller (GPDMA) for more details.

Power control (PWR)

When the TrustZone security is activated (TZEN = 1), the selected PWR registers can be secured through PWR_SECCFGR, protecting the following PWR features:

• • low-power mode setup
• • wake-up (WKUP) pins
• • voltage detection and monitoring
• • backup domain control

Other PWR configuration bits become secure:

• • when the system clock selection is secure in the RCC: the voltage scaling (VOS) and the regulator booster (BOOSTEN) configurations become secure.
• • when a GPIO is configured as secure: its corresponding bit for pull-up/pull-down configuration in Standby mode becomes secure.

• • when the USB Type-C/USB power delivery interface (UCPD) is configured as secure in TZSC: PWR_UCPDR register becomes secure.

See Section 10: Power control (PWR) for details.

Secure clock and reset (RCC)

When the TrustZone security is activated (TZEN = 1) and security is enabled in the RCC, the bits controlling the peripheral clocks and resets become TrustZone-aware:

• • If the peripheral is securable and programmed as secure in the TZSC, the peripheral clock and reset bits become secure.
• • If the peripheral is TrustZone-aware, the peripheral clock and reset bits become secure as soon as at least one function is configured as secure inside the peripheral.

Note: Refer to Section 3.5.4 for the list of securable and TrustZone-aware peripherals.

The SHSI configuration and status bits are secured when the SAES is configured as secure.

Additionally, the following configurations can be made secure-only using RCC_SECCFGR:

• • external clock (such as HSE or LSE), internal oscillator (such as HSI, MSI, or LSI)
• • main PLL and AHB prescaler
• • system clock source selection
• • reset flag clearing
• • automatic internal oscillator waking up configuration

See Section 11: Reset and clock control (RCC) for details.

Real time clock (RTC)

Like all TrustZone-aware peripherals, a nonsecure read/write access to a secured RTC register is RAZ/WI. It also generates an illegal access event that triggers a secure illegal access interrupt if the RTC illegal access event is enabled in the TZIC.

After a backup domain power-on reset, all RTC registers can be read or written in both secure and nonsecure modes. The secure boot code can then change this security setup, making registers alarm A, alarm B, wake-up timer, and timestamp secure or not, using RTC_SECCFGR.

When the SEC bit is set in secure-only RTC_SECCFGR:

• • Writing the RTC registers is possible only in secure mode.
• • Reading RTC_SECCFGR, RTC_PRIVCFGR, RTC_MISR, RTC_TR, RTC_DR, RTC_SSR, RTC_PRER, and RTC_CALR is always possible in secure and nonsecure modes. All the other RTC registers can be read only in secure mode.

When the SEC is cleared in secure-only RTC_SECCFGR, it is still possible to restrict access in secure mode to some RTC registers by setting dedicated control bits: INITSEC, CALSEC, TSSEC, WUTSEC, ALRASEC, and ALRBSEC.

Note: The RTC security configuration is not affected by a system reset.

See Section 63: Real-time clock (RTC) for more details.

Tamper and backup registers (TAMP)

Like all TrustZone-aware peripherals, a nonsecure read/write access to a secured TAMP register is RAZ/WI. It also generates an illegal access event that triggers a secure illegal access interrupt if the TAMP illegal access event is enabled in the TZIC.

After a backup domain power-on reset, all TAMP registers can be read or written in both secure and nonsecure modes. The secure boot code can change this security setup, making some registers secure or not as needed, using the TAMP_SECCFGR register.

When TAMPSEC is set in TAMP_SECCFGR:

• • Writing the TAMP registers is possible only in secure mode. Backup registers have their own write protection (see below).
• • Reading the TAMP registers (except for TAMP_SECCFGR, TAMP_PRIVCFGR and TAMP_MISR) returns zero if the access is nonsecure. Backup registers have their own read protection (see below).

The application can also:

• • make TAMP_COUNTR register read and write secure-only by setting the CNT1SEC bit in TAMP_SECCFGR secure register
• • in backup registers increase security for two of the three protection zones configured using BKPRWSEC[7:0] and BKPWSEC[7:0] bitfields in TAMP_SECCFGR:
  • – protection zone 1 is read nonsecure, write nonsecure
  • – protection zone 2 is read nonsecure, write secure
  • – protection zone 3 is read secure, write secure

Note: The TAMP security configuration is not affected by a system reset.

See Section 64: Tamper and backup registers (TAMP) for more details.

General-purpose I/Os (GPIO)

When the TrustZone security is activated (TZEN = 1), each I/O pin of the GPIO port can be individually configured as secure through the GPIOx_SECCFGR registers. Only a secure application can write to GPIOx_SECCFGR registers. After boot, each I/O pin of GPIO is set as secure.

When an I/O pin is configured as secure, its corresponding configuration bits for alternate function (AF), mode selection (MODE), and I/O data are RAZ/WI in case of nonsecure access.

When the digital alternate function is used (input/output mode), in order to protect the data transiting from/to the I/O managed by a secure peripheral, the devices add a secure alternate function gate on the path between the peripheral and its allocated I/Os:

• • If the peripheral is secure, the I/O pin must also be secure to allow input/output of data.
• • If the peripheral is not secure, the connection is allowed regardless of the I/O pin state.

The TrustZone-aware logic around GPIO ports, used as the alternate function, is summarized in the table below.

Table 12. Secure alternate function between peripherals and allocated I/Os

When an analog function with an analog switch is used, the connection to the peripherals listed in the table below, is blocked by hardware when the peripheral is nonsecure and the I/O is secure.

Table 13. Nonsecure peripheral functions that are not connected to secure I/Os

1. Used to find the I/O corresponding to the signal/function on the package (refer to the product datasheet).

Finally, regarding GPIO and security, the table below summarizes the list of peripheral functions that do not have any hardware protection linked to TrustZone. The listed signals (input and/or outputs) are not blocked when the I/O is set as secure, and the associated peripheral function is nonsecure.

For example, when a secure application sets PA4 as secure to be used as LPTIM2_OUT, if the DAC is nonsecure, it can be programmed to output data to PA4, potentially causing malfunction to the secure application.

Similarly, when a secure application sets PA0 as secure to be used as UART4_TX, if TAMP is nonsecure, it can be programmed to capture the USART input traffic through the TAMP_IN function.

It is important that, for each case described in the table below, the secure application decides if a potential effect on data integrity or confidentiality is critical or not. For example, if the USART situation described above is not acceptable (data transiting on secure USART is confidential), then the secure application must configure the TAMP as secure even if it is not used by the secure application.

Note: How to make a peripheral secure is summarized in the right column of the table below.

Table 14. Nonsecure peripheral functions that can be connected to secure I/Os

1. To find the I/O corresponding to the signal/function on the package, refer to the product datasheet.

Refer to Section 13: General-purpose I/Os (GPIO) for more details.

Extended interrupts and event controller (EXTI)

When the TrustZone security is activated (TZEN = 1), the EXTI is able to protect event register bits from being modified by nonsecure accesses. The protection can individually be activated per input event via the register bits in EXTI_SECCFGR1. When an input event is configured as secure, only a secure application can change the configuration (including security if applicable), change the masking or clear the status of this input event.

The security configuration in EXTI_SECCFGR1 can be globally locked after reset in EXTI_LOCKR.

See Section 23: Extended interrupts and event controller (EXTI) for more details.

System configuration controller (SYSCFG)

Like all TrustZone-aware peripherals, when the TrustZone security is activated (TZEN = 1), a nonsecure read/write access to a secured SYSCFG register is RAZ/WI. Such access also generates an illegal access event that triggers a secure illegal access interrupt if the SYSCFG illegal access event is not masked in the TZIC.

See Section 15: System configuration controller (SYSCFG) for more details.

Microcontroller debug unit (DBGMCU)

The MCU debug component (DBGMCU) helps the debugger, providing support for:

• • low-power mode behavior during debug
• • peripheral freeze during debug, applicable to I2Cs, IWDG, WWDG, timers, low-power timers, and LP/GPDMA channels

The DBGCMU is a TrustZone-aware peripheral, managing accesses to its control registers as described in the table below.

Table 15. TrustZone-aware DBGMCU access management

1. 1. As reported by the GTZC, the TrustZone-aware peripheral or the DMA channel.
2. 2. Secure access from the debugger is converted to nonsecure access in the device.

Refer to Section 75.12: Microcontroller debug unit (DBGMCU) for more details.

3.5.6 Activating TrustZone security

The TrustZone is deactivated by default in all STM32U5 series devices. It can be activated by setting the TZEN user option bit in FLASH_OPTR when in RDP level 0. Once TZEN has changed from 0 to 1, the default security state, after reset, is always the following:

• • CPU subsystem
  • – Cortex-M33 exits reset in secure state, hence the boot address must point toward a secure memory area.
  • – All interrupt sources are secure (in NVIC).
  • – The memory mapped viewed by the CPU through IDAU/SAU is fully secure.
• • Embedded flash memory
  • – Flash memory nonvolatile secure areas (with their HDP zone), are defined with nonvolatile registers FLASH_SECWMxR (x = 1, 2). Default secure option bytes setup is all user flash secure, without HDP area defined.
  • – Volatile block-based security attributions of the flash memory are nonsecure. The secure boot code can change this setup, making the blocks secure.
• • Embedded SRAM memories
  • – All SRAMs are secure, as defined in GTZC/MPCBB (see Section 3.5.4 ). The secure boot code can change this security setup, making the blocks secure or not.
• • External memories
  • – All memory devices connected to the FSMC and OCTOSPIs are secure, as defined in GTZC/MPCWM (see Section 3.5.4 ). The secure-boot code can change this security setup, making the components secure or not.
• • All GPIOs are secure.
• • All LP/GPDMA channels are nonsecure.
• • Backup registers are nonsecure.

• • Peripherals and GTZC:
  • – Securable peripherals are nonsecure and unprivileged.
  • – TrustZone-aware peripherals are nonsecure, with their secure configuration registers being secure.
  • – All illegal access interrupts in GTZC/TZIC are disabled.

Note: Refer to Section 3.5.4 for the list of securable and TrustZone-aware peripherals.

3.5.7 Deactivating TrustZone security

Once TrustZone is activated, it can only be deactivated during an RDP regression to level 0.

Note: Such RDP regression triggers the erase of embedded memories (SRAM2, flash memory), and the reset of all peripherals, including OTFDEC and all cryptographic engines.

After the TrustZone deactivation, most of the features mentioned in Section 3.5 are no longer available:

• • The nonvolatile secure area of the embedded flash memory is deactivated, including the HDP area.
• • The NVIC only manages nonsecure interrupts.
• • All secure registers in TrustZone-aware peripherals are RAZ/WI.

Note: When the TrustZone is deactivated, the resource isolation using privilege stays available (see Section 3.6.3 for details).

For more information, refer to the application note Arm TrustZone features for STM32L5 and STM32U5 Series (AN5347) .

3.6 Other resource isolations

These are hardware mechanisms offering an additional level of isolation on top of the TrustZone technology.

3.6.1 Temporal isolation using secure hide protection (HDP)

When the TrustZone security is enabled (TZEN = 1), the embedded flash memory allows an HDP area per watermarked-secure area of each bank (8-Kbyte page granularity) to be defined. The code executed in this HDP area, with its related data and keys, can be hidden after boot until the next system reset.

The hide protection principle is pictured on the figure below.

Figure 12. Flash memory secure HDP area

When the HDPxEN and HDPx_ACCDIS bits (x = 1, 2) are set, data read, write, and instruction fetch on the area defined by SECWMx_PSTRT and HDPx_PEND option bytes, are denied until the next device reset.

Note: Bank erase aborts when it contains a write-protected area (WRP or HDP area).
The HDP area can be resized by a secure application if the area is not hidden, and if RDP level \( \neq \) 2.

3.6.2 RSSLIB functions

The RSS provides runtime services thanks to RSS library. As other microcontroller peripherals features and mapping, the RSS library functions are exposed to user within the CMSIS device header file provided by the STM32Cube firmware package. Please refer to UM2656 to get more details regarding STM32Cube firmware package. RSS library functions are named RSSLIB functions hereafter.

The user firmware calls RSSLIB functions using RSSLIB_PFUNC C defined macro, that points to a location within nonsecure system memory. Hence prior calling RSSLIB functions, the secure user firmware must define a nonsecure region above this location within SAU of the Cortex®-M33. This nonsecure region starts from RSSLIB_SYS_FLASH_NS_PFUNC_START up to RSSLIB_SYS_FLASH_NS_PFUNC_END. These last addresses are provided within the CMSIS device header file. The user can set this nonsecure region either by using the CMSIS system partition header file or by implementing its own code for SAU setup. The CMSIS system partition header file is part of the STM32Cube firmware package.

RSSLIB functions are split between nonsecure callable and secure callable function.

The RSS library functions are described within sections hereafter.

CloseExitHDP

Bootloader ID:

CloseExitHDP1 function

Secure attribute:

Secure callable function.

Prototype:

uint32_t CloseExitHDP(uint32_t HdpArea, uint32_t
VectorTableAddr)

Arguments:

• • HdpArea:
  Input parameter, bitfield that identifies which HDP area to close. Values can be either: RSSLIB_HDP_AREA1_Msk, RSSLIB_HDP_AREA2_Msk or RSSLIB_HDP_AREA1_Msk | RSSLIB_HDP_AREA2_Msk.
• • VectorTableAddr:
  Input parameter, address of the next vector table to apply.
  The vector table format is the one used by the Cortex®-M33 core.

Description:

The user calls CloseExitHDP to close flash HDP secure memory area and jump to the reset handler embedded within the vector table which address is passed as input parameter.

CloseExitHDP sets the SP provided by the passed vector table, however it is up to the caller to first set the new vector table. Then it clears all general-purpose Cortex®-M33 registers (r0, r1, ...) before jumping to new vector table reset handler.

On successful execution, the function does not return and does not push LR onto the stack.

In case of failure (bad input parameter value), this function returns RSSLIB_ERROR.

Please refer to section Chapter 7.5.3: Secure hide protection (HDP) to get more details on flash memory HDP protection.

3.6.3 Resource isolation using Cortex privileged mode

In parallel to the TrustZone isolation described in Section 3.5 , the hardware and software resources of STM32U5 series devices can be partitioned so that they are restricted to software running in Cortex privileged mode.

Thanks to this hardware isolation technology, available even if TrustZone is deactivated (TZEN = 0), critical code or data can be protected against intentional or unintentional tampering from the more exposed unprivileged code.

Memory and peripheral privileged allocation using MPU

The Cortex-M33 MPU divides the unified memory into eight regions, each aligned to a multiple of 32 bytes. Each memory regions can be programmed to generate faults when accessed inappropriately by unprivileged software.

Memory and peripheral privileged allocation using GTZC

For the Cortex-M33 master, to complement the coarse isolation provided by the MPU, the GTZC reinforces, in a flexible way, the isolation between privileged and unprivileged tasks, for peripherals and selected memories.

For masters other than the Cortex-M33, the GTZC can assign them as unprivileged initiators, automatically protecting resources defined as privileged against this master.

• • Securing peripherals with TZSC (privileged-only)

In the devices, a peripheral is either securable privileged-only through GTZC, or is natively privileged-aware:

• – A securable privileged-only peripheral or memory is protected by an AHB/APB firewall gate that is controlled by the TZSC.
• – A privileged-aware peripheral or memory is connected directly to the AHB or APB interconnect, implementing a specific behavior such as a subset of registers or a memory area is privilege-only.

When such peripheral is made privileged-only with GTZC, if it is master on the interconnect (SDMMC), it automatically issues privileged transactions. Privileged-aware masters like GPDMA or LPDMA, drive privileged signal in the AHB interconnect according to their internal privileged mode, independently to the GTZC.

The list of securable peripherals can be found in Section 5: Global TrustZone controller (GTZC) .

• • Securing memories with TZSC and MPCBB (privileged-only)

The TZSC logic in GTZC provides the capability to manage the privilege level for all securable external memories, programming the MPCWM resources defined in Section 3.5.4 .

Similarly, the GTZC provides the capability to configure the privilege level of embedded SRAM blocks, programming the MPCBB resources defined in Section 3.5.4 .

• • Error management (privileged-only)

• – Any unprivileged transaction trying to access a privileged resource is considered as illegal. There is no illegal access event generated for illegal unprivileged read and write accesses.
• – The addressed resource follows a silent-fail behavior, returning all zero data for read and ignoring any write.
• – When an illegal unprivileged access occurs, no bus error is generated, except when this access is an instruction fetch, accessing a privileged memory or a peripheral register.

Managing security in privileged-aware peripherals

TrustZone-aware peripherals also implement privileged-only access mode. The privileged protection is valid even if TZEN = 0:

• • Embedded flash memory

By default all embedded flash registers can be read or programmed in both privileged and unprivileged modes.

When secure privileged bit SPRIV is set in FLASH_PRIVCFGGR, reading and writing the flash secure registers are possible only in privileged mode. Write access to this bit is ignored if TrustZone is deactivated (TZEN = 0).

When nonsecure privileged bit NSPRIV is set in FLASH_PRIVCFGGR, reading and writing the flash nonsecure registers are possible only in privileged mode.

Regarding privileged protection of the embedded flash memory, the devices offer the following features:

• – The system flash memory can be accessed both in privileged and unprivileged modes.
• – Each watermark-based secure area, including its secure HDP area, is accessible in secure-privileged and secure-unprivileged mode, if applicable.
• – Each 8-Kbyte page of the embedded flash memory can be programmed on-the-fly as privileged only, using the block-based privileged configuration registers FLASH_PRIV1BBRx and FLASH_PRIV2BBRx. An unprivileged page is accessible by a privileged or unprivileged access.

Note: Switching a page from privileged to unprivileged does not erase the content of the page.

When applicable, an erase or program operation is always available to privileged code, and is available to unprivileged code only for unprivileged pages or unprivileged memory.

• • On-the-fly encryption/decryption (OTFDEC)

When privileged bit PRIV is set in OTFDEC_PRIVCFGGR, the OTFDEC can only be initialized by a privileged application.

Note: OTFDEC_PRIVCFGGR can be read by both privileged and unprivileged code.

• • Direct memory access controllers (LPDMA and GPDMA)

When a DMA channel x is defined as privileged (PRIVx = 1 in LP/GPDMA_PRIVCFGGR), special rules apply when accessing privileged/unprivileged source or destination. Those rules are summarized on the table below.

Table 16. DMA channel use (privilege)

1. When a transfer is blocked, the transfer completes but the corresponding writes are ignored, and reads return zeros.

See Section 18: Low-power direct memory access controller (LPDMA) and Section 17: General purpose direct memory access controller (GPDMA) for more details.

• • Power control (PWR)

By default, after a power-on or a system reset, all PWR registers but PWR_PRIVCFGR, can be read or written in both privileged and unprivileged modes.

When secure privileged bit SPRIV is set in PWR_PRIVCFGR, reading and writing the PWR securable registers are possible only in privileged mode. Write access to this bit is ignored if TrustZone is disabled (TZEN = 0).

When nonsecure privileged bit NSPRIV is set in PWR_PRIVCFGR, reading and writing the PWR nonsecure registers are possible only in privileged mode.

See Section 10: Power control (PWR) for details.

• • Secure clock and reset (RCC)

By default, after a power-on or a system reset, all RCC registers but RCC_PRIVCFGR can be read or written in both privileged and unprivileged modes.

When the secure privileged bit SPRIV is set in RCC_PRIVCFGR, reading and writing the RCC securable bits are possible only in privileged mode. Write access to this bit is ignored if TrustZone is disabled (TZEN = 0).

When nonsecure privileged bit NSPRIV is set in RCC_PRIVCFGR, reading and writing the RCC nonsecure bits are possible only in privileged mode.

See Section 11: Reset and clock control (RCC) for details.

• • Real time clock (RTC)

By default after a backup domain reset, all RTC registers but RTC_PRIVCFGR, can be read or written in both privileged and unprivileged modes.

When PRIV bit is set in privileged-only RTC_PRIVCFGR:

• – Writing the RTC registers is possible only in privileged mode.
• – Reading the RTC_SECCFGR, RTC_PRIVCFGR, RTC_TR, RTC_DR, RTC_SSR, RTC_PRER and RTC_CALR is always possible in privileged and unprivileged modes.

All the other RTC registers can be read only in privileged mode.

When PRIV bit is cleared in privileged-only RTC_PRIVCFGR register, it is still possible to restrict access to privileged mode to some RTC registers by setting dedicated control bits: INITPRIV, CALPRIV, TSPRIV, WUTPRIV, ALRAPRV or ALRBPRIV.

See Section 63: Real-time clock (RTC) chapter for details.

• • Tamper and backup registers (TAMP)

By default after any backup domain reset, all TAMP registers but TAMP_PRIVCFGR can be read or written in both privileged and unprivileged modes.

When PRIV bit is set in privileged-only TAMP_PRIVCFGR:

• – Writing the TAMP registers is possible only in privileged mode, except for the backup registers and the monotonic counters that have their own protection setting.
• – Reading the TAMP_SECCFGR or TAMP_PRIVCFGR is always possible in privilege and unprivilege modes. All the other TAMP registers can be read only in privilege mode, except for the backup registers and the monotonic counters that have their own protection setting.

The application can also:

• – make TAMP_COUNT1R register read and write privileged-only by setting the CNTPRIV bit in TAMP_PRIVCFGR

• – increase security for two of the three protection zones in backup registers, using BKPRWPRIV and BKPWPRIV bits in TAMP_PRIVCFG:
  • – Make protection zone 1 read privileged, write privileged.
  • – Make protection zone 2 read privileged or unprivileged, write privileged.
  • – Protection zone 3 is always read and write privileged or unprivileged.
• • General-purpose I/Os (GPIO)
  All GPIO registers can be read and written by privileged and unprivileged accesses, whatever the security state (secure or nonsecure).
• • Extended interrupts and event controller (EXTI)
  The EXTI peripheral is able to protect event register bits from being modified by unprivileged accesses. The protection is individually activated per input event via the register bits in the privileged-only EXTI_PRIVCFG1 register. When an input event is configured as privileged, only a privileged application can change the configuration (including security if applicable), change the masking or clear the status of this input event.
  The security configuration in EXTI_PRIVCFG1 can be globally locked after reset in EXTI_LOCKR.
  See Section 23: Extended interrupts and event controller (EXTI) for more details.
• • System configuration controller (SYSCFG)
  All SYSCFG registers can be read and written in both privileged and unprivileged modes, except:
  – FPUSEC bit in SYSCFG_SECCFG registers (privileged only)
  – SYSCFG registers for CPU configuration: SYSCFG_CSLCKR, SYSCFG_FPUIMR and SYSCFG_CNSLCKR
  See Section 15: System configuration controller (SYSCFG) for more details.

3.7 Secure execution

Through a mix of special software and hardware features, the devices ensure the correct operation of their functions against abnormal situations caused by programmer errors, software attacks through network access or local attempt for tampering code execution.

This section describes the hardware features specifically designed for secure execution.

3.7.1 Memory protection unit (MPU)

The Cortex-M33 includes a memory protection unit (MPU) that can restrict the read and write accesses to memory regions (including regions mapped to peripherals), based on one or more of the following parameters:

• • Cortex-M33 operating mode (privileged, unprivileged)
• • data/instruction fetch

The memory map and the programming of the nonsecure and secure MPUs split memory into regions (up to eight per MPU). Secure MPU is only available when TrustZone is activated.

3.7.2 Embedded flash memory write protection

The embedded flash memory write protection (WRP) prevents illegal or unwanted write/erase to special sections of the embedded flash memory user area (system area is permanently write protected).

Write protected area is defined through the option bytes, writing the start and end addresses: two write-protected areas can be defined in each bank, with the granularity of an 8-Kbyte page.

WRP areas can be modified through option byte changes unless the corresponding FLASH_WRPxA/BR has its UNLOCK option bit cleared (meaning ROM emulation). UNLOCK can be set only when regressing from RDP level 1 to level 0.

Note: Bank erase aborts when it contains a write-protected area (WRP or HDP area).

3.7.3 Tamper detection and response

Principle

The devices include active protection of critical security assets against temperature, voltage and frequency attacks, with the following features:

• • erasure of device secrets upon tamper detection
• • improved guarantee of safe execution for the CPU and its associated security peripherals, including:
  • – out-of-range voltage (example: \( V_{BAT} \) , \( V_{DDA} \) ), temperature and clocking (LSE) detection
  • – security watchdog IWDG clocked by the internal oscillator LSI
  • – possible selection of internal oscillator HSI as system clock
• • power supply protection
  • – RTC/TAMP domain powered automatically with \( V_{DD} \) or \( V_{BAT} \)

See Section 64: Tamper and backup registers (TAMP) for more details.

Tamper detection sources

The devices support eight active input/output pins, allowing four independent active-tamper meshes, or up to seven meshes if the same output pin is shared by several input pins (for a total of eight active-tamper I/Os). The active-tamper balls are mapped in the center of packages that can be used in POS market (such as WLCSP90).

The active pins are clocked by the LSE, and are functional in all system operating modes (Run, Sleep, Stop, Standby or Shutdown), and in \( V_{BAT} \) mode.

Detection time is programmable, and a digital filtering is available (tamper triggered after two false comparison in four consecutive comparison samples).

Note: Timestamps are automatically generated when a tamper event occurs.

The internal tamper sources are listed in the table below.

Table 17. Internal tamper sources in TAMP

Response to tamper

Each source of tamper in the device can be configured to trigger the following events:

• • Generate an interrupt, capable of waking up the device from Stop and Standby modes (see TAMPxMSK bits in TAMP_CR2 register).
• • Generate a hardware trigger for the low-power timers.
• • Erase device secrets if the corresponding TAMPxNOER bit is cleared in TAMP_CR2 (for tamper pins) or TAMP_CR3 (for internal tamper). These erasable secrets are:
  • – symmetric keys stored in backup registers (x32), in SAES, AES, HASH, and OTFDEC (encrypted flash memory regions are read as zero)
  • – asymmetric keys stored in PKA SRAM, erased when V _DD is present
  • – other secrets stored in SRAM2 and CPU instruction cache memory (SRAM2 erased when V _DD is present)
  • – nonvolatile information used to derive the DHUK in SAES is zeroed until complete SRAM2 erase
  • – 2-Kbyte backup SRAM (depending on configuration bit), erased when V _DD is present
  • – ICACHE and DCACHE1 erased when V _DD is present

Read/write accesses by software to all these secrets can be blocked, by setting the BKBLOCK bit in TAMP_CR2. The device secrets access is possible only when BKBLOCK is cleared, and no tamper flag is set for any enabled tamper source.

Note: Device secret erase is also triggered by setting BKERASE in TAMP_CR2, or by performing an RDP regression as defined in Section 3.10.1 .

Device secrets are not reset by system reset or when the device wakes up from Standby mode.

Software filtering mechanism

Each tamper source can be configured not to launch an immediate erase, by setting the corresponding TAMPxNOER bit in TAMP_CR2 (for external tamper pin) or TAMP_CR3 (for internal tamper).

In such situation, when the tamper flag is raised, the access to below secrets is blocked until all tamper flags are cleared:

• • DHUK in SAES: fixed to a dummy value
• • Backup registers, backup SRAM, SRAM2: read-as-zero, write-ignored
• • AES, SAES, and HASH peripherals: automatically reset by RCC
• • PKA peripheral: reset, with memory use blocked (meaning PKA not usable)

Once the application, notified by the tamper event, analyzes the situation, there are two possible cases:

• • The application launches secrets erase with a software command (confirmed tamper).
• • The application just clears the flags to release secrets blocking (false tamper).

Note: If the tamper software fails to react to such a tamper flag, an IWDG reset triggers automatically the erase of secrets.

Tamper detection and low-power modes

The effect of low-power modes on a tamper detection are summarized on the table below.

Table 18. Effect of low-power modes on TAMP

3.8 Secure storage

A critical feature of any security system is how long-term keys are stored, protected, and provisioned. Such keys are typically used for loading a boot image, or handling of critical user data.

Figure 13 shows how the key management service application can use the AES engine, for example, to compute external image decryption keys. A nonvolatile key can be stored in the embedded secure HDP area (see Section 3.6.1 ), while volatile key storage consists in the battery-powered, tamper-protected SRAM or registers in TrustZone-aware TAMP.

Figure 13 also shows keys that are manipulated by software (like OTFDEC keys), or keys that are managed only by hardware (like DHUK). More information on those hardware keys can be found in Section 3.8.1 .

Figure 13. Key management principle

Tamper protection is detailed in Section 3.7.3 , while TAMP TrustZone features are briefly described in Section 3.5.5 .

3.8.1 Hardware secret key management

As shown in the previous figure, the devices propose a better protection for application keys, using hardware secret keys. These AES keys can be made usable to the application, without exposing them in clear-text (unencrypted). Such keys also become immediately unusable in case of tamper.

There are three different sources of hardware secret keys:

• • DHUK: derived keys based on 256-bit nonvolatile device unique secret in flash memory. The generation of this key takes into account the TrustZone state and key use state (KMOD).

Note: DHUK is the same for all devices when RDP = 0 (debug/development mode).

• • BHK: 256-bit application key stored in tamper-resistant volatile storage in TAMP
  This key is written at boot time, then read/write locked to application until next reset.
• • XORK: result of an XOR of BHK and DHUK

These keys can be used:

• • as normal key, loading in write-only key registers (software key mode)

• • as encryption/decryption key for another key, to be used in the DPA-resistant SAES (wrapped key mode)
• • as encryption/decryption key for another key, to be used in a faster AES engine (shared key mode)

3.8.2 Unique ID

The devices store a 96-bit ID that is unique to each device (see Section 76.1: Unique device ID register (96 bits) ).

Application services can use this unique identity key to identify the product in the cloud network, or make it difficult for counterfeit devices or clones to inject untrusted data into the network.

Alternatively, the 256-bit device unique key (DHUK) can be used (see Section 3.8.1 ).

3.9 Cryptographic engines

The devices implement state-of-the-art cryptographic algorithms featuring key sizes and computing protection as recommended by national security agencies such as NIST for the U.S.A, BSI for Germany or ANSSI for France. Those algorithms are used to support privacy, authentication, integrity, entropy and identity attestation.

The cryptographic engines embedded in STM32 reduce the weaknesses on the implementation of critical cryptographic functions, preventing, for example, the use of weak cryptographic algorithms and key sizes. They also enable lower processing times and lower power consumption when performing cryptographic operations, offloading those computations from Cortex-M33. This is especially true for asymmetric cryptography.

For product certification purpose, ST can provide certified device information on how these security functions are implemented and validated.

For more information on cryptographic engine processing times, refer to their respective sections in the reference manual.

3.9.1 Cryptographic engines features

Table 19 lists the accelerated cryptographic operations available in the devices. Two AES accelerators are available (both can be reserved to secure application only).

Note: Additional operations can be added using the firmware.

The PKA can accelerate asymmetric cryptographic operations (like key pair generation, ECC scalar multiplication, point on curve check). See Section 53: Public key accelerator (PKA) for more details.

1. Certifiable using STMicroelectronics reviewed documents.

2. Random numbers distribution to SAES and PKA using a dedicated hardware bus.

3. ECB and CBC chaining modes protected against side-channel and timing attacks in SAES (see Section 3.9.2 ).

4. Private key cryptography protected against side-channel and timing attacks.

Note: Binary curves, Edwards curves, and Curve25519 are not supported by the PKA.

3.9.2 Secure AES co-processor (SAES)

The devices provide an additional on-chip hardware AES encryption and decryption engine, that implements counter-measures and mitigations against power and electromagnetic side-channel attacks.

With a dedicated 48 MHz SHSI clock, SAES is also slower than the AES, in order to provide best-in-class side-channel protections. The SAES engine supports 128-bit or 256-bit key in electronic code book (ECB) or cipher block chaining (CBC) mode.

As shown in Section 3.8 , the SAES can be used for extra-secure on-chip storage for sensitive information. It can also be made secure-only.

For more information, refer to Section 50: Secure AES coprocessor (SAES) .

3.9.3 On-the-fly decryption engine (OTFDEC)

The OTFDEC TrustZone-aware peripheral proposes on-the-fly decryption of encrypted images stored on external flash memory, connected through the OCTOSPI. This decryption process introduces almost no additional cycle overhead when the standard NOR flash memory is used. The OTFDEC can also be used to encrypt flash memory images on the device (for example to encrypt with a device unique secret key).

When a tamper event is confirmed in TAMP, all OTFDEC keys are erased and encrypted regions are read as zero until the OTFDEC is properly initialized again.

An OTFDEC typical use is detailed in Section 3.12.2 . For more details on the peripheral programming, refer to Section 52: On-the-fly decryption engine (OTFDEC) .

3.10 Product life-cycle

A typical IoT device life-cycle is summarized in the figure below. For each step, the devices propose secure life-cycle management mechanisms embedded in the hardware.

Figure 14. Device life-cycle security

More details on the various phases and associated transitions, found either at the vendor or end-user premises, are summarized in the table below.

Table 20. Main product life-cycle transitions

The features described hereafter contribute to secure the device life-cycle.

3.10.1 Life-cycle management with readout protection (RDP)

The readout protection mechanism (full hardware feature) controls the access to the devices debug, test and provisioned secrets, as summarized in the table below.

Table 21. Typical product life-cycle phases

1. 1. Debug is not available when executing RSS code.
2. 2. Only applicable when TrustZone security is activated in the product.
3. 3. External flash memory area decrypted on-the-fly with the OTFDEC.

Note: OEM1KEY option byte can be modified when OEM1LOCK = 0 (RDP = 0.5 or 1 only).
OEM2KEY option byte can be modified when OEM2LOCK = 0 (RDP = 1 only).

The supported transitions, summarized in the figure below, can be requested (when available) through the debug interface or via the system bootloader.

Figure 15. RDP level transition scheme

As shown in the previous figure, the user flash memory is automatically erased, either partially or in totality, during an RDP regression from RDP1. Those regressions can be conditioned to dedicated 64-bit password keys, if provisioned by the OEM (see next subsection). During the regression from RDP level 1 to RDP level 0.5, only nonsecure embedded flash memory is erased, keeping functional, for example, the secure boot and the secure firmware update. In all regressions from level 1, the OTP area in the flash memory is kept, all SRAMS and targeted device secrets are erased. Hence, no secrets must be stored in the OTP as they are revealed after a regression to RDP level 0. These secrets, also erased as response to tamper, are defined in Section 3.7.3 .

Note: Enabling TrustZone using the option byte TZEN is only possible when RDP level is 0.

For more details on RDP, refer to Section 7: Embedded flash memory (FLASH) .

RDP unlocking sequences

The use of the two OEM password keys described in the last figure is further described hereafter.

Note: The devices support both permanent RDP level 2 (legacy mode) or password-based RDP level 2 regression to level 1. This level 2 regression does not erase the application code, and it does not change the RDP level 1 protections in place.

Details on the password-based regression can be found in the table below.

Table 22. OEM1/2 RDP unlocking methods

• • OEM1 unlock sequence, starting at RDP level 1:
  • – Shift the password key through JTAG/SWD (see the note below).
  • – If this key matches the OEM1KEY provisioned in the device, the application can trigger a regression sequence to level 0. After the regression is completed, the whole embedded flash memory and device secrets are erased. The OTP area is not erased.
  • – In case of mismatch value, the RDP regression is blocked and RDP level 1 protections are enforced until the next power-on reset.
• • OEM2.1 unlock sequence, starting at RDP level 1:
  • – Shift the password key through JTAG/SWD under reset (see the note below).
  • – If this key matches the OEM2KEY provisioned in the device, the application can trigger a regression sequence to level 0.5. After the regression is completed, the nonsecure embedded flash memory and device secrets are erased. The OTP area is not erased.
  • – In case of mismatch value, the RDP regression is blocked and RDP level 1 protections are enforced until the next power-on reset.
• • OEM2.2 unlock sequence, starting at RDP level 2:
  • – Shift the password key through JTAG/SWD under reset (see the note below).
  • – If this key matches the OEM2KEY provisioned in the device, the device automatically triggers a regression sequence to level 1. After the regression is completed, a power-on reset has to be performed by the user.
  • – In case of mismatch value, the RDP regression is blocked and RDP level 2 protections are enforced until the next power-on reset.

Note: Unlocking the device with a password is possible only once per power cycle. Shifting the password key through JTAG/SWD corresponds to writing two 32-bit key words, AUTH_KEY[31:0], then AUTH_KEY[63:32], in the DBGMCU_DBG_AUTH_HOST register.

JTAG 32-bit device specific ID

Unless the JTAG port is deactivated (OEM2LOCK = 0 and RDP level = 2), a 32-bit device specific quantity can always be read through the JTAG port. This information is stored in DBGMCU_DBG_AUTH_DEVICE.

The OEM can use this 32-bit information to derive the expected OEM password keys to unlock this specific device.

3.10.2 Recommended option-byte settings

Most of the time, the user threat model focuses mainly on software attacks. In this case, it may be sufficient to keep the RDP level 1 as device protection.

For a more aggressive threat model, where the user fears physical attacks on the STM32 device, it is recommended to optimize the level of security by setting the RDP level 2.

The recommended settings are detailed below:

• • If TrustZone is disabled (TZEN = 0)
  • – RDP level 2
  • – nonsecure boot address option bytes set in user flash memory
• • If TrustZone is enabled (TZEN = 1)
  • – RDP level 2
  • – BOOT_LOCK = 1
  • – secure boot address option bytes set in user secure flash memory

As described in the previous section, the customer can decide to allow any RDP level 2 part to regress to RDP level 1, provided the OEM Key2 has been successfully provisioned, and the OEM2LOCK option bit is set.

3.11 Access controlled debug

The device restricts access to embedded debug features, in order to guarantee the confidentiality of customer assets against unauthorized usage of debug and trace features.

3.11.1 Debug protection with readout protection (RDP)

As described in Section 3.10.1 , the hardware RDP mechanism automatically controls the accesses to the device debug and test. The protection of these debug features is defined in the table below. Possible password-based regressions are described in Section 3.10.1 .

Table 23. Debug protection with RDP

1. 1. Including ST engineering test modes, used for field returns.
2. 2. Only applicable when TrustZone security is activated in the product.
3. 3. External flash memory area decrypted on-the-fly with the OTFDEC.

3.12 Software intellectual property protection and collaborative development

Thanks to the software intellectual property protection and collaborative model, the devices allow the design of solutions integrating innovative third-party libraries.

Collaborative development is summarized on the figure below. Starting from a personalized device sold by STMicroelectronics, a vendor A can integrate a portion of hardware and software on a platform A, that can then be used by a vendor B, who does the same before deploying a final product to the end users.

Note: Each platform vendor can provision individual platforms for development not to be connected to a production cloud network (“Development Platform X”).

Figure 16. Collaborative development principle

graph TD; subgraph Vendor_states; A[STM32 personalized device] -- "Vendor A manufacturing" --> PA[Platform A]; PA -- "Vendor B manufacturing" --> PB[Platform B]; PA -- "Integrated" --> PP1[Platform part]; PB -- "Integrated" --> PP2[Platform part]; end; subgraph User_states; PA -- "User provisioning" --> DPB1[Development platform B]; PB -- "User provisioning" --> DPB2[Development platform B]; PB -- "Productization" --> DP[Deployed product]; DP -- "Decommissioning" --> DPP[Decommissioned product]; end;

The features described hereafter contribute to securing the software intellectual property within such a collaborative development.

3.12.1 Software intellectual property protection with RDP

As described in Section 3.10.1 , the hardware RDP mechanism automatically controls the accesses to secrets provisioned in the device.

The protection of these secrets are defined in the table below.

Table 24. Software intellectual property protection with RDP

1. Only applicable when TrustZone security is activated in the product.

2. External flash memory area decrypted on-the-fly with OTFDEC peripheral.

3.12.2 Software intellectual property protection with OTFDEC

As described in Section 3.9.3 , the OTFDEC associated with the OCTOSPI is able to decrypt on the fly, the encrypted images stored in external SPI flash memories.

Thanks to this feature, the devices allow the installation of intellectual properties, in one of the following ways:

• • over the air, with the image already encrypted with a key provisioned in the device
• • through a provisioning host located in a trusted or a non-trusted environment/facility

Figure 17 illustrates this last case, with the provisioning, in a non-trusted environment, of software intellectual properties both in the embedded flash memory and in an external SPI flash memory (encrypted).

Note: Since the OTFDEC uses the AES in counter mode (CTR) to achieve the lowest possible latency, each time the content of one encrypted region is changed, the corresponding cryptographic context (key or initialization vector) must be changed. This constraint makes OTFDEC suitable to decrypt read-only data or code, stored in external NOR flash memory.

Figure 17. External flash memory protection using SFI

Provisioning

Assuming the device is virgin, the first step is to provision both flash memories, as detailed below:

1. 1. The user creates a SFI image, composed of:
   • – encrypted internal firmware and data (including external flash memory drivers)
   • – encrypted external firmware and data AES key (up to 4)
   • – encrypted external firmware and data image
2. 2. The secure bootloader stored in the system memory, loads the second part of the secure bootloader in SRAM, through the supported communication ports (USART, SPI, I ² C, FDCAN, USB, and JTAG). This second part runs in the secure SRAM and is responsible for executing the SFI process, applying the SFI protocol thanks to the commands received through the above mentioned supported communication ports.

1. 3. The internal flash memory is programmed with decrypted option bytes, internal firmware and data, and external firmware and data AES keys. Alternatively, device unique external firmware AES keys can be used instead of such global keys.
2. 4. The OTFDEC is properly initialized with encrypted region information, including the corresponding external firmware and data AES key.
3. 5. Running the SFI process, chunks of encrypted external firmware and data image are decrypted in the device, then re-encrypted in the OTFDEC.
4. 6. After a chunk OTFDEC re-encryption, the user external flash memory programmer is responsible for programming the last encrypted chunks to the external SPI flash memories through the OCTOSPI.

Alternatively, external firmware and data AES keys for OTFDEC can be generated on the device, if they are not generated by the signing tool.

Secure boot

After provisioning, each time the device initializes on a trusted firmware, the following actions are required:

1. 1. Secure-boot firmware executes, programming the external firmware and data AES keys to the OTFDEC write-only key registers, along with the other needed information.
2. 2. The application reads or executes the encrypted external firmware and data through the OCTOSPI in memory mapped mode, unless a tamper event is detected. In this case, all OTFDEC keys are erased and encrypted regions are read as zero until the OTFDEC is properly initialized again.

For more information on SFI solutions for the devices, refer to the application note: “STM32 MCUs secure firmware install (SFI) overview ” (AN4992).

3.12.3 Other software intellectual property protections

The device additional protections to software intellectual property are:

• • Invasive attacks such as physical tampering or perturbation are countered by detection then decommissioning of the device before the detected attack succeeds.
• • Non-invasive attacks, such as side channel attacks, are countered by not leaking secret information via side channels such as timing, power, and EM emissions.