STM32 MPU ROM code secure boot

Applicable for

STM32MP13x lines, STM32MP15x lines

---

1. Purpose

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

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, this means that:

• authentication and integrity are not ensured
• 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 developers to debug the secure boot chain.

When the chip is closed, the secure boot is enforced, this means that:

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

For details about secure boot features on STM32MP13x lines  see Secure boot on STM32MP13 lines
For details about secure boot features on STM32MP15x lines  see Secure boot on STM32MP15 lines
For details about the closing and setup of the chip for enforced secure boot see Operating guidances

2. Secure boot on STM32MP13x lines 

2.1. Overview

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

The figure above shows the steps implied in secure boot:

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

2.2. Keys generation

The first step is to generate the necessary keys with STM32 KeyGen tool.

Authentication keys

• The STM32 KeyGen tool generates eight ECC pair of keys that are used to sign the images.
  

• The STM32 KeyGen tool also generates a file containing the hash of the table of eight (algo+public key) hashes (PKHTH) that are used to authenticate the public key on the target.

Encryption / Decryption key

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

2.3. Keys registration

• PKHTH must be stored in OTP WORD 24 to 31.
• EDMK must be stored in OTP WORD 92 to 95.

2.4. Image signing

• Eight 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

The EDCSA verification follows the process below:

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 it is different, the authentication process fails, otherwise it continues.
3. The ROM code computes the SHA256 hash of the “Public key” available in the signed file.
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 this is not the case, the authentication process fails, 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 it is different, the authentication process fails, 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 fails, 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 "min FSBL version" stored in OTP WORD 4. If not the authentication process fails, otherwise the ROM code updates the "min FSBL version" and continues the boot process.

2.6. Image encryption

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

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 fails, 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 an authenticated image.

3. Secure boot on STM32MP15x lines 

3.1. Overview

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

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

The first step is to generate the necessary keys with STM32 KeyGen tool.

Authentication keys

• The STM32 KeyGen tool generates one ECC pair of keys that is used to sign the images.
  

• The STM32 KeyGen tool tool also generates a third file containing the public key hash (PKH) that is used to authenticate the public key on the target.
  

3.3. Keys registration

• PKH shall be stored in OTP WORD 24 to 31.

3.4. Image signing

• 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

The EDCSA verification follows the process below:

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 fails, 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 fails, 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 "min FSBL version" stored in OTP WORD 4, if not the authentication process fails, otherwise the ROM code continues the boot process.

4. Operating guidances

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 becomes permanently unusable.

The needed keys file is generated using STM32 KeyGen tool.

The files are signed with STM32 Signing tool.

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

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

• the STM32MP13x lines  closing bits fuses
• the STM32MP15x lines  closing bits fuses

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).

Read only memory

First stage boot loader

Microprocessor unit

Elliptic curve digital signature algorithm

Elliptic curve cryptography

Error correction capability

Public key hash table hash, used for secure boot - NEW

Encryption Decryption master key, used for secure boot - NEW

Boot and Security and OTP control

Advanced encryption standard

Public key hash, used for secure boot - NEW

Secure secret provisioning

Light-emitting diode

Read only memory

First stage boot loader

Microprocessor unit

Elliptic curve digital signature algorithm

Elliptic curve cryptography

Error correction capability

Public key hash table hash, used for secure boot - NEW

Encryption Decryption master key, used for secure boot - NEW

Boot and Security and OTP control

Advanced encryption standard

Public key hash, used for secure boot - NEW

Secure secret provisioning

Light-emitting diode

One time programmed