Secure OTA DFU#

Introduction#

This page shows how to securely upgrade Bluetooth application OTA (over-the-air) using signed+encrypted upgrade files. The process is tested with Bluetooth SDK v3.2.2.

Gecko Bootloader#

The Gecko Bootloader is a common bootloader for all Silicon Labs protocol stacks. It can load applications from different sources (internal flash, external flash, UART, SPI, over-the-air) using different protocols (XMODEM, BGAPI, EZSP SPI, Bluetooth, and so on.). It can be configured in a number of ways and its capabilities depend on the current configuration. This document shows how you can use it for loading a new application into the device sent over a Bluetooth connection.

Security Features#

The Gecko Bootloader has three security features:

  • Authenticated (signed) upgrade file

  • Encrypted upgrade file

  • Secure Boot

Upgrade files are in a custom GBL (Gecko Bootloader) format. An authenticated upgrade file means that an electronic signature is attached to the GBL file. The signature is produced with a public-private key pair. The public key is stored in the device, while the private key is kept secret by the manufacturer. The signature ensures that the upgrade file is from a trusted source.

An encrypted upgrade file means that the content of the GBL file is encrypted to protect against eavesdroppers.

Secure Boot means that a signature is attached to the firmware image (.s37) before it is packed into upgrade file formal (.gbl). Note that this differs from an authenticated upgrade file, as authenticated upgrade file means that a signature is attached to the upgrade file after the image was packed into GBL format. A signed image file (secure boot) ensures that the image was not modified since last boot and that it is from a trusted source. This is checked at every boot. Upgrade file authentication is only checked while upgrading.

The following content shows how to use these security features.

OTA DFU#

Over-The-Air Device Firmware Upgrade (OTA DFU) means that the device firmware can be updated via a Bluetooth connection.

To enable Bluetooth OTA update, the target device must be programmed with an appropriate Gecko Bootloader configuration and additionally with any Bluetooth application that supports OTA.

A Bluetooth application developed with Silicon Labs Bluetooth SDK comprises two parts.

Since Bluetooth SDK v2.7 the two parts are as follows:

  • The Apploader (provided as precompiled binary code), referred to as Apploader from now on.

  • The Bluetooth stack (provided as precompiled library) + user application, referred to as Application from now on.

The OTA functionality is built into the Apploader code. If the device is restarted in DFU mode, the Apploader is started instead of the user application. This makes it possible to perform OTA update without any involvement from the user application.

The only requirement for the user application is for a way to trigger a reboot into DFU mode. Reboot into DFU mode can be triggered in a variety of ways. It is up to the application developer to decide which is most applicable. Most of the example applications provided in the Bluetooth SDK already have OTA support built into the code (using the OTA DFU software component). In these examples, the DFU mode is triggered through the Silicon Labs OTA service that is included as part of the application’s GATT database (contributed by the OTA DFU software component). To restart the device in OTA mode, the following API is used: sl_bt_system_reset(2) is used.

The following processes are OTA DFU:

  • Partial OTA: In this case, only the user application is upgraded. This process is done in two steps as follows:

    1. The device is restarted in OTA mode, and the Apploader is started.

      Partial OTA Step 1Partial OTA Step 1

    2. The Apploader overwrites the old Application code with the new one.

      Partial OTA Step 2Partial OTA Step 2

  • Full OTA: In this case, the Apploader code and application are upgraded. Because the running code cannot overwrite itself, this process is done in four steps as follows:

    1. The device is restarted in OTA mode and the Apploader is started.

      Full OTA Step 1Full OTA Step 1

    2. The new Apploader code is uploaded into Slot0. This process is handled by the Apploader. Note that on 256 kB devices, Slot0 is in the user application area, which means that the Application is overwritten.

      Figure 4. Full OTA Step 2Figure 4. Full OTA Step 2

    3. On reset, the bootloader copies the new Apploader code over the old one (extracting the binary from the stored GBL files).

      Figure 5. Full OTA Step 3Figure 5. Full OTA Step 3

    4. The new Apploader overwrites the old Application code with the new one.