1. Introduction
STM32H5 MCUs are equipped with numerous, new security features, such as product life cycle, isolation, debug authentication, secure storage, and secure boot. Solid security skills are required to use these blocks.
STMicroelectronics offers a full solution, owned and maintained by STMicroelectronics, which is SESIP 3 and PSA certified.
PSA certification is the highest level of security certification for general purpose MCUs.
2. Secure manager overview
Secure manager is a TEE (Trusted Execution Environment) integrating core security services.
- The blue elements in the above image correspond to the secure manager:
- The blue and green elements in the above image are delivered by STMicroelectronics.
- The yellow elements correspond to the user application. The user can call some security services, which are standards defined by the PSA ARM.
2.1. Secure manager
Secure manager is composed of one software brick, which is a binary encrypted and signed by STMicroelectronics. It is delivered by STMicroelectronics. The user does not have access to the code.
ST iROT is the first stage bootloader. It is installed inside your device at purchase.
Both secure manager and ST iROT are only available on STM32H573 devices.
ST uROT is the second stage bootloader. The second stage bootloader can be updated.
Secure manager core is a secure OS, which handles the platform security services.
The PSA API accesses the following services:
- Firmware update, allowing to update firmware in a secure way.
- Secure storage, to securely store data.
- Cryptography, to encrypt or decrypt an element to check.
- Attestation, which is defined for the iOT. It allows to have an identifier to the full picture of your device.
2.2. Additional modules
Third-parties or customers can add security services by defining them and developing a secure module. Security services are highlighted in green in the above image.
Confidentiality is ensured when delivering a software API: Encrypted and signed at delivery, the software API is installed securely.
After installation, access to the API is guaranteed, while preventing access to the software.
2.3. User application
Security is handled by the secure mpanager, being transparent for the user.
Secure manager is installed in the internal flash. A portion of RAM is locked by the secure manager, too.
For these reasons, when the user develops its own application, the only constraint is the size of the flash memory that is available.
2.4. Certification
Secure manager and hardware are certified SESIP level 3 and PSA level 3.
Platform certification requires application and secure modules certification. Secure manager handles the isolation between the different services.
This level of certification is required to ensure that one secure service cannot access the resources of the other secure services.
It is PSA API compatible, meaning that this API has not been defined by ST, it is a standard defined by ARM.
It is designed for long-term support. In case of weakness detection, STMicroelectronics delivers a new secure manager, as it can be updated using the different stage bootloaders.
It is optimized for certification. Just focus on the application certification.
2.5. Booting mechanism
The secure storage is used to store the keys that are used during boot time to authenticate each brick of software before launch.
After the provisioning and during the installation of the secure manager, we also provision those keys in the secure storage.
First step booting
- At reset, we are on the ST iROT that authenticates a second stage bootloader, with the keys in the secure storage.
- When this authentication is done, we are sure this one is authenticated and has not been modified by a hacker or something else we jump on it thanks to the temporal isolation.
- A portion of code can no longer be seen by the system with temporal isolation. The associated keys have the same isolation level. Once we jump to another level, we remove access to the previous one and also to the associated keys.
Second step booting
- The second stage bootloader authenticates the secure manager. This ensures that authenticity is not modified by a malicious action, such as hacking.
- The second stage bootloader authenticates the different modules. The keys need to be authenticated every time as keys owner are different.
- The second stage bootloader authenticates the application to ensure the integrity is guaranteed. When this step is successfully completed, the second stage bootloader jumps to the secure manager.
Third step booting
- The secure manager initializes the core, then jumps to the application.
- After these steps, we are in regular execution.
The application could call some secure API. For example, calling an API to trusted storage in order to store some data.
The secure manager uses the MPU to isolate the services that will be executed. During the execution of the secure storage, it could not access to other resources. Secure manager jumps to the Trusted storage and executes this API and then goes back to the application. This is transparent for the user.
3. Links
For further details about the secure manager, refer to the article secure manager.
Secure Manager STM32H5 How to Intro introduces the following How to start article:
How to start with secure manager on H573, describing how to experiment, install, and try the secure manager.