FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32MPUs security overview

Emmanuel COMBETTE DE RYMON
ST Employee

on ‎2020-06-15 6:13 AM - edited on ‎2025-02-28 6:08 AM by

Introduction

The STMP32MPU platform and OpenSTLinux provides elementary security features to help customer to build a desired global security level for their application.  

This FAQ is an overview of these elementary security features presented in the following ST MPU wiki article https://wiki.st.com/stm32mpu/wiki/Security_overview


1. Secure boot and open trusted execution environment (OP-TEE)

The trusted boot chain ensures the integrity of binaries of the First Stage (TF-A firmware) , of the Second Stage Boot Loaders (Uboot firmware) and OP-TEE. 

The STM32MPUs ROM code performs a binary authentication check of a signed TF-A firmware. This is done with an asymmetric ECDSA public key stored in STM32MPU OneTimeProgramming (OTP) peripheral and with TF-A binary headers with its signature. Secure boot on STM32MPU platform prevents the ROM code from booting when TF-A binaries have been replaced by hacked binaries in flash. ROM Secure boot is the first pillar of the Chain of Trust of the trusted boot chain.

Once the TF-A is authenticated, ROM code starts TF-A. TF-A is the second pillar of the trusted boot chain. TF-A authenticates in its turn the Second Stage BootLoader firmware (Uboot) and the OP-TEE binary (based on a X509 PKI infrastructure).

 

STMP32MP13 and STM32MP2 have enhanced security, a user can store 8 ECDSA public keys and key revocation is possible. TF-A can be decrypted when loaded by ROM code. The Crypto peripherals is robust against Side Channel Attack (SCA) and the boot chain is pre-certified for SESIP Level 3 and PCI6. 

 

OP-TEE (Open trusted execution environment) allow to run OP-TEE applications (TA) in Cortex®-A secure hardware execution context. OP-TEE and TA can be authenticated before execution by TF-A. 

Authentication of Cortex®-M firmware (M4 or M33) is implemented with a dedicated OT-PEE trusted application. Authentications above made by TFA uses by default the same ECDSA key as the key used for TF-A authentication.

 

The standard Uboot authentication and Uboot RSA decryption of FIT image (Linux kernel+ device tree+initramfs) are not by default enabled on OpenSTLinux release (can be depending upon the needs).

 

Secure firmware update allows the update of the Uboot and OP-TEE binaries with TF-A authentication is implemented in OpenSTLinux.

 

Signing tool to sign the TF-A binaries with the ley generated by KeyGen are available in the STM32MPU ecosystem. 

 

2. Key provisioning system

The keys can be protected inside a Hardware Security Module card (HSM), to share the private keys to the manufacturing plant. From HSM, the keys can be provisioned into STM32MPU OTP using the ST secure secret provisioning (SSP) tools.

 

STM32MPU offers hardware isolation. The Cortex®-A code, Cortex®-M (STM32MP15,STM32MP2), DMA have a controlled access to the STM32MPU peripherals and memories access depending on hardware execution context.

A secure boot chain configures the hardware firewalling of each peripheral and memories to one hardware execution context. Hardware isolation allows having part of the system protected against undesired cpu or DMA access (bug or malicious). Isolation allows SIL3 certification for safety.

 

3. Binary encryption in external memories

STM32MP15 SoC flash and DDR interfaces do not support on-the-fly decryption of the flash contents or the DDR DRAM contents. Therefore, automatic on the fly decryption of encrypted memories is not possible. However, the decryption of a binary located in external memories is always possible “manually” in software or with STM32MP15 crypto peripherals.

On-the-fly decryption, which allows to run OPTEE in encrypted DRAM, is supported for STM32MP13 (DDRMCE) and STM32MP2 (RISAF).

4. Secure element

The ST33 Trusted Platform Module Chip (TPM) services (key storage, authentication check, and encrypting) are possible using the standard linux framework.

5. Advanced security

SAES peripheral contains a secret hardware unique key that to make key wrapping for key stored in flash memories. It can be used for Rootfs encryption with Linux dm-crypt from wrapped key by SAES with the HUK. Rootfs encryption with wrapped key example (as yocto layer) can be requested to ST via OnLine Support.

 

Having these advanced features or more advanced services running in the secure execution context, like secure firmware update (update in secure environment), trusted applications, SVN, virtualization, STMicroelectronics strongly recommends contacting third-party companies. For more details, see ST Partner Program. 

The primary documentation for security aspect of the STM32MPU are located on the ST Wiki. See below for a list of related articles. 

 

Related ST wiki articles

How to get started with secure boot

Secure boot from distribution package
https://wiki.st.com/stm32mpu/wiki/How_to_perform_Secure_Boot_from_Distribution_Package
2. Creating signature key
Gives example of key generation command for each STM32MPU.

https://wiki.st.com/stm32mpu/wiki/How_to_create_Signed_FIT_image_from_Distribution_package

Options for secure boot with FIT image:

fuse PKH (MP15) or PKH table (MP13, MP2) in OTP
stm32key in the development phase. 
https://wiki.st.com/stm32mpu/wiki/How_to_use_U-Boot_stm32key_command

check TF-A authentication from ROM code
https://wiki.st.com/stm32mpu/wiki/How_to_enable_secure_boot_on_STM32_MPU
in development phase do not need to close the device
3.4.1. ROM code secure boot validation
The following trace should appear in the TF-A console:
NOTICE: Bootrom authentication succeeded or NOTICE: Bootrom authentication failed.

Version history
Last update:
‎2025-02-28 6:08 AM
Updated by:
Top