Literature
- AN6205 Introduction to the use of PKA Key wrapping.
- RM0487 STM32U3 Reference Manual (CCB chapter).
- Sensitive key protection wiki article
- CCB Online Training Module (available soon).
- Practical example:
- Key wrapping example explained step by step (CubeFW MbedTLS_HW_KWE) Security: How to start with CCB KW ECDSA Signature on STM32U3.
- Other key wrapping examples are available at: STM32Cube_FW_U3_Vx.x.x\Projects\NUCLEO-U385RG-Q\Applications\MbedTLS_HW_KWE
1. Introduction
It is advised to read first the Sensitive key protection article indicated above.
For asymmetric cryptography (also called public-key cryptography) a pair of related keys (one private. one public) is used.
The security of asymmetric cryptography relies on keeping the private key secret.
The CCB (Coupling and Chaining Bridge) feature included in some STM32 products ensures the protection of the private key. Its main features are described in this article.
Security standards (such as PSA, SESIP) require the protection of sensitive keys, such as the private keys.
- The CCB target SESIPL3 certification level.
- SESIP SFR claimed for U3: Cryptographic KeyStore
- Notes:
- SESIP SFR = Security Evaluation Standard for IoT Platforms, Security Functional Requirement.
- Cryptographic KeyStore claim implies:
- The platform provides a way to store cryptographic keys, not even the application can compromise their confidentiality.
- For our topic, these cryptographic keys can be used for the following cryptographic operations:
- Protected modular exponentiation (among them signature, decryption, key agreement)
- ECDSA signature
- ECC scalar multiplication
2. Asymmetric cryptography and PKA
Some STM32 products include a hardware Public Key Accelerator (PKA) that accelerates asymmetric cryptography.
- Typical use cases involving the PKA are (see below sections for more explanations and figure 2):
- Cryptographic key pair generation (generation of private and related public key)
- Secure cryptographic key import (provided public key A used to encrypt a key B, key B decrypted using the private key A before storage).
- Key agreement, like Diffie-Hellman (combination of private secret key and public key of other party, used to compute a common key for symmetric cryptography)
- Secure attestation (involving digital signature using private secret key).
The important point is that for the listed use cases, the private key must be provided to the PKA or retrieved from it.
The CCB ensures the protection of the private key against accesses by user code running on CPU or DMA.
3. Private key protection, wrapping and unwrapping
The protection of sensitive cryptographic key for symmetric cryptography is explained in the Sensitive key protection article.
It is advised to read first this article.
As explained previously, for asymmetric cryptography the protection of the private key is crucial.
The SAES (Secure Advanced Encryption Standard) peripheral is used to protect the private key (asymmetric cryptography) through wrapping.
However, there are some differences between wrapping a symmetric key and wrapping a private key using the SAES:
- The key in clear text is provided to the PKA, not to the SAES, by writing it into the PKA memory. The CCB is responsible for sending the key to the SAES Data IN register (DATA REG IN).
- The KDF (Key Derivation Function) receives an additional parameter specifying CCB usage. A wrapped private key and a wrapped symmetric key differ, even if the underlying clear key is the same.
Compare the figure 1 of the article mentioned above with the figure below.
The steps to wrap/unwrap a key are explained in the two next sections.
- Reminder (more details in Sensitive key protection article)
- The SAES (Secure Advanced Encryption Standard) is an embedded hardware cryptographic engine that incorporates a protection against side-channel attacks (SCA), certified SESIP and PSA security assurance level 3.
- The DHUK (Derived Hardware Unique Key) is a 256-bit AES key, unique for every device.
- The BHK (Boot Hardware Key), if used XORed with DHUK, must be written to the backup registers by the boot application at every boot. These protected registers are erased in the event of a tamper, rendering all wrapped keys unusable if BHK was employed.
Explanations about the CCB and the supported use cases are provided below in this article.
Programming the CCOP bits in the CCB_CR register selects one of the supported CCB use case (see RM0487).
3.1. Private key wrapping
The steps to protect (wrap) the private key are explained below (see figure above).
Programming the CCOP bits indicates the selection of one of the supported CCB use cases, enabling the corresponding key wrap mechanism.
The SAES must be configured to wrap the key using either the "DHUK" or the "DHUK XOR BHK" method (see the KEYSEL bit in SAES_CR register, RM0487).
- The key in clear text is written into the PKA RAM.
- If the CCOP bits are different than 0, reading back the key from the PKA RAM returns only 0s, but transfers the clear key into the SAES Data IN register (DATA REG IN).
- The key is encrypted using the derived key (DHUK, or DHUK XOR BHK, see the figure above) and stored in the SAES data OUT register (DATA REG OUT).
- The wrapped key can be stored unprotected, as, thanks to DHUK, it can be used only on the specific STM32 device that has wrapped it.
- Note:
- As shown in the figure above, the Key Derivation Function (KDF) that computes DHUK uses three inputs: RHUK (never accessible as such, only used for DHUK generation), TrustZone® (enabled or not), and the CCB usage (enabled in this case).
- An optional XOR with the BHK can be configured in the SAES, adding tamper protection, as explained previously.
3.2. Private key unwrapping
The steps to unwrap the private key are explained below (see figure above).
The CCOP bits in the CCB_CR register must be set to a value different from 0 to enable one of the supported CCB use case.
The SAES configuration must be the same as for key wrapping, selecting either "DHUK" or "DHUK XOR BHK" in the SAES_CR register.
- The wrapped key is written into the SAES Data IN register (DATA REG IN).
- The key is decrypted within the SAES and stored in the Data OUT register (DATA REG OUT), using the same inputs parameter as during key wrapping. A user code running on CPU or DMA reads 0s when accessing those registers.
- The unwrapped key is securely transferred to the PKA via the CCB using an internal protected key bus.
The decrypted key stays protected within SAES and PKA.
The private key in clear text is never accessible by any user application, ensuring its confidentiality.
The next chapters explain how the retrieved private key is used and protected for supported PKA use cases.
4. PKA wrapped key use cases and CCB role
The use cases of the PKA have already been mentioned at the beginning of this article.
The figure (see AN6205 ) below shows these use cases and indicates where a hardware protection is needed to avoid private keys exposure.
The CCB role is to ensure the mentioned hardware protection.
5. Coupling and Chaining Bridge (CCB)
The figure below shows how the CCB, when enabled, interfaces with other peripherals.
The CCB is enabled by setting the CCOP to a value different from 0 in the CCB_CR register (see RM0487).
It shows the involved hardware accelerators as well.
A specific internal protected bus is used to transfer the unwrapped/clear-text keys between SAES and the PKA memory.
The dotted lines show internal chaining and coupling possible through programming the CCB.
These chaining operations are defined through blob creation and usage (see RM0487 and AN6205 for details).
The CCB ensures the protection of the generated random number used for some cryptographic operations (such as ECDSA signature), see figure 2.
5.1. CCB coupling and chaining
The chaining and coupling of the hardware accelerators supporting the use cases described in the PKA wrapped key use cases and CCB role chapter are summarized in the following figure.
To illustrate the ECDSA signature example proposed as getting started, go through the following steps to perform an ECDSA signature:
- The authenticated but not encrypted data must be transferred from the flash memory to the SAES and to the PKA (see note below)
- The coupling CPU → PKA + SAES is used
- The private key decrypted by the SAES must be transferred from the SAES to the PKA
- The chaining SAES → PKA is used
- It is very important to use a nonce (random and kept secret) different for every signature to avoid the retrieval of a private key used twice.
- The chaining RNG → PKA is used
- and so on...
Note: Because AES-GCM (Galois Counter Mode) is used in this case, the confidentiality, integrity and authenticity are guaranteed. Some data are authenticated but not encrypted, they are added to the encrypted key when computing the TAG for authenticity check. Both the SAES and the PKA receive the authenticated data, the encrypted key (see AES-GCM usage for PKA key wrapping in AN6205). If TAG is not correct the PKA operation cannot start.
For detailed explanations of this and other cases, read the CCB coupling and chaining chapter of the RM0487
5.2. CCB coupling and chaining operation, blob creation and usage
For the cryptographic operations mentioned in the introduction (Protected modular exponentiation, ECDSA Signature, ECC scalar multiplication) and as shown with the example in the previous chapter, several protected steps are needed involving different chaining and coupling modes.
The definition and scheduling of these steps are managed through blob creation and usage.
Before using a blob, it must be created.
Tables are included in the RM0487 explaining all the steps to create and use the three supported blobs:
(AN6205 provides also further explanations.)
- ECDSA signature blob:
- Generate a public key from the wrapped (encrypted) private key stored in ECDSA signature blob.
- Perform a digital signature using the wrapped (encrypted) private key.
- Perform a digital signature verification using the generated public key (ECDSA signature blob verification).
- ECC key blob (scalar multiplication):
- Generate a public key from the wrapped (encrypted) private key stored in ECC key blob.
- Perform a scalar multiplication using the wrapped (encrypted) private key. Needed for ECC key generation, ECDH key agreement (key exchange for elliptic curve) and ECC secure key import.
- Generate reference public key during ECC key blob creation. This key must be compared with computed public key (ECC key blob verification).
- RSA key blob:
- Perform modular exponentiation using the wrapped (encrypted) private key stored in RSA key blob. Needed for RSA key agreement, RSA secure key import and RSA attestation.
- Generate reference modular exponentiation. This value must be compared with computed value (RSA key blob verification).
The table below shows the blobs involved for the cases shown in figure 2.
- | ECDSA signature blob | ECC key blob | RSA key blob |
---|---|---|---|
- | Signature | Scalar multiplication | Modular exponentiation |
Key generation | ![]() |
![]() |
- |
Key import | - | ![]() |
![]() |
Key agreement | - | ![]() |
![]() |
Attestation | ![]() |
- | ![]() |
The RM0487 and the AN6205 give more technical insides and explain in detail how to create and use blobs.