3. System security

The STM32U3 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 STM32U3 series devices.

Note: CCB, SAES, AES, and full feature PKA peripherals are only available on STM32U385/3C5 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, I2C, I3C, 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, CBC, CTR, GCM and CCM chaining modes with side-channel counter-measures and mitigations
  • – HASH processor, supporting 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
  • – Coupling and chaining bridge (CCB) for special coupling and chaining operations (involving PKA, SAES, RNG peripherals) to protect private keys used in PKA protected operations.
• • 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 and RDP level 0.5
• • External tamper detection and protection against frequency attacks
  • – Five passive inputs, 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 in the internal 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: Overview secure firmware install (SFI) (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.

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 option bytes of FLASH_SBOOT0R.

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 of FLASH_SBOOT0R 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 SFI, allowing secure and counted installation of OEM firmware in untrusted production environment (such as 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 option bytes of FLASH_SBOOT0R are 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 STM32U3 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 5. 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 STM32U3 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 (twelve 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 6 , 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.

Figure 6 shows the 32-bit address space viewed after the SAU configuration by the secure code.

Figure 6. 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 Figure 7).

Figure 7. 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 6. 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 Table 6 .

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 Arm TrustZone features for STM32L5, STM32U3, 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 8. Global TrustZone framework and TrustZone awareness

Securing peripherals

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

• • 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.2 ). In this case, if this peripheral is master on the interconnect, it automatically issues privileged transactions.

Securing memories with TZSC and MPCBB

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

Default security configuration is secure privileged when TrustZone is activated on the device, nonsecure unprivileged otherwise.

The MPCBB has block size of 512 Bytes. Super-blocks are groups of 32 consecutive block (that is with a size of 16 Kbytes) used to lock the configuration.

For details please refer to Section 5: Global TrustZone controller (GTZC) .

On STM32U3B5/3C5 devices, the MPCBB4 protects the physical 64-Kbyte SRAM4 and the following 16 Kbytes which correspond to the BRAM-AB dual port address remapping (refer to Section 19: Hardware signal processor (HSP) ). If HSP1 is used or not, each SRAM4 BRAM-AB block must have the same security and privilege attributes as the corresponding BRAM-A or BRAM-B block with the highest security and privilege policy.

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 size can be changed by a secure software. This software 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.

On STM32U3B5/3C5 devices, HSP1 peripheral can directly access the SRAM4. HSP1 peripheral transactions do not go through the bus matrix and MPCBB4 security policies are not applied to them. The software must ensure the consistency of the security and privilege attributes of HSP1 and SRAM4:

• • When the HSP1 peripheral is used in the application, the security and privilege attributes defined in MPCBB4 of every SRAM4 block must be the same as the security and privilege attributes of the HSP1 peripheral defined in TZSC1.
• • When the HSP1 peripheral is not used in the application, security and privilege attributes of the HSP1 peripheral defined in TZSC1 must be the same as the SRAM4 block with highest security and privilege policy.

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) .

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

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.2 ).

On STM32U3B5/3C5 devices, the overall FDCAN SRAM address space (2 Kbytes):

• • Is secured if and only if all instances have been configured as secured.
• • Always has the same security and privilege attributes (that is the attributes of the 1 ^st Kbyte are the same as those of the 2 ^nd Kbyte)

TrustZone-aware peripherals

The devices include the following TrustZone-aware peripherals:

• • GPIOA to GPIOH
• • GTZCx_MPCBB, GTZCx_TZIC and GTZCx_TZSC (GTZC blocks)
• • EXTI
• • Flash memory
• • RCC and PWR
• • GPDMA
• • SYSCFG registers
• • RTC and TAMP
• • MCU debug unit DBGMCU

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 Figure 9 , 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 9. Flash memory TrustZone protections

As shown in Section 7: Embedded flash memory (FLASH) , 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 modifies the HDPx_ACCDIS byte to a value different than the reset value, data read, write, and instruction fetch on this HDP area are 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.

Direct memory access controllers (GPDMA)

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

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

Table 7. 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 GPDMA_SECCFGR, GPDMA_PRIVCFGR, and 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 GPDMA_SECCFGR and GPDMA_RCFGLOCKR must be secure. For each bit in GPDMA_PRIVCFGR, write must be secure if the corresponding bit in 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 15: 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 definition
• • 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.

See Section 9: 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 10: 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 46: 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 47: 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 8. Secure alternate function between peripherals and allocated I/Os

The following table lists peripherals which, when nonsecure, cannot be connected to secure I/Os configured for an analog function with analog switch, thanks to hardware that blocks such connections.

Table 9. Nonsecure peripherals not connectable to secure I/Os

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

2. LCD is available only on STM32U356/366 devices.

Finally, regarding GPIO and security, Table 10 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 Table 10 , 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 Table 10 .

Table 10. Nonsecure peripherals connectable 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 12: 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 17: 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 13: 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 GPDMA channels

The DBGMCU is a TrustZone-aware peripheral, managing accesses to its control registers as described in Table 11 .

Table 11. TrustZone-aware DBGMCU access management

1. As reported by the GTZC, the TrustZone-aware peripheral or the DMA channel.

2. Secure access from the debugger is converted to nonsecure access in the device.

Refer to Section 57: Debug support (DBG) for more details.

3.5.6 Activating TrustZone security

The TrustZone is deactivated by default in all STM32U3 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 are nonsecure
• • All GPIOs are secure.
• • All 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 (All SRAMs except SRAM4, flash memory), and the reset of all peripherals, including 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.2 for details).

