Wireless sensor and actor networks are a crucial elements of today's effort to support and implement \textit{Industry 4.0} architectures and modern manufacturing processes. Small programmable logic controllers (PLC) and cloud computing are enabler but also drivers of these new manufacturing paradigms\cite{Nigappa:2016eb}. Thus, the networked interconnection of everyday objects, the automation of home appliances and environmental metering and monitoring based on sensor and actor networks controlled by ESP-based chipsets are subject of current research. In \cite{DiNisio:2015fg} a low-cost multipurpose wireless sensor network using \textit{ESP8266} PLCs is introduced. The usage of \textit{ESP8266} PLCs in combination with Raspberry PI acting as base station for the sensors is discussed in \cite{Thaker:2016fi}. The article \cite{Kodali:2016hc} presents a home automation solution based on a \textit{MQTT} message queue with \textit{ESP8266}-based sensors and actors. The control of smart bulbs with PLCs is summarized in \cite{Walia:2016bj}. Unfortunately, software update mechanisms are not addressed in these publications. Generic approaches of decentralized software updates in IoT environments are introduced in \cite{Weisbach:2016bs} and \cite{Ruckebusch:2016vo}. The \textit{Over the Air} programming capabilities of the \textit{ESP8266} PLCs are described in \cite{Gore:2016ue}.
\color{blue}lalala irgendwelche zwei zewilen, die wir hier auf der ersten seite noch unterkriegen, damit kapitel 3 auf der naechsten seite anfaengt. layout und so ...\color{black}
The research presented in this paper was mainly driven by \textit{Magrathea Laboratories e.V.}\cite{maglab}, the local hackerspace in Fulda, in cooperation with researchers at the department for computer science at Fulda University.
Requirements were clearly defined by Magrathea Laboratories demands to provide local and remote control over various sensors and actors in the foundations rooms to visitors and members.
Such components include door sensors, power sockets, temperature sensors, projectors and screens who are all managed by a home-automation controller, which is driven by the software \textit{home-assistant}\cite{HASS}.
The research presented in this paper was mainly driven by \textit{Magrathea Laboratories e.V.}\cite{maglab}, the local hackerspace in Fulda, in cooperation with researchers at the department for computer science at Fulda University.
Requirements were clearly defined by Magrathea Laboratories' demands to provide local and remote control over various sensors and actors in the foundations rooms to visitors and members.
Such components include door sensors, power sockets, temperature sensors, projectors and screens who are all managed by a home-automation controller, which is driven by the software \textit{home-assistant}\cite{HASS}.
It provides direct control over all existing components using a web UI and allows to define rules and automations on how these components interact.
For the component's hardware, boards based on the \textit{ESP8266} micro-controller are used.
@ -9,8 +10,10 @@ These boards feature a small and robust design, achieve very low power consumpti
It integrates a Tensilica L106 32-bit micro controller unit (MCU) with a maximum CPU performance of 160 MHz, 64 kB instruction memory and another 96 kB of main memory.
According to the manufacturer, the ESP8266 is among the most integrated WiFi-capable chips in the industry.
While at the beginning of this research, mostly \textit{ESP-01s}\cite{ESP-01s} boards in combination with self-developed power supplies and use-case specific hardware components were deployed, we quickly integrated wireless smart switches offered by Sonoff.
For these boards, a common software platform referred to as \textit{ESPer}\cite{ESPer} has been developed.
The software is based on the \textit{Sming}\cite{Sming} library, which in turn is based on the open-source SDK for \textit{ESP8266} and integrates a lot of other software components for easy use.
The firmware for all of the \textit{ESP8266}-based devices in the hackerspace is based on our common software platform, referred to as \textit{ESPer}.
\textit{Sming}, which in turn is based on the open-source SDK for \textit{ESP8266}, provides the base library for this framework.
It integrates a lot of other software components and provides all kinds of functionality shared by all devices, allowing to reuse parts of the source code in multiple devices.
For communication with the controller, the \textit{MQTT}\cite{MQTT} protocol is used.
It provides a lightweight messaging mechanism implementing the publish-subscribe pattern that allows devices to listen for commands and publish their current state to the controller and other interested parties.
The firmware for all \textit{ESP8266} based devices in the hackerspace are all based on the same framework.
\textit{Sming} provides the base library for this \textit{ESPer} framework, which provides components and functionality shared by all devices.
This allows to reuse code providing functionality which is common in multiple devices.
To implement \textit{OTA} updates under the given requirements, we define a topology, which integrates our build infrastructure, firmware repository, and controller with the IoT WiFi network, which the devices are connected to.
To implement \textit{OTA} updates under the given requirements, we first define a topology that integrates our build infrastructure, firmware repository, and controller with the IoT WiFi network, which the devices are connected to.
For our reference implementation, we particularly chose lightweight and common software projects to allow for easy exchangeability of the individual components.
The base topology used is shown in Figure \ref{fig:topology}.
The base topology, as well as the specific components used is shown in Figure \ref{fig:topology}.
@ -34,20 +30,22 @@ Regular updating of the framework version and rebuilding the firmware would ofte
Further, problems could arise if the application programming interface (API) of the framework changes.
In this situation, the device firmware must be updated to use the changed API, which can be an unpleasant and complex task and leads to higher latency for firmware updates.
To prevent these problems, the device firmware of all devices in the hackerspace is integrated with the framework into a larger project.
By doing so, each device specific code is always linked to the latest version of the framework.
By doing so, any device specific code is always linked to the latest version of the framework.
The according device type is provided as a string through a global constant at compile time and it must never be changed during operation.
Device specific code is organized in a sub-folder for each device type.
To build the software, a \textit{Makefile}\cite{make} is used, which provides a simple way for reproducible builds.
When a new build process is started, the build system scans for all device specific folders and calls the original build process for each of them.
After the build of the firmware has finished, the build system also creates a fail for each device containing the build version and the firmware signatures.
Whenever a new build process is started, the build system scans for all device specific folders and calls the original build process for each of them.
After the build of the firmware has finished, the build system also creates a file for each device type, containing the build version and cryptographic signatures of the corresponding binary images.
To avoid interferences between different build environments on developers computers and roll out new versions as early as possible, the code has been integrated into a continuous integration (CI) system.
To avoid interferences between different build environments on developers computers and roll out new versions as quickly as possible, the code has been integrated into a continuous integration (CI) system.
The CI, which is based on \textit{drone}\cite{drone} and provided as part of the hackerspace infrastructure, allows to execute commands on each version published into the \textit{Git} repository.
In the specific case, whenever a new version gets checked-in into the release branch, the \textit{Makefile} is used to build the binary firmware files and publish them to the firmware repository server.
Therefore, a \textit{drone} configuration file as shown in Listing~\ref{lst:drone} has been added to the source code as \texttt{.drone.yml}.
\subsection{Device setup and flash layout}\label{flashlayout}
Microcontroller boards based on the \textit{ESP8266} MCU are mostly following the same layout: the MCU is attached to a flash chip which contains the bootloader, firmware and other application data.
The memory mapping mechanism of the MCU allows only a single page of 1 MB of flash to be mapped at the same time \cite{ESP8266_Memory_Map} and the selected range must be aligned to 1 MB blocks.
@ -58,7 +56,7 @@ The memory mapping mechanism of the MCU allows only a single page of 1 MB of fla
\end{figure}
As the binary to download and flash possibly exceeds the size of free memory heap space, the received data must be written to flash directly.
In contrast, executing the code from the memory mapped flash while writing the same area with the downloaded update leads to errors, as the executed code changes immediately to the updated one.
In contrast, executing the code from the memory mapped flash while writing the same area with the downloaded update leads to unexpected behavior, as the executed code changes immediately to the updated one.
To avoid this, we chose the memory layout shown in Figure~\ref{fig:memory_layout}.
The flash is split into half to contain two firmware ROMs with different versions, one being executed and one which is being downloaded.
This standby firmware also acts as a safety mechanism if the download fails or is interrupted as the previous version stays intact and can still be used (refer to requirement \ref{req2}).
@ -67,14 +65,15 @@ In addition to the two firmware ROMs, the flash provides room for the bootloader
\subsection{Cryptographically securing the firmware update}
To ensure only valid firmware is running on the device, the update process is calculating and checking the firmwares signature.
To do so, \textit{curve25519}\cite{curve25519} and \textit{sha256}\cite{sha256} is used which is a modern secure method for signatures \cite{crypto-ftw}.
The signature is created by the build system for each of the two firmware ROMs during build time and is provided as meta-information beside the firmware binaries.
Therefor the build system must be equipped with the private key used to create the signatures.
In contrast, the Microcontroller does only need to know the according public key.
To ensure only valid firmware is running on the devices, a cryptographic signature of the firmware images is calculated and checked as part of the update process.
For the calculation of the signatures, the \textit{sha256} hashing algorithm \cite{sha256} and an elliptic curve cipher based on \textit{Curve25519}\cite{curve25519} are used, which are both considered modern and secure methods for software signing \cite{crypto-ftw}.
The cryptographic signature for each of the two firmware ROMs is created by the continuous integration system during build time and is provided as meta-information along with the firmware binaries.
Therefore, the CI system must be equipped with the private key used to create the signatures.
In contrast, the micro controller only needs to know the according public key, to be able to verify the cryptographic signature.
For the same reasons as stated above, the new firmware binary can not be downloaded and verified before it's written to flash.
Therefore the calculation of the checksum required for the signature is done while the update is downloaded and written to the flash.
After the download has succeeded, the signature is verified.
If the signature is invalid, the bootloader will not be reconfigured and the system will not reboot into the invalid firmware.
For the same reasons as stated in Section \ref{flashlayout}, the signature of the new firmware binary can not be verified before it is written to flash.
Therefore, the calculation of the sha256 checksum required for the signature is done while the update is downloaded and written to flash.
After the download has succeeded, the signature is verified and the bootloader only gets reconfigured if the signature is validated successfully.
Otherwise, the bootloader will not be reconfigured and the system will not start the invalid firmware.
Sven Reissmann
8 years ago