IoT devices without a build-in firmware update capability make hardly sense. However, the implementation of the same on small devices can be quite challenging, and often is done at the expense of security. This article gives an insight into this problematic taking as an example the popular ESP8266 microcontroller with integrated Wi-Fi, and orients you to a solution for it.
Have you ever been trying to use the support Espressif has built into their ESP8266 NONOS SDK to provide your IoT devices with Firmware-Over-the-Air (FOTA) update capabilities?
If yes, then you’ve probably noticed that the ESP8266 NONOS SDK offers two alternative functions for that purpose:
system_upgrade_start(…) andsystem_upgrade_start_ssl(…) (see upgrade.h)The former enables you to start the FOTA update process by issuing an unsecured HTTP GET request to the web server providing the new firmware version. But hold on – is it reasonable to make unsecured FOTA updates on IoT devices?
Certainly not.
A FOTA update of an IoT device boils down to nothing less than replacing the device’s entire functionality. Achieving this operation in an unsecured way means running into a very high risk:
Some attacker could highjack the web server the IoT device tends to download the firmware update from and substitute it with a different machine that is under his control. He can then easily provide a new firmware version created by himself that changes the IoT device’s behavior into literally anything. The device will perform the download of the new firmware version from the attacker’s web server instead of the original one, and use it without being aware of that it’s not a genuine firmware version.
Okay, got it – but what’s about second FOTA update function offered by the ESP8266 NONOS SDK? At first glance, it looks like a sound solution to this problem. It is meant to do the same thing as the first function but using secured instead of unsecured HTTP GET requests, i.e., making the same over a secure SSL/TLS (Secure Sockets Layer/Transport Layer Security) socket connection rather than a bare TCP/IP socket connection.
Among other things, SSL/TLS offers the IoT device to proceed to an authentication of the server using certificates that can be validated against some trusted Certificate Authority (CA). By leveraging this feature, the IoT device can verify whether the web server it connects to for downloading a firmware update is the real one and abort the FOTA update process if it turns out that this is not the case.
So, why not just using the second FOTA update function then?
Well, there is a little problem: it’s only present in the ESP8266 NONOS SDK header files, but never has been implemented in the underlying runtime libraries. What a mess, isn’t it?
Definitely. But there is a reason for it: the ESP8266 is a very resource-constraint device, and the SSL/TLS protocol layer has never been designed for such small devices. The ESP8266’s 82 KB of on-chip RAM memory is just enough to run basic SSL/TLS operations and to send and receive small amounts of data, e.g., configuration data, measurement data, etc. over secure socket connections.
However, any attempts to securely stream larger chunks of data from or to the ESP8266 – like it is typically the case when downloading new firmware versions – either result in cumbersome socket errors or let the device just crash.
And now what?
Depending on the project context and stage, there might be a possibility to opt for another microcontroller that is less resource-constraint to get out of that dead end. But what if you can’t?
At itemis, we have been in exactly this situation, and we have had a very hard time to face the challenge. The good news is, that we have managed to find a solution.
As a result, we are now able to make fully secure FOTA updates on ESP8266-based IoT devices via HTTPS. The same applies to any other small IoT device using a microcontroller with similar resource constraints as the ESP8266 (e.g., STM32, EFM32, PIC32, S5, etc.).
Want to know more about it?
Good!
Contact us, it will be our pleasure to support you!