Bluetooth Mesh proprietary DFU

Bluetooth Mesh proprietary DFU

    • Introduction to Mesh proprietary DFU protocol
      • feature
      • DFU modes and types
      • Role
      • concurrent transfer
      • A network of mixed devices
      • Transmission rate
      • background operations
      • transfer partition
      • memory map
      • Safety
      • DFU firmware ID
        • Application firmware ID
        • SoftDevice firmware ID
        • Bootloader firmware ID
      • Device page
        • Format
        • content

Introduction to Mesh proprietary DFU protocol

Device Firmware Update (DFU) is the process of updating the firmware of Bluetooth mesh devices.

Nordic’s mesh DFU protocol adopts the proprietary nRF OpenMesh project and runs on the proprietary OpenMesh protocol. The OpenMesh protocol is a broadcast-based protocol similar to Bluetooth mesh, but it does not support addressing, acknowledgment messaging, or encryption.

Features

The proprietary mesh DFU protocol is optimized to update all devices in the network as efficiently as possible. Although it shares some tools and code modules with the nRF5 SDK Bootloader and DFU modules, there are some differences in protocols and operations to make updating a large number of devices as easy as possible.

DFU modes and types

Mesh network supports two types of DFU. One is background mode. The new firmware is transmitted through the background while the application is running. At the same time, the application will be notified when the transmission is completed. The application can rewrite the flash after the new firmware is ready. The other is the Bootloader mode, which is used to use BootLoader for transmission when the application cannot run. This mode is mainly used as a fallback mechanism when the application fails.

In each DFU mode, DFU transmission can be performed on BootLoader, Application and SoftDevice respectively. All three types of firmware must be transferred separately, and each has its own identifier, each with its own area in the memory map. The nRF5 SDK for Mesh SoftDevice and Bootloader can be updated independently. This can save time and memory if you want to make small changes in the bootloader program.

Role

The source role is used when the device acts as the initiator of DFU transmissions. The source device controls the time interval for sending messages. It also responds to DFU data request packets. The source role is controlled by the nRF Util tool.
The purpose role is used when upgrading equipment. The proprietary Mesh DFU module receives new firmware and notifies the application when the transfer is complete. In this role, the proprietary Mesh DFU module also retransmits DFU packets it receives.
The relay role is used to retransmit DFU packets received from other devices. In this role, the device does not save received packets to flash.

Concurrent transmission

In contrast to the nRF5 SDK DFU, the entire Bluetooth mesh network can be updated simultaneously via concurrent transfers.
Bluetooth Mesh networks can contain hundreds of devices, and updating all of them one by one takes a lot of time. To solve this problem, the proprietary mesh DFU protocol allows mesh network devices to forward the data they receive to their neighbors. Both the passive mesh device and the device receiving the transmission will forward all packets, ensuring DFU transmission to all devices in the network. This approach is much faster than passing the entire DFU transfer to each device individually.

A device that receives a DFU transmission will perform the following steps for each data message it receives:
1. The verification packet has not been received.
2. Store the payload of the packet in flash at the appropriate offset of the transmitted data.
3. Mark the received data packet.
4. Retransmit the packet a predetermined number of times at exponential intervals.
Devices not directly interested in the content of the transmission will only perform steps 1, 3, and 4 to ensure that destination devices further along the network still receive the packet.

Network of mixed devices

Typically, a Bluetooth mesh network contains devices with multiple different roles and firmware. When performing DFU transfers, it is important to be able to differentiate between these devices. If the light switch device’s firmware is updated onto the light bulb, it is possible that the light bulb may stop working. This is different for one-to-one DFU transfers, as the nRF5 SDK DFU protocol does, where the sender is able to identify the target device and send it the correct firmware.

The proprietary mesh DFU protocol handles mixed device networks by allowing each device type to have its own application ID in addition to an application version number. When a device receives notification of an upcoming DFU transfer, it can compare the transferred Application ID to its own firmware’s Application ID. If the app id matches, and the incoming transport version is higher, the device usually accepts the transport. If a device receives notification of an upcoming DFU transmission with a different application ID than its own, it can choose to act as a relay device for that transmission, or ignore it.

Transmission rate

