Security with STM32H5

This article contains an overview of the security features[1] available on STM32H5 MCUs. The table below contains detailed information based on the different product lines.

Security features embedded on: STM32H503 picto.png STM32H523 picto.png STM32H533 picto.png STM32H563 picto.png STM32H573 picto.png
Secure Boot and Firmware Update YES YES YES YES YES
Secure manager NO NO NO NO YES
Secure provisioning NO NO YES NO YES
Initial attestation NO NO NO NO YES
Cryptography YES YES YES YES YES
Crypto libraries YES YES YES YES YES
Silicon device life cycle YES YES YES YES YES
Product state YES YES YES YES YES
Debug authentication YES YES YES YES YES
Secure manufacturing YES YES YES YES YES
Provisioning YES YES YES YES YES
Secure storage NO YES YES YES YES

1. Secure Boot and Firmware Update

Boot lock and HDP features are available on STM32H5 MCUs, allowing the development of the Secure Boot system.
TrustZone® runtime isolation is possible starting from the STM32H563 and STM32H523 lines, allowing the development of the TF-M based Secure Boot (mcuboot) to implement the PSA.
SAES and hardware cryptography, native STiRoT are options available on the STM32H533.
SAES and hardware cryptography, native STiRoT, and the Secure manager are only available on the STM32H573 top line.
In any case, Secure Boot is a sequence starting from a fixed starting point, configured and locked using option bytes. As the Secure Boot progresses, the basic and immutable firmware (iRoT, immutable Root of Trust) updates or validates the updatable part of the Secure Boot progression, which is called uRoT (updatable Root of Trust). This increases the HDP temporal isolation to level 2 when giving control to the next chain link.
Finally, the uRoT updates or executes an application or an operating system, either secure or nonsecure, in HDP level 3.

STM32H57x boot path

1.1. SBSFU legacy

STM32H5 MCUs do not support legacy SBSFU [2].

1.2. SBSFU by MCUboot

STM32H503 picto.png
Adapted for parts without TrustZone® support. SBSFU by MCUboot can also be used on STM32H503 product lines. However, there are some limitations compared to larger devices.
STM32H523 picto.png STM32H563 picto.png
SBSFU variant with TrustZone® support, based on the PSA TF-M mcuboot model. This is the tier of Secure Boot and field upgrade intended for the STM32H523 and STM32H563 product lines.
The Secure Boot starts in the user flash memory on a secure address range, starting from 0x0C00 0000, where it is assumed that there is an OEMiRoT or another chosen secure software [3].
STM32H533 picto.png STM32H573 picto.png
The crypto parts support the option to use STiRoT, which is an initial step in the secure boot solution with the Secure manager.

1.3. STiRoT STM32H533 picto.png STM32H573 picto.png

With TrustZone® enabled, the device starts the Secure Boot procedure.
In the case of STM32H533 and STM32H573, they evaluate the Unique Boot Entry (UBE) option byte setting, to determine whether STiRoT is the selected boot option.
From the STiRoT[4][5][6], the Secure Boot also continues in the user flash memory, by either using the STMicroelectronics installable services, like Secure Manager, or customized code. From the Secure Boot chain point of view, the latter is an OEMuRoT.

STM32H57x boot path software part

Depending on the selected boot address, there are different options for Secure Boot progression.
The upper path leading to the Secure Manager is the path targeting PSA level 3 security certification. This is only available on the STM32H573 crypto product line.

2. Isolation

To support the protection of the assets from unrelated processes, several means of isolation are available on STM32H5 MCUs.
TrustZone® facilitates protection in runtime, when secure and nonsecure coexist and take turns in executing code on the CPU core. Temporal isolation on the other hand protects the boot code from being reentered in any other way than by reset.

2.1. Temporal isolation

The temporal isolation feature (HDP) has significantly evolved in STM32H5 MCUs. Still called HDP, its usability is now extended. The two most significant changes are:

  • The HDP user has now three levels available.
  • The HDP protected area now can be defined almost anywhere in the memory, independently of the secure watermark area.

The HDP is now linked to the secure storage, which is also referred to as Option byte keys (OBK).
The HDP levels are:

  1. Level 1 - Level used by the Secure Boot. For example, iRoT, if STiRoT is used. This level is not accessible to the user.
  2. Level 2 - Level used by the later stages of the Secure Boot. For example, uRoT (updatable Root of Trust).
  3. Level 3 - Final level in which the product will end up once the Secure Boot phase is concluded.

Locking out the lower levels is under the control of the SBS, maintaining monotonic counter preventing lowering the level without proper reset. The option bytes define the start and the end of the HDPL1 reserved area in each flash memory bank, with sector granularity. Accessible part of the system flash memory contains a callable function that facilitates the transition. The system service to increase the level increases the monotonic level counter and jump to the desired address in the Level 2 area.

