Secure hide protection (HDP)

Some STM32 devices support the HDP memory concept. The HDP, named secure hide protection first on STM32L5 devices, is also known as secure user memory on STM32H7 devices, or securable memory on STM32G0 devices.

An HDP area is a part of the user flash memory that can be accessed only once, just after a device reset. The HDP targets sensitive applications that embed or manipulate confidential data, and that must be securely executed at boot. Once the transition is executed, the HDP area is closed, and cannot be accessed anymore by any means (see the figure below).

The code that facilitates the HDP transition is usually a STMicroelectronics code located in the RSS. Code in SRAM is an alternative.

Figure 10. HDP protected firmware access

The HDP is a static protection configured by option bytes. Once set, the CPU boots on the firmware embedded in this area, independent of the boot configuration set by boot pin or boot address. HDP can be single stage or use a monotonic counter to gradually cover more memory as the secure boot progresses (STM32H5). Some devices implement a dynamic HDP expansion. This means that the HDP can be extended by the number of sectors using the register value, without programming the OB (STM32H5, STM32U0).

When to use the HDP

The HDP is suited for a code that must only be executed after reset, like secure boot for root of trust. It should be used in synergy with the boot lock feature.

Note:

The HDP is available in STM32H7, STM32G0, STM32G4, STM32L5, STM32N6, STM32U0, STM32U3, STM32U5, and STM32H5 devices, with slight differences in its implementation and name (refer to the reference manuals for details).

Firewall

The firewall is a hardware protection peripheral controlling the bus transactions and filtering accesses to three particular areas: a code area (flash memory), a volatile data area (SRAM) and a nonvolatile data area (flash memory). The protected code is accessible through a single entry point (the call-gate mechanism explained below). Any attempt to jump and try to execute any of the functions included in the code section without passing through the entry point, generates a system reset.

The firewall is part of the dynamic protections. It must be set at startup (for example by an SB application).

Call gate mechanism

The firewall is opened by calling a 'call-gate' mechanism: a single entry point that must be used to open the gate, and to execute the code protected by the firewall. If the protected code is accessed without passing through the call gate mechanism, then a system reset is generated. If any instruction is fetched outside the protected area, the firewall is closed (see the figure below).

Since the only way to respect the call gate sequence is to pass through the single call gate entry point, a mechanism must be provided in order to support application calling multiple firewall-protected functions from unprotected code area (such as encrypt and decrypt functions). A parameter can be used to specify which function to execute (such as CallGate(F1_ID) or CallGate(F2_ID)). According to the parameter, the right function is internally called. This mechanism is represented in the figure below.

When to use the firewall

The firewall protects both code and data. The protected code can always be called as long as a call gate mechanism is respected.

Note:

A firewall is available on STM32L0 and STM32L4 devices only. Refer to the application note AN4730 for more details. The firewall functionality is replaced by TrustZone.

Memory protection unit (MPU)

The MPU is a memory protection mechanism that allows specific access rights to be defined for any memory‑mapped resource of the device: flash memory, SRAM, and peripheral registers. This protection is dynamically managed at runtime.

Note:

MPU attributes are only set for CPU access. Other bus master requests (such as DMA) are not filtered by the MPU, and must be deactivated if they are not needed.

Region access attributes

The MPU splits the memory map into several regions, each having its own access attribute. Access right can be set as executable, not executable(XN), read-write (RW), read only (RO), or no access.

Note:

There are other attributes set by the MPU for each region: shareable, cacheable, and bufferable. This application note does not cover the whole complexity of the MPU. This section provides only an introduction and high‑level overview. Refer to applicable programming manual, or to the document AN5156_General-Info.html#concept_vts_yqx_fcb__entry_ilk_brz_qvb.

Privileged and unprivileged modes

On top of the access attribute, the Arm Cortex-M architecture defines two execution modes, allowing a process to run in either privileged or unprivileged mode. For each region, the access attribute can be set independently for each mode.

