Life cycle management–product state

The addition of RDP 0.5 into the RDP mechanism used by the STM32 enabled the necessary isolation between secure and nonsecure development. However, the RDP does not allow going further in the user experience with the adoption of new development and OEM manufacturing models. The RDP has been replaced by the product state, a more refined life cycle management system, on the STM32H5 devices as a pilot project. The product state is also an answer to the needs of customers requesting a state that is effectively an RDP2 to the outside world and it allows them to perform a regression in the controlled environment. A similar provision was also added to the STM32U5 series, but the product state enabled finer control over delegating the debugging rights in TrustZone enabled products. It is sufficient for microcontrollers with no TrustZone isolation to use fewer states, for example, the STM32H7Rx/7Sx, which implement the product state this way.

For applications that do not need these new options, there are still product states corresponding to the original RDP values.

If the secure boot firmware is located in the user flash, it is important to prevent the attacker from diverting the boot sequence from the intended progression. This is the goal of the unique boot entry or BOOT_LOCK.

The RDP2 on some products prevent booting from other memory. The BOOT_LOCK goes further by also working in RDP1 and working with the product state life-cycle management. In some devices the BOOT_LOCK allows the possibility to lock the boot to a specific address.

Even if RDP2 is set; the unique boot entry provides additional security assurance against glitch attacks.

A unique boot entry is available on STM32Ux, STM32Gx, STM32Hx, STM32Cx series, and in STM32WBA wireless devices. Implementation details are available in each device reference manual, on the sections about boot configuration and flash.

The OTP is a dedicated, isolated area in the flash memory, which can be only written on or locked out, preventing any modification. It is usually a smaller area compared to the size of the user flash memory.

This feature is very useful for lifecycle management, provisioning, personalization, or configuration. Once the OTP is written, there is no method of erasing data without physically damaging the device. No restriction is implicitly put on reading written data.

On the STM32N6 series flashless microcontroller, the boot security and product state management are implemented using a large (12k) array of OTP fuses and data.

It is connected via core logic with debug interface, crypto, system bus, ST boot ROM, and clock control.

This system allows setting a 128-bit strong protection on debug access and product state including protection of the external program memory.

The OTP nature means increased security compared to regular flash memory, with acceptable drawback of limiting the re-usability of once provisioned device. OTP password were also used in product state protection on other popular devices.

Boot security is implemented so that the STM32N6 always boots in the ST boot ROM, which uses the OTP settings to execute the boot progression in configured manner.

This section describes the main features of the TrustZone® architecture. For further information, refer to the application note Arm® TrustZone® features on STM32L5 and STM32U5 series (AN5347), and to the device reference manual.

The Armv8-M TrustZone® architecture defines two domains at system level: secure and nonsecure. The full memory-map space is split into secure and nonsecure areas. This includes all memory types (flash memory, SRAM, and external memories), as well as all peripherals that can be shared (with specific context for each domain) or dedicated to one domain or the other.

The core state depends on the region of the current running code. When the code runs from a secure region, the core is in secure state. Otherwise, the core is in nonsecure state.

The SAU is a hardware unit coupled to the core (as the MPU). The SAU is responsible for setting the security attribute of the AHB/AXI transaction. The security attribute of a transaction is fixed by the targeted address of a memory-mapped resource (memory areas or peripherals). Depending on the SAU configuration, an address is tagged as secure, nonsecure callable (NSC), or nonsecure. The NSC is a subdomain of the secure domain that allows a gateway to be defined for nonsecure code to access the secure domain at a specific entry point.

The SAU is configurable by secure firmware. It can be configured at boot for a fixed configuration, or can be dynamically modified by a secure firmware.

Address aliasing

The security attribute is set depending on the fixed resource address. However, a memory‑mapped resource can be set either as secure or nonsecure, depending on the application. To overcome this apparent contradiction, two addresses are assigned to each memory-mapped resource: one used when the resource must be accessed in secure mode, one used in nonsecure mode. This mechanism is called address aliasing.

Refer to device reference manual for the detailed configuration.

The SAU defines the transaction security attribute, and the bus infrastructure propagates this attribute towards the targets. The targets (memories and peripherals) are protected by hardware mechanisms that filter the access depending on the secure and privileged attributes.

TrustZone®-aware peripherals are the ones with a bus master role (DMAs), the GTZC, the flash memory controller, and others peripherals with a fundamental role within the system (PWR, RTC, system configuration). The remaining system peripherals are securable.

The write protection feature is used to protect the content of the specified memory area against erase or update.

For flash memory technology, an update must be considered as filling with zeros.

For instance, the write protection can be set on a page or a sector of a flash memory to prevent its alteration during a firmware or data update. It can also be set by default on the unused memory area to prevent any malware injection. Its granularity is linked to the page or sector size.

When to use the WRP

Part of the STM32 flash memory can be configured with an 'execute-only' attribute. The firmware stored in such configured area can only be fetched by the CPU instruction bus. Any attempt to read or write this area is forbidden. The protection applies against both internal (firmware) accesses as well as external (debug port) accesses. In an STM32 device, this feature is named proprietary code readout protection (PCROP).

The PCROP is a static protection set by option bytes. The number of protected areas and their granularity depends on the STM32 device (see Security features by STM32 devices). When the PCROP is in use, care must be taken to compile the firmware with the execute-only attribute (refer to user compiler options). Refer to the document AN5156_General-Info.html#concept_vts_yqx_fcb__entry_jh2_brz_qvb for more details.

In particular, the ARMv6-M instruction set has difficulty working with this constraint. The compiler must be set not to place constants and literal pools within the program, otherwise even the code execution can eventually trigger the protection.

When to use the PCROP

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.

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