1. Introduction
STM32H5 MCUs are provided with numerous new security features, such as product lifecycle, isolation, debug authentication, secure storage, and secure boot.
With good security skills, all these blocks can be used. However, a full solution owned and maintained by STMicroelectronics is also available. This solution 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 Trusted Execution Environment (TEE) integrating core security services.
2.1. Secure Manager
Secure Manager is all what you see in blue. Secure Manager is composed of one software brick which is a binary encrypted and signed by STMicroelectronics. It is delivered by STMicroelectronics and user doesn't have access to this code. Secure Manager and ST iROT is only available on STM32H573 devices.
In blue and green correspond to all what is delivered by STMicroelectronics. In yellow it is the user application. User can call some security services which are standards defined by the PSA ARM.
- ST iROT is the fisrt stage bootloader. It is installed inside your device when you buy it.
- ST uROT is the second stage bootloader. It is possible to update this second stage bootloader.
- Secure Manager Core is a secure OS which handle the security services that you have in your platform.
- The services accessible by the PSA API are
- Firmware update: the capability to update your firmware in a secure way.
- The secure storage: the way to securely store data
- Cryptography : in order to encrypt or decrypt something you want to check
- Attestation : defined for the iOT. It allows to have an identifier to the full picture of your device.
2.2. Additional modules
If you need to add some security services you can define them by yourself and develop a secure module (in green).
It can be done by a third party or by customer.
This is a way to deliver a software API and ensure about its confidentiality.
As is is delivered encrypted and signed it will be installed securely and then it is possible to access this API but it's not possible to access to the software by itself.
2.3. User application
Security is handled by the Secure Manager so for user it is as itf there is no security.
There are some API to get access to security services but when user develops its application the only constraint is the size of the flash that is available. In fact Secure Manager is installed in the internal flash and a portion of RAM is locked by the Secure manager too.
2.4. Certification
Secure manager and Hardware are certified SESIP level 3 and PSA level 3 .
If you want to have your platform certified you just have to take care about certification of your application and your secure module(s).
The secure manager handle the isolation between the different services.
It is needed to have this level of certification to ensure that one secure service can’t access the resources of the other secure services.
It is PSA API compatible which means that this API has not been defined by ST, it is a standard defined by ARM.
It is designed for long term support : if a weakness is found STMicroelectronics will redeliver a new secure manager as it is updatable thanks to the different stage bootloaders.
It is optimized for certification : you just have to focus on the certification of your application.
2.5. Booting mechanism
The secure storage is used to store some keys. These keys will be used during the boot time to authenticate each brick of software before launching it.
After the provisioning and when we install the Secure Manager we also provision those keys in this secure storage.
- First step booting
At the reset we are on the ST iROT that will authenticate a second stage bootloader thanks to the keys that are inside 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.
Temporal isolation is a mechanism which allow to ensure that a portion of code can’t be seen anymore by the system. 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 will authenticate the secure Manager to ensure authenticity has not been modified from any hackers or something else. Then it will authenticate the different modules and each time the different keys because the keys owner are different. Then it authenticate the application to ensure the integrity is guarantee . If every thing is ok he will jump to the secure manager.
- Third step booting
The secure manager initialize by itself the core, and then jump to the application. After, we are in a “normal execution”:
The application could call some secure API and for example call an API to trusted storage in order to store some data.
The secure manager use the MPU to isolate the services that will be executed : during the execution of the secure storage it could not access to the resources of an other one. Secure manager jump on the Trusted storage, execute this API and then go back to the application All this is transparent for the user.
3. Links
For more details about 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 which describes how to experiment, install and try Secure Manager.