This article contains an overview of the security features[1] available on STM32C0 MCUs. The table below contains detailed information based on the different product lines.
Security features embedded on: | ![]() |
![]() |
![]() |
---|---|---|---|
Secure Boot and Firmware Update | |||
OEMiSB | ![]() |
![]() |
![]() |
OEMiRoT | ![]() |
![]() |
![]() |
Isolation | |||
Securable memory area | ![]() |
![]() |
![]() |
Cryptography | |||
ST crypto lib | ![]() |
![]() |
![]() |
Crypto libraries | ![]() |
![]() |
![]() |
Silicon device life cycle | |||
RDP with regression | ![]() |
![]() |
![]() |
Product state | ![]() |
![]() |
![]() |
Debug authentication | ![]() |
![]() |
![]() |
1. Secure Boot
When a product's code needs securing, it becomes necessary to embed a Root of Trust (RoT).
This RoT ensures the next stage of security ensuring the code integrity and its authenticity.
By definition, a RoT must be based on an immutable code handling the reset of the platform.
The RoT is the foundation to build a secure product.
On STM32C0, the implementation of the root of trust is based on boot lock and securable memory area features allowing to design robust secure boot solutions.
The proposed solution is OEMiSB.
1.1. OEMiSB
OEMiSB stands for OEM immutable (unchangeable) Secure Boot. OEMiSB offers only one service:
- The Secure Boot (root of trust service) is an immutable code, which is always executed after a system reset. It checks static protections (options bytes), activates runtime protections, and then verifies the integrity of the user application code before every execution.
2. Application Isolation
2.1. Securable memory area
The main purpose of the securable memory area is to protect a specific part of flash memory against undesired access. After system reset, the code in the securable memory area can only be executed until the securable area becomes secured and never again until the next system reset. This allows implementing software security services such as secure key storage or safe boot.
Securable memory area is located in the main flash memory. It is dedicated to executing trusted code. When not secured, the securable memory behaves like the rest of main flash memory. When secured (the SEC_PROT bit of the FLASH_CR register set), any access (fetch, read, programming, erase) to securable memory area is rejected, generating a bus error. The securable area can only be unsecured by a system reset.
3. Cryptography
Means of performing cryptography depends on the STM32C0 product line.
Cryptography features embedded on: | ![]() |
![]() |
![]() |
---|---|---|---|
Hardware Tiny AES | ![]() |
![]() |
![]() |
Hardware HASH | ![]() |
![]() |
![]() |
Hardware SAES | ![]() |
![]() |
![]() |
Hardware PKA | ![]() |
![]() |
![]() |
ST crypto lib | ![]() |
![]() |
![]() |
Crypto libraries | ![]() |
![]() |
![]() |
STM32Cube HAL can be used to work with the crypto IP.
3.1. Crypto libraries
Third-party libraries such as Mbed™ are available for STM32C0 MCUs.
Mbed™ library implements PSA crypto API. Mbed™ is distributed as source code.
4. Silicon device life cycle
The flexible device life cycle scheme is based on the readout protection (RDP) mechanism, including support for product decommissioning (auto-erase):
- Opened, closed, or limited debug protection, depending on the RDP level.
5. References
Pages in category "Security with STM32C0"
The following 3 pages are in this category, out of 3 total.