In this article you will access all the security features of the STM32H5
| Security functions embedded on: |  |
 |
|
|---|---|---|---|
| Secure boot and firmware update | YES | YES | YES |
| SBSFU legacy | YES | NO | NO |
| SBSFU by mcuboot | NO | YES | YES |
| STiROT | NO | YES | YES |
| Isolation | YES | YES | YES |
| HDP | YES | YES | YES |
| TF-M | NO | YES | YES |
| Secure manager | NO | NO | YES |
| IP protection | YES | YES | YES |
| Secure provisioning | YES | YES | YES |
| Initial attesation | YES | YES | YES |
| SMAK | NO | NO | YES |
| SMDK | NO | NO | YES |
| Cryptography | YES | YES | YES |
| ST crypto lib | YES | YES | YES |
| Crypto libraries | YES | YES | YES |
| Crypto lib usage | YES | YES | YES |
| Silicon device life cycle | YES | YES | YES |
| Legacy RDP | NO | NO | NO |
| Secure manufacturing | YES | YES | YES |
| SFI | YES | YES | YES |
| SFIx | YES | YES | YES |
| Provisioning | YES | YES | YES |
| Secure storage | NO | YES | YES |
| Attestation | YES | YES | YES |
1. Secure boot and firmware update 
This section is only fully applicable on the crypto parts - specifically the STM32H57x line. The boot lock and the HDP are available on all the STM32H5 series, allowing developers to develop a secure boot system. The SAES and hardware cryptography, native ST-iRoT and the subsequent option of the Secure Manager are only options in available in the STM32H57x top line.
In either case, the 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, called uRoT, updatable root of trust, increasing 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 non-secure, in HDP level 3.
1.1. SBSFU legacy
Legacy SBSFU is not yet supported on the STM32H5 family. It's use would be justified on the STM32H503, but with very limited flash size it's not practical.
1.2. SBSFU by mcuboot
SBSFU variant with TrustZone support.
1.3. STiROT
With TrustZone® enabled the device starts the secure boot procedure. In case of the STM32H57x it evaluates the UBE option byte setting to determine if ST-iRoT is the selected boot option. If not, or on the STM32H56x, the boot continues in user flash memory on secure address range starting from 0x0C00 0000, where it is assumed there is an OEM-iRoT or another chosen secure software. More details are available in Introduction to OEM-iROT on STM32H5 series
From the ST-iRoT, the secure boot also continues in the user flash memory, either using ST installable services (up to the Secure Manager), or customized code, from secure boot chain point of view the latter is an OEM-uRoT.
Depending on the selected boot address, there are different options for secure boot progression. The upper path leading to the Secure Manager is "golden". It is the path of certified PSA level 3 security, available on STM32H57x crypto line only. More details can be found in the article ST-IROT for STM32H5
- Useful links
- How to start with ST-iROT on STM32H573 help you with a typical use-case
- The article ST-iROT provide all the theory
- How to start with ST-iROT on STM32H573 help you with a typical use-case
2. Isolation
Several means of isolation are available on the STM32H5 to support protection of the assets from unrelated processing. TrustZone facilitates protection in run time, when secure and non-secure coexist and take turns in executing code on the CPU core. Temporal isolation on the other hand protects the boot code from being re-entered in any other way than by reset.
2.1. Temporal isolation
Temporal isolation feature (HDP) has significantly evolved in the STM32H5. It is still called HDP, but the usability is extended. The two most significant changes are:
- The HDP now has 3 levels available to the user
- The HDP protected area now can be defined (almost) anywhere in the memory, independently of the secure watermark area
Another novelty is that the HDP is now linked to the secure storage ( also referred to as Option Byte Keys, described later).
The HDP levels are:
- Level 1 - Level used by the secure boot, for example iRoT, if ST-iRoT is used, this level is not accessible to the user. ( More info on immutable root of trust ). OEM-iRoT may still allow applications to work in HDP level 1.
- Level 2 - Level used by the later stages of the secure boot, for example uRoT (updatable root of trust)
- 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. Open part of the system flash memory contains callable function that facilitates the transition. The system service to increase the level will increase 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 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 cannot be modified at all once the transition to HDPL3 is done.
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.
- Useful links:
2.3. Secure manager
The Secure Manager is a proprietary implementation of the PSA API, tailored for easy usage and optimized for STM35H5 specifically. Using the Secure Manager the user gets a certified security with no additional investment besides purchase of the microcontroller, which is also really easy to use.
2.3.1. IP protection
The Secure Manager is built on a secure boot and provides high level of confidence in protecting assets. User application can rely on the SM services 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
The provisioning is a necessary prerequisite for the Secure Manager to work on the device. It's not allowed to install the Secure Manager in the Open product state of the device. When developing for Secure Manager, the device is in product state of TZ-Closed. This means that the services of the Secure Manager runs isolated in the secure domain while the user can only debug the non-secure 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 DA before the Secure Manager Package is installed.
2.3.3. Initial attestation
Attestation is a standard part of the PSA API, so it's a function provided by the Secure Manager. The device is able correctly sign the challenge with a token using so called IAK (initial attestation key) as a claim that it's genuine and it performed a secure boot.
2.3.4. SMAK
Stands for Secure Manager Access Kit. This is a package which can be downloaded and used by anyone who wishes to use Secure Manager with their STM32H573. Allows and helps with development of application that uses the Secure Manager for security services.
2.3.5. SMDK
Stands for Secure Manager Development Kit. A program for professional security developers. Upon contacting ST and agreeing on signing an NDA, these can develop Modules for the Secure Manager. These Modules can expand the secure domain code with new API and functionality. Each Module runs isolated from the other modules to prevent compromising security of existing modules.
3. Cryptography
Means of performing cryptography depends on the particular STM32H5 line.
Software libraries are available.
Hardware cryptographic accelerators are available for both symmetric (AES) and asymmetric crypto. STM32Cube HAL can be used to work with the crypto IP.
3.1. ST crypto lib
ST crypto library v4 is available for the STM32H5 family. ST crypto library is closed-source, but it can be added to the project easily and is downloadable together with many examples.
- Useful links
3.2. Crypto libraries
Third party libraries such as Mbed exist for STM32H5 family. 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 family is distributed with the STM32H5 Cube intro package.
4. Silicon device life cycle
The STM32 has changed the device life-cycle management quite profoundly.
4.1. Legacy RDP
Product state is a system that replaces the old RDP (read protection) mechanism provided by the life cycle management. The STM32L5 introduced the RDP0.5, and the STM32U5 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. New Product State
. But a more radical change was necessary.
The new 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 non-secure 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 |
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.
ST 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. This means 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 non-secure part with different credentials
- Create credentials that allow the delegation of the access to other users
For more information about debug authentication see "How to start with DA access on STM32H573" and other articles.
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
This topic is closely related to the Product state. As delivered, the STM32H5 is Open with all security deactivated. Debug authentication allows the developer to establish cryptographic means to control the product state. Without diving into the technical details, which are to be explained later, read this paragraph to learn about the possibilities of the DA mechanism.
Prior to locking the product, developer chooses the maximum extent of future possible re-opening and provisions the product with this information. Along with this setting, cryptographic authentication means is established. The developer can then perform either a product state regression or temporary debug reopening of the product, when authenticated successfully.
On top of that, it's 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's 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.
The debug authentication means depends on the capabilities of the product in question. On cryptography enabled product it would use the secure storage and asymmetric cryptography, while on the STM32H503 the DA security is implemented as password HASH compare.
4.3.1. Debug Reopening
Temporary state in which the debug is permitted on Closed state product after successful debug authentication. It's possible to reopen only non-secure 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. ST provides tools to prevent such situation and protect OEM IP.
5.1. SFI
Secure Firmware Install (SFI) makes use of STM32PackageCreator tool and a HSM (hardware secure machine) to encrypt the install package, authenticate the genuine STM32 device for installation and limit the number of installation to a planned number.
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
6. Secure storage
Secure storage is, simply put, based on a sector of non-volatile memory with special access rules. It is primarily intended as key storage, though really any data can be stored there. Part of it is reserved for system security management, and part is open to the user. Access to the secure storage is under the control of the SBS, linked to the temporal isolation levels.
It is available on the STM32H56x, but the following description is only accurate for the STM32H57x crypto parts. The STM32H57x features an SAES, secure AES cryptography IP, which uses HUK (hardware unique key) to encrypt the OBK contents. As the HUK is never disclosed, and never used before provisioning, the storage of the OBK is very safe. To prevent replay attacks, the SAES is also "salting" the HUK with an EPOCH counter. EPOCH counters are monotonic, non-volatile counters, incremented on each regression.
The OBK is not available at all on the STM32H503.