Security

The following sections give a brief introduction to core security features available in Nordic Semiconductor products. The features are made available either as built-ins in modules, drivers, and subsystems, or are shown in samples or applications in nRF Connect SDK.

Secure boot

The nRF Connect SDK supports secure boot of application images enforced by the bootloader. The secure boot utilizes signature validation and security hardware features to establish a root-of-trust during the boot process, and to ensure the validity of the firmware that is booted.

There are two available bootloaders in nRF Connect SDK:

• nRF Secure Immutable Bootloader (NSIB), enabled by the configuration option CONFIG_SECURE_BOOT.

• A customized version of sdk-mcuboot, enabled by the configuration option CONFIG_BOOTLOADER_MCUBOOT.

When enabling the NSIB, the MCUboot can serve as an upgradable second-stage bootloader. For more information about the bootloaders, see Bootloaders.

Trusted Firmware-M

The Trusted Firmware-M project (TF-M) is a reference design of the Arm Platform Security Architecture (PSA). Through TF-M, nRF Connect SDK utilizes the security features of the Arm TrustZone technology to configure secure peripherals and memory, and to provide PSA functional APIs as secure services.

TF-M enables hardware supported separation of a Secure Processing Environment (SPE) and a Non-Secure Processing Environment (NSPE) that constitutes the Zephyr RTOS, protocol stacks, and the application. Enable TF-M in a project by enabling the CONFIG_BUILD_WITH_TFM option.

For more information about the TF-M, see the TF-M documentation and Running applications with Trusted Firmware-M. For more information about SPE and NSPE in the nRF Connect SDK, see Processing environments.

Hardware unique key

Nordic Semiconductor devices featuring the CryptoCell cryptographic accelerator allow the usage of a hardware unique key (HUK) for key derivation. A HUK is a unique symmetric cryptographic key which is loaded in special hardware registers allowing the application to use the key by reference, without any access to the key material. To enable the HUK in an application, enable the CONFIG_HW_UNIQUE_KEY option.

For more information, see the hardware unique key library and sample.

Trusted storage in the nRF Connect SDK

There are several options for storing keys and other important data persistently when developing applications with the nRF Connect SDK. Different storage options have different features. One of the options is to use the Trusted storage library.

The trusted storage library enables the users to provide features like integrity, confidentiality and authenticity of the stored data, without using the TF-M Platform Root of Trust (PRoT). The library implements the PSA Certified Secure Storage API. It consists of PSA Internal Trusted Storage API and PSA Protected Storage API.

The Internal Trusted Storage and the Protected Storage are designed to work in environments both with and without security by separation. The two APIs used in the trusted storage library are also offered as secure services by TF-M. While TF-M enables security by separation, building and isolating security-critical functions in SPE and applications in NSPE, the trusted storage can be used in environments with no TF-M and separation of firmware.

The table below gives an overview of the trusted storage support for the products and their features.

Trusted storage product support

Product	Backend	Confidentiality	Integrity	Authenticity	Isolation
nRF91 Series with TF-M	TF-M secure storage service	Yes	Yes	Yes	Yes
nRF91 Series without TF-M	Trusted storage library	Partial [1]	Yes	Yes	No
nRF5340 with TF-M	TF-M secure storage service	Yes	Yes	Yes	Yes
nRF5340 without TF-M	Trusted storage library	Partial [1]	Yes	Yes	No
nRF52840	Trusted storage library	Partial [1]	Yes	Yes	No
nRF52833	Trusted storage library	Partial [2]	Yes	Yes	No

[1] (1,2,3)

On systems without the isolation feature, the confidentiality is limited to protection of data at rest in a non-volatile internal or external memory. This partial confidentiality is based on a CPU-inaccessible master key used for data encryption. When the data is decrypted for usage, there is no mechanism providing access control and protecting its visibility. Use of a TrustZone-enabled system provides stronger protection, and is recommended if available.

[2]

The use of Hardware Unique Key (HUK) to provide the AEAD key is not available on nRF52833 devices. The trusted storage library offers the use of SHA-256 to generate the key, which does not provide guarantees of security beyond the integrity check of the encrypted data.

The trusted storage library addresses two of the PSA Certified Level 2 and Level 3 optional security functional requirements (SFRs):

• Secure Encrypted Storage (internal storage)

• Secure Storage (internal storage)

The Secure External Storage SFR is not covered by the trusted storage library by default, but this can be realized by implementing a custom storage backend.

Device firmware upgrade (DFU)

The nRF Connect SDK supports firmware upgrade using over-the-air (OTA) and serial firmware upgrades, depending on the capabilities of the device. For more information about the firmware upgrades, see the available DFU libraries.

The nRF Connect SDK can be configured to enforce secure DFU mechanisms, including validating the digital signature of an image and checking for the version to prevent downgrade attacks. The secure DFU mechanisms are handled by the MCUboot bootloader. For more information, see the MCUboot documentation.

Cryptographic operations in nRF Connect SDK

Cryptographic operations in nRF Connect SDK are handled by the nRF Security, which is configurable through Kconfig options. The module can be enabled through the CONFIG_NRF_SECURITY Kconfig option, and it allows the usage of Mbed TLS and PSA Cryptography API 1.0.1 for cryptographic operations and random number generation in the application.

The nRF Security acts as an orchestrator for the different cryptographic libraries available in the system. These libraries include the binary versions of accelerated cryptographic libraries listed in Crypto Libraries, and the open source Mbed TLS implementation in nRF Connect SDK located in sdk-mbedtls.

HW accelerated libraries are prioritized over SW libraries when both are enabled. For more information about the configuration and usage of the nRF Security, see the Configuration page.

See also Cryptography samples for examples of how to configure and perform different cryptographic operations in the nRF Connect SDK.

Access port protection mechanism

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.

For more information, see Enabling access port protection mechanism.