The proprietary mesh DFU transfer speed is quite slow compared to the nRF5 SDK DFU protocol. For example, transferring a 100 kB firmware image takes about an hour. The proprietary mesh DFU protocol relies on redundancy to ensure reliable communication, so it takes longer to propagate the same amount of data compared to nRF5 SDK DFU. DFU data is sent periodically in 16-byte chunks, with some redundant transmission of each packet to ensure that all devices receive it. The message interval is controlled by the transmission source device. By default, the Bluetooth mesh DFU tool emits a new packet every 500 ms (making the transfer rate 16 B/500 ms = 32 B/s), but this number should be adjusted based on the Bluetooth mesh network properties.
Some network characteristics to consider are:
Network Density: The number of devices within radio range of each other has a large impact on the packet reception rate. A higher number of devices within radio distance of each other will cause more packet collisions, thus reducing overall throughput.
Network span: Each hop in the network has a certain risk of packet loss and causes traffic delays. The higher the hop count in the network, the higher the risk that some device will miss a transmission.
Network topology: While high node density may negatively impact transmission success rates, too few paths to the destination node may result in packet loss. The more dependent a destination node is on multiple relay devices for successful transmission, the higher the likelihood that the destination node will be lost at some point during the transmission.
External noise: Proprietary mesh DFU performs worse when deployed in noisy environments (like all wireless technologies).

Because these characteristics are different for all deployments, it is impossible to formulate a general rule that applies to all networks. To maximize DFU performance:
① Tuning a single deployment;
② If possible, schedule DFU transfers during expected low traffic periods with minimal noise.

Background operations

Due to the relatively slow transfer rate of the proprietary mesh DFU protocol, transfers can end up taking over an hour, which is unacceptable downtime for many applications. To solve this problem, the proprietary Grid DFU implements a background mode.

Background mode allows applications to continue running normally during DFU transfers. Background mode is the default mode of operation unless there are no active applications on the device, in which case it falls back to the BootLoader.

Transfer partition

Devices receiving background DFU transfers must store incoming packets in an unused partition in the flash area to avoid overwriting themselves at runtime. During this process, the DFU transfer data is stored in the partition, and once completed, the application can tell the bootloader to copy the partition contents to the application area, effectively completing the update. Although the bootloader notifies the application as soon as possible that the transfer is complete, the application is free to copy the partition at any time, or not at all. There can be only one partition of each transfer type at a time, and partitions cannot overlap. Existing sectors of the same transfer type will be deleted after completing the partition DFU transfer.

The partition must be placed in a flash area that is large enough to accommodate the entire incoming application during transfer and must not overlap with new or old applications. To ensure maximum space to receive transfers, either as a partition or as a complete application, it is generally recommended to place the start of the partition right in the middle of the application section of the device. If the transfer is not available to the partition or application after the transfer is complete, the device must fall back to the bootloader and perform the transfer in bootloader mode.

Memory mapping

The proprietary mesh DFU protocol uses the same flash memory map as the nRF5 SDK’s Bootloader and DFU modules, with only minor differences. Instead of placing MBR parameter storage between the bootloader and the bootloader settings (called device pages in proprietary mesh DFU), MBR parameter storage in the proprietary mesh DFU protocol is placed between the bootloader and the application area.

Memory map:

The memory map contains the following main firmware elements:
SoftDevice
Application
Bootloader

These correspond to the previously mentioned transfer types. Each firmware element can be updated individually via DFU transfer. The application uses the bootloader to perform the receive and relay algorithm steps, even when working in background mode. When initializing the Bluetooth mesh framework, the DFU module initializes the command handler module in the bootloader, which runs along with the application.

In order to be able to run with the application, the BootLoader program reserves the last 768 bytes of RAM on the device. This reserved RAM is taken into account in all Bluetooth mesh project files and linker scripts. Failure to preserve these bytes will result in unexpected behavior of the BootLoader program when the application starts.

Security

Similar to the nRF5 SDK, the proprietary mesh DFU does not encrypt the data transmitted by the DFU.

In the case of Bluetooth mesh, this is a limitation inherited from the OpenMesh protocol, which means that under no circumstances should security-sensitive data (such as keys) be sent as part of the DFU transmission. However, the proprietary mesh DFU does have Elliptic Curve Digital Signatures (ECDSA) for authenticating transmissions. Although signing is optional, signing all transmissions is highly recommended. When creating a DFU transmission, signing is performed using a private signing key, and all Bluetooth mesh devices can be preprogrammed with a matching public signing key to authenticate the firmware. If a Bluetooth mesh device has a public signing key, it will always require the signature to pass before completing the transmission. The signing algorithm is performed by creating a SHA256 hash of the transfer metadata and firmware.

Hash decomposition:

The size of the firmware ID (F) depends on the type of transfer.

ECDSA uses the NIST P-256 curve (secp256r1) to create the signature:

signature = ecc_sign(curve=P-256, private_key, hash)

Verify the signature using the matching public key on the target device:

authenticated = ecc_verify(curve=P-256, public_key, hash, signature)

