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. To top it off, there are security concerns, that if IoT devices are not properly patched for vulnerabilities then they will be open to attack from unauthorised and malicious 3rd parties.

A typical OTA firmware update

An Over the air (OTA) firmware update method or FOTA, both application and the secondary boot loader (SBL) handles 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 - and LORA WAN networks are also used in certain enterprise scenarios to deliver the OTA firmware update. A secure communication channel is established between the server and the system so that the embedded device can receive the required update. In “Secure Firmware Update” the gateway or micro controller often through proxy, receives the updated or corrected firmware code. The received firmware and source are 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 boot-loader.

• The update checks for the current running image. The secondary boot-loader and the code share a common register which stores the current running image, image 1 or image 2 and upgrade flag to notify that there has been a firmware upgrade.

• If there is no image running then the gateway device or micro controller will be in idle state. It will wait indefinitely or check whether an upgrade is required.

• If the upgrade flash is not present then the current running image will be executed. The checksum of the received code will then be checked and verified.

• If the calculated checksum matches the received checksum then the received code is valid. Otherwise, the code has errors.

• If the checksum is not matched, the pointer jumps to the current running image entry point and starts execution.

• If the checksum is matched it updates the current running image and the pointer jumps to the updated current running image entry point and starts execution.

• In this way the secondary boot-loader 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 the security of devices in the field is considered. Both gateway devices and highly constrained devices such as micro controllers must also be considered and taken into account. Firmware upgrades must be delivered in a timely and systematic manner, otherwise devices in the fleet will be open to software vulnerabilities which increase 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.

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 Linux SoC, 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 3. 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.

Conclusion

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.

Contact us to learn how Mender can help you perform secure and robust OTA firmware updates.