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.
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
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 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 others
The product itself would only have the root certificate with the max allowed opening installed. All else is configured in the development environment.