KMU and CRACEN hardware peripherals overview

Most nRF54L Series devices are equipped with two hardware peripherals that work together to provide secure cryptographic operations: the Key Management Unit (KMU) and the Crypto Accelerator Engine (CRACEN). The hardware peripherals are supported in the nRF Connect SDK through the CRACEN driver, one of Cryptographic drivers. The CRACEN driver implements driver-specific parts of the PSA Crypto APIs and adds some vendor-specific functionalities to this API.

Together, these peripherals and the CRACEN driver are central for ensuring that cryptographic assets on these devices are protected.

For more information about these hardware peripherals, see the related pages in the device datasheets, for example KMU - Key management unit and CRACEN - Crypto accelerator engine in the nRF54L15 datasheet.

Device support for KMU and CRACEN 

The following table shows which devices use KMU and CRACEN peripherals.

KMU and CRACEN support by device
✔ Has KMU and CRACEN	✗ Does not have KMU and CRACEN
nRF54L05 nRF54L10 nRF54L15 nRF54LM20 nRF54LV10	nRF54LS05

CRACEN hardware peripheral 

CRACEN is a hardware peripheral that provides hardware-accelerated cryptographic operations and entropy generation. It is not directly accessed by the CPU and is typically not used directly by end-users and their applications. Instead, applications interact with CRACEN through the CRACEN driver, which provides a standard PSA Crypto API interface.

CRACEN supports various cryptographic operations including encryption, decryption, signing, verification, and key derivation. It can execute these operations using different types of keys, including keys that are stored in the KMU or derived from the CRACEN Isolated Key Generator (IKG).

Note

The CRACEN hardware peripheral relies on microcode for asymmetric cryptography operations like signature validation. On the nRF54L15, nRF54L10, and nRF54L05 devices, this microcode must be uploaded to a special CRACEN RAM area before first use and after each reset. On these devices, the CONFIG_CRACEN_LOAD_MICROCODE Kconfig option is enabled by default.

If a bootloader uploads this microcode, there is no need to re-upload it for application use. This saves approximately 5 KB in the crypto driver code.

CRACEN Isolated Key Generator 

The CRACEN Isolated Key Generator (IKG) is a hardware component inside CRACEN. The IKG generates secret keys in a way that keeps them isolated from the CPU and software.

The IKG can derive three keys from a 384-bit seed value. These keys are also called special hardware keys. They are typically not meant for application use. This is because they are not accessible by any CPU, but CRACEN can use them for cryptographic operations, provided directly to the cryptographic engine as a hardware signal. IKG keys are not retained, and have to be regenerated for every CRACEN power cycle.

The 384-bit seed value is provisioned to the device or generated automatically during the first boot of the device using the CRACEN Random Number Generator (RNG), and then stored in the KMU. Before the keys can be generated, the KMU pushes the seed to the SEED register and validates it. Generating keys without a valid seed will fail.

IKG keys are also accessed using the standard PSA Crypto APIs, and are referenced by special built-in key IDs.

Key type	Key ID	Description
ECC secp256r1	`CRACEN_BUILTIN_IDENTITY_KEY_ID`	Used for signing/verification.
AES 256-bit	`CRACEN_BUILTIN_MKEK_ID`	Used for key derivation.
AES 256-bit	`CRACEN_BUILTIN_MEXT_ID`	Used for key derivation.

The keys are not exportable, except for the public key associated with the asymmetric key.

CRACEN side-channel countermeasures 

The CRACEN peripheral supports countermeasures to increase protection of asymmetric cryptographic operations against side-channel attacks and other malicious usage. For more information about the hardware implementation, see the device datasheet, for example CRACEN - Crypto accelerator engine in the nRF54L15 datasheet.

In the nRF Connect SDK, the following countermeasures are exposed through the CRACEN driver for configuration:

ECC operation countermeasures - Enabled by default through the CONFIG_CRACEN_ECC_COUNTERMEASURES Kconfig option.
- Scalar randomization (RandKE) - Randomizes the scalar value before point multiplication, preventing attackers from correlating power traces to individual scalar bits.
- Projective coordinate randomization (RandProj) - Randomizes the internal projective representation of curve points so that each execution uses different intermediate values, making power and electromagnetic analysis non-reproducible.
These countermeasures apply to the following cryptographic operations for devices that support them:
- ECDSA signature generation and public key generation
- ECC point multiplication
- Montgomery curve multiplication (X25519, X448)
- EdDSA base point multiplication
- Edwards point multiplication
RSA countermeasures - Enabled by default through the CONFIG_CRACEN_RSA_COUNTERMEASURES Kconfig option.
- Exponent randomization (RandKE) - Randomizes the private exponent during modular exponentiation.
- Modulus randomization (RandMod) - Randomizes the modulus representation to decorrelate power traces from key material.
These countermeasures apply to RSA CRT modular exponentiation, standard modular exponentiation, and SRP server operations, for devices that support them.

For more information, see Side-channel countermeasures.

KMU hardware peripheral 

The Key Management Unit (KMU) is a hardware peripheral that facilitates secure and confidential storage of cryptographic keys in a dedicated region of RRAM (secure information configuration region, or SICR). The KMU acts as an intermediary between the CPU and the CRACEN hardware peripheral. It is designed to hide key material from the CPU, while providing operations to import, use, revoke, or delete assets (keys and metadata).

