Last edited one year ago

Security overview

1 Article purpose[edit source]

The purpose of this article is to explain how to secure an STM32 MPU-based platform thanks to several hardware mechanisms, and to briefly introduce the software components responsible for the secure configuration.

2 Secure boot[edit source]

STM32 MPU provides secure mechanism to ensure integrity and authenticity of software executed on SoC.
This is described in the Secure boot dedicated page.


3 Firewall[edit source]

MPU firewalls comprise access filters for MPU peripherals and subsystems memory mapped interfaces, internal RAMs/ROMs and external memory (DDR). Depending on the assignment, an MPU interface can be dedicated or shared between several hardware execution context(s).


3.1 STM32MP1 firewall[edit source]

  • ETZPC:
    • 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.
  • TZC: assigns access rights to DDR regions.

Some other peripherals are not linked to firewall controller and directly embeds security management:

  • RCC: can restrict the access of some of its registers to the secure execution context.
  • PWR: can restrict the access of some of its registers to the secure execution context.
  • BSEC: The OTP memory can be fused to restrict the access to some of its content to the secure execution context.
  • RTC: This MPU interface can restrict some of its interface registers to the secure execution context.
  • GPIO: can be configured to restrict some GPIO configuration to the secure execution context.
  • TAMP: can restrict the access of some of its registers to the secure execution context.
  • EXTI: can restrict the access of some of its registers to the secure execution context.
  • GIC: can restrict the access of some of its registers to the secure execution context.
  • MDMA: can configure MDMA interrupt execution context.


4 Secure debug[edit source]

The STM32 MPU offers the possibility to manage the platform debug configuration.
It is indeed possible to enable/disable independently secure and non-secure debug accesses.


4.1 STM32MP1 secure debug[edit source]

Debug accesses are controlled through BSEC peripheral.
When the trusted boot is enabled, the ROM code disables debug accesses and relies on secure OS to configure them.
When a FSBL debug is required, a dedicated wrapper exists (that can be also signed) to open the debug.


5 Secure and non-secure worlds[edit source]

Thanks to Arm® TrustZone, some portions of the executing code can be assigned to a non-secure world or to a secure world.

The secure world offers an isolated context that guarantee code and data integrity up to the hardware support. The secure world can be used to host a Trusted Execution Environment (TEE) that executes in parallel with the rich OS and provides secure services.


The firmware and more generally software executing in secure world implicitly use the TrustZone(r) NS signal/bit to be granted access to sensitive resources. These resources can be DDR locations, SoC peripheral interfaces or SoC internal resources such as clocks, debug facilities, and more.


5.1 Secure runtime services[edit source]

The platform non-secure world accesses to specific resources using generic frameworks. These operations are used to managed overall systems and must be implemented inside the TEE.

These accesses are using the SMC Calling convention [1]

Identifier Name Description
0x84000000-0x8400001F PSCI 32-bit calls 32-bit Power Secure Control Interface
0x82000000-0x8200FF00 SiP Service calls Interfaces to SoC implementation-specific services

5.1.1 OP-TEE OS runtime services[edit source]

The OP-TEE is recommended by STMicroelectronics as it is an open source TEE solution. The package provides additional secure services to the platform since it can host core secure services and run trusted applications. OP-TEE provides the same level of services as TF-A listed above: PSCI[2] , SCMI[3], SiP & OEM SMCCC.

OP-TEE provides other high level services, such as running trusted applications and possibly generic services used by standard non-secure components such as random number generation.

5.1.2 TF-A SP_MIN runtime services[edit source]

Warning white.png Warning
SP_MIN is tagged as deprecated
.

The TF-A configuration supports the installation of a minimal runtime secure service provider and peripheral access control with firewall. This runtime firewall is built from TF-A BL32 SP_MIN image.

Run time services provided by TF-A includes not restricted to, PSCI controls, SCMI resources, some SiP & OEM SMCCC services for power states transition and other platform facilities.

5.1.3 Platform SiP and OEM SMCCC services[edit source]

The STM32MP1 embeds SiP and OEM SMCCC services for non-secure world to access low-power transition facilities that are not yet covered by standard interfaces.


Identifier Name Description
0x82001001 PWR Access restricted to CR3/WKUPCR/MPUWKUPENR registers
0x82001008 PD_DOMAIN Access to program the power domain for low-power management


6 Security peripherals[edit source]

6.1 Cryptographic hardware acceleration[edit source]

The STM32 MPU embeds multiple peripherals for cryptographic acceleration:

6.2 Trusted platform module (TPM)[edit source]

The STM32 MPU can be associated to an external trusted platform module (TPM).
It provides secret data storage capabilities as well as cryptographic capabilities allowing to use them.


6.3 Tamper event detection[edit source]

The STM32 MPU embeds internal and external tampers detections mechanisms. They can be used to detect physical attack, out-of-spec voltage, etc. A tamper detection will result in the automatic clearing of sensitive data in the system: it is a key feature for security product.

7 Secure Secret Provisioning[edit source]

The STM32 MPU allows secrets to be provisioned in BSEC fuses in a secure way. This is the Secure Secret Provisioning (SSP) feature.


This feature is a secure process which runs between the software programmer (including a HSM), the ROM code and a customized TF-A BL2. The security relies on the chip attestation and a package encryption exchange between the programmer and the STM32 MPU.

This feature is fully describes in the AN5510: Overview of the secure secret provisioning (SSP) on STM32MP1 Series.

8 Secure update[edit source]

Secure firmware update feature is available to update firmware based on TF-A BL2 A/B mechanism.

9 References[edit source]