Sensitive Key protection

Literature

• Key storage available in STM32H5: STM32H5 secure storage
• Private key protection (asymmetric cryptography) through CCB (Coupling and Chaining Bridge): CCB key wrapping
• AN6205

1. Introduction

This article gives an introduction to the key protection feature supported by devices embedding the SAES (secure advanced encryption standard) module.
For detailed explanation refer to the documents listed previously.
For key protection related to CCB (coupling and chaining bridge) refer to the article CCB key wrapping.

Security standards (such as PSA, SESIP) require the protection of sensitive keys used in well-defined cryptographic operations.
The SAES is side-channel attack protected and is a central feature to ensure key protection.

• For products claiming SESIP SFR: Cryptographic KeyStore
  
  • It implies that the platform provides a secure way to store cryptographic keys, not even the application can compromise the confidentiality of this data.
    

• Notes:
  • SESIP SFR = Security Evaluation Standard for IoT Platforms, Security Functional Requirement.

1.1. Sensitive keys

• A single key is used for symmetric cryptographic operations, as the key used for AES to perform encryption/decryption. This key must be protected.
  
• A pair of related keys (one private, one public) is used for asymmetric cryptographic operations. Only the private key must be protected, because the public key, as its name indicates, can be made accessible to all.
  
  • Private keys are needed for different asymmetric cryptographic related to operations such as key pair generation, key agreement, key import, digital signature (see AN6205).
    
  • To prevent exposing the private key during these operations, and to ensure that even the application cannot compromise it (as defined by the SESIP SFR Cryptographic KeyStore document), additional mechanisms beyond the SAES are required (see the CCB article and further explanations below).

1.2. Protection of sensitive keys

SAES is an embedded hardware cryptographic engine that incorporates a protection against side-channel attacks (SCA), including differential power analysis (DPA), certified SESIP and PSA security assurance level 3.
It performs the wrapping (a specific SAES encryption key mode) of sensitive keys and issues the wrapped key.
The wrapping operation is done using a key derived from the HUK (Hardware Unique Key) and optionally XOR-ed with the BHK (Boot Hardware Key, protected against tampering). For detailed explanations see the dedicated on-line training.

• The HUK
  • Is an immutable, unique key for every device.
  • Is accessible only by the SAES to create the Derived Hardware Unique Key (DHUK).

• The BHK
  • If used (XOR-ed with DHUK), it must be written to the backup registers by the boot application. These registers are then read/write locked until the next reset.
  • The backup registers are erased only in case of a tamper event or in case of a backup domain power down.
  • If BHK is used, the erase of the BHK protected registers makes all BHK-wrapped keys unusable.

• The KDF
  • The Key Derivation Function is a cryptographic algorithm that uses the HUK as input and generates the DHUK.
  • The HUK is protected because it is not accessible to the user, and never used without derivation.

The following figures show the key wrapping/unwrapping principle.

Figure 1: Key wrapping and unwrapping for symmetric keys

• The DHUK
  • The DHUK is unique per device because it derives from the HUK.
  • The DHUK is used only as a key inside the SAES, and is not readable by user code.
  • All data encrypted with the DHUK can be used only on this specific device.

• The Wrapped Key
  • The key to be wrapped is loaded in the SAES Data IN register (DATA REG IN).
  • The key is encrypted using the SAES and the result is stored in the SAES Data OUT register (DATA REG OUT).
  • The wrapped key can be stored unprotected (for example in the user flash memory) because it is usable only on the specific STM32 device that wrapped it, thanks to the DHUK. The clear secret key must then be erased, for security reasons.
  • For the key unwrapping, the wrapped key is loaded in the SAES Data IN register (DATA REG IN).
  • The key is decrypted by the SAES and loaded into the write-only SAES key registers (KEY REG). The CPU can never access the secret key in clear text. It can only use the key for cryptographic operations running within the SAES.

See the next section for explanations of a typical use case.

1.3. Symmetric cryptography use case (AES)

In case of AES (symmetric cryptography), the same secret key is used for encryption and decryption.

1.3.1. AES peripheral wrapped key use case

In case of an encryption/decryption using the AES peripheral:

• The SAES unwraps the wrapped secret key.
• The unwrapped key is transferred to the AES through the keybus.
• The key can be used in the AES peripheral for encryption or decryption, nor the CPU neither the user application cannot access it.

The figure below shows the SAES block diagram (the shared key bus is highlighted) as included in the reference manuals.

Figure 2: Secure AES block diagram

1.3.2. SAES peripheral wrapped key use case

In case of an encryption/decryption using the SAES

• The SAES unwraps the wrapped secret key.
• The key can be used in the SAES peripheral for encryption or decryption, nor the CPU neither the user application cannot access it.

1.4. Asymmetric cryptography use case

The asymmetric cryptography involves a pair of related keys (a private key and a public key).
Some products embed a hardware Public Key Accelerator (PKA) used to accelerate asymmetric cryptography.

• Typical use cases using the PKA are:
  • Key pair generation (generation of private key and related public key)
  • Secure key import
  • Key agreement
  • Secure attestation

The PKA incorporates a protection against side-channel attacks (SCA), including differential power analysis (DPA), certified SESIP and PSA security assurance level 3.
For all the use cases listed above, the private key must be provided to the PKA.
Some products embed a Coupling and Chaining Bridge (CCB). The private key can be used in the PKA peripheral for asymmetric cryptography, nor the CPU neither the user application cannot access it.

For explanations about the Coupling and Chaining Bridge and the listed PKA use cases refer to the CCB article and to the AN6205.