Key storage in the nRF Connect SDK

Cryptographic keys are critical security assets that require secure storage and management.

This page provides an overview of the available key storage options in the nRF Connect SDK.

For information about storing general data, see Data storage in the nRF Connect SDK.

General key storage recommendations

When implementing key storage in your application:

  • Use the PSA Crypto API for all cryptographic operations.

  • Generate keys on-device when possible rather than importing them.

  • Leverage hardware features like Hardware Unique Key (HUK) and Key Management Unit (KMU) when available.

  • Enable access port protection in production to prevent debug access.

  • Use persistent keys through the PSA Crypto API when you need to store key material.

  • Implement proper key provisioning workflows for production devices.

Key storage options

Each option offers different security features and use cases.

PSA Crypto API

The PSA Crypto API is the recommended approach for cryptographic key management in the nRF Connect SDK. It provides a standardized, secure interface for key operations that abstracts the underlying hardware and software implementations.

This option offers the following features:

  • Secure key handling - Keys are managed securely without exposing key material.

  • Hardware acceleration - PSA Crypto API uses available cryptographic hardware when possible.

  • Standardized interface - PSA Crypto API follows PSA Certified standards for interoperability.

  • Key isolation - Keys can be isolated in the Secure Processing Environment (SPE) when using Trusted Firmware-M.

Key generation and import

Keys can have one of the following lifetimes:

  • Volatile - Stored in RAM, lost on reset.

  • Persistent - Stored in PSA Internal Trusted Storage or Key Management Unit, retained during reboots.

The PSA Crypto API supports two methods for using keys:

  • Key generation - Use psa_generate_key() to create random keys.

  • Key import - Use psa_import_key() to import existing key material. After import, the key is referenced by ID rather than direct access to key material.

Note

Generated keys are more secure than imported keys. This is because when generating keys the key material is never exposed to the application directly.

For more information, see Key management functions in the PSA Crypto API documentation.

Configuration

For information about how to configure the PSA Crypto API in the nRF Connect SDK, see Configuring PSA Crypto API.

Usage example

For usage examples, see Cryptographic samples, specifically the Persistent key usage sample.

Hardware Unique Key (HUK)

Hardware Unique Keys (HUKs) are device-specific keys that you can use for key derivation. HUKs provide a foundation for creating device-unique cryptographic keys without storing key material in software.

This option offers the following features:

  • Device uniqueness - Each device has a unique set of HUK values.

  • Hardware protection - Keys are stored in hardware-protected memory.

  • Key derivation - HUKs are used to derive other keys rather than directly perform cryptographic operations. The derived keys are then passed to the application.

See the Hardware unique key library for the list of supported HUKs in the nRF Connect SDK.

Device support

Different Nordic Semiconductor devices support different types of HUKs. See Hardware unique key for device-specific support information.

Usage

You cannot use HUKs directly. You can however use the Hardware unique key library to derive keys from HUKs using known labels.

You can use HUKs indirectly through PSA Secure Storage without TF-M, for example through the Trusted storage library. In such case, the HUK library will be used to derive keys that are then used to encrypt storage entries. This is done to prevent the application from accessing the HUK directly.

Configuration

To use the HUK storage options for keys, enable the CONFIG_HW_UNIQUE_KEY Kconfig option. For more configuration options, see the Hardware unique key library.

Usage example

If you use the HUK library, ensure that the HUKs are written. For an example of how to write HUKs, see the TF-M Provisioning image or Crypto persistent key usage samples.

For an example of how to derive keys from HUKs, see the Hardware unique key sample.

Key Management Unit (KMU)

The Key Management Unit (KMU) is a hardware peripheral for secure key storage available on select Nordic Semiconductor devices. It provides hardware-level protection for cryptographic keys.

This option offers the following features:

  • Hardware security - Keys are stored in dedicated hardware.

  • CPU isolation - CryptoCell and CRACEN can use KMU keys without CPU access to key material.

  • Metadata only - CPU only knows key metadata, not key material.

  • Multiple key slots - Supports storing multiple keys separately.

Device support

KMU is available on the following devices:

Key storage

The KMU stores various types of keys (when they are not just derived):

  • Hardware Unique Keys (MKEK, MEXT)

  • Initial Attestation Key

  • User-defined keys

Note

Consider using the PSA Crypto API or HUK library before working directly with KMU APIs, as these higher-level interfaces often provide the functionality you need with better security practices.

Configuration

Configuring the KMU varies depending on the device. See the device-specific documentation for more information.

