- Last edited 9 months ago ago
STM32MP15 ROM code secure boot
- 1 Purpose
- 2 Authentication processing
- 3 U-Boot command stm32key
- 4 Authentication steps
- 5 References
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.
2 Authentication processing
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:
The BSEC OTP used by secure boot are:
3 U-Boot command stm32key
OpenSTLinux embeds a
stm32key tool that can be called from U-Boot command line interface to manage these OTP.
STM32MP> help stm32key stm32key read [<addr>] : Read the hash stored at addr in memory or in OTP stm32key fuse [-y] <addr> : Fuse hash stored at addr in OTP stm32key close [-y] : Close the device, the hash stored in OTP
The optional option
-y is used to skip the confirmation message.
In this article, this
stm32key tool is used to illustrate and experiment the steps needed to activate the secure boot, but these OTP can also be updated directly by customer application or with Secure Secret Provisioning (SSP).
4 Authentication steps
The expected sequence to test the secure boot on the device is
- Key registration: update and lock PKH in OTP (
- Close the device, only signed binary will be accepted (
4.1 Key generation
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.
4.2 Key registration
4.2.1 Load hash public key
PKH file (publicKeyhash.bin) must be available in DDR before proceeding.
For example loaded from a filesystem partition on a storage device, like bootfs (partition 4) on SD card (mmc0):
STM32MP> load mmc 0:4 0xc0000000 publicKeyhash.bin 32 bytes read in 50 ms (0 Bytes/s)
4.2.2 Register hash public key
Make sure that a trusted image was programmed on your board, because below operation will not be possible with optee boot.
You can verify this PKH available in DDR:
STM32MP> 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
STM32MP> stm32key fuse 0xc0000000 Write and lock the key in OTP
The device now contains the hash to authenticate images. To read back the OTP, you can use NVMEM framework or the command
STM32MP> stm32key read Read the key in OTP
4.3 Image signing
In a second step, FSBL binary must be signed. STM32 Signing tool allows to fill the STM32 binary header that is parsed by the embedded software to authenticate each binary.
4.3.1 STM32 Header
Each binary image (signed or not) loaded by ROM code needs to include a specific STM32 header added on top of the binary data. The header includes the authentication information.
|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|
Byte1:major version = 0x01
Byte2: minor version = 0x00
|Image length||32 bits||76||Length of image in bytes[Note 3]|
|Image entry Point||32 bits||80||Entry point of image|
|Load address||32 bits||88||Load address of image[Note 4]|
|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]|
|Padding||83 Bytes||172||Reserved padding bytes[Note 8]. Must all be set to 0|
|Binary type||1 Byte||255||Used to check the binary type |
- Signature is calculated from first byte of header version field to last byte of image given by image length field.
- 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).
- Length is the length of the built image, it does not include the length of the STM32 header.
- This field is not used by ROM code.
- 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.
- Enabling signature verification is mandatory on secure closed chips.
- This field is an extract of PEM public key file that only kept the ECC Point coordinates x and y in a raw binary format (RFC 5480). This field will be hashed with SHA-256 and compared to the Hash of pubKey that is stored in OTP.
- This padding forces STM32 header size to 256 bytes (0x100).
4.4 Image programming
Once the image is signed, it can be programmed into the flash on the target board with STM32CubeProgrammer.
4.5 PKH check
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 provisioned in OTP.
4.6.1 ROM code authentication
Using a signed binary, the ROM code authenticates and starts the FSBL.
At boot time on board, you must see the following line in TF-A trace:
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
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).
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.7 Closing the device
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 is 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.
Here is how to proceed with U-Boot:
STM32MP> stm32key close
stm32key close is not supported, you can write bit 6 = 0x40 in OTP 0:
STM32MP> fuse prog 0 0x0 0x40