The KMU can store cryptographic keys and 384-bit random seeds for the CRACEN Isolated Key Generator (IKG) in key storage slots. Each KMU slot can store 128 bits of key material, along with metadata and destination address information. Keys larger than 128 bits are stored across multiple consecutive slots.

Only the KMU can push assets to CRACEN’s protected RAM and the SEED register. This hardware-level isolation ensures that sensitive key material never needs to be exposed to the CPU during cryptographic operations.

KMU slots 

The KMU hardware peripheral is partitioned into 256 numbered slots. Each KMU slot is capable of storing 128 bits of key material, a 32-bit destination address (kmu_push_area), and 32 bits of KMU metadata (kmu_metadata). Storing keys that are larger than 128 bits is supported by using multiple, consecutive slots.

The application can use the KMU slots to store key data for its own purposes. Some KMU slots are reserved for current and future nRF Connect SDK use cases. The following table gives an overview of the KMU slots and their usage:

List of reserved KMU slots
Reserved KMU slots (range inclusive)	nRF Connect SDK usage	Description
180-182	Reserved	–
183-185	IKG seed	384-bit random seed to generate keys using the CRACEN IKG.
186	Internal provisioning slot	Reserved slot for internal KMU usage. This slot is used to validate that provisioning of the KMU slots is completed.
187-225	Reserved	–
226-227	UROT_PUBKEY_0	Revokable firmware image key for upgradable bootloader, generation 0. ED25519 public key.
228-229	UROT_PUBKEY_1	Revokable firmware image key for upgradable bootloader, generation 1. ED25519 public key.
230-231	UROT_PUBKEY_2	Revokable firmware image key for upgradable bootloader, generation 2. ED25519 public key.
232-241	Reserved	–
242-243	BL_PUBKEY_0	Revokable firmware image key for immutable bootloader, generation 0. ED25519 public key.
244-245	BL_PUBKEY_1	Revokable firmware image key for immutable bootloader, generation 1. ED25519 public key.
246-247	BL_PUBKEY_2	Revokable firmware image key for immutable bootloader, generation 2. ED25519 public key.
248-249	Reserved	Random bytes which invalidate the protected RAM content after an operation.
250-255	Reserved	–

For more information about the KMU slots, see the device datasheet, for example KMU - Key management unit for nRF54L15.

KMU metadata 

If you want to use the keys stored in the KMU using the CRACEN PSA Crypto driver, and especially if you want to handle KMU provisioning for production, you can configure several elements of the KMU slots:

SRC data struct fields for KMU provisioning
Field	Description
VALUE	The key material to be stored in the KMU slot.
RPOLICY	The revocation policy for the key.
DEST	For symmetric encryption/decryption keys, this is the CRACEN Protected RAM address. For asymmetric keys, this is a different RAM location according to usage.
METADATA	Information about the key type and its usage. It is required by the CRACEN driver for the verification of some properties of the key and its intended usage.

The configuration must follow the device datasheet (for example, KMU - Key management unit for nRF54L15) and the CRACEN driver’s expectations. These expectations are different depending on the method you choose to provision keys to the KMU - see KMU provisioning methods.

KMU provisioning 

When you provision the KMU, you store one of the key types supported by the KMU and its metadata in the dedicated slot of RRAM. You can use the keys stored in the KMU to perform cryptographic operations using the CRACEN PSA Crypto driver, either for bootloader or for application purposes.

For more information about KMU provisioning, see Provisioning the KMU.

How KMU and CRACEN work together 

The KMU and CRACEN hardware peripherals work together to provide secure cryptographic operations while protecting key material from exposure to the CPU.

The KMU stores cryptographic keys securely in hardware. When a cryptographic operation is needed, the KMU pushes keys directly to CRACEN’s protected RAM for symmetric operations, or to a reserved RAM area for asymmetric operations. For symmetric keys used in cipher operations, the KMU pushes the key material directly to CRACEN’s engine without exposing it to the CPU. For asymmetric keys, the KMU pushes the key to a reserved RAM location, which CRACEN loads into its engine before performing operations like signing or verification.

The CRACEN driver in the nRF Connect SDK exposes KMU operations through standard PSA Crypto API calls, with some vendor-specific extensions. The driver carries out cryptographic operations using the CRACEN hardware peripheral and supports the following KMU operations:

Importing (provisioning) keys to KMU slots.
Deleting a key from the KMU, allowing the underlying storage location to be reused.
Revoking a key from the KMU, preventing reuse of the underlying key slots.
Pushing symmetric keys directly from the KMU to the CRACEN symmetric engine, without exposing the key material to the CPU.
Directly pushing a 384-bit seed to CRACEN’s IKG to derive isolated keys.
Using isolated keys derived from CRACEN’s Isolated Key Generator (IKG) for encryption and signing purposes.
Pushing asymmetric keys to CPU RAM before loading them into CRACEN’s engine for asymmetric operations.

The keys that are stored in the KMU or generated by the IKG are referenced using the built-in keys that are key IDs in the range from MBEDTLS_PSA_KEY_ID_BUILTIN_MIN to and including MBEDTLS_PSA_KEY_ID_BUILTIN_MAX.

Additionally, the CRACEN driver supports storing encrypted keys in KMU slots, transparently decrypting them to a temporary RAM location before using them in cryptographic operations.