How to secure STM32 MPU

Applicable for STM32MP13x lines, STM32MP15x lines

1 Article purpose[edit]

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

2 Overview[edit]

Warning white.png Warning
Make sure that a device with Secure boot available is used: this is mentioned in the chip part number, for STM32MP13 and STM32MP15, otherwise the device will become permanently unusable.


A STM32 MPU offers multiple ways to control and enforce security on the device. It exists some hardware and software mechanisms that can be adapted by the users to set the MPU to the expected security level. These security protection mechanisms are offered to users and fully customizable.

3 Secure Boot[edit]

The secure boot is a mandatory feature to ensure the integrity and security of the platform at runtime.
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 is the recommended open source bootloader. Its implementation supports the trusted boot and peripheral access control with firewall.

3.1 Enable secure boot[edit]

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

Encryption is an extended security feature (only available on STM32MP13x lines Warning.png) that can be enabled at each firmware level at the beginning or in a second step.

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

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

3.2 STM32MPU keys[edit]

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

STM32MP15x lines More info.png:

  • PKH (Mandatory): Hash (SHA256) of the ECC Public Key (ECDSA is the authentication algorithm STM32MP15_OTP_mapping). This hash is automatically generated by the KeyGen_tool in a dedicated file.
    • 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 Warning.png:

  • PKHTH (Mandatory): Hash (SHA256) of the 8 ECC Public Keys Hashes Table (ECDSA is the authentication algorithm STM32MP13_OTP_mapping). This hash is automatically generated by the KeyGen_tool in a dedicated file.
    • 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 (Optional): Encryption Decryption Master key used to decrypt the BL2 by the ROM and by the TF-A BL2 to decrypt FIP binaries. The firmware encryption is an optional feature and could be later enabled. 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 (Optional): 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.
Warning white.png Warning
The defined keys are used by ROM code and could not be changed. By default, OpenSTLinux uses the same key for the next stage boot loader TF-A BL2 but it can be updated by users to define specific keys.

3.3 Provisioning[edit]

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:

3.4 Firmware secure boot[edit]

The secure boot implementation is specific to each software described:


3.4.1 ROM code secure boot validation[edit]

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]

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.

4 Close the device[edit]

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:

5 References[edit]