STM32 MPU ROM code secure boot


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.

2 Authentication processing[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.

Two algorithms are supported for ECDSA calculation:

  • P-256 NIST
  • Brainpool 256

The algorithm selection is done via the signed binary header, as shown in STM32 header (subchapter in this same article).

The EDCSA verification follows the process below:

2.1 Key generation[edit]

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

2.2 Key registration[edit]

Warning white.png Warning
Make sure that a device with Secure boot enabled is used: this is mentionned in the part number, otherwise the device will become permanently unusable.

2.2.1 Register hash public key[edit]

First step to enable the authentication is to burn the OTP WORD 24 to 31 in BSEC with the corresponding public key hash (PKH, output file from STM32 KeyGen). OpenSTLinux embeds a stm32key tool that can be called from U-Boot command line interface to program the PKH into the OTP.

PKH file (publicKeyhash.bin) must be available in a filesystem partition (like bootfs) on a storage device (like sdcard) before proceeding.

  ext4load mmc 0:4 0xc0000000 publicKeyhash.bin                  Load hash file from mmc 0 partition 4 (ext4) in DDR
 32 bytes read in 50 ms (0 Bytes/s)
  stm32key read 0xc0000000                                       Read loaded key from DDR to confirm it is valid (without writing it in OTP)
 OTP value 24: 12345678
 OTP value 25: 12345678
 OTP value 26: 12345678
 OTP value 27: 12345678
 OTP value 28: 12345678
 OTP value 29: 12345678
 OTP value 30: 12345678
 OTP value 31: 12345678
Warning white.png Warning
If hash key is ok, the key in OTP can be fused
  stm32key fuse -y 0xc0000000                                    Write the key in OTP

The device now contains the hash to authenticate images. To read back the OTP, you can use NVMEM framework.

2.3 Image signing[edit]

In a second step, FSBL and SSBL binaries must be signed. STM32 Signing tool allows to fill the STM32 binary header that is parsed by the embedded software to authenticate each binary.

2.3.1 STM32 Header[edit]

Each binary image loaded by the ROM code needs to include a specific STM32 header added on top of the binary data. This header includes mandatory and optional information: this second one is only needed for the authentication (STM32MP1 series) and decryption (STM32MP13x lines More info.png) processes.

3 On STM32MP13x lines More info.png[edit]

3.1 Base header[edit]

STM32MP13 header base.png
Name Length Byte Offset [Note 1] Description
Magic number 32 bits 0 4 bytes in big endian:
'S', 'T', 'M', 0x32 = 0x53544D32
Image signature 512 bits 4 ECDSA signature for image authentication[Note 2]
Image checksum 32 bits 68 Checksum of the payload[Note 3]
Header version 32 bits 72 Header version v2.0 = 0x00020000
Byte0: reserved
Byte1: major version = 0x02
Byte2: minor version = 0x00
Byte3: reserved
Image length 32 bits 76 Length of image in bytes[Note 4]
Image entry Point 32 bits 80 Entry point of image
Reserved 96 bits 84 Reserved
Version number 32 bits 96 Image Version (monotonic number)[Note 5]
Option flags 32 bits 100 b0=1: Authentication enabled[Note 6]
b1=1: Decryption enabled.[Note 7]
b31=1: Header padding enabled[Note 8]
Header extensions length 32 bits 104 Sizes of header extensions enabled by option flags.
Padding 20 Bytes 108 Reserved padding bytes[Note 9].
Must all be set to 0
  1. Unless expressed differently, the 32 bits values are stored in little endian.
  2. Signature is calculated from first byte of header version field to last byte of image given by image length field.
  3. 32-bit sum of all payload bytes accessed as 8-bit unsigned numbers, discarding any overflow bits. Used to check the downloaded image integrity when signature is not used (if b0=0 in Option flags).
  4. Length is the length of the built image, it does not include the length of the STM32 header.
  5. Image version number is an anti rollback monotonic counter. The ROM code checks that it is higher or equal to the monotonic counter stored in OTP.
  6. Enabling signature verification is mandatory on secure closed chips. Authentication parameters are stored in "Authentication header extension".
  7. When decryption is enabled, authentication is mandatory. Decryption parameters are stored in "Decryption header extension".
  8. This header padding extension is always used to have a fixed size of 512 bytes for the whole size of header + its extensions.
  9. This padding forces STM32 base header size to 128 bytes (0x80).

3.2 Authentication header extension[edit]

This header extension contains parameters needed for authentication.

STM32MP13 header authentication.png
Name Length Byte Offset[Note 1] Description
Extension type 32 bits 0 4 bytes in big endian:
'S', 'T', 0x00, 0x02 = 0x53540002
Extension length 32 bits 4 Number of bytes of header extension = 340
Public key index 32 bits 8 Index of the public key to be used.
Public key number 32 bits 12 Number of public keys in table = 8
ECDSA algorithm 32 bits 16 1: P-256 NIST ; 2: brainpool 256
ECDSA public key 512 bits 20 ECDSA public key to be used to verify the signature.[Note 2]
Public key1 hash 256 bits 84 Hash of (ECDSA Algorithm+Public key1).[Note 3].
... ... ... Hashes of (ECDSA Algorithm+Public key), for key2 up to key7
Public key8 hash[Note 4] 256 bits 308 Hash of (ECDSA Algorithm+Public key8)
  1. Offset is relative to header extension base. Unless expressed differently, the 32 bits values are stored in little endian.
  2. Public key is a point on the ECC curve. This field contains the two big numbers in big endian format corresponding to ECC Point coordinates x and y. (If these coordinates are extracted from a PEM public key file that only kept coordinates in a raw binary format, you shall remove the first byte "04" which is an asn1 tag ; for more info: RFC 5480).
  3. The Public Key hash computation is the SHA-256 of ECDSA Algorithm expressed in little endian, concatenated to the public key itself. The entry of the public key table referenced by the public key index is compared to the hash of the ECDSA algorithm and public key that are stored in the header.
  4. The table of public key hashes will be hashed with SHA-256 by the ROM code and compared to the Hash of Public Keys Hashes Table (PKHTH) that is stored in OTP.

3.3 Decryption header extension[edit]

STM32MP13 header decryption.png

This header extension contains parameters needed for decryption.

Name Length Byte Offset[Note 1] Description
Extension type 32 bits 0 4 bytes in big endian:
'S', 'T', 0x00, 0x01 = 0x53540001
Extension length 32 bits 4 Number of bytes of header extension = 32
Key size 32 bits 8 Size of extension key (128 bits)[Note 2].
Derivation constant 32 bits 12 Constant used to derive decryption key from master key stored in OTP.
Plain hash 128 bits 16 128 msb bits of plain payload SHA256.
  1. Offset is relative to header extension base. Unless expressed differently, the 32 bits values are stored in little endian.
  2. Key size is fixed to 128 bits

3.4 Padding header extension[edit]

STM32MP13 header padding.png
Name Length Byte Offset[Note 1] Description
Extension type 32 bits 0 4 bytes in big endian:
'S', 'T', 0xFF, 0xFF = 0x5354FFFF
Extension length 32 bits 4 Number of bytes of header extension = N + 8
Padding bytes N bytes 8 Padding bytes[Note 2].
  1. Offset is relative to header extension base. Unless expressed differently, the 32 bits values are stored in little endian.
  2. N shall be calculated by signing tool so that the size of whole header plus its extension is equal to 512 bytes

4 On STM32MP15x lines More info.png[edit]

STM32 header.png
Name Length Byte Offset Description
Magic number 32 bits 0 4 bytes in big endian:
'S', 'T', 'M', 0x32 = 0x53544D32
Image signature 512 bits 4 ECDSA signature for image authentication[Note 1]
Image checksum 32 bits 68 Checksum of the payload[Note 2]
Header version 32 bits 72 Header version v1.0 = 0x00010000
Byte0: reserved
Byte1:major version = 0x01
Byte2: minor version = 0x00
Byte3: reserved
Image length 32 bits 76 Length of image in bytes[Note 3]
Image entry Point 32 bits 80 Entry point of image
Reserved1 32 bits 84 Reserved
Load address 32 bits 88 Load address of image[Note 4]
Reserved2 32 bits 92 Reserved
Version number 32 bits 96 Image Version (monotonic number)[Note 5]
Option flags 32 bits 100 b0=1: no signature verification[Note 6]
ECDSA algorithm 32 bits 104 1: P-256 NIST ; 2: brainpool 256
ECDSA public key 512 bits 108 ECDSA public key to be used to verify the signature.[Note 7][Note 8]
Padding 83 Bytes 172 Reserved padding bytes[Note 9]. Must all be set to 0.
Binary type 1 Byte 255 Used to check the binary type
0x10-0x1F: FSBL
0x30: Copro
  1. Signature is calculated from first byte of header version field to last byte of image given by image length field.
  2. 32-bit sum of all payload bytes accessed as 8-bit unsigned numbers, discarding any overflow bits. Used to check the downloaded image integrity when signature is not used (if b0=1 in Option flags).
  3. Length is the length of the built image, it does not include the length of the STM32 header.
  4. This field is not used by ROM code.
  5. Image version number is an anti rollback monotonic counter. The ROM code checks that it is higher or equal to the monotonic counter stored in OTP.
  6. Enabling signature verification is mandatory on secure closed chips.
  7. Public key is a point on the ECC curve. This field contains the two big numbers in big endian format corresponding to ECC Point coordinates x and y. (If these coordinates are extracted from a PEM public key file that only kept coordinates in a raw binary format, you shall remove the first byte "04" which is an asn1 tag ; for more info: RFC 5480).
  8. The Public Key hash computation is the SHA-256 of ECDSA Algorithm expressed in little endian, concatenated to the public key itself. The resulting value is compared to the Hash of pubKey that is stored in OTP.
  9. This padding forces STM32 header size to 256 bytes (0x100).


For STM32MP15x lines More info.png:

4.1 Image programming[edit]

Once the images are signed, they can be programmed into the flash on the target board with STM32CubeProgrammer.

4.2 PKH check[edit]

Before really starting the authentication process, the ROM code compares the hash of the public key carried in the STM32 header with the one that was provisionned in OTP.

4.3 Authentication[edit]

4.3.1 Bootrom authentication[edit]

Using a signed binary, the ROM code authenticates and starts the FSBL.

If the authentication fails, the ROM code enters into a serial boot loop indicated by the blinking Error LED (cf Bootrom common debug and error cases)

The ROM code provides secure services to the FSBL for image authentication with the same ECC pair of keys, so there is no need to support ECDSA algorithm in FSBL.

4.3.2 TF-A authentication[edit]

TF-A is the FSBL used by the Trusted boot chain. It is in charge of loading and verifying U-boot and (if used) OP-TEE image binaries.

Each time a signed binary is used, TF-A will print the following status:

INFO:    Check signature on Non-Full-Secured platform

If the image authentication fails the boot stage traps the CPU and no more trace is displayed.

4.4 Closing the device[edit]

Notice that this last step is not shown in the diagram above.

Without any other modification, the device is able to perform image authentication but 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 PKH is properly set.

As soon as the authentication process is confirmed, the device can be closed and the user forced to use signed images.

OTP WORD0 bit 6 is the OTP bit that closes the device. Burning this bit will lock authentication processing and force authentication from the Boot ROM. Non signed binaries will not be supported anymore on the target.

To program this bit, the STM32CubeProgrammer or U-Boot command line interface can be used.

Here is how to proceed with U-Boot:

  fuse prog 0 0x0 0x40
Warning white.png Warning
Once this bit is written the platform is locked