For more information, refer to the application note Arm TrustZone features for STM32L5, STM32U3, 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 (4-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 in Figure 10 .

Figure 10. Flash memory secure HDP area

When the HDP _x (x=1,2) area is enabled and the corresponding HDP _x _ACCDIS byte is different than its reset value 0xA3, data read, write and instruction fetch on the area defined by SECWM _x _STRT and HDP _x _END option bytes, are denied until the next device reset. The end of the HDP _x areas can be extended (dynamically by the application) thanks to FLASH_SECHDPEXTR register. Refer to Section 7.5.3: Secure hide protection (HDP) and Section 7.5.4: Secure hide protection extension (HDP extension) for details.

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 ≠ 2.

3.6.2 Resource isolation using Cortex privileged mode

In parallel to the TrustZone isolation described in Section 3.5 , the hardware and software resources of STM32U3 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. Privilege-aware masters like GPDMA, 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) .

On STM32U3B5/3C5 devices, the overall FDCAN SRAM address space (2 Kbytes) is privileged if and only if all instances have been configured as privileged.

Securing memories with TZSC and MPCBB (privileged-only)

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 PRIV 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 4-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.

Direct memory access controllers (GPDMA)

When a DMA channel x is defined as privileged (PRIVx = 1 in GPDMA_PRIVCFGR), special rules apply when accessing privileged/unprivileged source or destination. Those rules are summarized in Table 12 .

Table 12. 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 15: 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 9: 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_PRIVCFGGR, reading and writing the RCC nonsecure bits are possible only in privileged mode.

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

Real time clock (RTC)

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

When PRIV bit is set in privileged-only RTC_PRIVCFGGR:

Writing the RTC registers is possible only in privileged mode.

Reading the RTC_SECCFGR, RTC_PRIVCFGGR, 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_PRIVCFGGR 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 46: Real-time clock (RTC) chapter for details.

Tamper and backup registers (TAMP)

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

When PRIV bit is set in privileged-only TAMP_PRIVCFGGR:

• • 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_PRIVCFGGR 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_PRIVCFGGR
• • increase security for two of the three protection zones in backup registers, using BKPRWPRIV and BKPWPRIV bits in TAMP_PRIVCFGGR:
  • – 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_PRIVCFGGR1 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 17: 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_SECCFGR registers (privileged only)
• • SYSCFG registers for CPU configuration: SYSCFG_CSLOCKR, SYSCFG_FPUIMR and SYSCFG_CNSLCKR

See Section 13: 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 for the nonsecure, and up to twelve for the Trustzone). 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 a 4-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

Tamper detection sources

The devices support five input pins, allowing five static tamper inputs.

The tamper detection is functional in all system operating modes (Run, Sleep, Stop, Standby, or Shutdown), and in \( V_{BAT} \) mode.

Two modes are supported: edge detection, for which no clock is needed, and level detection with filtering. In this last case, the filtering is performed using either LSI or LSE clock (only LSE is available in Shutdown and \( V_{BAT} \) modes), and the tamper detection event is generated when either 2, 4 or 8 consecutive samples are observed at the selected level.

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

The internal tamper sources are listed in Table 493: TAMP interconnection . Refer to Section 47: Tamper and backup registers (TAMP) for more details.

Response to tamperers

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 TAMPxPOM 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 CCB
  • – 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
  • – ICACHE 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 TAMPxPOM bit in TAMP_CR2 (for external tamper pin) or TAMP_CR3 (for internal tamper).

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

• • DHUK in SAES: fixed to a dummy value
• • Backup registers, SRAM2: read-as-zero, write-ignored

• • AES, SAES, CCB, 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 in Table 497: 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 11 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 11 also shows keys that are manipulated by software, 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 11. 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, also known as Root Hardware Unique Key (RHUK). 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 58.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 (RHUK) 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 13 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 36: Public key accelerator (PKA) for more details.

Table 13. Accelerated-cryptographic operations

Table 13. Accelerated-cryptographic operations (continued)

1. 1. Certifiable using STMicroelectronics reviewed documents.
2. 2. Random numbers distribution to SAES and PKA using a dedicated hardware bus.
3. 3. Protected against side-channel and timing attacks in SAES (see Section 3.9.2 ).
4. 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 sidechannel attacks.

Clocked by the AHB bus clock and a dedicated kernel clock, SAES is slower than the AES, in order to provide best-in-class side-channel protections. The SAES engine supports 128-bit or 256bit key in electronic code book (ECB), cipher block chaining (CBC), (CTR), (GCM), (CCM), (GMAC) modes.

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 34: Secure AES coprocessor (SAES) .

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 12. 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 Table 14 .

Table 14. 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 Table 15 .

Table 15. Typical product life-cycle phases

1. Debug is not available when executing RSS code.

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

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

Figure 13. 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 128-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, except SRAM4, and targeted device secrets are erased. Hence, no secrets must be stored in the OTP, and the SRAM4, 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 Table 16 .

Table 16. OEM1/2 RDP unlocking methods

Note: RDP regression with OEM key is described in section OEM1 RDP lock mechanism and OEM2 RDP lock mechanism .

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 Table 17 . Possible password-based regressions are described in Section 3.10.1 .

Table 17. 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.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 14. Collaborative development principle

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 Table 18 .

Table 18. Software intellectual property protection with RDP

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

3.12.2 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.