FAQ:STM32MP1 Security overview

Emmanuel COMBETTE DE RYMON · ‎2020-06-15

What documentation, wiki.st.com 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.

https://www.st.com/content/st_com/en/partner/partner-program/partnerpage.html?key=MPU&country=country

The main documentation for security aspect of the STM32MP1 are the articles on the wiki.st.com.

Please find the wiki article overview:

1-Hardware Execution contexts and peripheral assignment for hardware isolation

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

explain execution contexts

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

show architecture overview

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

present possible peripheral assignments

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

explain how to assign peripheral to a context