1. Article purpose[edit source]
The main purpose of this article is to give main steps on how to enable security on MPU platforms.
2. Overview[edit source]
A STM32 MPU offers multiple ways to control and enforce security on the device. It exists some hardware and software mechanism that can be adapted by the users to set the MPU to the expected security level. These security protection mechanism are offers to users and fully customizable.
3. Device life cycle[edit source]
The STM32MP1 proposes different hardware state that manage different protection levels when changing state.
There are 3 modes defined at hardware level:
- OPEN state: By default the device is in open state. Authentication is not mandatory. It can be used to test authentication as error does not prevent FSBL from being started. Debugger is enabled with a limited access.
- CLOSED state: Once product secrets keys have been provisioned into the device, it can be closed. On closed devices, authentication is mandatory. An authentication error prevents FSBL from being started. All debug access are default turn off.
- RMA state: A closed device can be put once in RMA state and back again in CLOSED state. When the device is in RMA state, all ROM code features are disabled.
On STM32MP15x lines 
, it is possible to go back to close state.
4. Secure Boot[edit source]
The secure boot is essential to ensure the integrity and security of the platform at runtime.
The STM32 MPU trusted boot chain is designed to guarantee such a secure boot sequence.
It performs the following tasks:
- Configuration of the platform firewall, which is the foundation for a safe execution of the platform
- Configuration of the platform debug capabilities
- Verification of the integrity (thanks to a hash algorithm) and authentication (using asymmetric cryptography algorithms) of the started software components, including the Secure and non-secure worlds.
TF-A is the recommended open source bootloader. Its implementation supports the trusted boot and peripheral access control with firewall.
Once the STM32 MPU is in CLOSED state, the secure boot is enabled and cannot be bypass, all binaries must be signed using the below specific steps.
4.1. STM32MPU keys[edit source]
The secure boot relies on different keys fit the secure boot implementation.
STM32MP15x lines :
- PKH : Hash (SHA256) of the ECC Public Key (ECDSA is the authentication algorithm STM32MP15_OTP_mapping) used to compare the public root key. This file is automatically generated by the KeyGen_tool.
- ROM code used it to compare against the public key included in the STM32 header.
- TF-A BL2 used it to compare against the public root key from the trusted certificate.
STM32MP13x lines :
- PKHTH : Hash (SHA256) of the 8 ECC Public Keys Hashes Table (ECDSA is the authentication algorithm STM32MP13_OTP_mapping) used to compare the public root key. This file is automatically generated by the KeyGen_tool.
- ROM code used it to compare against the public key table hash included in the STM32 header.
- TF-A BL2 used it to compare against the public key table hash included in the STM32 header.
- EDMK : Encryption Decryption Master key used to decrypt the BL2 by the ROM and by the TF-A BL2 to decrypt FIP binaries. Key is a 128 bit random value. It can be generated using following commands:
- Linux: dd if=/dev/random of=edmk.bin bs=1 count=16
- Windows: Use openssl<refs>https://www.openssl.org/</refs> rand command
- BHK: The Boot Hardware key is located in the backup registers and can be used to decrypt secrets as directly connected to the SAES for firmware decryption. It is not used by the ROM code.
4.2. Provisioning[edit source]
The key provisioning or others secrets provisioning is an important step to deploy security management in STM32MPU.
There are different way to provision the OTP:
- U-Boot stm32key command to write authentication and encryption key.
- STM32CubeProgrammer to write all OTP.
- U-Boot fuse command to directly write OTP. By default only non secure OTP are accessible for read/write access to the OTP.
- Secure Secret Provisioning for an overall secure provisioning process.
4.3. Firmware secure boot[edit source]
The secure boot implementation is specific to each software described:
- the STM32 MPU ROM code secure boot article for the ROM code authentication process based on STM32 header.
- the TF-A BL2 trusted board boot using FIP.
- the coprocessor authentication.
4.3.1. ROM code secure boot validation[edit source]
When the chip is in secure open state, it is possible to check if the key provisioning is OK or not.
Once the FSBL image is signed using Signing_tool, it is possible to test the secure boot.
The authentication result is transmitted to TF-A and, at boot time on board, you must see the following line in TF-A trace:
NOTICE: Bootrom authentication succeeded or NOTICE: Bootrom authentication failed.
Example:
NOTICE: CPU: STM32MP157CAA Rev.? NOTICE: Model: STMicroelectronics STM32MP157C eval daughter on eval mother NOTICE: Board: MB1263 Var1.0 Rev.C-01 NOTICE: Bootrom authentication succeeded INFO: Reset reason (0x15): INFO: Power-on Reset (rst_por) INFO: PMIC version = 0x10
4.3.2. TF-A BL2 trusted board boot validation[edit source]
Once the key provisioning is done, the TF-A BL2 will check the Root Key Hash.
- Boot process will go to the next boot loader.
- Block the boot process with error authentication error -80 in case of incorrect provisioning.
5. Close the device[edit source]
Closing the device is the most important security feature as:
- it ensures that only signed binary can be used
- it closes the debug access
Closing the device can be done using:
- U-Boot stm32key command.
- STM32CubeProgrammer to write OTP.
- U-Boot fuse command to directly write OTP.
- Secure Secret Provisioning that close the device at the end of the process.
6. References[edit source]