Secure Boot for STM32H5

Secure Boot for STM32H5

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 first secure boot stage is done by an immutable code.
This code can't be modified (immutable) and must include only the mandatory services.
More complex operations can be done in a second boot stage that can be updated in case of future required improvements (e.g. attack robustness improvements).

Two possible Immutable Root of Trust 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).

A second secure boot stage is possible (optional) through the Updatable Root of Trust (uROT). Two possible uROT:

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

File:Bootpath0.png

Figure 1 STM32H5 one secure boot stage

• Two possible use case:
  • 1) A new firmware image or data image needs to be installed (encrypted and signed image).
    
    • The iROT verifies the integrity and authentication of the image (placed in a user flash download are).
    • 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 (detail explanations is given later in this article)
  • 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,

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.
• Role of the uROT (STuROT or OEMuROT)
  • The uROT verifies the integrity and authentication of the user application firmware images and user data image (if applicable) before installing it.
  • The uROT verifies the integrity of the user application firmware before allowing the execution.

File:Bootpath0 urot.png

Figure 2 STM32H5 two secure boot stage

The following sections explains the possible bootpathes and the limitations depending on the product serie.

3. The different possible bootpaths depending on the STM32H5 series

The possible bootpaths are depending on the chosen device, if it supports the embedded hardware cryptography and if Trust Zone is activated or not.

• The STM32H57 is supporting TrustZone and hardware cryptography, so all bootpathes 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 bootpath is selected through option bytes programming, as explained in next sections.

3.1. STM32H57 Bootpaths

The STM32H57x serie support services available in the embedded system flash and services that can be installed. (add link to secure manager intro)
The embedded hardware cryptography accelerator is used for integrity and authentication verification.
The figure below shows the possible bootpaths selected through the related user option bytes.

File:Bootpath1.png

Figure 3 STM32H57 possible bootpaths

As shown in the above figure, when Trust Zone is enabled (TZEN=1) 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.

The figure below gives another view of the possible bootpaths for the STM32H57 serie.

File:STM32H57 boot.png

Figure 4 STM32H57 boot

• When the TrustZone is enabled (TZ=1):
  • 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 figure3, a second boot stage (OEMiROT) is not mandatory
• When the TrustZone is disabled (TZ=0):
  • 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 figure3, OEMiROT and OEMuROT are not mandatory, so it's also possible to have only a non-secure application code

3.2. STM32H56 Bootpaths

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.

File:Bootpath2.png

Figure 2 STM32H56 possible bootpaths

File:STM32H56 boot.png

Figure x STM32H56x boot

• When TrustZone is enabled (TZ=1) the boot is in the user flash and the address is defined by the SECBOOTADD option byte (default value 0x0C00 0000) (see RM0481)
• When TrustZone is disable (TZ=0) the boot is in the user flash and the address is defined by the NSBOOTADD option byte (default value 0x0800 0000)

3.3. STM32H50x Bootpath

The STM32H50x is not supporting the STiROT and STuROT because the cryptographic hardware accelerator is not supported.
The activation of TrustZone is not supported with consequence that a secure user application is not possible.

File:Bootpath3.png

Figure 4 STM32H50 possible bootpaths

File:STM32H503.png

Figure x STM32H503 boot

• The Boot is from the used Flash and the boot address is defined by the NSBOOTADD (boot address option byte, see RM0492)

4. State after reset and Isolation levels

A secure boot is guaranteed through the isolation levels (HDP).
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 5 STM32H5 HDPL levels

• Level 0 (HDPL0): reserved for system flash memory
• Level 1 (HDPL1): user flash memory starts fully accessible
• Level2 (HDPL2): Option Bytes based HDP area protected
• Level3 (HDPL3): HDPx_EXT sectors are additionally protected