Secure Boot for STM32H5

Revision as of 09:37, 26 May 2023 by Registered User
This message will disappear after all relevant tasks have been resolved.
Semantic MediaWiki
There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

Target description

1. Introduction

The secure boot is the first firmware executed after a reset and verifies the integrity of the user application(s) (check if not modified) before executing it.
It also ensures a secure firmware installation and firmware update. The integrity and authentication (identity) of the user application image(s) are verified before installation.
It also activates the security mechanisms.
This is called the Root Of Trust (ROT).

2. Secure Boot stages

The secure boot can be done in one or two stages.
The first stage is done by an immutable code (iROT). It can't be modified and must include only the mandatory services.
In a second stage (optional), more complex operations can be done. It can be updated in case of future required improvements (e.g. attack robustness improvements).

First stage: two Immutable Root of Trust (iROT) are possible for the STM32H5.

  • The STiROT: immutable code, provided by ST and integrated in the system flash of the devices supporting embedded cryptographic accelerator.
  • The OEMiROT: an OEM can develop his own boot code including similar feature than STiROT. Flash write protection is used to ensure this code can't be modified (immutable).

Second optional stage: two Updatable Root of Trust (uROT) are possible for the STM32H5.

  • STuROT: installable service provided by ST, includes module installation/update capability
  • OEMuROT: developped by 3rd party OEM and installed through the embedded bootloader

As mentioned above, the uROT has the advantage to be updatable for later modifications or improvements.

2.1. One secure boot stage

Two possible single stage boot are possible:

  • STiROT using the immutable firmware provided by ST and natively embedded in the device
  • OEMiROT immutable firmware developed and installed by an OEM.

Two possible use cases for STiROT or OEMiROT:

