ST Employee

How to navigate STM32 secure storage and key management across STM32 series

0 replies
340 views

In this article, we provide an overview of STs secure storage solutions and then present ST's key management solutions across multiple STM32 products.

Introduction

Protecting sensitive information requires secure storage and controlled access to plaintext secrets. Sensitive assets typically fall into two categories:

Cryptographic keys
Confidential application data

STM32 security architectures address this using two complementary layers:

Secure storage (Key storage): Securely stores cryptographic keys and confidential data while enforcing hardware or software access control to prevent unauthorized access.
Key management: Protects cryptographic keys throughout their life cycle by enabling secure provisioning, isolation, wrapping, unwrapping, and usage without exposing plaintext keys.

Key management uses dedicated hardware security features. These features include the Secure AES (SAES) peripheral and the Coupling and Chaining Bridge (CCB). They provide hardware-assisted key isolation. They also enable key wrapping and secure key sharing for cryptographic operations.

1. Secure storage

As introduced earlier, secure storage is the mechanism used in STM32 devices to protect cryptographic keys and confidential application data at rest, while enforcing controlled access to them.

The implementation differs between STM32 families. This section covers three approaches:

OBKeys: A dedicated hardware key storage IP available on STM32H5 and STM32H7R/S.
Customer Secure Storage (CKS): A CPU-isolated secure storage solution specific to STM32WB.
Software-based secure storage: A solution relying on STM32 hardware isolation mechanisms.

1.1 OBKeys

Only supported on the STM32H5 and STM32H7R/S families.
This is a dedicated nonvolatile memory used to store keys for secure storage and cryptographic usage.

HDPL (HDP level) domains organize the storage. Each domain has its own secure storage area and its own access rules. Access control is enforced with SBS (system configuration, boot, and security block control). The access control depends on the STM32 family (H5 or H7R/S). For more information about SBS, refer to Annex.

Data can be provisioned securely (using the RSS function RSSLib->DataProvisioning()).
Data is isolated, only authorized parts of the system can access it.
Protects against anti-rollback attacks and anti-cloning.
Data cannot be extracted from the system or reused.

The OBKeys store two types of keys:

Application hardware keys (AHK) also referred to hardware keys: these keys are indexed from 0 to 7. They are not accessible to the user and are injected directly into the SAES engine. These keys can be STiRoT keys or Memory Cipher Engine (MCE) keys (for external memory encryption). The SAES accesses these keys through a special bus.
Software keys: Indexed from 8 to 31, related to the user application, accessed by software (read/write), and can be provisioned (bootloader keys, etc.).

The features of OBKeys are as follows:

Controls access via HDPL level
Crypto isolation: keys can be stored encrypted using DHUK or AHK
Provides anti-rollback and anti-replay via EPOCH
An HDPL level can access its current OBKey area and the next one in level (N and N+1).

1.2 Hardware keys

Hardware secret keys are used to protect application keys without exposing them. ST establishes these keys and the application can never access them. Below is an overview of the hardware keys present on STM32 devices:

Hardware Unique Key (HUK) also referred to as Root Hardware Unique Key (RHUK): ST provisions a key of 256 bits during manufacturing.

Boot Hardware Key (BHK), stored in tamper-resistant backup registers and written during boot. Once written, this key cannot be read or written by any application until the next product reset.
Device Unique Attestation (DUA), a private key provisioned by ST during manufacturing (only available on U3).
Device electronic signature contains information about the chip itself.
These keys are used by a key derivation function to generate new keys:
Derived Hardware Unique Key (DHUK) generated from the RHUK and the current HDP level. It is a 256-bit AES key for every device.

For the H5 and H7R/S, a new key counter is added that is also used as a parameter in key derivation:

EPOCH: a monotonic counter (24 bits) increased at each regression (erasing data storage). It helps protect against installation of an older firmware/data version (anti-rollback/anti-replay).
For the H5, the counter is split into two parts: (EPOCH NS and EPOCH S)

1.3 Secure storage for H7S/R

Three OBKey areas, one for each HDP level (0, 1, 2), up to 1 KB. Below is an overview of the secure storage areas and their attributes:

HDPL0: permanently allocated to STMicroelectronics and never erased.
HDPL1: designated for initial Root of Trust (iRoT) keys, erasable through regression.
HDPL2: for user application or if used the updatable root of trust (uRoT).

1.4 Secure storage for H5

Below is an overview of the secure storage areas and their attributes:

HDPL0: permanently allocated to STMicroelectronics and never erased.
HDPL1: designated for initial Root of Trust (iRoT) keys, erasable through regression.
HDPL2: for secondary Root of Trust (uRoT), Operating System (OS), or secure applications, also erasable through regression.
HDPL3S: reserved for secure application keys, subject to erasure via regression.
HDPL3NS: allocated for nonsecure application keys, erasable through nonsecure regression (NS regression).

