What is DFU (Device Firmware Update)?

A device firmware update (DFU) is an operation used to, partially or fully, update the firmware on a device.

In most cases, DFU relies on the existence of a Bootloader. A bootloader is a minimal piece of code that is responsible for:

  • Launching the main firmware or operating system (OS) in a device.
  • Providing the capability of updating the device’s main firmware or OS.

It is usually optimized and kept to a minimum due to the following reasons:

  • To ensure minimum impact on boot times.
  • To ensure bugs are kept to a minimum in this critical part of the device’s firmware. Bootloaders are rarely updated, so they need to be robust (more lines of code usually increase the probability of bugs).
  • The size of the bootloader impacts how much ROM is left for the application firmware.

In general, the main operations of a DFU process include:

  • Updating the application, the stack/OS (and sometimes even the bootloader).
  • Verifying DFU package authenticity.
  • Downgrade prevention.
  • Verifying hardware compatibility.
  • Verifying data integrity.
  • Decrypting encrypted data.
  • Support for updating over different transport mediums.

One thing to note is that DFU sometimes involves multiple parts of the system that can be all, or partially, updated with the firmware update process (e.g. bootloader, RTOS/stack, and application).

What is OTA DFU?

OTA stands for “Over The Air” and simply refers to the fact that the DFU package is sent to the target/end-device over a wireless connection. In our case, the wireless medium is Bluetooth Low Energy. For OTA DFU over BLE, there are three main parts:

  1. Packaging of the DFU image to be transferred to the target device.
  2. Design of the GATT Services and Characteristics needed for the transfer of the DFU image down to the target device.
  3. Design of the device firmware update process itself for the target chipset once the device receives the DFU image.

Vendors usually provide an implementation of #3 on the target chipset as well as the tools necessary for #1. Part #2 is optional and sometimes not provided by the vendor. Even if this part is provided by the chipset vendor, in some cases, the end-device designer may wish to design their own implementation.

In this course, we’ll provide an example of utilizing Nordic’s OTA DFU implementation for the nRF52 series chipsets.

Benefits of OTA DFU

While implementing OTA DFU might be/seem like a daunting and complex feat, it has very important benefits. Also, with the proliferation of connectivity for battery-powered and remote devices in recent years, OTA DFU has become more of a product requirement rather than a nice-to-have feature.

Some of the most important benefits of OTA DFU include:

  • Adding new features to the end product.
  • Fixing critical bugs and addressing security vulnerabilities.
  • Cutting costs: a product recall is usually way more costly than implementing OTA DFU, especially in large product deployments.

As you can see, the benefits of OTA DFU will usually outweigh the cost of implementing this capability in your end product.

Robust and Secure OTA DFU Process

With the introduction of OTA DFU, you are exposing your device to a new attack vector. With the increasing popularity of OTA DFU capability in IoT devices, many devices are now getting more exposure to vulnerabilities and security threats. Because of this, it is extremely important to make sure that your device’s OTA DFU process is very robust and, most importantly, secure.

Here are a few of the most important aspects to keep in mind when designing your OTA DFU process:

  • Secure:
    • Applying data and communications security measures via encryption of both the DFU image and the transmission channel.
    • Identity verification via adding a digital signature to the DFU image that proves the authenticity of the image (signed by the official DFU creation authority).
  • Reliable:
    • Being able to verify that the received DFU image is complete and not corrupted and only updating to this new image if this is the case.
    • Being able to recover in case of failure. This can be achieved by writing the new DFU image to a space in flash memory that does not overlap with the original image. If the new image is validated, then the bootloader may not point to run the new image instead of the old one. In the failure case, the bootloader will simply revert to running the original image, and the DFU process may be retried.
    • Minimal disruption to functionality by optimizing the time it takes to complete a firmware update operation and allowing the device to operate normally (as much as possible).
  • Version management:
    • Rollback prevention measures to ensure that a malicious party cannot roll back the firmware to an older valid version that may contain vulnerabilities and security holes.
    • In order to implement these measures, a versioning system must be implemented.