The STM32H5 was designed to radically improve the security on the STM32 product family, taking into account experience gained with previous Cortex-M33 microcontrollers, customer feedback and requirements to achieve highest PSA certification levels. This article is intended for readers who already have previous knowledge of the STM32 MCUs together with their security features, and want to focus on the specific updates and changes introduced in the STM32H5 series.
Most notable security-related innovations of the STM32H5 are the debug authentication and the lifecycle management using product state. Learning about these is a basic requirement even for the most elementary security. The secure storage, secure boot options and the security ecosystem are the next steps in the learning process.
For general STM32 security see this article or AN5156.
For more details on each particular security topic, there is more documentation available in the form of: the product reference manual, user manuals and application notes.
There are 3 distinct STM32H5 lines:
| STM32H5 MCU line | Security features |
|---|---|
| STM32H503 | Product state management with provisioning, temporal isolation, boot lock, write protection |
| STM32H563 | STM32H503 + TrustZone® |
| STM32H573 | STM32H563 + Cryptography, SAES and secure (key) storage |
This article focuses on the most featured sales type, but important differences in the former two will be highlighted.
1. Debug Authentication (DA)
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. DA feature of the STM32H563 is virtually the same as in case of the STM32H573, only uses different encryption option.
2. Product state
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. 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.
3. Temporal isolation (HDP)
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 (system configuration, boot and secure storage) internal functional block, maintaining monotonic counter preventing lowering the level without proper reset. The option bytes (HDPx_STRT and HDPx_END) 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 of HDPx_EXT. 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.
4. Secure storage (OBK)
Secure storage is, simply put, 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. The OBK is not available at all on the STM32H503. 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.
5. The secure boot ecosystem
5.1. Selection of boot address
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 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.
The option bytes determine from which memory the device boots from. With default state ( product state Open, TZ disabled, unique boot entry disabled ) the device uses user flash memory in the non-secure address range, the 0x0800 0000 starting point, which is common with other STM32 MCUs. It is also possible to use the usual bootloader. This is also the only option for the STM32H503 devices.
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.
Lastly, if the device is reset in Provisioning product state, the RSS (root secure services) part of system flash memory is given control. The sole purpose of it is to finish the provisioning and change to state to the next in the lifecycle. No user code can be executed on the STM32H5 in Provisioning state.
5.2. Secure boot progression in software
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 introduction to ST-iROT onSTM32H573. The dashed arrows represent optional divergence, which is available when the product be configured as such. It is always possible to choose the customized secure environment. But of course the STM32H56x MCUs do not have the option to load the Secure Manager and the STM32H503, with TrustZone® forced to disabled, only the lowest path is possible.
6. What is replaced on the STM32H5 MCUs
The STM32H5 is the peak in STM32 general purpose microcontroller family security. However coming from other STM32, users may find some security features missing. That is the case of old approach to security being replaced with newer and better methods.
- The replacement of RDP (read-out protection) by the PRODUCT_STATE scheme was already covered. There is no direct replacement for RDP1, which allowed to set read protection on the non-volatile memory only with possibility of removal on condition of mass erase. With PRODUCT_STATE, it is not possible to carry out a mass erase of a closed product without a successful debug authentication.
- PCROP was removed. This extension to RDP prevented even the code running on the device from reading certain areas of the internal flash memory. Obviously this feature is redundant with the availability of TrustZone® and HDP.
- Firewall was removed. This feature was introduced on the STM32L4 and used extensively in SBSFU. Also replaced by the TrustZone®.
7. Changes in the existing security functions
A summary of common security features across the STM32 family, and how they appear in the STM32H5. For introduction on these features, look at this guide.
7.1. Secure hardware architecture (SBS)
In contrast to the STM32L5 and the STM32U5, the security configuration is now concentrated around protected registers in the SBS (system configuration, boot and security) block. Concentrating the security related configuration to a single place reduces the attack surface and makes the protection more efficient.
This block takes care of:
- System configuration - including register access control
- Boot control - interpreting settings from option bytes and managing the temporal isolation
- Debug control - making sure only legitimate debug access is allowed
- Hardware storage control - managing the secure storage components (EPOCH, SAES, OBK, HUK)
7.2. MPU
Up to eight MPU regions can be defined with TrustZone® deactivated, twelve with TrustZone® enabled.
7.3. WRP
Flash write protection is configured in a bitmap fashion, with a granularity of 4 sectors (32kB per configuration bit). The configuration is entered using OB.
Also the SRAM2 features write protection, bits of write protection configuration each represent 1kB of the total 64kB (or 16kB in case of STM32H503) of the SRAM2 memory.
7.4. OTP
One-time programmable flash memory area is 2kB, programmable by 16bit word at the time. It has a locking mechanism, and a separate write protection. Each bit of the locking OB word locks a block of 32 OB words from modification.
On the STM32H503, a block of the OTP is used to perform the provisioning, and storing a HASH of the password needed for regression.
7.5. OTFDEC
The underlying communication interface is now called XSPI, to prevent confusion when more SPI lines are added. This would be a universal title for OCTOSPI, QUADSPI, and any other number of lines.
The IP is practically identical to the one used in STM32U5, but the secure storage (OBK) expands application possibilities of the external memory. It's possible to use the OBK to store OTFDEC keys and only reveal them in safe condition, improving the overall security.
7.6. AES/SAES
Taking the STM32U5 series as baseline for the comparison, the interface remains the same, but the speed is increased. The SEAS now supports more operating modes and again, the ability to work in close cooperation with the secure storage (OBK) is a big improvement for the overall application security.
7.7. PKA
Public key cryptography has more capability compared to the STM32L4Px and STM32L4Qx, providing more functions, with larger keys and with greater resistance to SCA. But the features remain the same as STM32U5, apart for the speed increase due to higher clock.
7.8. Tamper
Apart for the 8 usual external tamper sources, the STM32H5 allows monitoring up to 15 internal test points with tamper detection, newest addition being the HSE presence guard, enhancing the security already provided by the CSS. There are 32 tamper protected registers of 32 bits. It is the most advanced anti tamper built to STM32 to date.