STM32 MPU ROM code secure boot

Applicable for STM32MP13x lines, STM32MP15x lines

Warning white.png Warning
Work in progess

1 Purpose[edit]

Secure boot is a key feature to guarantee a secure platform.

STM32MP1 boot sequence supports a trusted boot chain that ensures that the loaded images are authenticated and checked in integrity before being used.

Warning white.png Warning
The secure boot feature availability is indicated in the security field of the chip part number, for STM32MP13 and STM32MP15.


When the chip is open the secure boot is not enforced, meaning that:

  • authentication and integrity are not ensure,
  • authentication is not mandatory,
  • when required, the authentication may fail,
  • an image may be encrypted but not authenticated

The ROM code logs error and goes on processing until it jumps to FSBL. The goal is to help developer of secure boot chain to debug it.

When the chip is closed, the secure boot is enforced, meaning that:

  • authenticity and integrity are ensure,
  • authentication is mandatory
  • only authenticated images may be encrypted

For details about secure boot features on STM32MP13x lines Warning.png see Secure boot on STM32MP13 lines
For details about secure boot features on STM32MP15x lines More info.png see Secure boot on STM32MP15 lines
For details about closing the chip and setup it for enforced secure boot see Operating guidances

2 Secure boot on STM32MP13x lines Warning.png[edit]

2.1 Overview[edit]

STM32 MPU provides authentication processing with ECDSA [1] verification algorithm, based on ECC [2]. ECDSA offers better result than RSA with a smaller key. STM32 MPU relies on a 256 bits ECDSA key.

STM32MP13 secure boot full.png

The figure above shows the steps implied in secure boot:

  1. Keys generation
  2. Keys registration
  3. Image signing & encryption
  4. Image authentication with key revocation and version anti-rollback
  5. Image decryption

2.2 Keys generation[edit]

First step is to generate necessary keys with STM32 KeyGen tool.

Authentication keys

  • The STM32 KeyGen tool generates 8 ECC pair of keys that will be used to sign the images.
  • The STM32 KeyGen tool tool also generates a file containing the hash of the table of 8 (algo+public key) hashes (PKHTH) that will be used to authenticate the public key on the target.

Encryption / Decryption key

  • The STM32 KeyGen tool generates the encryption/decryption master key (EDMK) that will be used to derive the decryption key used to encrypt and decrypt the image payload.

2.3 Keys registration[edit]

2.4 Image signing[edit]

STM32MP13 image signing.png
  • 8 signing keys available.
  • Public Keys are hashed and this table of hashes is stored in the header.
  • Each key is identified by its index in the table.
  • The index of the key used for signing, the activate key index, is stored in the header.
  • Using a key revokes all the keys with lower index.
  • Two algorithms supported for ECDSA calculation. The algorithm is in the header
    • P-256 NIST
    • Brainpool 256


2.5 Image authentication[edit]

The EDCSA verification follows the process below:

STM32MP13 image authentication.png
  1. The ROM code computes the SHA256 hash of the Table of Public Hashes available in the header.
  2. Then, it compares this hash with the one stored in STM32MP1 BSEC non volatile memory in OTP WORD 24 to 31 : if different, the authentication process is ko. Otherwise, it continues…
  3. The ROM code computes the SHA256 hash of the “Public key” available in the signed file[Note 1].
  4. Then, it checks this “Public key” :
    • It checks that the active key index stored in the header is greater or equal to the "min active key index" stored in BSEC non volatile memory: if not, the authentication process is ko. Otherwise, it continues…
    • It compares the hash of of the “Public key” previously computed to the one corresponding to the active key index in the Table of Public Hashes: if different, the authentication process is ko. Otherwise, it continues…
  5. The ROM code computes the SHA256 of the FSBL payload plus the “Public key” and the file header.
  6. It uses the “Public key” that has just been authenticated to verify that the signature stored in the header is a valid signature of this hash: if the verification fails, then the authentication process is ko. Otherwise, the authentication is successful and the ROM code goes on with the boot process.
  7. The ROM code ends the authentication process by, if needed, updating the "min active key index" and the "min FSBL version" in the STM32MP1 BSEC non volatile memory.
    Key revocation 
    The "min active key index" stored in in OTP WORD 22 is updated if the active key index that was used is greater that it.
    Anti rollback 
    The ROM code checks that the FSBL version contained in the header is greater or equal to the the "min FSBL version" stored in OTP WORD 4 : if not the the authentication process is ko. Otherwise, the ROM code updates the "min FSBL version" and continues the boot process.
  1. "Public key" hash is in fact the hash of (Algorithm id + Public key)

