Security with STM32U3

This article contains an overview of the security features^[1] available on STM32U3 MCUs. The table below contains detailed information based on the different product lines.

Security features embedded on:	STM32U375	STM32U385
Secure Boot and Firmware Update
OEMiRoT_OEMuRoT
Application Isolation
TF-M
Secure Manager
Cryptography
ST crypto lib
Crypto libraries
Silicon device life cycle
RDP with regression
Product state
Debug authentication
Secure manufacturing
SFI

(1) Only on demand

1. Secure Boot and Firmware Update↑

When the code of a product needs securing, it becomes necessary to embed a Root of Trust (RoT). This RoT ensures the next stage of security ensuring the code integrity and its authenticity. By definition, a RoT must be based on an immutable code handling the reset of the platform. The RoT is the foundation to build a secure product.

On the STM32U3 devices, the Root of trust is based on the unique boot entry and the temporal isolation features allowing to design robust secure boot solutions.

1.1. OEMiRoT_OEMuRoT↑

OEMiRoT stands for OEM immutable Root of Trust and acts as a first boot stage. It is based on the MCUboot open-source software^[2] provided with the STM32CubeU3.

OEMiRoT_OEMuRoT offers two services:

The Secure Boot (root of trust service) is an immutable code, which is always executed after a system reset. It checks static protections (option bytes), activates runtime protections, and verifies the authenticity and integrity of the user application code before every execution.
The Secure Firmware Update application is an immutable code that detects new firmware image candidates. It checks the version (version downgrade prevention), authenticity, and integrity before installing it after decryption.

OEMuRoT stands for OEM updatable (unchangeable) Root of Trust. OEMuRoT acts as a second boot stage after OEMiRoT and provides the same two services: Secure boot and secure firmware update.

OEMiRoT OEMuRoT for STM32U3 detailed

2. Unique Boot Entry↑

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, 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 user flash address defined by FLASH_SBOOT0R option bytes. All these option bytes cannot be modified by the application anymore when BOOT_LOCK is set.

For more information on the boot mechanisms, refer to the STM32U3 reference manual (RM0487^[3]) Section4: Boot modes.

3. Application Isolation↑

To support the protection of the assets from unrelated processes, several means of isolation are available on the STM32U3 MCUs.

TrustZone® facilitates protection in runtime, when secure and nonsecure coexist and take turns in executing code on the CPU core. Temporal isolation on the other hand protects the boot code from being reentered in any other way than by reset.

3.1. Temporal isolation↑

The temporal isolation is implemented thanks to the Hide Protect area (HDP). The main purpose of the HDP is to protect a specific part of the flash memory against undesired access. Following a system reset, the code in the HDP area is executable only until this area is hidden. It remains inaccessible until a system reset occurs. This allows implementing software security services with root parameters including secret parameters owned only by the secure boot.

The HDP area can be extended though a dedicated volatile register indicating the number of supplementary pages added to the securable memory area.

3.2. TF-M↑

Trusted firmware-M is a security framework proposing a solution to among else Secure Boot and secure field upgrade on embedded devices with special focus on IoT applications^[4]^[5].

3.3. Secure Manager↑

Secure Manager is an easy-to-use proprietary implementation of the PSA API. By using the Secure Manager, the user benefits straight away from an easy-to-use certified security, without the need for an additional investment^[6].

4. Cryptography↑

The means of performing cryptography depends on the STM32U3 product line.

Cryptography features embedded on:	STM32U375	STM32U385
Hardware AES	NO	YES
Hardware HASH	YES	YES
Hardware SAES	NO	YES
Hardware PKA	NO	YES
Hardware CCB	NO	YES
ST crypto lib	YES	YES
Crypto libraries	YES	YES

4.1. CCB↑

The CCB (coupling and chaining bridge) peripheral can be programmed to implement special coupling and chaining operations required to protect private keys used in PKA protected operations. These coupling and chaining operations involve the PKA, the SAES, and sometimes the RNG peripherals. For further details, refer to AN6205 and to the STM32U3 reference manual (RM0487^[7]) Section 29: Coupling and chaining bridge (CCB).

4.2. ST crypto lib↑

ST crypto library v4^[8] is available for the STM32U3 MCUs.
ST crypto library is delivered through X-CUBE-CRYPTOLIB with many examples.

4.3. Crypto libraries↑

Third-party libraries such as Mbed™ are available for STM32U3 MCUs.
Mbed™ library implements PSA crypto API. Mbed™ is distributed as source code.

5. Silicon device life cycle↑

The flexible device life cycle scheme is based on the readout protection (RDP) mechanism, including support for product decommissioning (auto-erase):

Opened, closed, or limited debug protection, depending on the RDP level.
Optional password-based RDP level regressions, including for RDP Level 2.

5.1. SFI↑

Secure Firmware Install (SFI) uses the STM32 Trusted Package Creator tool and a HSM (hardware secure machine) to encrypt the install package, authenticate the genuine STM32 device for installation and limit the installation number to a planned number.
For further details, refer to UM2238^[9] and AN5054^[10].
Useful links: