Security

Nordic Matter samples leverage security features supported in the nRF Connect SDK that can be divided into three major categories:

• Cryptography

• Trusted storage

• Securing production devices

In the following sections you will learn more details about each listed category.

Cryptography

Depending on the networking backend, the nRF Connect SDK Matter samples currently use the following APIs to implement cryptographic operations:

• PSA Cryptography API for Thread networking.

• Mbed TLS for Wi-Fi networking. Support for PSA Cryptography API for the Wi-Fi backend is planned for a future release.

Both APIs are integrated in the nRF Security library. This library offers various configuration possibilities and backends that can be employed to implement cryptographic operations. You can find an overview of the cryptography layer configuration supported for each nRF Connect SDK Matter-enabled platform in the Matter platforms security support section.

Trusted storage

Trusted storage in the nRF Connect SDK is a security mechanism designed to securely store and manage sensitive data, such as cryptographic keys, device credentials, and configuration data. The mechanism is essential for IoT devices, as it allows the implementation of secure communication between devices.

The Trusted Storage can utilize one of the following backends to implement PSA Certified Secure Storage API:

• TF-M Platform Root of Trust (PRoT). This can only be utilized if the ARM TrustZone technology and hardware-accelerated firmware isolation are supported by the platform in use.

• The Trusted storage nRF Connect SDK software library.

Currently all Matter samples in the nRF Connect SDK use the trusted storage library as a Trusted Storage backend for all supported platforms.

The trusted storage library provides confidentiality, integrity, and authenticity for the assets it operates on. It handles sensitive data in two contexts:

• Volatile - Before data is forwarded to the non-volatile storage and after it is retrieved from the non-volatile storage.

• Non-volatile - When data is written to the non-volatile memory in encrypted form.

In the case of the volatile context, the trusted storage library leverages the Authenticated Encryption with Associated Data (AEAD) encryption backend (CONFIG_TRUSTED_STORAGE_BACKEND_AEAD). It is used to encrypt and decrypt the assets that are being securely stored in the non-volatile memory. AEAD can be configured with the set of Kconfig options described in the library’s Configuration section.

An important setting, that depends on the hardware platform in use, is the way of generating the AEAD keys. The recommended and the most secure option is to use Hardware unique key (HUK) library. HUK support is automatically enabled with the CONFIG_TRUSTED_STORAGE_BACKEND_AEAD_KEY_DERIVE_FROM_HUK Kconfig option for compatible configurations.

The HUK library is supported for both the nRF52840 and nRF5340 platforms, but for Matter samples in the nRF Connect SDK, it is only enabled for the nRF5340 platform:

• For the nRF5340 platform, the HUK is generated at first boot and stored in the Key Management Unit (KMU). No changes to the existing partition layout are needed for products in the field.

• For the nRF52840 and nRF54L15 platforms, AEAD keys are derived with a SHA-256 hash (CONFIG_TRUSTED_STORAGE_BACKEND_AEAD_KEY_HASH_UID). This approach is less secure than using the library for key derivation as it will only provide integrity of sensitive material. It is also possible to implement a custom AEAD keys generation method when the CONFIG_TRUSTED_STORAGE_BACKEND_AEAD_KEY_CUSTOM Kconfig option is selected.

  Using the HUK library with nRF52840 SoC is possible, but it requires employing the nRF Secure Immutable Bootloader that would generate the AEAD key at first boot and store it in the dedicated HUK partition that can be accessed only by the CryptoCell peripheral. Note that adding another partition in the FLASH layout implies breaking the firmware backward compatibility with already deployed devices.

  Note

  Using the HUK library with the nRF54L15 SoC is not possible yet. This means that you need to use AEAD keys derived with a SHA-256 hash.

You can find an overview of the Trusted Storage layer configuration supported for each nRF Connect SDK Matter-enabled platform in the Matter platforms security support section.

Matter platforms security support

The following table summarizes the current security configuration and features supported for Matter-enabled hardware platforms in the nRF Connect SDK. This is a reference configuration that can be modified in the production firmware by using proper Kconfig settings or implementing custom cryptographic backends.

Matter platforms security support

Platform	Networking backend	Cryptography API	Cryptography backend	ARM TrustZone support	Trusted Storage backend	Trusted Storage AEAD key
nRF52840 SoC	Thread	PSA	Oberon + CryptoCell [1]	No	Trusted Storage library	SHA-256 hash
nRF5340 SoC	Thread	PSA	Oberon + CryptoCell [1]	Yes	Trusted Storage library	Hardware Unique Key (HUK)
nRF5340 SoC + nRF7002 companion IC	Wi-Fi	Mbed TLS	Oberon + CryptoCell [1]	Yes	—	—
nRF54L15 SoC	Thread	PSA	CRACEN + Oberon [2]	Yes	Trusted Storage backend	SHA-256 hash

[1] (1,2,3)

The CryptoCell backend is used in parallel with the Oberon backend. It is only used to implement Random Nuber Generation (RNG), and the AED keys derivation driver (only for Thread networking). For all other cryptographic operations, the Oberon backend is used.

[2]

When the CRACEN driver is used in parallel with the Oberon driver, you need to disable specific CRACEN cryptographic operations to use the Oberon ones. This is because the CRACEN driver has priority when both are enabled. See the nRF Security drivers documentation for more information.

Securing production devices

When finalizing work on a Matter device, make sure to adopt the following recommendations before sending the device to production.

Enable AP-Protect

Make sure to enable the AP-Protect feature for the production devices to disable the debug functionality.

Several Nordic Semiconductor SoCs or SiPs supported in the nRF Connect SDK offer an implementation of the access port protection mechanism (AP-Protect). When enabled, this mechanism blocks the debugger from read and write access to all CPU registers and memory-mapped addresses. Accessing these registers and addresses again requires disabling the mechanism and erasing the flash.

See Enabling access port protection mechanism for more information.

Disable debug serial port

Make sure to disable the debug serial port, for example UART, so that logs and shell commands are not accessible for production devices. See the prj_release.conf files in Matter samples for an example of how to disable debug functionalities.