Showing results for 
Search instead for 
Did you mean: 

FAQ:STM32MP1 Security overview

What documentation, article, application notes are available for STM32MP1U product lines ?

Provide ST security features overview in the context of STMP32MP15x  STMP32MP13x?  


STMP32MP1 solution provides some bricks to bring security features from which the customer can build Its own adapted solution. 


Find below the security blocks available to customers.

For STM32MP15x family

1/The major security feature provided by STM32MP1 is the secure boot called “trusted boot chain”.


The secure boot ensures the integrity of binaries of the First Stage (TF-A firmware) and Second Stage boot loaders (Uboot firmware). 

The STM32MP1 ROMCode performs a binary authentication check of TF-A firmware. This is done with asymmetric key stored in STM32MP1 OneTimeProgramming (OTP) peripheral and binary headers with signature. Once the TF-A authenticated, ROMCode starts TF-A. TF-A will authenticate in its turn the second stage boot loader firmware with ROMCode authentication service and start it when authentication succeeds.
This ensures that STM32MP1 does not boot if TF-A or SSBL binary integrity is attacked in Flash. 


The authentication of Linux kernel & applications nor the Cortex-M4 coprocessor firmware are not sustained by OpenSTLinux release.



2/Tools from STM32MP1 ecosystem are available to activate the authentication check of the boot chain.

Signing tool to sign the binaries, KeyGen tool to generate asymmetric key.

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


3/STM32MP15x offers hardware isolation. The Cortex-A code, Cortex-M, DMA have a controlled access to the STM32MP1 peripherals and memories access depending on hardware execution context.

Trusted boot chain configures the hardware firewalling of each peripheral and memories to one hardware execution context. Hardware isolation allows to have part of the system protected against undesired Cpu or DMA access (bug or malicious).


Hardware isolation can be used also in context of security to protect and use secrets.
ROM code, TF-A, OPTEE applications are executed in Cortex-A secure hardware execution context. When TF-A starts the SSBL(Uboot), the SSBL (then later Linux) is executed in Cortex-A non-secure hardware execution context.

Secrets can be protected by locating them in RAM accessible only by Cortex-A in secure hardware execution context. Secrets copy and memory firewall lock activation can be implemented in TF-A secure monitor. Secure services like encrypt/decrypt or authentication from secrets protected the A7 secure context can be implemented in the TF-A secure monitor or in OPTEE applications. These services can be then called from application running in the Cortex-A7 non-secure context. This is not available in OpenSTLinux release.


4/OPTEE (open trusted execution environment) OS to run OPTEE applications in Cortex-A secure hardware execution context. OPTEE can be authenticated before execution by TF-A. OTPEE application are authenticated too.  



5/Authentication and decryption of Cortex-M4 firmware could be implemented with a dedicated OTPEE application or Kernel application using TF-A secure monitor. This is not implemented in OpenSTLinux. Authentication is scheduled in the coming deliveries.


6/Binary encryption in external memories.

STM32MP1 Soc Flash and DDR interfaces do not support on-the-fly decryption of the Flash contents nor 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 STM32MP1 crypto peripherals.


The secure boot chain does not support the decryption of its binaries.  

The STM32PM1 ROMCode cannot perform the TF-A firmware decryption.  TF-A does not implement the decryption of SSBL (Uboot) firmware.



7/The ST33TPM12 (external Trusted Platform Module chip -TPM) services (Key storage, authentication check, encrypting) are possible using standard Linux framework.


For having these advanced features or more advanced service running in the secure execution context like secure firmware update (update in secure environment), trusted applications, SVN, Virtualization, ST strongly recommends to contact with Third Party companies. Proven & Run company is one of them.


The main documentation for security aspect of the STM32MP1 are the articles on the


Please find the wiki article overview:


1-Hardware Execution contexts and peripheral assignment for hardware isolation

explain execution contexts

show architecture overview

present possible peripheral assignments

explain how to assign peripheral to a context


2-Secure boot and secure boot chains

          shows the different stages in the boot chain
          shows an overview of what is done in ROM code


          how  to generate and store keys in OTP,

          how to sign binaries (TF-A, u-boot binaries) to be authenticated

          how to close the device to force always authentication

          tools for generating keys  : public key hash to be stored in OTP with STM32CubeProgrammer , private key used for binary signing

           tools for signing binaries


3-security overview

security overview

assigns access rights to MPU peripherals from Cortex-A7 contexts (secure or normal) and Cortex-M4 context.

assigns access rights to internal ROM/RAM from Cortex-A7 and Cortex-M4.

assigns access rights to DDR regions


4-TPM(external Trusted Platform Module chip) with OpenSTLinux that follow the TPM V2.0 specification implementation 

5-Cortex-M4 firmware authentication principles


6 -OPTEE and Trusted Application (TA)

ST does not currently deliver any TA but demo examples can be run.



For STM32MP13x family
 New features for security
-more tamper pins (12 Tamper pins (5x active)

-Hardware Unique Key (HUK)
-SCA (Side Channel Attack) using SAES
-OTF DRAM Encryption/Decryption (allows to execute Optee in encrypted DDR)
For secure boot new features are

-fsbl autentication
-key revocation
-encrypted fsbl and ssbl based on X509 PKI infrastructure
-no M4 coprocessor for MP3x products

other useful links

Version history
Last update:
‎2020-06-15 06:13 AM