2.6 Image encryption[edit]

STM32MP13 image encryption.png
  1. The host calculates the SHA256 hash of FSBL binary, and stores the 128 most significant bits of it in the header.
  2. The host calculates the PRF CMAC derivation of the Encryption Decryption Master Key (EDMK) with a derivation constant to generate the encryption key, and stores the derivation constant in the header.
  3. The host uses the encryption key to encrypt the FBSL binary with AES algorithm. AES Initial Vector (IV) consists in the 128 most significant bits of the hash.


2.7 Image decryption[edit]

STM32MP13 image decryption.png
  1. The ROM code calculates the PRF CMAC derivation of the Encryption Decryption Master Key (EDMK) stored in STM32MP1 BSEC non volatile memory, with the derivation constant stored in the header, and obtains the decryption key.
  2. The ROM code uses the decryption key to decrypt the FBSL binary with AES algorithm. AES Initial Vector (IV) consists in the 128 most significant bits of plain image hash stored in the header.
  3. The ROM code calculates the SHA256 hash of the plain FSBL binary,
  4. The ROM code compares the 128 most significant bits of this hash with the ones stored in the header : if the verification fails, then the decryption process is ko. Otherwise, the decryption is successful and the ROM code goes on with the boot process.


Note that as shown in "Image encryption" figure above the decryption process is optional and when enabled always occurs on a authenticated image.

3 Secure boot on STM32MP15x lines More info.png[edit]

3.1 Overview[edit]

STM32 MPU provides authentication processing with ECDSA [3] verification algorithm, based on ECC [4]. ECDSA offers better result than RSA with a smaller key. STM32 MPU relies on a 256 bits ECDSA key.

STM32MP15 secure boot full.png

The figure above shows the steps implied in secure boot:

  1. Keys generation
  2. Keys registration
  3. Image signing
  4. Image authentication

3.2 Keys generation[edit]

First step is to generate necessary keys with STM32 KeyGen tool.

Authentication keys

  • The STM32 KeyGen tool generates one ECC pair of keys that will be used to sign the images.
  • The STM32 KeyGen tool tool also generates a third file containing the public key hash (PKH) that will be used to authenticate the public key on the target.

3.3 Keys registration[edit]

3.4 Image signing[edit]

STM32MP15 image signing.png
  • Only one signing key available.
  • The public key is stored in the header.
  • Two algorithms supported for ECDSA calculation. The algorithm is in the header
    • P-256 NIST
    • Brainpool 256


3.5 Image authentication[edit]

The EDCSA verification follows the process below:

STM32MP15 image authentication.png
  1. The ROM code computes the SHA256 hash of the “Public key” available in the signed file. Then, it compares this hash with the one stored in STM32MP1 BSEC non volatile memory in OTP WORD 24 to 31 : if different, the authentication process is ko. Otherwise, it continues…
  2. The ROM code computes the SHA256 of the FSBL payload plus the “Public key” and the file header.
  3. It uses the “Public key” that has just been authenticated to verify that the signature stored in the header is a valid signature of this hash: if the verification fails, then the authentication process is ko. Otherwise, the authentication is successful and the ROM code goes on with the boot process.
  4. The ROM code checks that the FSBL version contained in the header is greater or equal to the the "min FSBL version" stored in OTP WORD 4 : if not the the authentication process is ko. Otherwise, the ROM code continues the boot process.


4 Operating guidances[edit]

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

The needed keys file is generated using STM32 KeyGen tool.

The file are signed with STM32 Signing tool.

The secure provisioning on the board of the needed keys in the associated OTPs are done on directly by customer application or with Secure Secret Provisioning (SSP).

When the device is closed as explained in Life cycle, the ROM accept accept only authenticated images. It is closed by blowing:

See How to use U-Boot stm32key command for examples of secure boot activation without SSP.

On closed device, if the authentication fails, the ROM code enters into a serial boot loop indicated by the blinking Error LED (cf ROM code common debug and error cases).

5 References[edit]