STM32 MPU ROM code secure boot

This message will disappear after all relevant tasks have been resolved.

Semantic MediaWiki

There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

Applicable for

STM32MP13x lines, STM32MP15x lines

Warning

Work in progess

1. Purpose[edit source]

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.

2. Authentication processing on STM32MP13x lines [edit source]

2.1. Full view[edit source]

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.

The figure above shows the steps implied in secure boot:

Keys generation
Keys registration
Image signing & encryption
Image authentication with key revocation and version anti-rollback
Image decryption

2.2. Keys generation[edit source]

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 source]

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

2.4. Image signing[edit source]

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 source]

The EDCSA verification follows the process below:

The ROM code computes the SHA256 hash of the Table of Public Hashes available in the header.
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…
The ROM code computes the SHA256 hash of the “Public key” available in the signed file^{[Note 1]}.
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…
The ROM code computes the SHA256 of the FSBL payload plus the “Public key” and the file header.
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.
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.

↑ "Public key" hash is in fact the hash of (Algorithm id + Public key)

2.6. Image encryption[edit source]

The host calculates the SHA256 hash of FSBL binary, and stores the 128 most significant bits of it in the header.
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.
The host uses the encryption key to encrypt the FBSL binary with AES algorithm

2.7. Image decryption[edit source]

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.
The ROM code uses the decryption key to decrypt the FBSL binary with AES algorithm.
The ROM code calculates the SHA256 hash of the plain FSBL binary,
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.

3. Authentication processing on STM32MP15x lines [edit source]

3.1. Full view[edit source]

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.

The figure above shows the steps implied in secure boot:

Keys generation
Keys registration
Image signing
Image authentication

3.2. Keys generation[edit source]

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 source]

PKH shall be stored in OTP WORD 24 to 31.

3.4. Image signing[edit source]

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 source]

The EDCSA verification follows the process below:

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…
The ROM code computes the SHA256 of the FSBL payload plus the “Public key” and the file header.
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.
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. Authentication operating guidances[edit source]

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.

In this article, the stm32key U-Boot command is used to illustrate and experiment the steps needed to activate this authentication.

Warning

For real secured product, the associated OTPs must be updated directly by customer application or with Secure Secret Provisioning (SSP).

4.1. Prerequisite[edit source]

The needed keys file is generated using STM32 KeyGen tool.

4.2. U-Boot command stm32key[edit source]

U-Boot in OpenSTLinux embeds a stm32key command that can be called from U-Boot command line interface to manage the keys in OTPs.

  stm32key help

 stm32key - Manage key on STM32
 
 Usage:
 stm32key list : list the supported key with description
 stm32key select [<key>] : Select the key identified by <key> or display the key used for read/fuse command
 stm32key read [<addr> | -a ] : Read the curent key at <addr> or current / all (-a) key in OTP
 stm32key fuse [-y] <addr> : Fuse the current key at addr in OTP
 stm32key close [-y] : Close the device, force use of PKH stored in OTP

The optional option -y is used to skip the confirmation message.

The name of the used <key> for authentication is:

PKHTH for STM32MP13x lines

  stm32key list
 PKHTH : Hash of the 8 ECC Public Keys Hashes Table (ECDSA is the authentication algorithm)
 	OTP24..32
 FEK : Firmware Encryption Key
 	OTP92..95

PKH for STM32MP15x lines ,

  stm32key list
 PKH : Hash of the ECC Public Key (ECDSA is the authentication algorithm)
 	OTP24..32

4.3. Authentication steps with U-Boot[edit source]

The steps described in authentication for STM32MP13x and for STM32MP15x are executed with the same sequence of U-Boot stm32keycommands:

U-Boot Key registration with U-Boot: update and lock OTPs (stm32key fuse)
Check Authentication with registered keys
Close the device with U-Boot, only signed binary will be accepted (stm32key close)

4.3.1. Keys registration with U-Boot[edit source]

The first step to enable the authentication is to burn the keys in OTPs with the output file from STM32 KeyGen.

Select keys with U-Boot : with the command sm32key select <key>
with <key>=

PKHTH for STM32MP13x lines

  sm32key select PKHTH
 PKHTH selected

PKH for STM32MP15x lines

  sm32key select PKH
 PKH selected

Load keys file in DDR

The keys file, the output file from STM32 KeyGen, must be available in DDR before proceeding the stm32key command;
this file is loaded at 0xc0000000 in the next examples.

