This article contains an overview of the security features[1] available on STM32U0 MCUs. The table below contains detailed information based on the different product lines.
| Security features embedded on: |  |
 |
|
|---|---|---|---|
| Security features embedded on: | STM32U031 | STM32U073 | STM32U083 |
| Secure Boot and Firmware Update | YES | YES | YES |
| OEMiSB | YES | YES | YES |
| OEMiROT | NO | NO | YES |
| Isolation | YES | YES | YES |
| HDP | YES | YES | YES |
| Cryptography | YES | YES | YES |
| ST crypto lib | YES | YES | YES |
| Crypto libraries | YES | YES | YES |
| Crypto lib usage | YES | YES | YES |
| Silicon device life cycle | YES | YES | YES |
| RDP | YES | YES | YES |
| RDP regression | YES | YES | YES |
| Product state | NO | NO | NO |
| Debug authentication | NO | NO | NO |
| Secure manufacturing | NO | NO | NO |
1. Secure Boot and Firmware Update
Boot lock and HDP features are available on STM32U0 MCUs, allowing the development of the Secure Boot system.
Secure Boot is a sequence starting from a fixed starting point, configured and locked using option bytes.
As the Secure Boot progresses, the basic and immutable firmware (iRoT, immutable Root of Trust) updates or validates the updatable part of the Secure Boot progression, which is called uRoT (updatable Root of Trust).
iRoT has the possibility to activate HDP securable memory before giving control to the next level (uRoT or appication)
if iRoT has root parameters that must not be shared.
Finally, the uRoT updates or executes an application or an operating system. uRot also has the possibility to extend HDP securable memory to hide its own root parameters.
1.1. SBSFU legacy
STM32U0 MCUs do not support legacy SBSFU [2].
1.2. OEMiSB
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.
1.3. OEMiRoT
Boot is performed through OEMiROT boot path after authenticity and integrity checks of the application firmware and application data image.
If a downloaded new version of the application firmware and the application data images are detected at next reset, the OEMiROT will decrypt and install these new versions after successful check of the authenticity and the integrity of each image.
2. Isolation
2.1. Securable memory area by Hide Data Protect(HDP)
The main purpose of the securable memory area is to protect a specific part of flash memory against undesired access. After system reset, the code in the securable memory area can only be executed until the securable area becomes secured and never again until the next system reset. This allows implementing software security services such as secure key storage or secure boot.
2.2. Securable memory area extension
The HDP area can be extended though a dedicated volatile register indicating the number of supplementary pages added to the securable memory area.
3. Cryptography
Means of performing cryptography depends on the STM32U0 product line.
STM32U031 and STM32U073: Software libraries are available for RNG only.
STM32U083: Hardware cryptographic accelerators are available for symmetric cryptography (AES) and random number generation(RNG).
STM32Cube HAL can be used to work with the crypto IP.
3.1. ST crypto lib
ST crypto library v4[3] is available for the STM32H5 MCUs. ST crypto library is closed-source, but it can be added to the project easily, and it is downloadable together with many examples.
3.2. Crypto libraries
Third-party libraries such as Mbed™ exist for STM32H5 MCUs.
Mbed™ library implements PSA crypto API which makes it well suited for TF-M related projects. Mbed™ is distributed as source code.
Mbed™ port working with STM32H5 MCUs is distributed with the STM32H5 Cube intro package.
4. Silicon device life cycle
4.1. RDP level management
The STM32U0 silicon device life cycle is based on the RDP mechanism implemented for the FLASH interface.
| RDP protection level | Debug | Comments |
| Level 0: Device open | Allowed | Boot address can be either user flash, bootloader in system memory or embedded SRAM
depending on boot mode configuration. Any security configuration including OEM1 and OEM2 keys can be provisioned in flash user options. |
| Level 1: Device memories protected | Limited | Boot address can be either user flash, bootloader in system memory or embedded SRAM
depending on boot mode configuration. Debug access to user FLASH memory, embedded SRAM and backup registers is not allowed. Any security configuration including OEM1 and OEM2 keys can be provisioned in flash user options. |
| Level 2: Device closed | None | Boot address must target the user flash memory. Flash user options are read-only, hence RDP level 2 cannot be changed, unless OEM2
unlocking key is activated. |
4.2. Regression
Regression allows reopening the product, by returning to RDP level 0.
A full flash user memory mass erase is applied prior to the reopening.
The devices support both permanent RDP Level 2 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.
| OEM2LOCK | OEM1LOCK | |
0 |
1 | |
| 0 | RDP 1 to 0 always granted RDP 2 to 1 never granted |
RDP 1 to 0 needs OEM1KEY unlock sequence RDP 2 to 1 never granted |
| 1 | RDP 1 to 0 always granted RDP 2 to 1 needs OEM2KEY unlock sequence |
RDP 1 to 0 needs OEM1KEY unlock sequence RDP 2 to 1 needs OEM2KEY unlock sequence |
5. References