STM32MP1 security overview

Emmanuel COMBETTE DE RYMON · ‎2020-06-15

Introduction

STMP32MP1 security solution provides some bricks to bring security features from which you can build your own adapted solution. The security blocks developed in this FAQ are available in https://wiki.st.com/stm32mpu/wiki/Security_overview

1. Secure boot and OPTEE

The secure boot ensures the integrity of binaries of the first stage (TF-A firmware) and second stage bootloaders (Uboot firmware).

The STM32MP1 ROMCode performs a binary authentication check of signed TF-A firmware. This is done with a asymmetric ECDSA public key stored in STM32MP1 OneTimeProgramming (OTP) peripheral and binary headers with signature. Once the TF-A is authenticated, ROMCode starts TF-A. TF-A authenticates in its turn the second stage bootloader firmware (Uboot) based on X509 PKI infrastructure and OPTEE binary.

This ensures that STM32MP1 does not boot if TF-A or SSBL binaries integrity are not replaced by hacked binaries in flash.

Specificity of STMP32MP13 enhanced for security , user can store 8 CDSA public key and key revocation is possible. TF-A can be decrypted when loaded by ROM code. Cytpo Peripheral are robust against Side Channel Attack (SCA). The Boot chain is pre-certified SESIP Level3 and PCI6.

The Uboot authentication and RSA decryption (or EDCSA encryption as option, ask ST support)

of FIT image (linux kernel, device tree, initramfs) are not by default enabled on OpenSTLinux release (can be depending upon the needs).

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 is authenticated too.

Authentication of Cortex®-M4 firmware (STM32MP15 only) is implemented with a dedicated OTPEE Trusted application for STM32MP15.

Secure firmware update is supported in TF-A , this process allow to update the Uboot and OPTEE binaries with authentication.

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

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

2. Key provisioning system

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.

STM32MP1 offers hardware isolation. The Cortex®-A code, Cortex®-M (STM32MP15 only), DMA have a controlled access to the STM32MP15 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.

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

Secrets can be protected by locating them in RAM accessible only by Cortex®-A in a secure hardware execution context. Secrets copy and memory can be locked with firewall activation in TF-A secure monitor. Secure services like encrypt/decrypt or authentication from secrets protected in the A7 secure context can be implemented in the TF-A secure monitor or in OPTEE trusted applications. These services can then be called from an application running in the Cortex®-A7 non-secure context.

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.

STM32MP13 supports on-the-fly decryption, which allow to run OPTEE in encrypted DRAM.

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. 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 request to ST.

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, STMicroelectronics strongly recommends contacting 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 ST Wiki