Best Practices


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).

In the next module, we’ll take a look at implementing OTA DFU for the Nordic nRF52 chipsets.