- Last edited 3 days ago ago
- 1 Article purpose
- 2 Secure boot
- 3 Firewall
- 4 Secure debug
- 5 Secure and non-secure worlds
- 6 Security peripherals
- 7 Secure Secret Provisioning
- 8 Secure update
- 9 References
1 Article purpose
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
STM32 MPU provides secure mechanism to ensure integrity and authenticity of software executed on SoC.
This is described in the Secure boot dedicated page.
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
- 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
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
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
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
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 
|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
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 , SCMI, 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.
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
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.
|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
6.1 Cryptographic hardware acceleration
The STM32 MPU embeds multiple peripherals for cryptographic acceleration:
6.2 Trusted platform module (TPM)
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
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
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.