How does an OTA firmware update work?

Firmware updates are necessary to ensure the performance of embedded devices and to remove the software bugs that could impair their performance. It is inefficient to have technicians perform updates locally on IoT devices, at scale in IoT projects it becomes too costly or even impossible to manage. Additionally, there are security concerns that unpatched IoT devices and third-party software may be vulnerable to attacks from unauthorized and malicious third parties.

A typical OTA firmware update

In an over-the-air (OTA) firmware update method (also known as FOTA, firmware-over-the-air), both application and the secondary boot loader (SBL) handle the update process without intervention of the technician. In some methods the updated firmware overwrites the previous firmware. If the received firmware is faulty then the system may stop running. The update is typically delivered via cellular connection — typically LTE 4G, 3G or 2.5G — or in certain enterprise scenarios, LORA WAN networks. A secure communication channel is established between the server and the system so that the embedded device can receive the required update. In a secure firmware update, the gateway or micro controller (often through proxy) receives the updated or corrected firmware code; the received firmware and source are then authenticated. If they are successfully authenticated the current firmware is replaced by updated firmware. If either of the source or updated firmware is not authorized, the memory of the current firmware remains locked.

A typical OTA firmware process has the following steps:

• After any software reset, the execution begins at the secondary bootloader.

• The secondary bootloader checks the current running image. A common register shared between the secondary bootloader and the code stores information about the current running image and an upgrade flag, indicating whether a firmware upgrade has occurred.

• If no image is currently running, the gateway device or microcontroller enters an idle state. It will either wait indefinitely or periodically check whether an upgrade is required.

• If the upgrade flag is absent, the secondary bootloader proceeds to execute the current running image.

• The checksum of the received code is calculated and compared against the received checksum:

  • If the checksums match: The received code is deemed valid, the current running image is updated, and the pointer jumps to the updated image's entry point to begin execution.

  • If the checksums do not match: The code is considered erroneous, and the pointer jumps to the entry point of the current running image, initiating its execution.

• In this way the secondary bootloader will be implemented for the over-the-air firmware upgrade.

Security concerns and OTA firmware updates

Having a consistent and scalable process for OTA firmware updates is especially important when considering the security of devices in the field. The process must also take into account gateway devices and highly constrained devices such as microcontrollers. Firmware upgrades must be delivered in a timely and systematic manner otherwise devices in the fleet will be open to software vulnerabilities, increasing the threat vectors for these devices.

Malicious attackers have already penetrated traditional firmware update processes and mechanisms to compromise deployed IoT devices, and launch destructive attacks through these controlled devices. More secure IoT firmware update frameworks can be developed based on the MQTT protocol. This is a firmware update model with IoT devices, gateway devices, firmware distribution broker servers, and firmware deployment servers of IoT vendors.

A secure firmware update mechanism is developed to help IoT devices authenticate the source of received firmware and verify the integrity of the received firmware. Cryptographic methods such as Elliptic Curve key exchange and key-hashed message authentication code can be used to secure the process and corresponding protocols.

OTA Software Updates for IoT: the Essentials

Download the definitive guide

The idea of exploiting firmware vulnerabilities to attack embedded devices has been reported for various types of embedded systems. For example, it has been demonstrated that arbitrary malware can be injected into printers due to a vulnerability of the remote firmware update procedure.

A comprehensive review of firmware images found 38 previously unknown vulnerabilities in over 693 firmware images. Besides Commercial Off-The-Shelf (COTS) devices, Programmable Logic Controllers (PLC) are also vulnerable to modified firmware updates . Other experts have shown how it's possible to load malicious code into field device Ethernet cards due to the lack of authentication in the firmware upload mechanism. Attackers can also leverage a car's external interfaces. A custom firmware was used to compromise the radio and electronic control units.

Using Mender to perform OTA firmware updates

The easiest way to create system level updates is to use the snapshot functionality in Mender, which will create a snapshot of the full system on a currently running device and package it as a Mender Artifact that you can deploy to other devices.

A typical scenario in which Mender is used to perform OTA firmware updates through what is called a proxy deployment. With Linux-based embedded devices, it is common from a design perspective to have an external micro-controller Unit (MCU) that handles the real-time critical tasks. The external MCU is typically mounted on the same PCB as the SBC, or it could be an external component that is connected to the Linux capable device, such as over USB or a serial connection. The external MCU is another software component in the system that should be updated over the lifetime of the product.

To help you understand how this type of OTA firmware update process would work, this is a full tutorial on how to do a proxy deployment. This is a FRDM-K64F device connected to a Raspberry Pi 4. The FRDM-K64F board acts as the external MCU which supports updating firmware using the Device Firmware Update (DFU) USB class. A prerequisite to this tutorial is familiarity with how to update a device firmware using DFU in Zephyr Project on a FRDM-K64F board.

OTA firmware updates are crucial to device fleets

OTA firmware updates are essential for device fleets at scale. They provide operational efficiency, robust operation and protect against potential security threats by ensuring that the firmware is upgraded correctly and in a timely manner. OTA firmware updates can be performed directly or by proxy from a gateway to a bare metal device.

Get in touch

Contact us to learn how Mender can help you deliver secure and robust OTA firmware updates to your whole device fleet — or sign up for a free trial and try out Mender for yourself.