The threshold between HDPL2 and final HDPL3 is a register value:

  • This is the number of sectors past the end of the HDPL1 lockout area that will also be rendered inaccessible until the next reboot.
  • It is volatile and needs to be set every time the transition is needed.
  • The value has dual protection: Once set, it can never be decremented, and it cannot be modified at all once the transition to HDPL3 is done.
HDP protection configuration example

2.2. TF-M

Trusted firmware-M is a security framework proposing a solution to among else Secure Boot and secure field upgrade on embedded devices with special focus on IoT applications[7][8].

2.3. Secure manager

STM32H573 picto.png
Secure Manager is an easy-to-use proprietary implementation of the PSA API, which is specifically optimized for STM35H5 MCUs. By using the Secure Manager, the user benefits straight away from an easy-to-use certified security, without the need for an additional investment[9].

2.3.1. IP protection

STM32H503 picto.png
If all the firmware in the microcontroller is trusted (single-tenant protection), and for simple IP protection, the Closed state is used as IP protection. The Closed state protects the content from the outside world.
STM32H523 picto.png STM32H533 picto.png STM32H563 picto.png

The Trustzone® isolation between secure and nonsecure allows IP protection implementation, where secure firmware IP is protected from the nonsecure application code. This isolation extends to debugger access to the nonsecure application as well.
STM32H573 picto.png
The STM32Trust TEE secure manager (STM32TRUSTEE-SM) is a suite of system-on-chip security solutions that brings multi-tenants IP protection. Secure manager development kit (SMDK) can be used to develop modules that will be mutually isolated thanks to Secure Manager. Secure manager is built on a Secure Boot and provides high level of confidence in protecting assets. User application can rely on the Secure manager modules to encrypt data, authenticate a communication counterpart or signed data blob, exchange keys or issue digital signatures with provided certificates.

2.3.2. Secure provisioning

Secure provisioning is a prerequisite for the Secure manager to be operational on the device.
Secure manager cannot be installed on the device in the Open product state.
When developing for Secure manager, the device is in TZ-Closed product state. This means that the services of the Secure manager run isolated in the secure domain while the user can only debug the nonsecure domain, where the application code is.
The provisioning is a process in which all the prerequisites are set, including useful optional provisioning such as the Debug authentication before the Secure manager package is installed.

2.3.3. Initial attestation

Attestation is a standard part of the PSA API. Secure manager provides attestation.
The device is able to correctly sign the challenge with a token using the IAK (initial attestation key), as a proof of performed a Secure Boot using correct software and hardware.

2.3.4. SMAK

SMAK stands for Secure manager access kit.
This is a package that can be downloaded and used by anyone who wishes to use Secure manager with STM32H573 MCUs.
SMAK allows and helps with the development of applications using the Secure manager for security services.

2.3.5. SMDK

Stands for Secure manager development kit, a program for professional security developers.
Upon contacting STMicroelectronics and agreeing on signing an NDA, these can develop Secure manager modules, which can expand the secure domain code with new API and functionality. Each module runs isolated from the other modules, to prevent compromising the security of existing modules.

3. Cryptography

Means of performing cryptography depends on the STM32H5 product line.

STM32H503 picto.png STM32H523 picto.png STM32H563 picto.png
Software libraries are available.

STM32H533 picto.png STM32H573 picto.png
Hardware cryptographic accelerators are available for both symmetric (AES) and asymmetric cryptography.
STM32Cube HAL can be used to work with the crypto IP.

3.1. ST crypto lib

ST crypto library v4[10] is available for the STM32H5 MCUs. ST crypto library is closed-source, but it can be added to the project easily, and it is downloadable together with many examples.

3.2. Crypto libraries

Third-party libraries such as Mbed™ exist for STM32H5 MCUs.
Mbed™ library implements PSA crypto API which makes it well suited for TF-M related projects. Mbed™ is distributed as source code.
Mbed™ port working with STM32H5 MCUs is distributed with the STM32H5 Cube intro package.

4. Silicon device life cycle

STM32H5 MCUs have deeply changed the device life cycle management.

4.1. Legacy RDP

Product state is a system that replaces the old RDP (read protection) mechanism provided by the life cycle management:
STM32L5 MCUs introduced the RDP0.5. STM32U5 MCUs introduced the much needed rollback mechanism for debug authentication.
When comparing the Product State with the legacy RDP mechanism, Open state is equivalent to RDP0 and Locked (Closed) state is equivalent to the RDP2. There is no direct equivalent of the RDP1 in the Product State.

4.2. Product State

Rather than only extending the RDP with necessary intermediate states, complete replacement makes introduction of new features easier to understand.
The basic progression now looks like this:

Product state Description Transitions possible
Open State intended for unrestricted development. HUK is hidden, user is free to experiment Provisioning, Provisioned
Provisioning (and Provisioned) States intended to establish security, install keys, the secure firmware and set the OB Closed, Locked, TZ-Closed, Regression
TZ-Closed State in which the secure environment is set and developers work only with the nonsecure domain Regression, Closed, Locked
Closed Final product delivery state - no debug access is possible Regression
Locked As closed, but with no chance for regression (as old RDP2) None
Regression (or NS-Regression) Process of reopening for debug Open or TZ-Closed, depending on regression type
Product state transitions - simplified

