|
Coming soon |
1. What is the Secure Manager
In the world of microcontroller security necessitated by the requirements of an IoT application, the PSA (platform security architecture) defined under leadership of ARM emerged. Secure Manager (SM) is a proprietary implementation of the PSA. The goal was to pave customers the way to a dependable secure MCU solution with minimal learning efforts on the user side. It's a matter of installing, configuring and using services, without the necessity to understand how the PSA works internally.
PSA is associated with an security certification scheme, and it is not limited to ARM architecture, with open source implementation available. Using the open source implementation grants API compatibility with the the standard, but no security certification. Anybody can use the source code to improve security of their IoT application, but only the certification can holds a proof to the outside world that the security is implemented correctly.
There are many certified implementations, but only handful are certified to the highest mark - level 3. Level 3 PSA certification evaluates API conformance, resistance to software attacks and also complete hardware protection of the security functions. This is the Secure Manager.
Using the SM the customer gets a complete level 3 solution with no extra cost or effort.
The idea is simple:
- All secure services are provided using the PSA API and certified, offering high level of confidence.
- Application development proceeds on TZ-Closed product state.
- The application relies on the secure API for authentication, confidentiality, firmware update, secure storage etc.
- Product is then shipped in Closed state, applications are protected by the Secure Manager services.
- Regression is only possible in conditions set during the provisioning.
2. Architecture overview
The SM cannot be installed as standalone library, only as a part of the certified configuration consisting of ST-supplied secure boot chain. To install the SM, the STM32H573 must have the ST-iRoT (immutable root of trust fixed in system flash) activated as the stage 1 unique boot option. The secure boot chain must then continue with stage 2, the ST-uRoT (updatable root of trust, installed to the user flash). The final step in the secure boot process is the SM. For the sake of simplicity the ST-uRoT and the SM are installed in one step as the Secure Manager Package. While the ST-uRoT may be used without the SM, opposite is not possible.
2.1. Structure
The flash memory of the STM32H573 is partitioned to facilitate the resource isolation required by the security goals. The situation is illustrated by the following diagram (rectangles are not in scale to actual memory size).
Lowest part is the system flash where the ST-iRoT is active. The entire secure partition is taken by the Secure Manager Package contents plus optional Modules. Both RoT are only used in the boot phase and are not available when the application is running.
The application (or the OS, if present) will use the API to call the SM. The SM-Core will dispatch the request to one of the installed, mutually isolated, secure services. Basis for the API is the ARM PSA of the version supported in the present SM. Any API extensions present are documented in the SM user manual or in the Module documentation, if a Module is installed.
3. Licensing
The SM is provided under the same SLA license as most parts of the STM32Cube software ecosystem. In case of the SM the source code is not published only the binary is available, the API is work of ARM and their rights must be respected. However the binary can be installed in any STM32H573 device with no additional fee, regardless of the devices final use.
The license is planned to be kept free for future upgrades of the SM, which will update the services for compliance with future versions of the TF-M (PSA) specification in a long term support plan. The update is of course going to be optional for SM users.
4. SMAK and SMDK
In it's base form, the Secure Manager Application Kit, is quite straightforward. All the security services are under control of the SM and the user application uses the certified functionality of the SM to get services in cryptography, secure storage, attestation an firmware upgrade. Since the whole secure part, which is the target of PSA evaluation, is fixed, the whole solution is PSA level 3 secure, regardless of what's the non-secure code executed on top of it.
It's always better if the application takes the advantage of secure services provided by the PSA API, because otherwise the whole exercise makes little sense, but it's not mandatory to do so. As long as the non-secure user code relies on the Secure Manager services with all the sensitive actions, the whole system is secure.
The SMDK allows the developer to add secure code to the SM in form of Modules. The modules would have their own API and work side by side with the PSA API modules of the SM.
Such installable module is then used to provide additional secure services to the non-secure application. It may be adding new cryptographic services, serve as secure OS kernel or anything that is justified in being isolated from normal operation.