Case 1:
A new firmware image (encrypted and signed image containing the secure and the non-secure applications) or a new data image (encrypted and signed image) needs to be installed.

  • The iROT verifies the integrity and authentication of the image (placed in a user flash download area).
  • For a user firmware: the image is decrypted and installed in the defined execution user flash area.
  • For user data, if applicable, the image is decrypted and stored after re-encryption in a secure storage area (see article Security_with_STM32H5#Secure_storage) .


File:Boot one stage case1.png
Figure 1 STM32H5 one secure boot stage, image installation

Case 2:
A secure user application and if applicable non-secure user application is already installed in the user flash.

  • The iROT verifies the integrity before the user firmware execution, so it ensures that this firmware has not been modified.
File:Bootpath0.png
Figure 2 STM32H5 one secure boot stage, application already installed

2.2. Two secure boot stages

For two secure boot stages first the iROT is executed followed by the uROT.

  • Role of the iROT (STiROT or OEMiROT):
    • The iROT ensures the secure installation of the uROT through verification of the integrity and authenticity of the uROT firmware.
    • The iROT verifies the integrity of the uROT before executing the uROT firmware.
    • The iROT is only insuring the secure execution of the next boot stage (uROT)
  • Role of the uROT (STuROT or OEMuROT)
    • The uROT verifies the integrity and authentication of the user application firmware images (secure and non-secure) and the user data image (if applicable) before installing it.
    • The uROT verifies the integrity of the user application firmware (secure and non-secure) before allowing the execution.


File:Bootpath0 urot.png
Figure 3 STM32H5 two secure boot stage

3. State after reset and Isolation levels

A secure boot is guaranteed through the isolation levels (HDPL).
The HDPL levels are related to customer use cases requiring security.
So a user don't need to take care of the HDPL level if no iROT and uROT (optional) is used with a product in OPEN state. (see Introduction_to_Silicon_device_life_cycle article


  • The HDPL is controlled trough a protected hardware block SBS (System Boot and Security).
  • The HDPL level is defined by a monotonic counter, incremented during the boot stages.
  • A power-on or system reset is needed to reset the HDPL counter.
  • The access and execution rights are defined for each isolation levels.
  • At a specific HDPL level, the code and related secrets of the previous HDPL levels can't be accessed.
File:HDPL.png
Figure 4 STM32H5 HDPL levels


  • Level 0 (HDPL0): never erased, reserved for system flash memory
    • The RSS (Root Security Service) includes
      • The RSSFS (Root Security Service First Stage) embedded in the system flash. It is an immutable code programmed by ST.
      • The RSSe (RSS extension) loaded and installed in SRAM .
    • When the device is in PROVISIONING product state and the TrustZone is enabled, the boot of the device will be automatically forced through the RSS
    • The RSS is used to install securely an extension (for instance allowing the provisioning of a device)
  • Level 1 (HDPL1): immutable Root of Trust, iROT: STiROT (embedded natively in system flash, fixed and never erased) or OEMiROT (user flash, installed by OEM)
  • Level 2 (HDPL2): updatable Root of Trust, uROT, further optional boot stage: OEMuROT (user flash, installed by OEM) or STuROT (installable service provided by ST)
  • Level 3 (HDPL3): secure user application code (protected through TrustZone), non-secure user application code
    • If the uROT is not present, the STiROT/OEMiROT will directly call the secure application. In this case, the user application can be in HDPL2 or in HDPL3

Notes:

  • For one stage secure boot (no uROT), the user can chose to execute the user application(s) in HDPL2 or in HDPL3. In HDPL2 a debug authentication is needed to access to the code as soon as the device is in another state than OPEN. In HDPL3, the debugger stays open for the non-secure application in PROVISIONING, PROVISIONED and in TZ-Closed states (see Debug_Authentication article and Product life-cycle phases table in RM0481 and RM0492). So the HDPL3 gives a higher flexibility for debugging a user application(s) under development.
  • For the STM32CubeFW examples without secure boot stage (no iROT and no uROT), the user application is running by default in HDPL1. In this case, for product state different than OPEN, a debug authentication is needed to access to the debugger (see Debug_Authentication_for_STM32H5_MCUs article).


4. The different possible boot paths depending on the STM32H5 series

This section explains the possible boot paths and the limitations, depending on the product series.
Some devices don't support the embedded hardware cryptography or the Trust Zone.

  • The STM32H57 is supporting TrustZone and hardware cryptography, so all boot paths are possible with this device
  • The STM32H56 is supporting TrustZone but not the hardware cryptography (without export control constraints), so the STiROT (ST immutable Root of Trust) and the secure manager are not supported.
  • The STM32H503 is not supporting TrustZone and not supporting the hardware cryptography (without export control constraints), limiting the possible use cases as explained in next sections.

The boot path is selected through option bytes programming, as explained in next sections.

For explanations about the secure manager, please refer to the following articles:

4.1. STM32H57 Boot paths

The STM32H57x serie supports services embedded in the system flash (RSS, STiROT), services developed by an OEM (OEMiROT, OEMuROT) and services provided by ST that can be installed (STuROT, ST-SecureManager).

The embedded hardware cryptography accelerator is used for integrity and authentication verification.
The figure below shows the possible boot paths selected through the related user option bytes.

  • When TrustZone is enabled (TZEN) the Unique Boot Entry (UBE) is selecting which secure boot is executed after reset (STiROT or OEMiROT).
  • This figure shows also the optional Updatable Root Of Trust (uROT), which is a second possible boot stage.


File:Bootpath1.png
Figure 5 STM32H57 possible boot paths

The figure below gives another view of some possible boot paths for the STM32H57 serie.

File:STM32H57 boot.png
Figure 6 STM32H57 boot
  • When TrustZone is enabled:
    • If STiROT is selected (UBE=0xC3): the STiROT embedded firmware located in the system flash is executed after reset.
    • If OEMiROT is selected (UBE=0xB4): the OEMiROT located in the user flash is executed after reset. The address is defined by the SECBOOTADD option byte (default value 0x0C00 0000) (see RM0481)
    • Note: as mentioned in figure 4, a second boot stage (OEMuROT) is not mandatory
  • When TrustZone is disabled:
    • OEMiROT located in the user flash will be executed after reset. The address is defined by the NSBOOTADD option byte (default value 0x0800 0000).
    • Note: as mentioned in figure 4, OEMiROT and OEMuROT are not mandatory, so it's also possible to have only a non-secure user application code.
    • Note:when TrustZone is disabled, it's not possible to have secure user application code.

4.2. STM32H56 Boot paths

The STM32H6x is not supporting the STiROT and STuROT because the cryptographic hardware accelerator is not supported.

Without hardware cryptographic accelerator, the authentication and integrity verification are ensured using the middleware cryptographic library.
The figure below shows the remaining possible bootpaths.

  • When TrustZone is enabled (TZEN) the OEMiROT is executed after reset.
  • This figure shows also the optional Updatable Root Of Trust (uROT), which is a second possible boot stage.


File:Bootpath2.png
Figure 7 STM32H56 possible bootpaths
File:STM32H56 boot.png
Figure 8 STM32H56x boot
  • When TrustZone is enabled:
    • The boot is in the user flash and the address is defined by the SECBOOTADD option byte (default value 0x0C00 0000) (see RM0481)
    • Note: as mentioned in figure 6, a second boot stage (OEMuROT) is not mandatory
  • When TrustZone is disabled:
    • The boot is in the user flash and the address is defined by the NSBOOTADD option byte (default value 0x0800 0000)
    • Notes:
      • As mentioned in figure 6, OEMiROT and OEMuROT are not mandatory, so it's also possible to have only a non-secure user application code.
      • When TrustZone is disabled, it's not possible to have secure user application code.
      • A non-secure user application doesn't mean that it can't be protected. Protection can be done through product state setting (see RM0481).

4.3. STM32H50x Boot path

The STM32H50x supports temporal isolation (HDPL) (as for the other STM32H5).
The figure below shows that with STM32H50x the boot can be done through up to three isolated stages.

For STM32H50x, the TrustZone disabled is the only supported boot path. (see figure 5).
A secure user application is not supported since TrustZone is disabled.
With TrustZone disabled it's possible to have only a non-secure user application (OEMiROT and OEMuROT are optional).
Note: it is possible to protect the non-secure user application through setting of the product state (see RM0492)


File:Bootpath3.png
Figure 9 STM32H50 possible boot paths
File:STM32H503.png
Figure 10 STM32H503 boot
  • The Boot is from the user Flash and the boot address is defined by the NSBOOTADD (boot address option byte, see RM0492)



Retrieved from "https://wiki.st.com/stm32mcu/index.php?title=Security:Secure_Boot_for_STM32H5&oldid=34308"