1. Article purpose[edit | edit source]
The purpose of this article is to:
- Explain the different life cycle available on STM32 MPU.
- Explain when they will be used.
- Explain how to manage the transitions.
2. Life cycle purpose[edit | edit source]
The STM32 MPU life cycle manages the device behavior of some security features during different development phases. It enables some secure mechanisms that are specific to every device family to enforce the security of the system.
3. Life cycle overview[edit | edit source]
The life cycle of the STM32 MPU is following the below diagram state:
Each state of the diagram refers to a specific device behavior:
3.1. Unsecured[edit | edit source]
This is the unique and final state for devices that do not embed the secure features:
- STM32MP13xA/D lines
- STM32MP15xA/D lines
- STM32MP25xA/D lines
The device is ready for production, there is no possibility to enable secure features. OTP (including upper) are available to store data. TrustZone® remains still available to manage software isolation and allow access to context isolation configuration and upper OTP sections.
In this state, only unsigned firmware is supported for booting the device. The development boot is also supported to allow the user to directly connect the target with the debugger.
3.2. Secured_Unlocked[edit | edit source]
In this state, the device is not protected by security features, but all the mechanisms are available:
- OTP upper to store secrets
- HUK management (not supported on STM32MP15x lines )
- Hardware cryptographic support
- Secure boot
It allows to use unsigned firmware for booting. In that state, the development boot is supported to allow the user to directly connect the target with the debugger.
This state is targeted to be used for development purpose, to design and evaluate the security features of the device. It allows the user to simulate all the security of the platform such as secure boot implementation, secret provisioning in fuses, and cryptographic implementation without locking the device.
3.3. Under_Provisioning[edit | edit source]
This transitioning and optional provisioning state is a specific state where the device is only limited to execute the SSP use case.
The switch to this state is done by the ROM code when:
- The chip certificate is requested on STM32MP1 series.
- The SSP firmware is started on STM32MP2 series.
All the OTP are available for provisioning.
As soon as the SSP process is done, the firmware will directly set the Secured_Locked life cycle.
3.4. Secured_Locked[edit | edit source]
This state is a final secure state.
On STM32MP13x lines and STM32MP25x lines , the device has been certified (SESIP3) in this state.
Once the device achieves this state, all the hardware secure mechanism are enabled:
- Secure boot is enabled: The first booted images must be signed with the provisioned keys.
- Isolation mechanisms are in place and must be guaranteed to guarantee the low power mechanism:
- Backup registers security is enforced.
- Peripheral assignment.
On STM32MP25x lines , the configuration that impact the ROM code is detailed in the ROM isolation description.
3.5. RMA[edit | edit source]
RMA is a specific analysis state where it becomes possible to debug device issues. It is protected by a password and required a specific processing to enter in this state describe in AN5827. It ensures that all the secrets stored in the upper OTP are no more accessible (including the hardware unique key usage).
The switch between RMA and secure closed device state is limited by a counter:
- 1 on STM32MP13x lines
- 3 on STM32MP15x lines
- 4 on STM32MP25x lines
4. Encoding life cycle[edit | edit source]
The life cycle uses a set of OTP words to encode the different states.
4.1. STM32MP13x lines [edit | edit source]
| Secured_Unlocked | |||
|---|---|---|---|
| OTP word | Bit | Name | Value |
| 0 | CFG0 | ||
| Bit [9:0] | OTP mode | b0000010111 | |
| Under_Provisioning | |||
| OTP word | Bit | Name | Value |
| 0 | CFG0 | ||
| Bit [9:0] | OTP mode | b0000010111 | |
| 9 | CFG9 | ||
| Bit [5] | SSP_REQ | b1 | |
| Secured_Locked | |||
| OTP word | Name | Value | |
| 0 | CFG0 | ||
| Bit [9:0] | OTP mode | b0000111111 | |
| 9 | CFG9 | ||
| Bit [6:5] | SSP_REQ / SSP_SUCCESS | b11 | |
4.2. STM32MP15x lines [edit | edit source]
| Secured_Unlocked | |||
|---|---|---|---|
| OTP word | Bit | Name | Value |
| 0 | CFG0 | ||
| Bit [6] | Closed_device | 0 | |
| Under_Provisioning | |||
| OTP word | Bit | Name | Value |
| 0 | CFG0 | ||
| Bit [6] | Closed_device | 0 | |
| 8 | CFG8 | ||
| Bit [8] | SSP_REQ | b1 | |
| Secured_Locked | |||
| OTP word | Name | Value | |
| 0 | CGF0 | ||
| Bit [6] | Closed_device | b1 | |
| 8 | CFG8 (only in case of SSP) | ||
| Bit [9:8] | SSP_REQ / SSP_SUCCESS | b11 | |
4.3. STM32MP25x lines [edit | edit source]
| Secured_Unlocked | |||
|---|---|---|---|
| OTP word | Bit | Name | Value |
| 0 | OTP_HW_WORD0 | 0xAAAA5555 | |
| Under_Provisioning | |||
| OTP word | Bit | Name | Value |
| 0 | OTP_HW_WORD0 | 0xAAAA5555 | |
| 8 | OTP8 | 0xF | |
| 18 | BOOTROM_CONFIG_9 | ||
| Bit [3:0] | secure_boot | 1 - 15 | |
| 124 | HCONF1 | ||
| Bit 20 | DISABLE_SCAN | 1 | |
| Secured_Locked | |||
| OTP word | Bit | Name | Value |
| 0 | OTP_HW_WORD0 | 0xAAAA5555 | |
| 8 | OTP8 | 0xFF | |
| 18 | BOOTROM_CONFIG_9 | ||
| Bit [3:0] | secure_boot | 1 - 15 | |
| Bit [7:4] | prov_done | 1 - 15 | |
| Bit [15:12] | otp_prov_done (only if SSP used) | 1 - 15 | |
| 124 | HCONF1 | ||
| Bit 20 | DISABLE_SCAN | 1 | |
5. How to change the life cycle[edit | edit source]
Different ways are available to change the device life cycle:
- In a trusted environment:
- STM32DDRFW-UTIL, which allows OTP update directly on board or connected to STM32CubeProgrammer.
- stm32key command part of U-Boot firmware included in the OpenSTLinux.
- In an untrusted environment:
- SSP process that directly managed the life cycle transition.
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 