Introduction to STM32H5 security

The STM32H5 is designed to radically improve the security of the STM32 product family. This takes 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 its security features, and want to focus on the specific updates and changes introduced in the STM32H5 series.
The most notable security-related innovations of the STM32H5 are the debug authentication and the lifecycle management using product state. Understanding these basic requirement is the basis for the implementation of the most elementary security. The secure storage, secure boot options and the security ecosystem are the next steps in the learning process.
Main introductory article to STM32H5 security is here. For general STM32 security see this article and AN5156.
For more details on each particular security topic, refer to the appropriate 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 + HW Cryptography, SAES and secure (key) storage, supports Secure Manager

1 Secure storage (OBK)

The ability to support secure storage by facilitating management of cryptographic keys is substantially improved on the STM32H5 through the implementation of the OBK mechanism. This makes it stand out as a differentiating feature of the STM32H5
OBK is, to put it simply, a sector of non-volatile memory with special access rules. It is primarily intended as key storage, though 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 partially functionnal on the STM32H503. It is available on the STM32H56x, but the description of secure storage is only accurate for the STM32H57x crypto parts. The STM32H57x features an SAES, secure AES cryptography IP, which uses hardware unique key (HUK) 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. This invalidates all the information stored in the OBK on regression, preventing replay attacks.
The feature is detailed in a dedicated article here.

2 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 read-out protection (RDP) by the PRODUCT_STATE scheme. 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^®.

3 Changes in the existing security functions

The following section is a summary of common security features across the STM32 family, and how they appear in the STM32H5. For introduction on these features, refer to this guide.

3.1 Secure hardware architecture (SBS)

In contrast to the STM32L5 and the STM32U5, the security configuration is now concentrated around protected registers in the system configuration, boot and security (SBS) block. Concentrating the security related configuration in 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)

SBS effectively replaces the SYSCFG section of the STM32H5 predecessors.

3.2 MPU

Up to eight MPU regions can be defined with TrustZone^® deactivated, twelve with TrustZone^® enabled.
For broader context follow here.

3.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.
For broader context click here.

3.4 OTP

One-time programmable flash memory area is 2kB, programmed by blocks of 16bit words. 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 being modified.
On the STM32H503, a block of the OTP is used to perform the provisioning, and storing a HASH of the password needed for regression.
For broader context clickhere.

3.5 HDP

The so-called Hide protection has been made independent from the use of the TrustZone feature. While tying the beginning of the HDP area to the start of the secure area made sense and covered vast majority of the use cases, it is still better to have two independent protections in place.
As opposed to the enable/disable approach, used in STM32U5 for example, the HDP in the STM32H5, three user levels of the secure boot process an be linked to 3 different memory areas accessible using the HDPL setting in the SBS.
For more STM32H5 specific information click here.
For broader context click here.

3.6 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 is possible to use the OBK to store OTFDEC keys and only reveal them in safe condition, improving the overall security.
For broader context click here.

3.7 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.
For broader context click here.

3.8 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 increased speed due to higher clock frequency.
For a broader context click here.

3.9 Tamper

Apart for the 8 usual external tamper sources, the STM32H5 allows the monitoring up to 15 internal test points with tamper detection, the newest addition being the HSE presence guard, enhancing the security already provided by the CSS. There are 32 tamper protected 32-bit registers. It is the most advanced anti tamper built to STM32 to date.
For broader context click here.