Thread Secure DFU protocol

Table of Contents

• Characteristics
  • Transfer modes
    • Thread Secure DFU unicast mode
    • Thread Secure DFU multicast mode
  • Transfer components
  • Transfer entities
    • DFU client
    • DFU server
  • Security
• Thread Secure DFU Application Firmware ID
• Memory layout
• Thread Secure DFU Tools and Utilities
• Init packet
• Creating a firmware package
• Validation

A Device Firmware Update (DFU) is the process of updating the firmware on a Thread device.

This page focuses on conceptual information about the Over-the-Air Thread Secure DFU protocol. However, when working with the nRF5 SDK for Thread and Zigbee, you can also choose to use the Bootloader and DFU modules proper of the nRF5 SDK, including Secure DFU Bootloader over Serial Link (UART/USB).

For information about how to configure and test the Thread Secure OTA DFU, see Thread Secure OTA DFU Example.

Characteristics

Although it shares some tooling and code modules with BLE Secure DFU Bootloader, there are several differences both in protocol and operation to make updating of large amounts of devices more efficient.

Category	nRF5 SDK DFU	Thread Secure DFU
Transfer modes	Background and bootloader DFUs.	Only background mode: unicast and multicast DFU variants.
Transfer components	SoftDevice, bootloader, application. SoftDevice and bootloader can be updated independently.	Application only. Thread Secure DFU does not use SoftDevice, but it requires a Master Boot Record. Bootloader does not initialize any transports and cannot be updated.
Transfer entities	DFU server and DFU client.	DFU server and DFU clients.
Concurrent transfers	Not possible: each device updated individually.	Possible: multiple DFU clients supported.
Device network	Devices with single role or firmware.	Devices with single role or firmware.
Transfer rate	Fast transfer rate.	Moderate transfer rate.
Background operation	Background mode transfer in the application not available.	Only background mode transfer in the application available.
Security	No encryption on the DFU level. Optional security key signing.	Transfer of unencrypted, but signed image transferred over the secure Thread link. The init packet contains the signature that is verified.

Transfer modes

Thread Secure DFU supports only the background DFU mode. This means that the device downloads the firmware while performing its normal operations, without switching to a dedicated DFU mode.

Thread Secure DFU offers the following modes of firmware updates:

• unicast, in which each DFU client requests consecutive firmware blocks from the server individually;
• multicast, in which the server sends consecutive firmware blocks with a multicast message, and clients interested in a new firmware receive and process them.

Thread Secure DFU unicast mode

In unicast mode, the Thread DFU server sends a trigger packet with the mode bit set to 0. In this mode, the DFU server does not undertake any action on its own - it is the DFU client's responsibility to send appropriate requests to the server and download the image. All communication in this mode (with exception of the initial trigger packet) is sent through unicast messages. Therefore, each node must download the image individually.

It is suggested to use this mode when there is a single device to be updated. This mode is also used when the DFU process is initialized by the client.

Unicast mode is the default mode when --address option is passed with the client unicast address or when there is no --address parameter given to the nrfutil. In the second variant the trigger packet is sent by the server to the multicast (FF03::1 - all Thread Nodes) address. Then clients can ask for image blocks and receive them on theirs unicast addresses.

Unicast mode is used in the following cases:

• --address is specified with the client unicast address.
• No --address is passed. In this variant, the trigger packet is sent by the server to the multicast address (FF03::1 - all Thread Nodes). Then, clients can ask for image blocks and receive them on their unicast addresses.

Thread Secure DFU multicast mode

In multicast mode, the Thread DFU server sends a trigger packet with the mode bit set to 1.

In this mode, the DFU server sends consecutive blocks of init packet and firmware package through multicast messages. Every DFU client node that receives the multicast DFU trigger packet decides whether to participate in the DFU process and store the firmware blocks. A client that recognizes that it missed one or more of the firmware blocks automatically sends a request to the server for retransmission of these specific blocks. Use this mode when the firmware must be updated on several nodes at once.

You can select this mode by passing a realm-local multicast address as a parameter to nrfutil, for example, --address FF03::1.

Transfer components

The Thread Secure DFU example consists of the following components:

• Bootloader that is used to verify application integrity and to install a new application image.
• DFU client module that is typically incorporated into the user application. It contains the Thread network stack and uses it for downloading a new image while the user application is running.

This mechanism differs from the one in the BLE Secure DFU Bootloader where a new image is downloaded and installed in the bootloader.

