Implementing Over-the-Air Device Firmware Update (OTA DFU) – Part 1

Introduction

One of the most important and critical features of wirelessly-connected devices is the capability of over-the-air device firmware updates (aka OTA DFU).

You may be asking “why is this becoming an increasingly popular and in-demand feature?”

Well, it’s due to many good reasons, some of which are:

• The increasing demand by end-users for new functionality.
• To address bugs and security vulnerabilities (critical and non-critical).
• To ship products to market faster and have the option of delaying lower priority features and being able to roll them out to devices in the field.

As you can see, these reasons (and many others) make OTA DFU one of the most critical and important features in a wireless connected device.

Bluetooth Low Energy has recently become very popular especially in wearables, medical devices, beacons, and other devices that utilize a smartphone as a way to interface with small resource-constrained devices. As such, Bluetooth Low Energy serves as one of the most popular mediums for performing OTA DFU for wirelessly-connected devices.

Unfortunately, the resources on the subject are either scarce, very scattered or very specific to a certain platform.

So, I set out with the goal to gather all the important guidelines and theory behind the subject and put them all in a single post.

In this tutorial, we’ll go over:

• What is Device Firmware Update (DFU)?
• What is Over-the-Air Device Firmware Update (OTA DFU)?
• How does OTA DFU work? 
• The role of the bootloader
• The basic steps of OTA DFU
• Best practices in implementing OTA DFU

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 Over-the-Air Device Firmware Update (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 Bluetooth Low Energy, 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.

Why implement OTA DFU capability?

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.

Ensuring a 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: encryption + identity verification (via digital signatures).
• Reliable: verifying integrity + failure recovery.
• Version management: rollback prevention + versioning system.

How Does OTA DFU work?

Here are the basics of how an over-the-air device firmware update (DFU) process works:

1. Firmware Image and manifest are encrypted, signed, and uploaded to the firmware update server.
2. End-device queries the firmware update server and fetches new firmware image and manifest.
3. The package will be decrypted, validated and applied.

These are simply generic steps and depending on the chipset used and system design, there will usually be differences in your own implementation.

Example of an OTA DFU Process Workflow

Let’s look at an example of the DFU process. Here’s an example from the documentation of Nordic’s DFU process:

A few notes about this diagram:

• The diagram shows the operations and workflow that occurs on the target device.
• “DFU controller” refers to the device that connects to the target BLE device that needs to be updated and transfers the firmware image to. This could be a mobile phone running an app or nRF Connect on desktop (via an nRF52 DK).
• The target device may be running the bootloader in DFU mode or running the application with DFU running in the background.
• The DFU controller connects to the target device and initiates the transfer of the DFU image.
• The target device will first receive an init packet which it validates (pre-validation phase).
• The init packet contains important information such as the type of image, hash of the image, firmware version, hardware version, allowed versions of the SoftDevice, and others.
• If the init packet is validated, the controller will then initiate the transfer of the DFU image to the target.
• The target will receive the full DFU image and validate it.
• Once the DFU image is validated, the target will reset and the bootloader will activate the new DFU image to replace the original image.
• The process is capable of handling updates to the Bootloader + SoftDevice + Application all in one package. Other subsets of this combination are allowed as well, with some exceptions (more information can be found here).

Other Examples of OTA DFU using Bluetooth Low Energy

Here are a few other great examples of OTA DFU implementations:

• mbed FOTA service
• ST FOTA upgrade
• BLE113 over the air update

Best Practices for Implementing OTA DFU

Designing an OTA DFU process can be a lengthy process, and rightfully so. OTA DFU is a risky operation that can break a device’s functionality or make a device vulnerable to security holes. In order to reduce these risks, best practices need to be followed.

Here are some of the best practices to follow when designing your system’s OTA DFU process:

1. Digital Signing: digital signatures ensure the authenticity of the image and integrity of the data in the image. Without a signature, there’s no way to verify that the image came from an authentic source, and it could’ve come from a malicious third-party. A digital signature also ensures that the data within the image has not been modified (preserving integrity) and is intact/complete as it was generated at the source/author.
   
2. Encryption: encrypting the image ensures the confidentiality of the data. This makes that no unauthorized parties are able to peek at the contents of the image and make sense of it. Only the end-device should be able to decrypt the image. This is especially true for wireless over-the-air updates since the data will be susceptible to third parties sniffing the communications channel used to transfer the image. Security measures also have to be in place to protect any decrypted version of the image that’s stored locally on the end-device.
   
3. Communications channel protection: in addition to taking the necessary security measures to protect the DFU image itself (at the source and destination), measures need to be taken to secure the communications channel over which the DFU image is transferred. Depending on the communication technology used, there are different configurations and implementations that would make sure the communications channel is secure. Examples include utilizing Bluetooth LE Secure Connections (which requires version 4.2 or later), TLS, etc.
   Keep in mind that communications channels are not always wireless and may involve intra-system transfers such as from an SoC to external flash. This could pose a security threat if a malicious party gets physical access to the end-device.
4. Versioning: one of the security measures that need to be put in place is to make sure that a DFU update cannot be performed with an older version of the firmware. In order to achieve this, a versioning system must be put in place allowing only newer versions to be installed.
   
5. Recoverability: a process needs to be put in place to recover from failures in different stages of the DFU process. This includes handling scenarios such as loss of power, data corruption, manipulated DFU image, etc, and being able to roll back the firmware to the original image.
   
6. Logging and status reporting: It’s good practice to log operations and their statuses during DFU processes over the lifetime of a product. These logs could be reported to other devices within the system (such as a gateway, cloud server, etc.) for remote monitoring purposes. They could be useful for debugging purposes or for a better understanding of the causes of failures that may have occurred during a DFU.
   
7. Timely updates: ensuring timely updates can be critical for certain systems or in specific scenarios such as when a security vulnerability has been discovered. In this case, the manufacturer would want to make sure all devices in the field are updated as soon as possible.
   
8. Minimize downtime: depending on the application, some system functionality may be critical and need to be available even during a DFU operation.
   
9. User awareness: It is good practice to make the user aware of an available update. This helps to make sure the user performs the update in close-to-optimal circumstances (e.g. connected to power, sufficient battery levels, minimal disruptions to functionality and usability of the end-device, etc.). It could also help to accelerate initiating the update process in cases where the update addresses vulnerabilities or software bugs (user is more incentivized to perform/allow the update if they’re aware of issues that will be fixed by the update).
   
10. Utilize a hardware-accelerated cryptoprocessor to speed up cryptographic operations (e.g. in time-critical applications, memory-constrained applications).
    
11. Integrate a secure cryptoprocessor into your system when feasible (e.g. in safety-critical applications, time-critical applications, memory-constrained applications).

Next Steps: OTA DFU for Nordic nRF52 chipsets

In part 2, we’ll be learning about implementing OTA DFU on the nRF52 platform.

If you’re interested in learning about over-the-air device firmware update in much more detail including implementing it for your nRF52 project in full detail, then check out the Bluetooth Developer Academy where I cover this topic in a full course (more importantly including implementing Buttonless DFU, which integrates DFU into your application instead of as a separate process that needs to be triggered manually on the end-device).

Summary & Closing

In this post, we covered:

• What is Device Firmware Update (DFU)?
• What is Over-the-Air Device Firmware Update (OTA DFU)?
• How does OTA DFU work? 
• The role of the bootloader
• The basic steps of OTA DFU