Note that there is no direct equivalent to the RDP1 in the new scheme. RDP1 was not suitable for development, nor good enough for serious protection.
STMicroelectronics delivers the microcontroller in the Open state. It is possible to freely manipulate option bytes, including the TrustZone® enable, to simplify development and testing, down to HDP level 1. Only part of the development closely related to the installable secure services must be done in the TZ-Closed state, when the services are actually present.
The provisioning is used to secure the product and manage control over the security. Among other settings, the debug authentication means are established in this step, meaning that the product can be set, for example, to:

  • regress back to the Open state, if the correct credentials are provided.
  • regress only to TZ-Closed on different credentials.
  • temporarily allow full debug with right credentials.
  • temporarily allow debug on a nonsecure part with different credentials.
  • create credentials that allow the delegation of the access to other users.

The product itself only has the root certificate in the Open state. All other configuration must be done through the development environment.

4.3. Debug authentication

STM32H5 devices are delivered as Open with all security deactivated. Debug authentication[11] allows the developer to establish cryptographic means to control the product state. Without diving into the technical details, the paragraph below describes the possibilities of the Debug authentication mechanism.

STM32H523 picto.png STM32H533 picto.png STM32H563 picto.png STM32H573 picto.png

Before locking the product, the developer chooses the maximum extent of future possible reopening and provisions the product with this information. Along with this setting, cryptographic authentication means are established. The developer can then perform either a product state regression or temporary debug reopening of the product, when authenticated successfully.

It is also possible to delegate the debug or regression rights using generated certificates. When generating the certificate, the delegated rights may be any subset of the original settings. For example, this way it is possible to create separate certificates for temporary debug access and for regression to Open (blank) state and provide them to different teams, according to their roles. If allowed, the teams may also delegate further, within their set limits.

In case of regression to Open state, the Debug authentication must be renewed on provisioning.
STM32H503 picto.png

The debug authentication means depends on the capabilities of the product in question. On a cryptography enabled product, it would use the secure storage and asymmetric cryptography, while on the STM32H503 the Debug authentication security is implemented as password HASH compare. The HASH is stored in OTP area, meaning that once the Debug authentication is set, it is permanent.

4.3.1. Debug reopening

Debug reopening is a temporary state in which the debug is permitted on a Closed state product, after successful debug authentication. It is possible to reopen only the nonsecure isolation domain or the whole product.

4.3.2. Regression

Regression allows reopening the product, by changing the Product State to Open. All secure storage contents are invalidated and cannot be reused even if the same set of keys are used in provisioning.

5. Secure manufacturing

Mass production of devices is often outsourced and sometimes the contractual manufacturer cannot be fully trusted with sensitive provisioning data or binaries. They may produce copies of the original product for alternative market, compromise the devices or simply not prevent the data from leaking outside. STMicroelectronics provides tools to prevent such situation and protect OEM IP.

5.1. SFI

Secure Firmware Install (SFI) uses the STM32 Trusted Package Creator tool and a HSM (hardware secure machine) to encrypt the install package, authenticate the genuine STM32 device for installation and limit the installation number to a planned number.
For further details, refer to UM2238[12] and AN5054[13].
Useful links:

5.2. SFIx

SFIx extends the SFI with support of external memories connected to the STM32 device. It uses the same tools as the regular SFI.

5.3. Provisioning

Provisioning is the process of installing keys, certificates, and settings to the product. It is written either to an OTP memory or to the OBK storage, if available. It is also done using the HSM, especially in case of STM32H5 devices where it is, in this context, effectively part of the SFI.

6. Secure storage

6.1. OBKeys

Secure storage is based on a sector of nonvolatile memory with special access rules:

  • It is primarily intended as key storage, despite the fact that any data can be stored there.
  • One part of it is reserved for system security management. One part is open to the user.
  • Access to the secure storage is under the control of the Flash memory, linked to temporal isolation levels.

The dedicated flash area called OBKeys is available on all STM32H5 lines except for the STM32H503. It offers to user up to 4 areas related to HDPL1, HDPL2, HDPL3S, HDPL3NS. The goal is to use them to protect Root of Trust keys and data.

OBKeys can be provisioned thanks to RSSLib->DataProvisioning() API described in the reference manual.

STM32H503 picto.png

The OBK is not available on the STM32H503 product lines.

6.2. Using SAES for secure storage

STM32H533 picto.png STM32H573 picto.png

For crypto part versions (STM32H533 and STM32H573) the keys and data can be encrypted/decrypted using DHUK corresponding to there HDPL levels. That way keys and data are protected in confidentiality including for next levels, but also are anti-rollback protected thanks to EPOCH counter (incremented during regressions).

Combining both access control and encryption using SAES brings a really high level of security that we call Secure Storage.

7. References