Registered User |
Registered User |
| (26 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| {{ReviewsComments|-- [[User:Lionel Debieve|Lionel Debieve]] 07:42, 5 November 2021 (CET)<br />To be updated}} | | <noinclude>{{ApplicableFor |
| | |MPUs list=STM32MP13x, STM32MP15x, STM32MP25x |
| | |MPUs checklist=STM32MP13x, STM32MP15x, STM32MP25x |
| | }}</noinclude> |
| | |
| == Article purpose == | | == 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.<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> |
| == Introduction ==
| | Click on the following figure to explore them. |
| The STM32 MPU is based on the Arm<sup>®</sup> Cortex<sup>®</sup>-A core, which is using 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>
| |
| | |
| Arm-v7A 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=]]
| |
| | |
| The '''normal world''' is used to run rich OSs such as [[STM32 MPU Linux kernel overview|Linux Kernel]] and its [[Linux application frameworks overview|applications framework]].<br>
| |
| The '''secure world''' runs a secure monitor with minimal services (i.e. [[#TF-A|TF-A SP_MIN]]) or a TEE as secure OS (i.e. [[#OP-TEE_OS|OP-TEE OS]]).<br>
| |
| | |
| <br />
| |
| 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 />
| |
| | |
| 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 />
| |
| | |
| 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 />
| |
| <br />
| |
| | |
| 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_chain_overview|trusted boot chain]] is designed 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 ===
| |
| The STM32MP1 secure boot implementation is described in :
| |
| * the [[STM32 MPU ROM code secure boot]] article for the [[STM32_MPU_ROM_code_overview|ROM code]] authentication process based on STM32 header.
| |
| * the [[TF-A_BL2_overview#Trusted_boot_support|TF-A BL2 trusted boot]] management using [[How to configure TF-A FIP|FIP]] authentication mechanism.
| |
| * the [[How_to_protect_the_coprocessor_firmware|coprocessor]] authentication.
| |
| | |
| == 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 ===
| | {{ImageMap|Image:Security_summary.png |
| Debug accesses are controlled through [[BSEC internal peripheral|BSEC]] peripheral.<br>
| | rect 690 161 969 194 [[Category:Secure_boot | Secure boot]] |
| By default, the STM32 MPU is started by the [[STM32_MPU_ROM_code_overview|ROM code]] with both secure and non-secure debug enabled.
| | rect 830 236 1110 270 [[Secure_Firmware_Update]] |
| When the trusted boot is enabled, the [[STM32_MPU_ROM_code_overview|ROM code]] disables debug accesses and relies on secure OS to configure them.
| | rect 891 311 1170 345 [[Device life cycle | Device life cycle]] |
| When a FSBL debug is required, a [[Wrapper_for_FSBL_images|dedicated wrapper]] exists (that can be also signed) to open the debug.
| | rect 893 386 1172 418 [[Category:Context_isolation | Isolation]] |
| | | rect 821 460 1099 494 [[Category:Platform_security | Secure Storage]] |
| == Secure and non-secure worlds==
| | rect 690 535 969 568 [[Category:Platform_security | Crypto Engine]] |
| 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.
| | rect 285 535 563 568 [[Secure Secret Provisioning (SSP) overview]] |
| | | rect 133 460 412 493 [[Category:Platform_security | Identification/Authentication]] |
| 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.
| | rect 77 385 355 418 [[Category:Platform_security | Software IP Protection]] |
| | | rect 77 311 355 344 [[Category:Abnormal_situation_handling]] |
| 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.
| | rect 146 236 424 270 [[Category:Platform_security | Audit/log]] |
| | | rect 285 161 563 194 [[Category:Platform_security | Application Life Cycle]] |
| === TF-A SP_MIN runtime services ===
| |
| 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 [[How to configure TF-A SP-MIN|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, such as running trusted applications and possibly generic services used by standard non-secure components such 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.
| |
| | |
| These accesses are using the SMC Calling convention <ref name=smccc>https://developer.arm.com/documentation/den0028/latest/</ref>
| |
| | |
| {| class="st-table"
| |
| !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
| |
| |}
| |
| | |
| === 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 SP_MIN and OP-TEE implement PSCI v1.1 <ref>https://developer.arm.com/docs/den0022/latest</ref> and offer standard services for:
| |
| * Core idle management
| |
| * Boot up for secondary boot core
| |
| * Dynamic addition and removal of cores
| |
| * System shutdown and reset
| |
| | |
| === SCMI ===
| |
| The 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
| |
| | |
| The SCMI specification does not specify the SMC IDs to use. It relies on specific OEM IDs.
| |
| | |
| ==== STM32MP1 SCMI support ====
| |
| | |
| See the specific article on [[SCMI overview]]. It presents
| |
| SCMI used by the secure world (TF-A SP_MIN, 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 ====
| |
| The 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.
| |
| | |
| {| class="st-table"
| |
| !Identifier !! Name !! Description
| |
| |-
| |
| | 0x82001000 || RCC || Access restricted to CIER/CIFR registers
| |
| |-
| |
| | 0x82001001 || PWR || Access restricted to CR3/WKUPCR/MPUWKUPENR registers
| |
| |-
| |
| | 0x82001002 || RCC Calibration || Secure services to start a HSI or CSI calibration
| |
| |-
| |
| | 0x82001003 || BSEC || Secure service to access OTP (read/write/programmation)
| |
| |-
| |
| | 0x82001008 || PD_DOMAIN || Access to program the power domain for low-power management
| |
| |-
| |
| | 0x82001009 || RCC OPP || Access to program CPU frequency
| |
| |-
| |
| | 0x82002000 || SCMI_AGENT0 || Access to SCMI services Channel 0
| |
| |-
| |
| | 0x82002001 || SCMI_AGENT1 || Access to SCMI services Channel 1 (MCKPROT Resources)
| |
| |}
| |
| <br>
| |
| {{InternalInfo| Test services:
| |
| * 0x8300f100 : TEST_BSEC : Extended tests for OTP management (to be removed)
| |
| * 0x8300f200 : TEST_ETZPC : ETZPC SoC IP verification (Valid Only)
| |
| * 0x8300f300 : ETZPC : Dynamic configuration for IPs (required for valid Kernel)
| |
| * 0x8300f400 : TEST_TZC : Secure service to access OTP (read/write/programmation)
| |
| * 0x8300f500 : TEST_RTC : To remove
| |
| * 0x8300f600 : TEST_RCC : To remove
| |
| * 0x8300f700 : TEST_TAMP : Test Tamper mode (limited to Monotonic and RTC)
| |
| * 0x8300f800 : TEST_LP_FORCE_PARAM : Force low power param
| |
| * 0x8300f900 : TEST_RESET_A7 : Trigget a CPU reset
| |
| * 0x8300fa00 : TEST_SET_CALIB : Start calibration
| |
| * 0x8300fb00 : DDR_CHECKSUM : Enable DDR checksum
| |
| * 0x8300f800 : TEST_DDR : Access to SCMI services Channel 1 (MCU resources)
| |
| }}
| |
| | |
| == 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.
| |
| | |
| === 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.
| |
| | |
| ==== STM32MP1 ====
| |
| The tamper configuration is described in [[STM32MP15 Tamper configuration]].
| |
| | |
| == Secure Secret Provisioning ==
| |
| The STM32 MPU allows secrets to be provisioned 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 [[STM32_MPU_ROM_code_overview|ROM code]] and a customized [[How to configure TF-A BL2#Secure_secret_provisioning | 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 [[STM32MP15 resources#AN5510|AN5510: Overview of the secure secret provisioning (SSP) on STM32MP1 Series]].
| |
| | |
| === Fuses provisioning in STM32MP1 ===
| |
| The build process for the TF-A SSP firmware is described [[How to configure TF-A BL2#Secure_secret_provisioning|here]].
| |
| | |
| {{InternalInfo|
| |
| Secure update
| |
| Not yet available
| |
| }} | | }} |
|
| |
|
| == References == | | == References == |
| <references /> | | <references /> |
|
| |
| <noinclude> | | <noinclude> |
| {{PublicationRequestId | 19287| 2021-03-10 | AnneJ}}
| | [[Category:Sub-articles]] |
| [[Category:Platform security|01]] | |
| [[Category:Architecture overview]]
| |
| </noinclude> | | </noinclude> |