Thread Secure DFU does not use a SoftDevice, but the bootloader requires the Master Boot Record (MBR). The example uses a stand-alone MBR provided as a hex file. See Thread Secure OTA DFU Example for details about hwo to configure MBR.

Transfer entities

The are two entities that participate in the Thread Secure DFU process:

• DFU client - an application functionality that runs on a DFU target, which is the device that is being upgraded, and is responsible for downloading and installing the new firmware. The DFU client incorporates a DFU controller (see Device Firmware Update process) which manages the DFU process. This means that each DFU target might be in a different state regarding the DFU process at a given point of time.
• DFU server - a server that provides a firmware package.

DFU client

The DFU process flow in the Thread Secure DFU is slightly different from, for example, the BLE Secure DFU Bootloader DFU process flow.

The DFU client is a module which is typically integrated with the user application. The module uses the IoT SDK CoAP library to implement a DFU algorithm that runs concurrently to the user application. The Thread Secure DFU example shows how the module will be initialized and triggered from a user application.

The basic operation of the DFU client is as follows:

1. Once initialized with the coap_dfu_init() function, the DFU client binds to DFU_UDP_PORT (by default 5683).
2. The DFU client waits for a trigger packet. The trigger packet contains information about firmware size, checksum, and DFU mode.
3. If the installed firmware size or checksum differs from the size or checksum sent in the trigger packet, the DFU client either requests the init packet from the DFU server that sent the trigger packet or waits for multicast init packet transmission from the server (multicast mode).
4. Once the init packet is downloaded, a validation procedure is performed (see Validation).
5. If validation is successful, the firmware image download starts.
6. Once the firmware image is downloaded, the DFU client checks its integrity. If it is successful, the device is restarted (unless the nRF Util reset suppress option -rs was provided) and the new image is copied into the active bank.

The DFU client checks for availability of new firmware packages by sending a trigger packet using the coap_dfu_trigger() function. The trigger packet can be sent to a particular host or to a group of hosts using a multicast address. Sending the packet to a particular host is useful in a scenario where the DFU server is outside of the Thread network. The DFU initialized by the client is always performed in the mode in which the DFU server is started, either unicast or multicast.

DFU server

The DFU server is a device that contains the new firmware package and disseminates it among devices in the Thread network. In the Thread protocol examples, it is an nRF52840 Development Kit in conjunction with nRF Util.

Security

To protect the target device against malicious attackers trying to impersonate the rightful sender of the firmware update, the init packet of the firmware package must be signed.

Thread Secure DFU Application Firmware ID

Thread Secure DFU allows only for modifying the Application Firmware in Thread-only examples. To replace new software, the new software must have a higher Application Firmware ID, that is the application-version value must be higher than the current application version.

Memory layout

When adding a bootloader to your device, you must be aware of where in the device memory the different firmware components are located.

Thread Secure DFU memory layout

The following table shows the memory layout used by the Thread Secure DFU.

Note

The old application and the new one must not exceed the total size of the application area.

Usage	Memory range	Memory size (kB)
Bootloader settings	0x000F F000 - 0x0010 0000	4
MBR parameter storage	0x000F E000 - 0x000F F000	4
Bootloader	0x000F 8000 - 0x000F E000	24
OpenThread settings	0x000F 4000 - 0x000F 8000	16
Application area (incl. free space)	0x0000 1000 - 0x000F 4000	972
Master Boot Record (MBR)	0x0000 0000 - 0x0000 1000	4

Thread Secure DFU memory layout for nRF52840

Thread Secure DFU Tools and Utilities

The Thread Secure DFU uses the following tools and utilities:

• nRF Util – see nRF Util for more information about the tool.
  • Support for multicast DFU over Thread has been added to nRF Util in v3.4.0.
  • Thread Secure DFU example behavior was modified in Thread SDK v0.11.0. The current example is not compatible with older versions of nRF Util. Therefore, you must use nRF Util v3.5.0 or newer (latest recommended) with the current version of this example. Older versions of Thread Secure DFU (Thread SDK 0.10.0 and older) are compatible with nRF Util v3.2.0.

Init packet

Thread Secure DFU uses the same packet format as the BLE Secure DFU Bootloader. Refer to Init packet for details regarding the init packet customization.

Creating a firmware package

Firmware packages for Thread Secure DFU are created using the same method as in the BLE Secure DFU Bootloader. Refer to Creating a firmware package to find out how to create a firmware package.

Validation

Thread Secure DFU uses the same validation algorithm as BLE Secure DFU Bootloader. Refer to Validation for details of the validation algorithm.