Difference between revisions of "Security overview"

[quality revision] [quality revision]
m (Secure Secret Provisioning)
m
 

Contents

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[edit]

    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]

    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]

    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]

    • 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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    6.1 Cryptographic hardware acceleration[edit]

    The STM32 MPU embeds multiple peripherals for cryptographic acceleration:

    6.2 Trusted platform module (TPM)[edit]

    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]

    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]

    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]

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

    9 References[edit]

    OpentSTLinux distribution is following the STM32Trust[1] reference by integrating by default some security and secure system functionalities.
    Click on the following figure to explore them...


    Error: Image is invalid or non-existent.

    2 References[edit]

    == 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>
    
    
    == Secure boot ==
    STM32 MPU provides secure mechanism to ensure integrity and authenticity of software executed on SoC.<br>
    
    This is described in the '''[[How_to_secure_STM32_MPU|Secure boot dedicated page]]'''.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:04, 27 June 2022 (CEST)<br />will it be better to put directly page name ?}}
    
    == 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)]].
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />remove MPU in front of peripherals and interface}}
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:02, 27 June 2022 (CEST)<br />should you add information about CubeMX for firewall configuration ?}}
    
    ==== STM32MP1 firewall ====
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />firewall --> firewalls}}
    * [[ETZPC_internal_peripheral|ETZPC]]: 
    ** assigns access rights to MPU peripherals from Cortex-A7 contexts (secure or normal) and Cortex-M4 context.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />remove MPU}}
    ** assigns access rights to internal ROM/RAM from Cortex-A7 and Cortex-M4.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />ROM is controlled by ETZPC ? strange no ?, no info about A7 secure and non secure?}}
    * [[TZC_internal_peripheral|TZC]]: assigns access rights to DDR regions.
    
    Some other peripherals are not linked to firewall controller and directly embeds security management:
    * [[RCC_internal_peripheral|RCC]]: can restrict the access of some of its registers to the secure execution context.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />Cortex-A7 secure...}}
    * [[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]]: 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.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />dont catch last comment for MDMA}}
    
    == 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.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:44, 27 June 2022 (CEST)<br />temporary configuration? possible in any states?}}
    
    === STM32MP1 secure debug ===
    Debug accesses are controlled through [[BSEC internal peripheral|BSEC]] peripheral.<br>
    
    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.<br>
    
    When a FSBL debug is required, a [[Wrapper_for_FSBL_images|dedicated wrapper]] exists (that can be also signed) to open the debug.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:44, 27 June 2022 (CEST)<br />need to repeat SoC states...}}
    
    == Secure and non-secure worlds==
    Thanks to Arm<sup>&reg;</sup> [[Trustzone_environment|TrustZone]], some portions of the executing code can be assigned to a non-secure world or to a secure world.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />at processor level}}
    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.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />I think you need to correlate CPU TrustZone and firewall to mention that MPU is providing a complete isolated secure environment}}
    
    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.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />put this sentence before and add that NS bit is used by firewalls to grant access or not to the different resources previously listed}}
    
    === Secure runtime services ===
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />Secure firmware is handling secure resources like ..., but also critical system resources like ... which must be secured to guarantee the behavior of the platform. Non-secure world can access to specific services provided by secure firmware using generic 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
    |}
    
    ====OP-TEE OS runtime services====
    The [[OP-TEE_overview|OP-TEE]] is recommended by STMicroelectronics as it is an open source TEE solution. {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />it's a bit light as argument :) }}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<ref name=psci>https://developer.arm.com/architectures/system-architectures/software-standards/psci</ref> , SCMI<ref>https://developer.arm.com/architectures/system-architectures/software-standards/scmi</ref>, SiP & OEM SMCCC.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />TF-A is no more above}}
    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. {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />(RNG)}}
    <div class="mw-collapsible  mw-collapsed">
    
    ====TF-A SP_MIN runtime services====
    {{Warning| SP_MIN is tagged as deprecated}}.
    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.</div>
    
    
    ==== 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.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />why, because some registers are part of a secure group even if feature is not really}}
    
    {| class="st-table"
    !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
    |}<br>
    
    
    == Security peripherals ==
    === Cryptographic hardware acceleration ===
    The STM32 MPU embeds multiple peripherals for cryptographic acceleration: <br>
    
    * [[CRYP_internal_peripheral | CRYP]]
    * [[HASH_internal_peripheral | HASH]]
    * [[RNG_internal_peripheral | RNG]]
    * [[SAES_internal_peripheral | SAES]]
    * [[PKA_internal_peripheral | PKA]]
    
    === 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.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:01, 27 June 2022 (CEST)<br />to be moved after tamper. Moreover mention it is not allocated to secure context}}
    
    === Tamper event detection ===
    The STM32 MPU embeds [[TAMP_internal_peripheral|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.
    
    == 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.
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:05, 27 June 2022 (CEST)<br />what's the most important, secure? secret? both? way}}
    
    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]].
    
    ==Secure update==
    [[Secure_Firmware_Update|Secure firmware update]] feature is available to update firmware based on [[TF-A_BL2_overview|TF-A BL2]] A/B mechanism.
    
    == References ==<references />
    
    <noinclude>
    
    {{PublicationRequestId | 19287| 2021-03-10 | AnneJ}}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...
    
    {{ImageMap|Image:Security_summary.png
    rect 227 59 506 92 [[Security_overview]]
    rect 89 134 368 168 [[Secure_Secret_Provisioning_(SSP)]]
    rect 22 207 299 243 [[Security_overview]]
    rect 20 283 298 318 [[Security_overview]]
    rect 78 357 355 390 [[Trustzone_environment]]
    rect 227 433 508 465 [[Security_overview]]
    rect 636 59 914 92 [[How_to_secure_STM32_MPU]]
    rect 773 134 1055 165 [[Secure_Firmware_Update]]
    rect 834 207 1115 243 [[Security_overview]]
    rect 837 281 1116 317 [[Security_overview]]
    rect 765 358 1042 390 [[Security_overview]]
    rect 634 430 914 466 [[Power_overview]]
    }}
    
    == References ==<references />
    <noinclude>
    [[Category:Platform security|01]]
    [[Category:Architecture overview]]</noinclude>
    (4 intermediate revisions by the same user not shown)
    Line 1: Line 1:
     
    == 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>
      +
    Click on the following figure to explore them...
       
    == Secure boot ==
    +
    {{ImageMap|Image:Security_summary.png
    STM32 MPU provides secure mechanism to ensure integrity and authenticity of software executed on SoC.<br>
    +
    rect 227 59 506 92 [[Security_overview]]
    This is described in the '''[[How_to_secure_STM32_MPU|Secure boot dedicated page]]'''.
    +
    rect 89 134 368 168 [[Secure_Secret_Provisioning_(SSP)]]
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:04, 27 June 2022 (CEST)<br />will it be better to put directly page name ?}}
    +
    rect 22 207 299 243 [[Security_overview]]
     
    +
    rect 20 283 298 318 [[Security_overview]]
    == Firewall ==
    +
    rect 78 357 355 390 [[Trustzone_environment]]
    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)]].
    +
    rect 227 433 508 465 [[Security_overview]]
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />remove MPU in front of peripherals and interface}}
    +
    rect 636 59 914 92 [[How_to_secure_STM32_MPU]]
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:02, 27 June 2022 (CEST)<br />should you add information about CubeMX for firewall configuration ?}}
    +
    rect 773 134 1055 165 [[Secure_Firmware_Update]]
     
    +
    rect 834 207 1115 243 [[Security_overview]]
    ==== STM32MP1 firewall ====
    +
    rect 837 281 1116 317 [[Security_overview]]
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />firewall --> firewalls}}
    +
    rect 765 358 1042 390 [[Security_overview]]
    * [[ETZPC_internal_peripheral|ETZPC]]:
    +
    rect 634 430 914 466 [[Power_overview]]
    ** assigns access rights to MPU peripherals from Cortex-A7 contexts (secure or normal) and Cortex-M4 context.
    +
    }}
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />remove MPU}}
     
    ** assigns access rights to internal ROM/RAM from Cortex-A7 and Cortex-M4.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />ROM is controlled by ETZPC ? strange no ?, no info about A7 secure and non secure?}}
     
    * [[TZC_internal_peripheral|TZC]]: assigns access rights to DDR regions.
     
     
     
    Some other peripherals are not linked to firewall controller and directly embeds security management:
     
    * [[RCC_internal_peripheral|RCC]]: can restrict the access of some of its registers to the secure execution context.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />Cortex-A7 secure...}}
     
    * [[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]]: 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.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:39, 27 June 2022 (CEST)<br />dont catch last comment for MDMA}}
     
     
     
    == 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.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:44, 27 June 2022 (CEST)<br />temporary configuration? possible in any states?}}
     
     
     
    === STM32MP1 secure debug ===
     
    Debug accesses are controlled through [[BSEC internal peripheral|BSEC]] peripheral.<br>
     
    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.<br>
     
    When a FSBL debug is required, a [[Wrapper_for_FSBL_images|dedicated wrapper]] exists (that can be also signed) to open the debug.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 14:44, 27 June 2022 (CEST)<br />need to repeat SoC states...}}
     
     
     
    == Secure and non-secure worlds==
     
    Thanks to Arm<sup>&reg;</sup> [[Trustzone_environment|TrustZone]], some portions of the executing code can be assigned to a non-secure world or to a secure world.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />at processor level}}
     
    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.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />I think you need to correlate CPU TrustZone and firewall to mention that MPU is providing a complete isolated secure environment}}
     
     
     
    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.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />put this sentence before and add that NS bit is used by firewalls to grant access or not to the different resources previously listed}}
     
     
     
    === Secure runtime services ===
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />Secure firmware is handling secure resources like ..., but also critical system resources like ... which must be secured to guarantee the behavior of the platform. Non-secure world can access to specific services provided by secure firmware using generic 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
     
    |}
     
     
     
    ====OP-TEE OS runtime services====
     
    The [[OP-TEE_overview|OP-TEE]] is recommended by STMicroelectronics as it is an open source TEE solution. {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />it's a bit light as argument :) }}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<ref name=psci>https://developer.arm.com/architectures/system-architectures/software-standards/psci</ref> , SCMI<ref>https://developer.arm.com/architectures/system-architectures/software-standards/scmi</ref>, SiP & OEM SMCCC.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />TF-A is no more above}}
     
    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. {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />(RNG)}}
     
     
     
    <div class="mw-collapsible  mw-collapsed">
     
    ====TF-A SP_MIN runtime services====
     
    {{Warning| SP_MIN is tagged as deprecated}}.
     
    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.
     
    </div>
     
     
     
    ==== 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.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:00, 27 June 2022 (CEST)<br />why, because some registers are part of a secure group even if feature is not really}}
     
     
     
    {| class="st-table"
     
    !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
     
    |}
     
    <br>
     
     
     
    == Security peripherals ==
     
    === Cryptographic hardware acceleration ===
     
    The STM32 MPU embeds multiple peripherals for cryptographic acceleration: <br>
     
    * [[CRYP_internal_peripheral | CRYP]]
     
    * [[HASH_internal_peripheral | HASH]]
     
    * [[RNG_internal_peripheral | RNG]]
     
    * [[SAES_internal_peripheral | SAES]]
     
    * [[PKA_internal_peripheral | PKA]]
     
     
     
    === 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.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:01, 27 June 2022 (CEST)<br />to be moved after tamper. Moreover mention it is not allocated to secure context}}
     
     
     
    === Tamper event detection ===
     
    The STM32 MPU embeds [[TAMP_internal_peripheral|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.
     
     
     
    == 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.
     
    {{ReviewsComments|-- [[User:Loic Pallardy|Loic Pallardy]] ([[User talk:Loic Pallardy|talk]]) 15:05, 27 June 2022 (CEST)<br />what's the most important, secure? secret? both? way}}
     
     
     
    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]].
     
     
     
    ==Secure update==
     
    [[Secure_Firmware_Update|Secure firmware update]] feature is available to update firmware based on [[TF-A_BL2_overview|TF-A BL2]] A/B mechanism.
     
       
     
    == References ==
     
    == References ==
     
    <references />
     
    <references />
     
     
    <noinclude>
     
    <noinclude>
    {{PublicationRequestId | 19287| 2021-03-10 | AnneJ}}
     
     
    [[Category:Platform security|01]]
     
    [[Category:Platform security|01]]
     
    [[Category:Architecture overview]]
     
    [[Category:Architecture overview]]
     
    </noinclude>
     
    </noinclude>