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.
Main introductory article to STM32H5 security is here.
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 + HW Cryptography, SAES and secure (key) storage, supports Secure Manager |
1. Secure storage (OBK)
Ability to support secure storage by facilitating management of cryptographic keys was substantially improved on the STM32H5 through the use of the OBK mechanism. This makes it stand out as a distinct new feature of the STM32H5
OBK 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 description of secure storage 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. This invalidates all the information stored in 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 RDP (read-out protection) 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
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, look at 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 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)
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 follow here.
3.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.
For broader context follow here.
3.5. HDP
The so-called Hide protection has been made independent on 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's still better to have two independent protections in place.
As opposed to the enable/disable approach, used in for example STM32U5, the HDP in the STM32H5 allows to link 3 user levels of the secure boot process to 3 different memory areas accessible to them using the HDPL setting in the SBS.
For more STM32H5 specific information go here.
For broader context follow 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's possible to use the OBK to store OTFDEC keys and only reveal them in safe condition, improving the overall security.
For broader context follow 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 follow 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 speed increase due to higher clock.
For broader context follow here.
3.9. 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.
For broader context follow here.