TrustZone Secure Key Storage#
In Series 2 devices, key management can be handled by a feature called TrustZone. TrustZone divides the device memory map into a Secure Processing Environment (SPE) and a Non-secure Processing Environment (NSPE). User code is executed from the NSPE, which cannot access any part of the SPE. The SPE is used to store cryptographic keys securely and to control other Secure operations.
The following sections describe using TrustZone on Series 2 devices for Secure Key Storage. Refer to Series 2 TrustZone for details about TrustZone implementation on Series 2 devices.
TrustZone Root Key Generation (HSE and VSE)#
The TrustZone Root Key (TRK) is generated by the True Random Number Generator (TRNG) in Series 2 devices.
The PUF-derived key (HSE and xG27 VSE devices) or padded unique device serial number (xG22 VSE devices) is used to wrap (AES-GCM) the TRK.
The wrapped TRK is stored in the SE Non-volatile memory (NVM), and the TRK in RAM is deleted.
The wrapped TRK already existed if the shipped Series 2 device with SE firmware version supports this key.
The wrapped TRK will be generated when upgrading from a SE firmware version that did not support this key to the one that does.
The wrapped TRK will be renewed after performing a Device Erase.
Note: The Physically Unclonable Function (PUF) is not retained when the device loses power, so the TRK wrapped by the PUF-derived key is not vulnerable to a storage-extraction attack.
TrustZone Root Key Usage (HSE)#
The Secure application in the host uses a non-exportable built-in key to access the wrapped TRK in HSE NVM for cryptographic operations.
The PUF-derived key is used to decrypt (AES-GCM) the wrapped TRK in HSE NVM.
The unwrapped TRK in the HSE is the master key of a Key Derivation Function (KDF).
The encryption key in SPE for Secure Key Storage is derived from the KDF CMAC.
Notes:
All cryptographic operations are performed by the HSE (security co-processor).
Only the HSE can access the unwrapped TRK for KDF, so this key will not expose the Secure application in the host.
TrustZone Root Key Usage (VSE)#
The wrapped TRK in VSE NVM is accessed by the VSE Root mode firmware.
The PUF-derived key (xG27) or padded unique device serial number (xG22) is used to decrypt (AES-GCM) the wrapped TRK in VSE NVM.
Unwrapped TRK is transferred to the shared RAM when switching from VSE Root mode to User mode. The VSE user mode Secure application stores this key to the Secure RAM in SPE and deletes this key in the shared RAM.
The unwrapped TRK in the Secure RAM is the master key of a Key Derivation Function (KDF).
The encryption key in SPE for Secure Key Storage is derived from the KDF CMAC.
Note: On VSE devices, all cryptographic operations are performed by the Cryptographic Accelerator (CRYPTOACC) peripheral.
For more information about the HSE and VSE, refer to the section Secure Engine Subsystem in Series 2 Secure Debug.
TrustZone Secure Key Storage (HSE and VSE)#
The TRK allows a user to securely store a key in the Non-secure flash, limiting the number of keys that can be saved only by the amount of Non-secure storage. The following figure describes using the TRK to encrypt a plaintext key and store it in Non-secure NVM.
After power-on, the device's TRK (wrapped in HSE NVM and unwrapped in VSE Secure RAM) is available for the SPE.
A user key is generated and imported into the device's Non-secure memory. In this example, the key is imported into Non-secure RAM for easy deletion, and the key is lost if device power is removed.
Call the PSA Crypto API (
psa_import_key()
orpsa_generate_key()
) through the Secure Gateway (SG) in Non-secure Callable (NSC) memory to generate a key for crypto operations.The plaintext key is passed in the PSA Crypto API to the SPE, where it is encrypted (AES-GCM) with the encryption key derived (KDF CMAC) from the TRK.
The encrypted key is stored to the NVM region in the NSPE through the PSA Internal Trusted Storage (ITS) and NVM3 drivers.
The plaintext key can now be deleted from the Non-secure RAM.
Only the PSA Crypto API in the SPE can retrieve the encrypted key from NVM in the NSPE and decrypt it for crypto operations in the SPE.
Note: Ignore steps 2 and 6 if the plaintext key is randomly generated by the PSA Crypto.