You’ve probably heard about the numerous OTA-related horror stories in the past couple of years that have seen people locked outside rental properties by bricked smart locks, stuck watching a single channel on their smart TVs, and far more seriously, driving cars that can be remotely controlled by hackers.

In this article, we will answer the following questions:

• What is OTA (Over-The-Air)? Why should I use it?
• What are the challenges of using Over-The-Air updates in devices with restricted resources like Microcontrollers? (security, authenticity, and integrity)

Then we will look at the OTA process of Microchip’s boards.

Finally, we will introduce Zerynth Device Manager, a secure and efficient tool to do OTA updates seamlessly.

An Over-The-Air (OTA) update is a mechanism for remotely updating internet-connected hardware with new settings, software, and/or firmware.

Why should I use OTA?

For many reasons, most importantly:

• The opportunity to rapidly respond to bugs and security vulnerabilities without the need for physical recalls of devices or truck rolls. (you know the bugs I am talking about).
• The ability to add new software features to a product after a device has been deployed in the field to improve functionality over time. (like in smartphones).
• Ensuring embedded developers can quickly prototype and seamlessly roll out new versions of the device firmware, speeding up innovation cycles.

What are the challenges of using OTA in restricted resources like microcontrollers?

Updating the firmware with restricted resources as in microcontrollers can be very challenging.

Because, a poorly executed OTA update can result in “bricked” (nonfunctioning) devices and significant inconvenience to consumers, as well as reputational damage to you, the developer/business owner.

So it is a process that needs to be handled efficiently and securely.

Some challenges of OTA are

Security, when the microcontroller communicates with a cloud service, a lot of security issues arise. For instance, are you using a secure way of communication? For example, Secure HTTP (HTTPS) is currently the most popular protocol used for OTA updates.

TLS is the security component in the familiar https protocol, that we rely on for security on the Internet. A TLS connection between a device and the server ensures that the data exchange between them is secured from the multiple threats possible over an untrusted medium. The TLS connection typically includes mutual authentication of the communicating parties, secure key exchange, symmetric encryption, and message integrity checks. If you’re using gateway devices, the connection between them and microcontrollers must also be secure.

How about the authenticity of the firmware image being transmitted?

Connecting the IoT device to the correct source for the OTA update does not guarantee that the device will receive the correct image, as the image might be corrupted by transmission errors or replaced by a different one in a man-in-the-middle attack.

An IoT device must be able to authenticate that the image is indeed the original sent by the OTA update service. This requires the IoT device OEM to sign the image using their code-signing certificate and attaches metadata, such as a version number and company of origin. Performing a hash of the image and associated metadata with the private key in the OEM’s certificate generates a signature.

The IoT device, which contains the OEM’s public signing certificate, decrypts the hash and compares it to a hash of the image it generated itself. If these match, the device knows that the image is authentic.

How about the integrity of the received firmware? Checking the integrity of the received firmware is different from checking the authenticity of it.
Checking the integrity means checking that you have received the correct firmware, typically you will be receiving the firmware in small parts on-by-one, The integrity check is to make sure that every part of the firmware is received correctly and the whole machine code is received correctly collectively.

Even after the successful storage of the correct OTA update files, transitioning the IoT device to a new image may fail. For example, a power failure during reboot or a flaw in the update image may cause the IoT device to lose network or service connectivity and become unrecoverable

Updates must be fail-safe in order to prevent the node from being unreachable after a software failure. That means you have to make sure that you are updating with a stable version of the firmware and that there is a rollback mechanism in the firmware of the microcontroller should anything go south.

Then there is memory management:

Having enough memory space available is a key requirement for performing OTA updates. However, because memory adds costs, most systems offer limited memory space. If you would like to enable your application to perform OTA updates, you will need to plan on generally providing a memory that offers storage for more than twice the size of the code to be updated. The bootloader or application that will be managing the OTA update will also need adequate memory space.
This restriction makes OTA updates impractical for low-memory microcontrollers.

Example: Microchip OTA using WINC1500 Wifi chip

Now Let’s have a look at a typical OTA update process.

Microchip provides a user guide for updating the firmware over the air using their Wifi chip Winc1500.

If we take a look at the OTA process:

Essentially, it is composed of 4 stages:

1. The bootloader takes over as soon as a reset is triggered.
2. It checks if there is a new firmware downloaded. If so, it reads the image, checks for integrity through CRC16 check, and runs it.
3. If there isn’t, it runs the main application, and if the user presses the OTA button checks for available firmware in the server.
   One interesting point is that the downloaded firmware image doesn’t get written to the MCU flash directly, rather it is downloaded on the WINC1500 chip first, then if it passes the CRC check it will be copied to the MCU flash.

There are more details related to memory management, SSL certificates, integrity check, the microchip implementation, You can check them on their host image Over-the-Air (OTA) guide.

Do we have an easy and secure way to do the OTA updates?

Zerynth Device Manager: an easy, secure way to do OTA.

Zerynth offers an industrial IoT platform to developers and business owners. Zerynth enables the development of secure, efficient, and connected IoT products.

The Zerynth platform includes:

• Zerynth OS, multithreaded Real-Time OS that provides real hardware independence that also runs Python/C Hybrid development.
• Zerynth SDK, Zerynth own IDE for product development and mass programming.
• Zerynth Device Manager, a device and data manager for IoT applications. It helps you register, organize, monitor, and remotely manage and do OTA updates of IoT devices at scale.

One of the goals of Zerynth device Manager is to facilitate the process of OTA updates, Through the following steps, I will show a demonstration of updating an ESP32 board firmware over the Air.

There is a lot of information about Zerynth, its system structure, how it uses Python for IoT development, you can find this information in the docs, but in this article, I’ll be showing an example of doing OTA on Zerynth SDK.

Let’s compile a project and prepare the machine code that will be updated to the device.

As you can see, we are setting the device that the firmware will be assigned to and the firmware version.

After clicking prepare, the machine code will be compiled and sent the ZDM cloud service and linked to the device, waiting for the user to trigger the update.

Then we go to Zerynth Device Manager:

Here you can see the data the device is currently sending, ID, Name, and other features.

We can click on FOTA on the top right corner.

Choose the firmware version you want to update the device with, hit start and that’s it.

Zerynth OS takes care of connecting to the cloud securely, receiving and checking the firmware, and safely updating and starting the new firmware. For developers, I know we don’t like GUIs. There is a CLI tool for this.

If you’re interested in Zerynth device manager, have a look at the getting started guide where this is a guide for the example I am showing here.

I hope that this was a good introduction for the OTA updates, leave your feedback in the comments.