STM32H5 was designed to radically improve STM32 security, taking into account experience with previous Cortex-M33 microcontrollers, customer feedback and requirements to achieve highest PSA certification levels. This article is intended for readers who already know previous STM32 MCU's and their security features and want to focus on the specific updates and changes introduced to STM32H5.
For general STM32 security see or AN5156.
For more details on each particular security topic, there is more documentation to study, 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. Secure hardware architecture (SBS)
In contrast to STM32L5 and 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 an 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)
2. Product state
Product state is a system that replaces the old RDP (read protection) mechanism of life cycle management. The STM32L5 introduced the RDP0.5 and the STM32U5 also the much needed rollback mechanism for debug authentication, but 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 in which no development is possible, used just to establish security | Closed, Locked, TZ-Closed, Regression |
| TZ-Closed | State in which secure environment is fixed in place 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 |
One thing to note is 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's possible to freely manipulate option bytes, including the TrustZone enable, to facilitate for easy development and testing, down to HDP level 1. The limitation is that secure boot and services, the iRoT ( immutable root of trust ) and the Secure Manager, are not available before provisioning.
The provisioning is used to secure the product and manage the control over the security. This means that the product can be set for example to:
- Regress up to the Open if correct credential is provided
- Regress only to TZ-Closed on different credential
- Temporarily allow full debug with right credentials
- Temporarily allow debug on non-secure part with different credentials
- Create credentials that allow delegating the access to other users
The product itself would only have the root certificate with the max allowed opening installed. All else is configured in the development environment.
3. Temporal isolation (HDP)
Temporal isolation feature has evolved in the STM32H5 significantly. It's still called HDP, but the usability is extended. There are 2 most significant changes:
- The HDP now has 4 level of which 3 are available to the user
- The HDP protected area now can be defined (almost) anywhere in the memory, independent 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 0 - only defined in the system flash, never accessible to user, linked to regression control
- Level 1 - Level used by the secure boot, for example iRoT, if ST-iRoT is used, this level is also not user accessible.
- 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. The option bytes define the start and the end of the HDPL1 reserved area in each flash bank, with sector granularity. Open part of the system flash 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's volatile and needs to be set every time the transition is needed. The value has dual protection - once set, it cannot ever 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, intended primarily 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 user. Access to the Secure storage is under control of the SBS, linked to the temporal isolation levels. The OBK is not available at all on the STM32H503 and it's limited in protection of the STM32H56x, following description is only accurate in case of the STM32H57x crypto parts. The STM32H57x features SAES, secure AES crpytography 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 EPOCH counter. EPOCH counters are monotonic, non-volatile counters, incremented on each regression.
5. The secure boot ecosystem
This section is really only applicable on the crypto parts - the STM32H57x line. The boot lock and the HDP are available on all the STM32H5 series, allowing developers to develop a secure boot system, but without the SAES the security level will be limited. The native ST-iRoT and the subsequent option of the Secure Manager is only an option where full cryptography support exists - in the STM32H57x top line.