How to update IoT devices: Process and Methods

How to Update Internet-of-Things (IoT) Devices: Programmer’s Guide

The Internet of things is growing exponentially every year. Internet-connected devices are changing the way we work, communicate, sleep, eat and take care of our health. There are about 11 billion devices connected to the Internet in the world. By 2030, their number is expected to exceed 29 billion.

Taking advantage of the Internet of things, consumers rarely think the devices are subject to security problems that can lead to negative consequences. There is always a risk of losing confidentiality, data integrity, or device access. To fix weaknesses and eliminate vulnerabilities, manufacturers are constantly releasing new updates.

However, many users tend to ignore them, often without even knowing they compromise their devices and the entire network to which they are connected. According to the Ubuntu survey, 40% of consumers have never consciously performed updates on their devices or doesn’t even know how to update IoT device. And it is even worse than one could ever imagine.

In some cases, it is not about the user who ignores updates: there are producers who do not provide performing updates at all. It means that in case of any vulnerability it will exist in the device until the end of its service life, and all this time the user’s gadget will be exposed to unjustified risks. Not surprisingly, some users are still skeptical about using IoT devices.

It is fair for consumers not to see updating devices as their problem to solve, especially when it comes to “headless” gadgets, unlike smartphones with a human who manages them. It is up to the producers themselves to ensure updates are delivered to the device automatically, driven by some event that the device can observe.

Here is your conductor in IoT update management. We are going to expose how to update software on IoT devices and what pitfalls this process contains. You will learn how it is possible to reduce the impact of some security risks, and what approaches to updating devices exist in the smart things industry.

Main types of IoT firmware updates: which one to choose

From the perspective of an edge device/end user, the process of IoT device updates is represented by two main approaches: manual and remote updates over-the-air (OTA). Let’s look at their features.

Automatic (remote) OTA updates

An over-the-air (OTA) update is a way to deliver remotely new settings, software, and/or firmware to the hardware which is connected to the Internet.

IoT device manufacturers send updates to the user’s device and deploy them automatically. The process is based on preset configuration parameters like automatic update enable flags and update schedules. It works like this: the device administrator decides that the IoT gadget should receive updates only during certain hours when the device is not in use and marks this in the settings. This could be helpful both for critical and less critical IoT software updates.

OTA updates are a more efficient way for manufacturers to fix bugs and update software than manual upgrades of each individual device. OTA updates are able to detect issues before devices launch. This saves manufacture’s time and money, as well as reduces the software development process. OTA updates also enable producers to more easily update the software on devices that are difficult to access.

An OTA update is also comfortable for end users. They do not need to go to a physical store or connect to a PC to update their devices. Instead, the end user only needs to press a button on their smart device to download an update.

The Manual OTA updates

The most convenient way of how IoT devices can be updated that the user is used to. For a small embedded IoT system, manual updating can be performed by connecting the device to a computer or using particularized programmers such as JTAG. It is possible to scale the process by accessing an embedded computer such as a Raspberry Pi or an Nvidia Jetson single board computer over a local network, installing SSH, or connecting to a remote desktop.

Using manual OTA updates makes sense if the user has little interest in this process, for example, to update operating system features or user interface. This device must be closely associated with the user, such as a smartphone.

In this case, the end user should check for updates and, if found, agree to install them. The firmware of an IoT device may, from time to time, wait for the user to receive an available update.

From an administrator’s point of view, manual OTA updates are also referred to as semi-automatic OTA updates because the process of creating and downloading software is still automatic. However, updates are installed manually when interacting with the user.

Wired updates are the last century. Over-the-air automatic updates are mandatory in the modern world, as they drastically reduce efforts to support the system. Imagine updating the software of a hundred devices by wire. And a thousand?

Nevertheless, there could be situations when it is advisable to resort to manual updates. We recommend considering this option if any of the following describes your product:

– It is critical for the user to have whole control over the update process as a sudden hardware failure can lead to catastrophic consequences (e.g. medical devices);

– You have confident answers to questions about who and how should control the release of updates available for all devices, who should decide whether to accept them and how devices are to be updated.

– The fleet of devices counts tens, not hundreds of them; otherwise, the process could be quite challenging;

– You do not plan to integrate your product with the rest of your software system, otherwise manual updates become inappropriate;

– You provided for a return to the initial version of the firmware in case of an error in the code because if not, you immediately need to make a new update, which is inconvenient in the case of manual setup.

Methods to update IoT devices and examples from industries

