1. Article purpose[edit source]
This article explains, step by step, how to run the SSP process from the OEM secret generation till the chip provisioning. The SSP overview is explained here.
This example uses the STM32CubeProgrammer (STM32CubeProg) and its associated tools to manage the complete SSP.
2. OEM secret management[edit source]
The aim of SSP is to protect OEM secrets. It includes multiple secrets:
- Secrets to be provisioned in OTP
- OEM authentication keys for Secure Boot
- OEM secrets encryption key
For STM32MP2 series it also include :
- Backup registers
- Backup SRAM
2.1. Key generation[edit source]
2.1.1. Authentication keys[edit source]
The initial keys to generate for STM32 MPUs are the authentication keys. This is the root of trust of the STM32 MPU secure boot.
The PKHTH (on STM32MP13xC/F lines ) or PKH (on STM32MP15xC/F lines
) is automatically installed during the SSP process in the dedicated OTP.
On STM32MP25xC/F lines they must be provided by the user in the secret file to generate a valid payload.
To generate the keys, you can use the KeyGen_tool:
Example to generate eight ECC key pairs (Prime256v1) using AES_256_cbc encryption:
STM32MP_KeyGen_CLI -abs /home/user/KeyFolder/ -pwd testkey1 testkey2 testkey3 testkey4 testkey5 testkey6 testkey7 testkey8 -n 8
Example to generate one ECC key pair (Prime256v1) using AES_256_cbc encryption:
STM32MP_KeyGen_CLI -abs /home/user/KeyFolder/ -pwd testkey
2.1.2. Encryption key[edit source]
The SSP process uses a symmetric encryption to protect the OEM secrets exchanged with the chip. This encryption/decryption uses an AES encryption scheme using:
- a 128-bit symmetric key
- a 128-bit nonce value
Both values are provisioned in a HSM, and then securely sent to a ST verified chip using a secured transfer flow.
The two values can be directly generated with the STM32 Trusted Package Creator available in STM32CubeProgrammer , which also further manages the secret file encryption with the given key:
![SSP secret UI.png](/stm32mpu/nsfr_img_auth.php/thumb/0/0b/SSP_secret_UI.png/900px-SSP_secret_UI.png)
Another solution is to prepare both keys using the KeyGen_tool (till version 2.12.0) with the command:
STM32MP_KeyGen_CLI -rand 16 enc_key.bin STM32MP_KeyGen_CLI -rand 16 nonce.bin
2.2. Payload file[edit source]
The payload file is a binary containing all the data the OEM will be provisioning during the SSP procedure. A payload file must at least include the section of data for the OTP : the secret file.
On STM32MP2 series, the payload file can also include a section to provision data in the battery backed memory such as TAMP backup registers and BKPSRAM.
2.2.1. Secret file creation on STM32MP1 series[edit source]
On STM32MP1 series, the secret file must represent the OTP 59 to 95 on STM32MP1 series, named Free for user.
On STM32MP1 series:
- the words 57 and 58 are reserved for mac_address.
- the final file size must be (96 - 59) * 4 bytes = 148 bytes.
![]() |
On the STM32 boards, the word 59 is already fused to store the ST board ID. For SSP testing purpose on an STM32 MPU board, the content of the word 59 must be skipped by using the 0x00000000 value in the secret file. |
2.2.2. Secret file creation on STM32MP2 series[edit source]
On STM32MP2 series, the secret file must include:
- The Root of trust the PKHTH which is the public key hash table hash file (32 bytes) generated by KeyGen_tool.
- the RMA [1] passwords
STM32 Trusted Package Creator provides an interface to generate the secret file. After selecting the "STM32MP25", the OEM client can set a value and the permanent lock status for each OTP he wants to provision :
2.2.3. Backup memory file creation[edit source]
The STM32 Trusted Package Creator integrates an interface to create the backup memory file : backup-out.bin
The data and offset must be aligned on 32bits.
The base address of the file is registered during the creation of the payload.
If the data provision is a 128bits or 256bits AES key, the key can be wrapped with the HUK of the Cortex-A35 (TDCID1) or Cortex-M33 (TDCID2).
The backup file list can also be saved to a json file to be imported later.
2.2.4. Payload creation[edit source]
The STM32 Trusted Package Creator is used to encrypt and prepare the payload file used for provisioning.
All the previous generated keys and files must be properly selected in the STM32 Trusted Package Creator interface to generate the final encrypted file (.ssp).
2.2.4.1. On STM32MP1 series[edit source]
On STM32MP1 series, the OEM authentication key (or root public key table hash) and RMA password(s) must be registered in the interface.
2.2.4.2. On STM32MP2 series[edit source]
On STM32MP2 series, the OEM root public hash key table and RMA passwords should already be embedded in the secret file.
Hence, the user does not need to register them on this interface.
The user can also add one backup memory file.
The supported base addresses are :
2.3. HSM provisioning[edit source]
The HSMv2[2] must be provisioned with the OEM associated SSP file.
The STM32 Trusted Package Creator has a dedicated SSP HSM provisioning interface to select:
- the encryption key used to encrypt the SSP secret file
- the nonce used to encrypt the SSP secret file
- the personalization data file (used to identify the chip):
- the maximum number of images to program, which depends also on the HSMv2 used.
3. SSP Firmware management[edit source]
On STM32MPUs, a specific firmware is used to:
- exchange SSP communication with the host,
- burn the OTP in fuses,
- provision battery backed memory (only on STM32MP2 series)
3.1. SSP Firmware for STM32MP1 series[edit source]
On STM32MP1 series, the SSP SSP Firmware is a specific TF-A BL2 that is delivered with each ecosystem version and must be updated regarding the user's board.
It only includes a limited part of the TF-A BL2 scope:
- only serial boot support
- dedicated SSP feature set
The main TF-A firmware is ready for all targets except the board device tree. It must be customized in the same way as for TF-A BL2.
3.1.1. Build TF-A BL2 SSP[edit source]
Because it uses the same firmware, the way of building and configuring the firmware is described in the How_to_configure_TF-A_BL2 page.
The specific part is the following one:
- dedicated flag to enable the SSP part: STM32MP_SSP
- no TRUSTED_BOARD_BOOT enabled to limit the BL2 binary size
Example:
make ARM_ARCH_MAJOR=7 ARCH=aarch32 PLAT=stm32mp1 STM32MP_UART_PROGRAMMER=1 \ STM32MP13=1 STM32MP_SSP=1 DTB_FILE_NAME=stm32mp135f-dk.dtb
make ARM_ARCH_MAJOR=7 ARCH=aarch32 PLAT=stm32mp1 STM32MP_USB_PROGRAMMER=1 \ STM32MP15=1 STM32MP_SSP=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb
3.1.2. Signing TF-A BL2 SSP[edit source]
This TF-A BL2 SSP firmware MUST be signed with the OEM authentication key generated at step 1. The authentication is made by the ROM code using the OEM public key given by the HSM during the process.
This is made in the same way as TF-A BL2 using the Signing_tool:
Example :
STM32MP_SigningTool_CLI -bin tfa-ssp.stm32 -pubk OEMpublicKey.pem –prvk OEMprivateKey.pem –pwd testkey
3.2. SSP Firmware for STM32MP2 series[edit source]
On STM32MP2 series, STMicroelectronics provides a dedicated ST firmware that is signed and encrypted by ST. This firmware is generic and does not need to be customized by the OEM to be compatible with the layout of his board. The SSP firmware for STM32MP2 series is delivered inside the STM32CubeProgrammer.
![]() |
The SSP firmware for STM32MP2 series is not yet included in the delivery of STM32CubeProgrammer. It will be temporary delivered on demand to the OEM. |
4. Production processing[edit source]
At that stage, the following parts are available:
- SSP encrypted secret file
- provisioned HSM
- SSP firmware
All that material must be given to the untrusted production to start the SSP process.
4.1. Test case using STM32CubeProgrammer_Cli[edit source]
For an evaluation purpose, STM32CubeProgrammer can be used to test the SSP processing chain.
On the host, the STM32CubeProgrammer must be installed. HSM is plugged into the host smartcard reader. The board is connected, its chip is virgin. The serial boot mode is selected and the power is ON.
The following command can be used for a USB SSP provisioning:
STM32_Programmer_CLI -c port=usb1 -ssp <ssp_file_path> <ssp-fw-path> hsm=1 slot=1
5. SSP : Final state[edit source]
At that stage, the device is provisioned with all the OEM secrets:
- OEM PKH or PKHTH
- OTP secrets
- battery backed memory
The chip is now in the secure close state; The secure boot is mandatory.
Enabling secure boot is the final step to use the chip.
The SSP process cannot be restarted anymore.
6. References[edit source]