Downgrade protection

The downgrade protection feature blocks downgrading the firmware version on the device. This can be useful for security reasons, because firmware downgrade can allow attackers to bring back security vulnerabilities that were fixed by a particular firmware update.

As part of this process, the bootloader compares the new firmware image version with the version of the currently booted firmware. The bootloader rejects the update if the new image version is lower than the version of the currently booted firmware.

The implementation is related to the Image versions and depends on the type of bootloader used:

Software-based downgrade protection is supported only by MCUboot. In this kind of protection, the current firmware version is encoded into the currently active image.
Hardware-based downgrade protection is supported by both MCUboot and nRF Secure Immutable Bootloader. In this kind of protection, the current version is encoded into a non-volatile storage partition outside of any image.

Software-based downgrade protection 

The nRF Connect SDK supports MCUboot’s software-based downgrade prevention for application images, using semantic versioning. This feature offers protection against any outdated firmware that is uploaded to a device.

To enable this feature, set the MCUboot-specific configuration options CONFIG_MCUBOOT_DOWNGRADE_PREVENTION and CONFIG_BOOT_UPGRADE_ONLY for the MCUboot image.

Caution

Enabling CONFIG_BOOT_UPGRADE_ONLY prevents the fallback recovery of application images. Consult its Kconfig description and the MCUboot Design documentation for more information on how to use it.

You can compile your application with this feature as follows:

west build -b board application -- \
-DCONFIG_BOOTLOADER_MCUBOOT=y \
-DCONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION=\"0.1.2\+3\" \
-Dmcuboot_CONFIG_MCUBOOT_DOWNGRADE_PREVENTION=y \
-Dmcuboot_CONFIG_BOOT_UPGRADE_ONLY=y

See Configuring and building an application for information on how to set the required configuration options temporarily or permanently.

After you upload a new image and reset the development kit, MCUboot attempts to boot the secondary image. If this image has, in order of precedence, a major, minor, or revision value that is lower than the primary application image, it is considered invalid and the existing primary application boots instead.

Note

The optional label or build number specified after the + character is ignored when evaluating the version. For example, an existing application image with version 0.1.2+3 can be overwritten by an uploaded image with 0.1.2+2, but not by one with 0.1.1+2.

Hardware-based downgrade protection 

You can implement hardware-based downgrade protection using a non-volatile monotonic counter.

Counter updates are written to slots in the Provision area, with each new counter update occupying a new slot. For this reason, the number of counter updates, and therefore firmware version updates, is limited. The Provision is a partition in non-volatile memory, and its location can be found using Partition Manager report.

Using a counter is optional and can be configured for the application using configuration options. You can also configure the supported number of updates, but the number is limited by the size of the Provision area and how much of that area is taken up by other features, like public key hashes. In addition, you can configure what firmware version of the image you want to boot.