Registered User |
Registered User |
| (67 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| == Article Purpose == | | <noinclude>{{ApplicableFor |
| The purposes 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.<br>
| | |MPUs list=STM32MP13x, STM32MP15x, STM32MP25x |
| | |MPUs checklist=STM32MP13x, STM32MP15x, STM32MP25x |
| | }}</noinclude> |
|
| |
|
| == Introduction == | | == Article purpose == |
| The STM32 MPU is based on the Arm<sup>®</sup> Cortex-A<sup>®</sup> core, which is based on the Arm<sup>®</sup> TrustZone<ref>https://www.arm.com/why-arm/technologies/trustzone-for-cortex-a</ref> architecture that enables context isolation: the '''normal world''' holds the applications whereas the '''secure world''' isolates all the trusted applications and core secure services so that they can safely manipulate platform secret data. The MPU includes [[#Firewall|Firewall]] mechanisms that allow the secure world to forbid read/write accesses from the normal world to given peripherals.<br>
| | OpentSTLinux distribution is following the STM32Trust<ref>[https://www.st.com/content/st_com/en/ecosystems/stm32trust.html STM32Trust]</ref> |
| | reference by integrating by default some security and secure system functionalities.<br> |
| | Click on the following figure to explore them. |
|
| |
|
| Armv7 defines PL0, PL1 and PL2 privilege levels:
| |
| * PL0 is the lowest software execution level (unprivileged calls allowed for applications).
| |
| * PL1 is the execution level for the OS.
| |
| * PL1 (secure) is also the privilege level for secure monitor execution, to switch from the secure to the normal world.
| |
| * PL2 is dedicated to the hypervisor (only non-secure).
| |
|
| |
|
| [[File:Trustzone.png|link=]]
| | {{ImageMap|Image:Security_summary.png |
| | | rect 690 161 969 194 [[Category:Secure_boot | Secure boot]] |
| The '''normal world''' is used to run rich OSs such as [[STM32MP15 Linux kernel overview|Linux Kernel]] and its [[Linux application frameworks overview|applications framework]].<br>
| | rect 830 236 1110 270 [[Secure_Firmware_Update]] |
| The '''secure world''' runs a secure monitor with minimal services (i.e. [[#TF-A|TF-A]]) or a TEE as secure OS (i.e. [[#OP-TEE_OS|OP-TEE OS]]).<br>
| | rect 891 311 1170 345 [[Device life cycle | Device life cycle]] |
| | | rect 893 386 1172 418 [[Category:Context_isolation | Isolation]] |
| <br />
| | rect 821 460 1099 494 [[Category:Platform_security | Secure Storage]] |
| The [[#Secure_Boot|secure boot]] is a key feature of this multiple execution contexts environment. It allows the boot chain to be authenticated by the ROM code as well as the authentication of the components that are launched in the secure and normal worlds.<br /><br />
| | rect 690 535 969 568 [[Category:Platform_security | Crypto Engine]] |
| | | rect 285 535 563 568 [[Secure Secret Provisioning (SSP) overview]] |
| The TrustZone environment is a complete system solution that is not limited to the Cortex context. It provides a bus and peripheral infrastructure to the MPU in order to ensure that the secure world relies on a completely secured pipe when it controls a secure peripheral. The assignment of the peripherals to a given world is done thanks to a [[#Firewall|Firewall]] mechanism, which is set up during the secure world initialization.<br><br />
| | rect 133 460 412 493 [[Category:Platform_security | Identification/Authentication]] |
| | | rect 77 385 355 418 [[Category:Platform_security | Software IP Protection]] |
| Dedicated secure and normal contexts also impact the debugging facilities: depending on the targeted user, the debug can be opened to both worlds (e.g. for a secure aware developer), to normal world only (for a Linux<sup>®</sup> developer) or completely closed (for the end user). This is achieved by configuring the [[#Secure_debug|Debug]] control.<br />
| | rect 77 311 355 344 [[Category:Abnormal_situation_handling]] |
| <br />
| | rect 146 236 424 270 [[Category:Platform_security | Audit/log]] |
| | | rect 285 161 563 194 [[Category:Platform_security | Application Life Cycle]] |
| Some internal or external peripherals can be used by the secure world to support cryptographic operations. Refer to [[#Security peripherals|security peripherals]] for an introduction.
| |
| | |
| == Secure boot ==
| |
| The secure boot is essential to ensure the integrity and security of the platform at runtime.<br>
| |
| | |
| The STM32 MPU [[Boot_chains_overview|trusted boot chain]] was design to guarantee such a secure boot sequence.<br>
| |
| It performs the following tasks:
| |
| * Configuration of the platform [[#Firewall|firewall]], which is the foundation for a safe execution of the platform
| |
| * Configuration of the platform [[#Secure debug|debug]] capabilities
| |
| * Verification of the integrity (thanks to a hash algorithm) and authentication (using asymmetric cryptography algorithms) of the started software components, including the [[#Secure and non-secure worlds|Secure and non-secure worlds]].
| |
| | |
| [[TF-A_overview|TF-A]] is the recommended open source bootloader. Its implementation supports the trusted boot and peripheral access control with [[#Firewall|firewall]]. | |
| | |
| === STM32MP1 secure boot ===
| |
| STM32MP1 secure boot implementation is described in the [[STM32MP15 secure boot]] article.
| |
| | |
| == Firewall ==
| |
| 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 [[Getting_started_with_STM32_MPU_devices#Hardware_execution_contexts|hardware execution context(s)]].
| |
| | |
| ==== STM32MP1 firewall ====
| |
| * [[ETZPC_internal_peripheral|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_internal_peripheral|TZC]]: assigns access rights to DDR regions.
| |
| * [[RCC_internal_peripheral|RCC]]: can restrict the access of some of its registers to the secure execution context.
| |
| * [[PWR_internal_peripheral|PWR]]: can restrict the access of some of its registers to the secure execution context.
| |
| * [[BSEC_internal_peripheral|BSEC]]: The OTP memory can be fused to restrict the access to some of its content to the secure execution context.
| |
| * [[RTC_internal_peripheral|RTC]]: This MPU interface can restrict some of its interface registers to the secure execution context.
| |
| * [[GPIO_internal_peripheral|GPIO]]: GPIO bank Z can be configured to restrict some GPIO configuration to the secure execution context.
| |
| * [[TAMP_internal_peripheral|TAMP]]: can restrict the access of some of its registers to the secure execution context.
| |
| * [[EXTI_internal_peripheral|EXTI]]: can restrict the access of some of its registers to the secure execution context.
| |
| * [[GIC_internal_peripheral|GIC]]: can restrict the access of some of its registers to the secure execution context.
| |
| * [[MDMA_internal_peripheral|MDMA]]: can configure MDMA interrupt execution context.
| |
| | |
| == Secure debug ==
| |
| The STM32 MPU offers the possibility to manage the platform debug configuration. <br>
| |
| It is indeed possible to enable/disable independently secure and non-secure debug accesses.
| |
| | |
| === STM32MP1 secure debug ===
| |
| Debug accesses are controlled through [[BSEC internal peripheral|BSEC]] peripheral.<br>
| |
| By default, the STM32 MPU is started by the [[STM32MP15_ROM_code_overview|ROM code]] with both secure and non-secure debug enabled.
| |
| When the trusted boot is enabled, the [[STM32MP15_ROM_code_overview|ROM code]] disables debug accesses and relies on the FSBL to configure them.
| |
| | |
| == Secure and non-secure worlds==
| |
| Thanks to Arm<sup>®</sup> 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. Secure world can be used to host a Trusted Execution Environment (TEE) that executes in parallel with the rich OS and provides secure services.
| |
| | |
| 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 as clocks, debug facilities, and more.
| |
| | |
| === TF-A runtime services: SP_MIN ===
| |
| The [[TF-A_overview|TF-A]] configuration supports the installation of a minimal runtime secure service provider and peripheral access control with [[#Firewall|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.
| |
| | |
| === OP-TEE OS runtime services ===
| |
| The [[OP-TEE_overview|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, as running trusted applications and possibly generic service used by standard non-secure components as random number generation.
| |
| | |
| == Security frameworks ==
| |
| 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.
| |
| | |
| === PSCI ===
| |
| PSCI<ref>https://developer.arm.com/architectures/system-architectures/software-standards/psci</ref> manages the power state of the CPU and the overall system. This framework is an Arm<sup>®</sup> generic implementation targeting CPU related power management services among which secondary CPUs boot up, dynamic addition and removal of CPUs, CPU idle management and system shutdown and reset.
| |
| | |
| ==== STM32MP1 PSCI support ====
| |
| Both TF-A and OP-TEE implement PSCI v1.0 <ref>https://developer.arm.com/docs/den0022/latest</ref> and offers standard services for:
| |
| * Core idle management
| |
| * Boot up for secondary boot core
| |
| * Dynamic addition and removal of cores
| |
| * System shutdown and reset
| |
| | |
| === SCMI ===
| |
| SCMI<ref>https://developer.arm.com/architectures/system-architectures/software-standards/scmi</ref> specification defines a standard to access resources for power, performance and system management. This framework is an ARM<sup>®</sup> generic implementation.<br>
| |
| SCMI protocols can be used to create device interfaces for external resource that are controlled by a SCMI server implementation. Targeted devices are of, not limited to:
| |
| * Power domain management
| |
| * Performance management
| |
| * Clock management
| |
| * Sensor management
| |
| * Reset controller management
| |
| | |
| ==== STM32MP1 SCMI support ====
| |
| | |
| See the specific article on [[SCMI_on_STM32MP1|SCMI on STM32MP1]]. It presents
| |
| SCMI used by secure world (TF-A, OP-TEE) to expose system resources,
| |
| as input source clocks and PLL output clocks, reset controllers to non-secure
| |
| world (U-Boot bootloader, Linux kernel).
| |
| | |
| === Platform SiP and OEM SMCCC services ===
| |
| ==== STM32MP1 ====
| |
| STM32MP1 embeds SiP and OEM SMCCC services for non-secure world to access low power transition facilities, clock calibration facilities, BSEC OTP access, possibly also some test facilities.
| |
| Both TF-A and OP-TEE implement the same level of services aside possible test facilities.
| |
| | |
| == Security peripherals ==
| |
| === Cryptographic hardware acceleration ===
| |
| The STM32 MPU embeds multiple peripherals for cryptographic acceleration: <br>
| |
| * [[CRYP_internal_peripheral | CRYP]]
| |
| * [[HASH_internal_peripheral | HASH]]
| |
| | |
| === Trusted platform module (TPM) ===
| |
| The STM32 MPU can be associated to an external trusted platform module ([[STPM4RasPI expansion board|TPM]]).<br>
| |
| It provides secret data storage capabilities as well as cryptographic capabilities allowing to use them.
| |
| | |
| == Secure Secret Provisioning ==
| |
| The STM32 MPU allows to provision secrets in [[BSEC internal peripheral|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 a dedicated application note.
| |
| {{ReviewsComments|-- [[User:Gerald Baeza|Gerald Baeza]] ([[User talk:Gerald Baeza|talk]]) 15:35, 5 June 2020 (CEST)<br />Reference to be added when the AN is available}}
| |
| | |
| === Fuses provisioning in STM32MP1 ===
| |
| The build process for the TF-A SSP firmware is described [[STM32MP15_TF-A#Secure_secret_provisioning|here]].
| |
| | |
| {{InternalInfo|
| |
| Secure update
| |
| Not yet available
| |
| }} | | }} |
|
| |
|
| == References == | | == References == |
| <references /> | | <references /> |
|
| |
| <noinclude> | | <noinclude> |
| {{PublicationRequestId | 10403 | 2019-01-21 | AnneJ}}
| | [[Category:Sub-articles]] |
| [[Category:Platform security|01]] | |
| [[Category:Architecture overview]]
| |
| </noinclude> | | </noinclude> |
