How to enable secure boot on STM32 MPU

Applicable for

STM32MP13x lines, STM32MP15x lines, STM32MP25x lines

1. Article purpose[edit | edit source]

The main purpose of this article is to give main steps on how to enable the secure boot on MPU platforms.

2. Overview[edit | edit source]

Warning

The secure feature are only available on STM32MP13xC/F lines , STM32MP15xC/F lines and STM32MP25xC/F lines .

A STM32MPU offers a way to control and enforce security of the platform by enabling the secure boot feature. It relies on some hardware and software mechanisms that can be enabled and configured by the OEM to set the expected security level. The secure boot is the initial security step to ensure the global platform security.

3. Secure Boot[edit | edit source]

The secure boot is a mandatory feature to ensure the integrity and security of the platform at runtime.

This is the initial security step to be setup on the platform to start the platform security.

The STM32 MPU trusted boot chain is designed to answer such requirements, relying on ROM code and TF-A security features to guarantee a complete chain of trust.
It performs the following tasks:

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.
Decryption of the loaded binary (Optional)
Configuration of the platform firewall, which is the foundation for a safe execution of the platform
Configuration of the platform debug capabilities

TF-A BL2 is the recommended open source bootloader. Its implementation supports the trusted boot and the PKI management for firmware loading.

3.1. Secure boot flow[edit | edit source]

The authentication is the minimal setup required when enabling the secure boot.

STM32MP13x lines and STM32MP25x lines also offer an encryption feature that can be enabled at each firmware level.

To enable the secure boot, the following steps must be done:

Generate authentication keys (and encryption if needed)
Provision keys in the chip
Close the device
Prepare software to support trusted boot features by signing the loaded firmware
Flash the binaries on the boot device

3.2. STM32MPU keys[edit | edit source]

The secure boot relies on different keys to manage the secure boot implementation.

STM32MP15x lines :

PKH (Mandatory): Hash (SHA256) of the ECC Public Key (ECDSA is the authentication algorithm). See STM32MP15_OTP_mapping. This hash is automatically generated by the KeyGen_tool.
- ROM code uses it to compare against the public key included in the STM32 header.
- TF-A BL2 uses it to compare against the public key from the trusted certificate.
RMA: Return material for analysis password that is user to hide the upper OTP. It is made of a 2*7-bit password to unlock and relock. The password part of the OTP.

STM32MP13x lines :

PKHTH (Mandatory): Hash (SHA256) of the 8 ECC Public Keys Hashes Table (ECDSA is the authentication algorithm). See STM32MP13_OTP_mapping. This hash is automatically generated by the KeyGen_tool.
- ROM code uses it to compare against the public key table hash included in the STM32 header.
- TF-A BL2 uses it to compare against the public key table hash included in the STM32 header.
EDMK (Optional): Encryption Decryption Master Key used to decrypt the BL2 by the ROM and stored in STM32MP13_OTP_mapping. EDMK is a 128-bit random value that can be generated using the following commands:
- Linux:
```
  dd if=/dev/random of=edmk.bin bs=1 count=16 
```
- Windows: Use openssl^[1] rand command

Information

EDMK is also used by the TF-A BL2 to decrypt FIP binaries.

BHK (Optional): The Boot Hardware key is located in the STM32MP13 backup registers and can be used to encrypt or decrypt secrets as directly connected to the SAES for firmware decryption. It is not used by the ROM code.
RMA: Return material for analysis password that is user to hide the upper OTP. It is made of a 32-bit password to unlock. The password part of the OTP.

STM32MP25x lines :

PKHTH1 (Mandatory): Hash (SHA256) of the 8 ECC Public Keys Hashes Table (ECDSA is the authentication algorithm). See STM32MP25_OTP_mapping. This hash is automatically generated by the KeyGen_tool.
- ROM code uses it to compare against the public key table hash included in the STM32 header.
- TF-A BL2 uses it to compare against the public key table hash included in the STM32 header.
EDMK1 (Optional): Encryption Decryption Master Key used to decrypt the BL2 by the ROM.
- Linux:
```
  dd if=/dev/random of=edmk.bin bs=1 count=16 
```
- Windows: Use openssl^[1] rand command
FIP-EDMK: FIP Encryption Decryption Master Key used by the BL2 TF-A BL2 to decrypt firmware that are contained in the FIP image. The key is a 256bit symmetric key stored in OTP. It can be generated using following commands:
- Linux:
```
  dd if=/dev/random of=fip-edmk.bin bs=1 count=32 
```
- Windows: Use openssll^[1] rand command
BHK (Optional): The Boot Hardware key is located in the STM32MP2 backup registers and can be used to encrypt or decrypt secrets as directly connected to the SAES for firmware decryption. It is not used by the ROM code.
RMA: Return material for analysis password that is user to hide the upper OTP. It is made of a 4*32-bit password with unlock and relock. The password part of the OTP.

Warning

PKH/PKHTH/PKHTH1 are used by ROM code. By default, OpenSTLinux uses the same keys for the next stage boot loader TF-A BL2 but it can be updated by users to define specific keys.

3.3. Key provisioning[edit | edit source]

The key provisioning or others secrets provisioning is an important step to deploy security management in STM32MPU.

There are different ways to provision the OTP:

U-Boot stm32key command to write authentication and encryption keys.
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.

3.4. Firmware: secure boot implementation[edit | 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.
the U-Boot FIT authentication.

3.4.1. ROM code secure boot validation[edit | edit source]

When the chip is in secure opened state, it is possible to check if the key provisioning procedure is OK or not.

Once the FSBL image is signed using Signing_tool, it is possible to test the secure boot.

The ROM code authentication result is transmitted to TF-A BL2 during boot sequence. The following trace should appear in the TF-A console:
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

3.4.2. TF-A BL2 trusted board boot validation[edit | edit source]

Once the key provisioning is done, the TF-A BL2 will compare the Root Key Hash to the Root key hash used to generate FIP certificate.
The process boot to the next running image if hash match.
The process ends with error authentication error -80 in case of incorrect provisioning.

4. Close the device[edit | 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.

5. References[edit | edit source]

↑ ^1.0 ^1.1 ^1.2 https://www.openssl.org/

[openssl-1] 1.0 ^1.1 ^1.2 https://www.openssl.org/

[1]