The picture below demonstrates the usage of OBKeys:

The key storage firmware selects the current context. This context includes HDPL and the secure or non-secure state. It then passes this information to the hardware key access control unit.
The unit selects the OBK-HDPL and EPOCH according to the current HDPL context and SBS registers. The application sets the EPOCH_SEL.
OBK-HDPL selects the area of secure storage of the flash memory and selects the corresponding DHUK in SAES.
It checks whether the requested domain is accessible. If no violation is detected, the data are encrypted using DHUK.

1.5 Comparison between the H7R/S and the H5

Feature	STM32H5	STM32H7R/S
Secure storage technology	A special area called OBKeys secure storage	OBK secure storage in internal flash
Number of domains	5 domains: HDPL0, HDPL1, HDPL2, HDPL3S, HDPL3NS	3 domains: HDPL0, HDPL1, HDPL2
TrustZone secure/non-secure split	Yes, via HDPL3S/HDPL3NS	No TrustZone support for OBK
Total storage size	Up to 8 KB	1 KB max
Access model	Memory-mapped	Register-based, chained-list structure
Max HDPL covered by OBKeys	Through HDPL3	Through HDPL2 only
Encryption basis	SAES + DHUK per HDPL on supported crypto parts	SAES + DHUK or AHK
Anti-cloning/anti-rollback	Supported	Supported, including EPOCH-based anti-rollback
Provisioning	`RSSLib->DataProvisioning()`	`RSSLib->DataProvisioning()`
Encryption key used during provisioning	DHUK	AHK

1.6 Customer secure storage (CKS)

This is a solution only available on STM32WB.
The STM32WB has two CPUs: CPU 1 (Cortex®-M4), dedicated to the user application, and CPU 2 (Cortex®-M0+), dedicated to the network stack.

CKS is a secure storage solution, accessible only by CPU 2.
It is a whole mechanism that involves a secure area to store provisioned keys, a mechanism to enable the AES peripheral to access these keys securely without exposing them, and a way to provide the result to the user. CPU 2 manages all of this in full isolation from CPU 1 running the user application.

1.7 Software based secure storage

ST provides software-based solutions that expose secure storage services to the user application. These services are isolated and secured through underlying hardware isolation mechanisms that the table below summarizes.

Solution	Services	Description	STM32 devices	Hardware isolation
SBSFU legacy	key management services (KMS)	It provides secure storage and secure key management services through the PKC#111 API.	STM32L4 and STM32L4+	Firewall and MPU (Memory protection unit)
Secure Manager	Internal Trusted Storage (ITS), Protected Storage (PS)	ST proprietary TEE that provides secure services: storage solutions using PSA2 APIs.	STM32H573	TrustZone®, MPU, HDP level.
TF-M (Trusted Firmware-M)	ITS & PS	Open-source TEE that exposes the same ITS/PS storage services via PSA APIs.	STM32H5, STM32U3, STM32L5, STM32WBA, STM32U5	TrustZone®, MPU

1: PKCS#11 (PKCS = Public Key Cryptography Standards; #11 is the standard for cryptographic tokens/HSM interfaces).

2: PSA Platform Security Architecture is an Arm security framework designed to standardize hardware and firmware security for connected devices.

2. Key management

Key management is done through:

SAES: secure AES peripheral
CCB: coupling and chaining block

2.1 Secure AES (SAES)

The Secure AES (SAES) peripheral is a hardware AES accelerator designed for secure key management, not just fast AES encryption. It is protected against Side-Channel Attacks (SCA) and Differential Power Analysis (DPA) attacks.

Unlike the standard CRYP peripheral, SAES protects secret keys from software and physical attacks by providing:

Write-only key registers (accessible for writing only; the content cannot be read)
Hardware-managed secret keys
Key wrapping and unwrapping
Secure key sharing with the CRYP/AES peripheral
DPA resistance
Hardware RNG integration

In normal mode, the CPU loads the key into the SAES write-only register; the key cannot be read back afterward.

For key management, SAES supports key derivation. It manages the DHUK through a key derivation function, which is later used for key wrapping and unwrapping.
The DHUK is not exposed, and it is generated when needed. The derivation of the DHUK depends on the STM32 family. However, it generally takes the RHUK and the HDPL level context as inputs.

The key wrapping and unwrapping operation are a key protection mechanism; it serves as a key isolation mechanism. Keys should not be stored in clear text. For symmetric keys, SAES is used for key wrapping/unwrapping. For asymmetric cryptography, PKA and CCB are used alongside SAES; this is explored further in a later section.

The key wrapping process:

Select the hardware secret key (DUHK or DUH XOR BHUK)
Provide the key to encrypt
Perform the wrapping operation (encryption; the user can select the wrapping according to the mode, such as chaining or counter mode)
Save in a flash