Since the hash requires the entire firmware data, the signature is not checked until the entire transfer is complete. This design creates the possibility for denial-of-service attacks on the target device, as an attacker could initiate erroneous transmissions. Such erroneous transmissions may be indistinguishable from normal transmissions until the final signature check, at which point the target device may have spent significant resources receiving the transmission. However, this attack vector does not allow the attacker to execute any code on the target device because when the signature check fails, the target device will delete all information about the transmission.

DFU Firmware ID

All proprietary mesh DFU transfers are identified by firmware ID. The structure of the firmware ID depends on the transfer type:
Application firmware ID
SoftDevice firmware ID
Bootloader firmware ID
In order to decide whether to accept incoming transmissions, all Bluetooth mesh devices carry their current firmware ID in their device page.

Application firmware ID

The application firmware ID identifies the application.

Every application has an ID and version number. Typically, a device should accept DFU application transfers with the same application ID as its own firmware, and with a higher version number. The version number is a 32-digit number, and the version plan is customized by the user.

When in bootloader mode, the prebuilt bootloader enforces a strictly increasing version number. This prevents malicious devices from downgrading the firmware to a previous version, an attack that could be used to reintroduce old weaknesses in the firmware. This rule is not enforced when in background mode, but is strongly recommended as there is no other native way to prevent malicious downgrades.

To create a unique firmware ID for each application, the application ID contains a 32-bit Company ID field that identifies the device vendor. The company ID field can contain:
①Company ID assigned by Bluetooth SIG (0xFFFF or lower), or
② Randomly selected identifier greater than 0xFFFF.
A randomly selected identifier is not guaranteed to be unique, but it allows suppliers who are not assigned a company ID to maintain a high probability of uniqueness.

SoftDevice firmware ID

Nordic assigns each SoftDevice version a unique 16-bit SoftDevice identifier, which can be read from the firmware.

The SoftDevice Firmware ID on the device is meant to match this number (although this is not explicitly required for correct operation). Since the SoftDevice id represents a release id rather than an ever-increasing version number, the policy for accepting incoming SoftDevice DFU transfers is user-definable.

When in bootloader mode, if it receives a FWID beacon with an application ID that represents a later version of the current application, but with a different SoftDevice firmware ID, the bootloader starts requesting SoftDevice updates. In background mode, the upgrade strategy is customized by the user.

Due to bootloader implementation limitations, SoftDevice DFU transfers are only accepted if the new SoftDevice can fit into the defined SoftDevice area.

Bootloader firmware ID

The bootloader firmware ID consists of an 8-bit bootloader ID field and an 8-bit bootloader version field. Just like applications, bootloaders can have different configurations, and each configuration can have different versions.

In bootloader mode, the bootloader accepts incoming bootloader DFU transfers when the bootloader ID field is the same as its current bootloader ID and the bootloader version field is greater than the current bootloader version.

In background mode, the upgrade strategy is customized by the user.

Device page

All devices running the proprietary mesh DFU bootloader program need to save the device page in flash. The device page defines the device configuration and serves as the operating parameters for the bootloader program.

The device page must be generated on the host and flashed on each device before deployment. The device_page_generator.py script that generates device pages can be found in tools/dfu/.

Format

The device page is the single-page flash management area of the last flash page of the device.

Content

The device page contains all the information the bootloader needs to participate in the DFU transfer:
① Flash area: Each transfer type (SoftDevice, bootloader and application) has a designated area in flash. These areas are defined in the device page and must be able to contain the largest possible firmware block of their type.

② Firmware ID: Each transmission type (SoftDevice, bootloader and application) has a designated firmware ID. These firmware IDs are used to decide whether to accept incoming DFU transfers and are updated after each DFU transfer is completed.

③ Public signature key: used to verify DFU transmission signature.

④ Status flag: A flag indicating the validity of each firmware block (SoftDevice, bootloader and application).

⑤ Partition transfer: Each partition transfer on the device has a specialized structure to describe it. This entry type is generated by the bootloader after each successful partition transfer. There can only be one partition per transfer type.

⑥ Firmware signature: The signature of each firmware (if it exists).

The following table lists possible entries, both required and optional.

Signature public key: The public key used for signature verification.

Firmware ID: Current firmware ID. The firmware ID entry is a concatenation of three different proprietary mesh firmware IDs.

Flags: The current status of each firmware.

SoftDevice area: The Flash area that SoftDevice firmware can write to.

Bootloader area: The Flash area where Bootloader firmware can be written.

Application area: Flash area that Application firmware can write to.

SoftDevice signature: The signature of the current SoftDevice.

Bootloader signature: The signature of the current bootloader.

Application signature: The signature of the current Application.

SoftDevice partition: SoftDevice transmits partition information. Padding is a fixed data field whose value is always 0.

Bootloader partition: Bootloader transmits partition information. Padding is a fixed data field whose value is always 0.

Application partition: Application transfer partition information.