For the nRF54L Series devices, you can use nRF Util for provisioning keys to KMU. See Provisioning cryptographic keys in the nRF Util documentation for more information.

One-Time Programmable (OTP)

Caution

OTP provides no read protection. Use it only for non-sensitive data. Do not use it to store sensitive keys that need to remain confidential.

One-Time Programmable (OTP) memory provides permanent, write-once storage for keys and other critical data. OTP memory is part of the User Information Configuration Registers (UICR).

This option offers the following features:

  • Write-once - Can only be programmed once, providing tamper evidence.

  • Non-volatile - Retains data without power.

  • No read protection - Data can be read by any code with appropriate access.

Use cases

OTP is suitable for storing the following data:

  • User IDs or device identifiers

  • Feature activation keys

  • Root certificates or trust anchors

  • Any data that should never change during device lifetime

Device support

Not all nRF devices have OTP peripherals. Check device-specific documentation for more information. For example, nRF5340 OTP and nRF9160 OTP.

Usage

Use the NVMC data storage option for OTP operations, and specifically the nrfx_nvmc_otp_halfword_read() function for reading OTP data.

Wi-Fi Credentials

For Wi-Fi applications, the nRF Connect SDK provides the Wi-Fi credentials library for loading and storing Wi-Fi® network credentials. This library is leveraging either Zephyr’s Settings subsystem or PSA Internal Trusted Storage (ITS) to store credentials.

This option offers the following features:

  • PSA Internal Trusted Storage backend - Benefits from encryption and integrity protection.

  • Easy-to-use API - Simplified interface for Wi-Fi credential management.

  • Multiple networks - Support for storing multiple Wi-Fi network credentials.

Configuration

To use the Wi-Fi credentials library, enable the CONFIG_WIFI_CREDENTIALS Kconfig option. For more configuration options, see the Wi-Fi credentials Library page.

Usage example

See the Wi-Fi Bluetooth LE based provision sample for an example.

Additional considerations

The nRF Connect SDK includes several additional features that are related to cryptographic key storage.

Initial Attestation Key (IAK) / Identity Key

The Initial Attestation Key (IAK), also known as Identity Key, is required by PSA Certified Security Framework for PSA Attestation API. This key is used to sign attestation tokens that prove the device’s identity and integrity state.

This option offers the following features:

  • Device identity - Provides cryptographic proof of device identity.

  • Attestation support - Meets the requirement for PSA Attestation implementation.

  • Hardware protection - Ensures access is limited to hardware. For devices other than the nRF54L Series, the key is encrypted using MKEK and stored in Key Management Unit (KMU). For nRF54L Series devices, the key is derived each time.

When using TF-M, the Initial Attestation service uses the IAK to sign attestation tokens that prove the device’s identity and integrity state.

Configuration

When using TF-M, you must generate and provision the IAK before running applications. The configuration is device-specific.

Complete the following steps:

  1. Generate the MKEK first (required for IAK encryption). See the TF-M Provisioning image sample for an example.

  2. Generate the IAK using the Identity key library. See the Identity key generation sample for an example.

The IAK is automatically encrypted and stored securely.

Usage example

See the Identity key usage sample for an example.

Modem certificate storage

The nRF91 Series modem includes a dedicated certificate storage and integrated TLS/DTLS driver. The application can write (provision) certificates to slots in the modem and choose which slots the modem should use for TLS in communication.

Certificates are provisioned to the modem before the main application runs. Once written, they cannot be read back by the application, which provides a level of protection similar to hardware-backed key storage such as the KMU.

Hardware flash write protection

The nRF Connect SDK provides the fprotect driver for hardware-level flash protection. This driver uses underlying hardware peripherals (BPROT, ACL, or SPU) to protect flash regions from unauthorized writes or reads.

Use fprotect to protect stored keys from modification, secure bootloader regions, and implement additional layers of security.

Configuration

To use the fprotect driver, enable the CONFIG_FPROTECT Kconfig option. For more information, see the Hardware flash write protection page.

Access port protection (AP-Protect)

The access port protection mechanism (AP-Protect) prevents the debugger from accessing device resources, including keys and sensitive data. When enabled, AP-Protect blocks read and write access to CPU registers and memory-mapped addresses.

Nordic Semiconductor recommends enabling AP-Protect in production devices to prevent extraction of keys and sensitive data through debug interfaces.

Configuration

AP-Protect configuration is device-specific. See Implementation overview for detailed information.