For the unwrapping process:

Select the hardware secret key
Write the wrapped encrypted key into the data register
Decrypt the key in SAES and put it into the write-only key register
The application uses the key as needed

While SAES is designed for secure key handling, it is not optimized for high-throughput encryption. The standard CRYP/AES peripheral provides faster cryptographic acceleration for bulk data, but it cannot protect keys the way SAES does. To get both SAES's key protection and CRYP/AES's speed, SAES provides a key-sharing mechanism: it lets the application select a key already held in secure storage and share it with CRYP/AES for fast processing, without ever exposing the key in plaintext to the application.

Key sharing works in two steps:

SAES decrypts (unwraps) the protected key internally.
SAES transfers the unwrapped key directly into CRYP/AES's key register, a hardware-to-hardware path the application code never has visibility into.

The key is never exposed through software or become readable by the application.

2.2 Coupling and chaining bridge (CCB)

The Coupling and Chaining Bridge (CCB) is an advanced peripheral designed to protect private keys, even from CPU access. The keys are wrapped (encrypted) using unique device keys and stored securely in secure storage.

The mechanism that protects PKA private keys, even against CPU access, by sitting between secure storage, SAES, and PKA (and sometimes RNG).

The CCB is available in H51, U3, and C5 depending on the STM32 series and part number.

1: Not available for all STM32H5 families.
The inner working of CCB:

Coupling: the CPU feeds the data to both SAES and PKA. (Commanding at the same time).
Chaining: the result of a peripheral is the input of another.
Functionality:
DUA: a pre-provisioned key pair (private and public key) by ST during manufacturing. The keys are generated using the ECC (Elliptic Curve) algorithm, 265 bytes. The public key is accessible through a certificate signed by the ST CA. The private key is wrapped and accessible through the RSSe KW service. RSS KW (key wrapping) provides a wrapped key usable only on one specific device. For more information, refer to STM32 wiki KW for STM32U3
Private key protection

First, let us introduce private key usage on STM32:

Key pair generation: generation of the public and private keys
Secure key import (RSA): sharing a key between two parties; the key is first encrypted using the public key of the receiver and then sent. For decryption, it is decrypted with the private key of the receiver.
Key agreement: ECDH (Elliptic Curve Diffie-Hellman); the shared secret is then used in a key derivation function (KDF) to derive a usable symmetric key.
Secure attestation is the process of digital signature.

Key pair generation, key import, key agreement, and attestation are the high-level asymmetric crypto use cases.

ECDSA, ECC, and RSA:

	ECDSA signature blob	ECC key blob	RSA key blob
	Signature	Scalar multiplication	Modular exponentiation
Key generation	yes	yes	-
Key import	-	yes	yes
Key agreement	-	yes	yes
Attestation	yes	-	yes

2.3 Private key protection, wrapping and unwrapping

The key in clear text is provided to the PKA, by writing to the PKA memory. The CCB is responsible for sending the key to the SAES data input register.
The key derivation function inside the SAES received an additional parameter specifying CCB usage.
The key wrapping/unwrapping operation uses the AES-GCM encryption algorithm with Galois/counter mode. This is used to achieve authenticated encryption.
The picture below explains the wrapping and unwrapping process of the private key:

2.4 Key management across STM32 products matrix

The table below represents a summary of the key management implemented through a combination of hardware secret keys, cryptographic peripherals, and access-control mechanisms, depending on the family.

Key management		U5	N6	WB6	C5	H5	U3	H7R/S
Keys	HUK	x	x	x	x	x	x	x
Keys	BHK	x	x	x	x	x	x	x
Access management	SAES	x	x	x	x	x	x	x
	PKA	x	x	x	x	x	x	x
	CCB	-	-	-	x	x	x	x
Key use policy1		TZ	TZ	TZ	HDPL	HDPL/ TZ/EPOCH	TZ	HDPL/ EPOCH

1: Key use policy: Enforced by hardware key access control and cryptographic peripheral context, depending on family, including secure/non-secure state, HDPL, SBS settings, and EPOCH.

3. Annex: System configuration boot and security

System configuration boot and security (SBS), a peripheral that replaces the SYSCFG, available in STM32 C5, H5, H7R/S, and U3 depending on the device part number.
Its main functions are:

Boot control setting up the right boot address and the HDPL level.
Debug control: control the reopening of the device, ensuring the right sequence of events that guarantee the device security.
System configuration (EXTI source, ...).
Security status BKPRAM and PKA SRAM erase
RSSCMD for application to pass on command to the RSS.

Conclusion

In this article, we covered secure storage solutions, including OBKeys, CKS, and software-based approaches. We then presented ST’s key management solutions, namely SAES and CCB. Finally, we provided a summary of key management across STM32 products.