IoT devices can receive OTA automatic updates in many ways, we describe three of them.

1. Edge-to-Cloud OTA updates (E2C)

E2C updates use the internet connectivity of the IoT device to communicate with a remote server and receive the updates directly from it. The device can process updates to both its firmware and the software. Most of the consumer-ended smart devices belong to this group, as they are usually in the WiFi area in people’s homes or in little commercial locations. Among examples, one can mention Amazon Echo Dot update, Google Home update, Nest thermostat update, which use the G2C update method.

Edge-to-Cloud updates allow updating devices separately from each other so that an update error will not affect the entire fleet of devices. On the other hand, in the case of many devices in the fleet, such updates will take too long. You also should be mindful of the device’s working state and not try to force updates if the device is busy performing a critical task.

2. Gateway-to-Cloud updates (G2C)

If you select this method, the update will be sent to an Internet-connected gateway which is responsible for managing a fleet of IoT devices. So there is a mediator in this scenario, a middle-man gateway that receives, processes, and distributes the IoT firmware update to the connected IoT nodes. Involving a gateway makes this way more complex but more secure, as devices can be protected from outside signals and intrusion by the gateways. Besides, the IoT devices themselves remain unchanged. Gateway-to-Cloud updates are popular for simpler IoT devices that do not have a lot of computing capacity, nor do they have a direct Internet connection.

Due to better security, this update technique is preferred by finance and healthcare businesses, for instance, such IoT products as ATMs, other banking and financial services such as kiosks, etc.

The main weak point of this method is the reliability issue. The gateway becomes a single point of failure for the entire system, which can render it unusable if something goes wrong during the upgrade process. There is even a risk of a complete system collapse if the gateway fails to recover after an update failure. Later in this article, we will go into more detail about the ways to counter this problem.

Along with this, you should mind choosing the right time when the gateway is available for updating because it is constantly involved in managing nodes and processing data. During the upgrade process, the functionality of the IoT system may be violated.

3. Edge-to-Gateway-to-Cloud OTA updates (E2G2C)

Similar to the previous method, this one also uses the Internet-connected gateway that controls IoT devices and updates the firmware and software applications on it. But, unlike the G2C scenario, the gateway is not updated at this time. In other words, the gateway acts as a dispatcher, downloading updates from the cloud server and then forwarding them to the other edge/gateway.

For this method, IoT devices must have enough computing power to accept a connection from the gateway and perform the update on themselves but do not necessarily need Internet connectivity. This method is useful for IoT devices like field-based sensors, for example, temperature, humidity sensors, weather sensors, and other industrial management sensor systems.

E2G2C is one of the best possible solutions for safe, modular OTA updates today. It reduces risks for all devices connected to the system, as each node connected to the gateway handles updates on its own. At the same time, the gateway can directly perform updates at the edge, and if any of the updates go wrong, the fleet will be protected. Even with damaged one or more nodes, the system will be able to work.

However, like the previous method described, Edge-to-Gateway-to-Cloud OTA updates come with a single point of failure, which is important in case of errors in updates.

To get away from the problem of a single point of failure, another blockchain-based strategy can be applied. Its main advantage over the client-server model is that it makes it possible to keep track of all firmware update events stored in an immutable registry. Manufacturers get the opportunity to use smart contracts for the flexible application of firmware update conditions. The smart contract is decentralized, securely stored on every node of the network, and protected from unauthorized access.

The distributed nature of blockchain frameworks makes the blockchain ledger and smart contracts resilient to network failures and cyberattacks.

Data and device security issues during updates: what to consider

While remote receiving firmware update for IoT devices gives many advantages, it also creates security concerns. IoT vendors should consider security as a top-notch feature of the OTA update mechanism, not something as an afterthought.

Next, we’ll look at the security risks associated with OTA updates and offer options to prevent them.

Let’s leave out the reminder that the built-in ability to update devices is extremely important for the deployment of IoT. There are several types of malicious activity that can expose the privacy of a device. Some known vulnerabilities that exist in IoT cause these actions. This includes insufficient authentication/authorization, lack of transport encryption, privacy concerns, insufficient security configuration, poor physical security, and insecure software firmware updates for IoT devices. As an attacker takes advantage of these vulnerabilities, one of the recovery mechanisms would be to initiate a secure firmware update procedure. This is why it is significant for IoT devices to stay updated and well patched to mitigate subsequent security vulnerabilities which may lead to various attacks.

