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: |  |
 |
|
|---|---|---|---|
| Secure Boot and Firmware Update | |||
| OEMiSB | YES | YES | YES |
| OEMiROT | NO | NO | YES |
| Isolation | |||
| HDP | YES | YES | YES |
| Cryptography | |||
| Hardware Tiny AES | NO | NO | YES |
| Hardware HASH | NO | NO | NO |
| Hardware SAES/HUK | NO | NO | NO |
| Hardware Asymmetric Cryptography | NO | NO | NO |
| ST crypto lib | YES | YES | YES |
| Crypto libraries | YES | YES | YES |
| Silicon device life cycle | |||
| RDP | YES | YES | YES |
| RDP regression | YES | YES | YES |
| Product state | NO | NO | NO |
| Debug authentication | NO | NO | NO |
| Secure manufacturing |
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 application)
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. OEMiSB
OEMiSB stands for OEM immutable (unchangeable) Secure Boot. OEMiSB offers only one service:
- The Secure Boot (root of trust service) is an immutable code, which is always executed after a system reset. It checks static protections (Options Bytes), activates runtime protections and then verifies the integrity of the user application code before every execution.
1.2. OEMiRoT
OEMiRoT stands for OEM immutable (unchangeable) Root of Trust and acts as a first boot stage. It is based on the MCUboot open-source software[2] provided with STM32CubeU0.
OEMiRoT 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.
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 hidden and never again until the next system reset. This allows implementing software security services with root parameters only owned by the 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.
| Cryptography features embedded on: | |
|
|
|---|---|---|---|
| Hardware Tiny AES | NO | NO | YES |
| Hardware HASH | NO | NO | NO |
| Hardware SAES | NO | NO | NO |
| Hardware PKA | NO | NO | NO |
| ST crypto lib | YES | YES | YES |
| Crypto libraries | YES | YES | YES |
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 STM32U0 MCUs.
ST crypto library is delivered through X-CUBE-CRYPTOLIB with many examples.
3.2. Crypto libraries
Third-party libraries such as Mbed™ exist for STM32U0 MCUs.
Mbed™ library implements PSA crypto API. Mbed™ is distributed as source code.
4. 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. References