For example loaded from a filesystem partition on a storage device by using the load.

with a file Keys.bin in bootfs (partition 4) on SD card (mmc0):

  load mmc 0:4 0xc0000000 Keys.bin
 32 bytes read in 50 ms (0 Bytes/s)

Verify keys file in DDR

Then you can verify the content of keys files loaded in DDR with the command:

  stm32key read 0xc0000000

Example for STM32MP13x lines with PKHTH

 stm32key read 0xC0000000
 Read PKHTH at 0xc0000000
 PKHTH OTP 24: [c0000000] 27051956
 PKHTH OTP 25: [c0000004] b56aef2d
 PKHTH OTP 26: [c0000008] 6215263c
 PKHTH OTP 27: [c000000c] 00000439
 PKHTH OTP 28: [c0000010] 00000000
 PKHTH OTP 29: [c0000014] 00000000
 PKHTH OTP 30: [c0000018] 72429173
 PKHTH OTP 31: [c000001c] 05020600

Example for STM32MP15x lines with PKH

 stm32key read 0xC0000000
 Read PKH at 0xc0000000
 PKH OTP 24: [c0000000] 27051956
 PKH OTP 25: [c0000004] b56aef2d
 PKH OTP 26: [c0000008] 6215263c
 PKH OTP 27: [c000000c] 00000439
 PKH OTP 28: [c0000010] 00000000
 PKH OTP 29: [c0000014] 00000000
 PKH OTP 30: [c0000018] 72429173
 PKH OTP 31: [c000001c] 05020600

Register keys

To write and lock the keys in OTP, you use the command:

  stm32key fuse 0xc0000000

Warning

Verify keys before to confirm the operation, it is a irreversible operation !

Verify keys in OTPs

After the previous command, the device contains the keys to authenticate images and it can be verified with the command:

  stm32key read

Result for STM32MP13x lines with PKHTH

 stm32key read
 PKHTH OTP 24: 27051956 lock : 50000000
 PKHTH OTP 25: b56aef2d lock : 50000000
 PKHTH OTP 26: 6215263c lock : 50000000
 PKHTH OTP 27: 00000439 lock : 50000000
 PKHTH OTP 28: 00000000 lock : 50000000
 PKHTH OTP 29: 00000000 lock : 50000000
 PKHTH OTP 30: 72429173 lock : 50000000
 PKHTH OTP 31: 05020600 lock : 50000000

Result for STM32MP15x lines with PKH

 stm32key read
 PKH OTP 24: 27051956 lock : 50000000
 PKH OTP 25: b56aef2d lock : 50000000
 PKH OTP 26: 6215263c lock : 50000000
 PKH OTP 27: 00000439 lock : 50000000
 PKH OTP 28: 00000000 lock : 50000000
 PKH OTP 29: 00000000 lock : 50000000
 PKH OTP 30: 72429173 lock : 50000000
 PKH OTP 31: 05020600 lock : 50000000

4.3.2. Check authentication[edit source]

Without any other modification, the device is able to perform image authentication but the non-authenticated images can still be used and executed: the device is still opened, let's see this as a kind of test mode to check that the keys is properly set.

To check authentication, the FSBL =TF-A binary must be signed with the STM32 Signing tool.

Once the image is signed, it can be programmed into the flash on the target board with STM32CubeProgrammer.

Using this signed binary, the ROM code compares the keys carried in the STM32 header with the one that was provisioned in OTP and starts the FSBL = TF-A.

The Authentication result to transmit to TF-A and, at boot time on board, you must see the following line in TF-A trace:
NOTICE: Bootrom authentication succeeded

For 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.3. Closing the device with U-Boot[edit source]

As soon as the authentication process is confirmed, the device can be closed and the user is forced to use signed images; Non signed binaries will not be supported anymore on the target.

This operation is perform with the U-Boot command:

  stm32key close

Warning

This must not be done on STM32MP15 part numbers without Secure boot enabled, otherwise the chip will be bricked and could not be used anymore

Non signed binaries will not be supported anymore on the target.

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 source]

[3] "Public key" hash is in fact the hash of (Algorithm id + Public key)

[1] ttps://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

[2] ttps://en.wikipedia.org/wiki/Elliptic-curve_cryptography

[4] ttps://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

[5] ttps://en.wikipedia.org/wiki/Elliptic-curve_cryptography

[1]

[2]

[Note 1]

[3]

[4]