Over-the-air updates occur using wireless communication technologies such as Bluetooth, Wi-Fi, WiMax, ZigBee. However, these protocols are not always suitable for IoT devices, as they consume a lot of energy, cannot transmit data over long distances, and reduce network operation time. As an alternative, other protocols have been developed, in particular, Low-Power Wide Area Networks communication protocols (LPWANs) including technologies such as LoRa, NB-IoT, Sigfox, IQRF.

At the same time, each of these technologies has its own security challenges. For instance, LPWANs offer long-range connectivity, therefore it is more exposed to various attacks. One of the most common types of such attacks is reverse engineering, which is possible in the case of an insecure firmware update mechanism. There are many cases when in this way attackers gained access to user data and even to unauthorized device control. One of the most famous such attacks, known as the Jeep hack of Miller & Valasek, took place in 2015. The hackers gained remote access to the car’s internal computer network, known as a CAN bus, causing life-threatening manipulations. The attack became possible due to insufficiently secure transmission of updates.

On the other hand, when it comes to more encrypted connection types, firmware updates are a problem in IoT due to the limitation of device resources such as storage and processing power. Their resources are sufficient to transmit data via the HTTP protocol, which, however, does not provide device security. The solution may be to integrate supported protocols with others to ensure security.

It’s worth remembering that there are three things that need to be protected during updates: firmware repository, communication channel, and IoT device itself. Attacks can happen at different levels as the firmware is transmitted to the IoT devices and after the firmware has been securely delivered to the IoT. So one of the following scenarios is possible:

1) Firmware manufacturer produces the new version of it and distributes it over the untrusted network. 2) An attacker may eavesdrop on the communication channel in the untrusted network. An attacker can take hold of the firmware image and extract sensitive data from it, modify the file and return it for distribution. 3) Customers get the firmware, then distribute it to the IoT devices.

Let’s look separately at each channel.

Firmware Repository

Attackers can take possession of the firmware in different ways, such as getting it from the vendor’s website or community forums, sniffing the OTA update mechanism, and dumping it from the device. This gives them access to sensitive information, like API, encryption keys, Access tokens, encryption algorithms, and others. That is why the firmware must be encrypted and signed before it gets stored in the repository. Usually, AES or XOR encryption is used to ensure the confidentiality and integrity of the firmware at rest. The firmware manufacturer should sign the firmware image using the private key, which is held secret, and attach the signature to the firmware. Before accepting the update for installation, the device will validate it.

Communication Path

To ensure the secure delivery of the signed and encrypted firmware, it is better to use the SSL for transport encryption. This protocol applies digital signatures for data integrity, confidentiality, and authentication. This will protect you from man-in-the-middle attacks such as spoofing or reverse engineering.

IoT device

The last step in the updating process is flashing the firmware. Before this happens, the device remains vulnerable to such attacks as time-of-check-to-time-of-use attacks (TOCTOU). So it is necessary to ensure consistent integrity of the firmware, as well as the physical security of IoT devices. We recommend blocking unnecessary ports such as JTAG and UART to avoid any interruption in the update process by intruders.

To sum up, we share these considerations that you should definitely take into account when developing solutions for OTA updates. You may also use it as a checklist:

• Check if you have provided an automatic recovery (return to the initial state) in case of damaged or interrupted updates. It is desirable that this happens without manual intervention. WebbyLab recommendation: use a separate memory area for storing newly downloaded firmware. Thus, slot #1 will be used for the current firmware, and slot #2 for the new one. When the firmware is rolled, it is loaded into the 2nd slot, you check the performance and if everything works, then the 1st slot is cleared. At the next update, the firmware is loaded into the 1st slot, and the verification operation is repeated.
• Integrity and code origin should always be checked when updates are downloaded. A cryptographic signature is used to confirm that connected devices only accept code from verified authors and that the code has not been modified in transit.
• Validate your updates before releasing them for compatibility to ensure fail-proof updates. Look for service providers that provide tools for testing updates, for example, 2Smart Cloud.
• Use only secure communication channels, both between the cloud and the Internet-connected gateway, and local connection between the gateway and its edge devices.
• Consider your networking capabilities when rolling out updates at scale.

In this guide, we answered the most common questions about the update process of IoT software. Webbylab has extensive expertise in products for the Internet of things, both in creating devices and hardware modules and developing software or firmware for them. At your disposal, years of experience with Webbylab’s developers, as well as our team’s competencies in working-out solutions for IoT architecture. Consulting on the topic of IoT update management is just one of the possible examples. We will be happy to share our practical experience related to IoT device updates or corresponding topics with you.