The table below shows the different cases supported by mixing modes and access attributes.

Table 15. Attributes and access permission managed by MPU
Privileged mode attribute	Unprivileged mode attribute	Description
Execute never (XN)⁽¹⁾		Code execution attribute
No access	No access	All accesses generate a permission fault.
RW	No access	Access from a privileged software only
RW	RO	Written by an unprivileged software generate a permission fault.
RW	RW	Full access
RO	No access	Read by a privileged software only
RO	RO	Read only, by privileged or unprivileged software

The code executed in privileged mode can access additional specific instructions (MRS), and can also access Arm® core peripheral registers (such as NVIC, DWT, or SBC). This is useful for OS kernels or pieces of secure code requiring access to sensitive resources that are otherwise inaccessible to unprivileged firmware.

Secure process isolation strategy

At reset, the privileged mode is the default one for any process. The SB application is then executed in privileged mode. The idea is to isolate secure processes (such as SB, OS kernel, key manager, or SFU) from unsecured or untrusted processes (user applications).

Table 16. Process isolation
Firmware type	Mode	Resources access
Secure firmware (such as SB or OS kernel)	Privileged	Full access
All remaining firmware	Unprivileged	MPU controlled access: no access, RO, RW

An OS kernel can manipulate MPU attributes dynamically to grant access to specific resources depending on the currently running task. Access right can be updated each time the OS switches from one task to another.

When to use the MPU

The MPU is used at runtime to isolate sensitive code, and/or to manage access to resources depending on the process currently executed by the device. This feature is useful especially for advanced embedded operating systems that incorporate security in their design.

Note:

The MPU is available on all STM32 devices except the STM32F0 (see the various programming manuals for more details).

¹ XN attribute is set by region, and is valid for both modes. It can be used to avoid SRAM code injection for example.

Resource isolation framework (RIF)

The RIF represents a complex system of address filtering logic that is embedded into the central bus matrix of the device. It can implement various rules for isolation between application code, data, and other resources in a multi-tenant secure OS. The RIF is complementing the TrustZone® system of SAU/IDAU isolation rules, known from other devices.

The configuration is volatile and set during the secure boot, and then fixed in place until the next boot.

In STM32N6, the RIF consists of RIFSC, RISAF, and IAC parts.

For more information, refer to the following wiki article: https://wiki.st.com/stm32mcu/wiki/Security:Resource_Isolation_Framework_(RIF)_overview_for_STM32N6

RAM and integrity secure area firewall (RISAF)

RISAF controls access to a protected address space based on the target address and the bus master that initiates the access. It is controlled by the privileged secure domain.

Peripherals integrated in the MCU that can act as bus masters, such as complex DMA controllers, manage their own RIF alignment. Other resources have their RIF configuration defined by the RIFSC.

The IAC is invoked when an illegal access is detected. It manages the security exception with the secure framework.

Customer key storage (CKS)

STM32WB series are dual-core devices with one core (CPU1) for user application, and another core (CPU2) dedicated to the wireless real-time aspect execution (either Bluetooth^® LE, ZigBee, or thread protocols). The flash memory used by CPU2 is isolated from the CPU1 or external access. Communication between the two cores is ensured by a mailbox and an interprocess channel control hardware block (IPCC).

In addition to the wireless stack execution, the CPU2 offers a secure storage service for cryptographic keys used with a dedicated AES hardware peripheral (see Figure 13 Dual-core architecture with CKS service). The AES key register is accessible only to the CPU2, preventing access to the key by an untrusted process running on the CPU1, or by the debug port.

After the keys have been provisioned inside the secure area, the user application can use them by calling a secure load service with an index referencing the key and no more the key itself.

Figure 13. Dual-core architecture with CKS service

When to use the CKS

The CKS must be used when a user application relies on AES encryption or decryption. Provisioned keys can be stored in a secure area, so that no other internal process or external access can read their value.

Note:

The CKS is available on STM32WB series only.