Introduction

When an nRF5 SDK project uses a bootloader, the system can contain up to four separate, standalone programs or "images": Master Boot Record (MBR), the SoftDevice, the application, and the bootloader itself. When the chip comes out of reset, for example through a pin reset, a soft reset (triggered by software), or when waking up from a sleep state, it always starts executing the image located at address 0 (zero), unless debugging is enabled.

This first image that is booted is the MBR. It is required that the MBR is available as the first image. The MBR looks up the location of the bootloader and boots it. If it cannot find a bootloader, it boots the image that directly follows itself, at address 0x1000 (for nRF52 devices).

The bootloader is responsible for the secure boot functionality. It uses cryptographic signatures to ensure that firmware can be verified as signed by the private key, and that it is not corrupted. It does this by doing checks at two critical points: when booting the system, and whenever a firmware update is received:

Checking at boot time ensures that nothing has changed the already present code. See Boot validation.
Checking at update time ensures that any new code that arrives is also valid. See Activation of updates.

Note: These checks can be enabled or disabled using the sdk_config.h file. This description of the secure boot process assumes that update-time signature checks are enabled.

In addition to cryptography, the bootloader uses hardware protection mechanisms to further ensure that the code on the device stays unchanged. nRF52 devices have a BPROT or ACL peripheral which can be used to disable write access to flash until next reset. Write access cannot be enabled again once disabled, except through a reset. The bootloader uses this functionality to protect itself and the MBR as soon as it boots, as well as for protecting the application and the SoftDevice before booting them.

Memory layout, protection details, and boot order

The MBR and bootloader together make up the Root of Trust (RoT) of the system. Because they are booted first, these images are able to protect the system from unintentional or malicious tampering by the application, and detect injected code.

Boot validation

The following sections describe various aspects of boot validation.

Cryptography

The bootloader uses Elliptic Curve Digital Signature Algorithm (ECDSA) secp256r1 together with the SHA-256 hashing algorithm. The ECDSA public key is compiled into the bootloader in an uncompressed, raw format (little-endian X followed by little-endian Y). The signatures are stored as little-endian R followed by little-endian S.

Note: "Signature" in this document refers to ECDSA digital signatures. "Digest" refers to SHA-256 cryptographic digests.

Boot validation modes

Boot validation can run in four modes, depending on the configuration:

Signature validation (ECDSA):
Direct authentication against signature on each boot. Highest security and highest cost in power and time.
Only this mode can be considered as secure boot.
Hash validation (SHA-256):
Lower security, and slightly lower power and time cost. Hash validation can detect unintentional changes to code, but not intentional malicious changes that are advanced enough to circumvent the hash check or re-write the reference digest.
CRC validation (CRC32):
Protection against chance events but, in theory, no protection against malicious attacks. Significantly lower power and time cost.
No validation:
Power and time cost is limited to short housekeeping tasks in the MBR and bootloader, essentially applying write protection, checking whether a DFU operation has been requested, and booting to the next stage.

Selecting the boot validation mode

The firmware update package decides which mode is to be used for each image. Only the SoftDevice and the application can be validated because the bootloader performs the validation. Note that bootloaders are always checked when they are updated.

If the signature mode is specified, the signature is also part of the update package. This signature is verified using the same public key that is used to check the update package itself.

For hash and CRC modes, the reference digest is created on-chip and written to flash when the update is applied. Note that the bootloader can be configured to only accept update packages using the signature mode.

The four secure boot modes apply only to the boot validation, and are independent of the validation performed during firmware upgrade. That means that an update package is signed regardless of the secure boot mode contained in it. The update-time validation combined with the BPROT/ACL protection means that the system is protected from unauthorized firmware image installation even with no boot validation. This is relevant since boot validation spends both power and time on each boot, which restricts its usage in certain applications.

Root of Trust (ROT) reset

Whenever the bootloader takes a sensitive action, like upgrading an image, the system must go through a Root of Trust reset to be put into a known state, as well as to release the BPROT/ACL protections.

Activation of updates

After an update package has been received, the bootloader requires a Root of Trust reset before it checks the update for the last time. If the check passes, the package is activated: it is copied into place and its metadata is written into the active part of its settings page.

When activating an update of the bootloader itself, the bootloader cannot perform the activation since its code cannot be running while it is being rewritten. Instead, the bootloader leverages the MBR, which has the ability to perform power-failure-safe copy operations. The bootloader calls into the MBR (through SVC) which stores the operation details in the MBR params page. The MBR then does its own Root of Trust reset and follows the instructions it left for itself in the MBR params page. If a reset happens at any time during the copy procedure, the MBR will continue or restart the copy operation, because its details are stored in flash. After this is done, it erases the MBR params page and boots the new bootloader.

Bootloader settings backup

The bootloader settings page contains sensitive information that should be changed only as a result of authorized firmware upgrades. Because of this, it always keeps a protected backup. The original settings can be left open to allow the application to exchange data with the bootloader (for example, for background DFU). However, the sensitive parts of the settings page are always read from the backup to protect against both malicious and unintended tampering.

Recoverability

The bootloaders in the nRF5 SDK have standalone DFU capabilities, which means that even if the application is completely non-functional, the system can be recovered using the bootloader's DFU mechanism. Note that BLE bootloaders require the SoftDevice.

Depending on configurations, GPIOs can be used to force the bootloader into DFU mode instead of booting the current application.

Security Configuration of the app and bootloader

The following configuration options are related to security. See the sdk_config.h file for detailed descriptions, as well as a complete list of available configuration options. See also some notes on configuration below.

NRF_BL_APP_SIGNATURE_CHECK_REQUIRED
NRF_BL_DEBUG_PORT_DISABLE
NRF_DFU_APP_ACCEPT_SAME_VERSION
NRF_DFU_APP_DOWNGRADE_PREVENTION
NRF_DFU_HW_VERSION
NRF_DFU_REQUIRE_SIGNED_APP_UPDATE
NRF_DFU_EXTERNAL_APP_VERSIONING (if external apps are enabled)
NRF_DFU_FORCE_DUAL_BANK_APP_UPDATES (if using background DFU)
NRF_DFU_BLE_REQUIRES_BONDS (if using buttonless BLE DFU)

The flash patch functionality in Cortex-M4 can be used by malicious code to circumvent the secure boot checks. In nRF52840 and nRF52833, flash patch can be disabled by writing 0x00 to CPUFPBEN in DEBUGCTRL. Note that this also disables breakpoints, so it is not done by default. Enabling NRF_BL_DEBUG_PORT_DISABLE will also write 0 to CPUFPBEN.

The Debug Access Port (DAP) has, by default, full memory access and register access to the CPU core and peripherals. The DAP can be disabled using APPROTECT. In nRF52840 and nRF52833, ITM/ETM trace can also be disabled by using DEBUGCTRL. Enabling the NRF_BL_DEBUG_PORT_DISABLE configuration option disables both UICR registers APPROTECT and DEBUGCTRL.

Enforcing strictly ascending application versions prevents rollback attacks which exploit known security flaws in older versions of an image. You can do this by disabling the NRF_DFU_APP_ACCEPT_SAME_VERSION config option.

If multiple projects share a public key, images from one project can risk being applied to a device from another, potentially bricking it. To avoid this, the projects must use different HW IDs (NRF_DFU_HW_VERSION).

Anyone with access to the private key can put any firmware they want onto your device. Private key management is outside the scope of this documentation.

Table of Contents