Firmware Update Security Best Practices#

Implementing a firmware update in a secure manner is critical to the continued secure operation of a Mesh network. There is hardly a more powerful security threat than an attacker that has the ability to execute program code they control inside of a network.

Fortunately, there are multiple defense mechanisms that can be used to help defend against such attacks. This document describes multiple security best practices that can be used to protect the firmware update process from attackers.

For Mesh Device Firmware Update implementation on Silicon Labs devices, refer to Bluetooth Mesh Device Firmware Update.

For details on Silicon Labs Secure Boot, refer to Gecko Bootloader Security documentation.

The Mesh Device Firmware Update specification can be found at the Bluetooth SIG website.

This guide makes use of terms defined in the above documentation without re-explaining them.

Mesh Device Firmware Update Best Practices#

The following sections describe security best practices and why they should be applied.

Note that the practices are typically applied by the mesh network operator that manages a given mesh deployment, but the device vendor must enable the technical means to do so.

Use Distinct Encryption Keys for Firmware Messaging#

It is a general security best practice to use distinct encryption keys for specific purposes, and it should be followed in firmware update messaging. The network manager can bind the BLOB transfer and DFU models involved in the firmware update to an application key that is not used for other purposes. Ideally, that application key would be bound to an underlying network key that is also not used for other purposes.

The benefit of using a distinct key for a specific purpose is that it limits the attack surface that opens up if an encryption key leaks. For example, even if an attacker got hold of the encryption key used for controlling lighting, they would not be able to initiate a firmware update as long as a different key is used for that functionality.

If possible, use both a distinct application key and a distinct network key; but at least use a distinct application key.

Consider Internet Download Security#

The Initiator may acquire firmware update images from the Internet, if the vendor of the Target nodes makes the images available on a firmware image server. The nodes will provide the Initiator with a URI pointing to the server during the firmware update process.

In that case, the Mesh Device Firmware Update specification requires that HTTP over TLS (i.e., HTTPS) is used, but it is important to note that it is not enough in itself. Using HTTP over TLS ensures that the communication is encrypted, so that passive eavesdroppers cannot see what firmware images are being downloaded, but in addition to that, the Initiator must take care to authenticate the server. Otherwise, there is no guarantee that the source of the firmware images is in any way legitimate even if the images are transmitted over an encrypted link.

It is recommended that the Initiator keeps a list of trusted firmware server hostnames and does not attempt to connect to a server not contained in that list. Refer to Target node vendors' documentation for server hostnames that are valid for a given make and model of a node.

It is strongly recommended that the name lookup to translate the server hostname in the URI into an IP address is protected against manipulation, for example, by using DNSSEC.

It is strongly recommended that the Initiator uses the latest version of TLS to connect to the server. Using TLS versions with known vulnerabilities is strongly advised against.

It is strongly recommended that the Initiator keeps a list of trusted root certificates, and verifies the server certificate only against root certificates in that list.

It is strongly recommended that the server hostname is checked against the server certificate.

It is strongly recommended that on encountering any problem with a server, such as certificate expiration, the Initiator aborts the attempt to acquire a firmware update from that server and logs the problem to the user, instead of continuing with the download.

Digitally Sign the Firmware Update Images#

Silicon Labs bootloader supports digitally signed firmware updates. This allows a Target node to authenticate the update against a known trusted encryption key to verify that the upgrade comes from a trusted source, but also to verify that the upgrade has not been tampered with.

It is strongly recommended that only digitally signed update images are applied at the Target node, and any non-signed images are rejected.

Enable Version Rollback Prevention for Secure Boot#

Silicon Labs bootloader supports anti-rollback, which means that a newer firmware image cannot be replaced with an older one. This feature can help protect from attacks that attempt to replace the currently running firmware with an older firmware that is from a legitimate source as such but contains exploitable vulnerabilities. Without anti-rollback, an attacker might succeed in exploiting a vulnerability in an old firmware image that has already been fixed in newer versions.

It is strongly recommended that anti-rollback protection is taken into use at the Target node.