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.
Wireless sensor and actor networks are 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 research presented in this paper was mainly driven by \textit{Magrathea Laboratories e.V.}\cite{maglab}, the local hackerspace in Fulda, Germany, in cooperation with researchers at the department for computer science at Fulda University of Applied Sciences.
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.
It provides direct control over all existing components using a web-based user interface 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.
These boards feature a small and robust design, achieve very low power consumption and integrate WiFi without requiring any extra components.
@ -10,10 +10,10 @@ The base topology, as well as the specific components used is shown in Figure \r
\end{figure}
The source code of the \textit{ESPer} project is published into a \textit{Git}\cite{git} source code repository.
From there, the continuous integration system is responsible for automatically building and publishing the firmware image files, as soon as updated source code is available.
It is also in charge of assembling and publishing meta-information (version and signature) required for the update process.
Both systems are described in detail in the following section.
Updates to the devices firmware is either triggered actively (manual or by the CI system) or on a regular schedule by the devices themselves.
From there, the continuous integration (CI) system is responsible for automatically building and publishing the firmware image files, as soon as updated source code is available.
It is also in charge of assembling and publishing meta-information (version number and cryptographic signature) required for the update process.
The CI systems is described in detail in the following section.
Updates to the devices firmware are either triggered actively (manual or by the CI system) or on a regular schedule by the devices themselves.
This process is described in section \ref{flashlayout}.
For monitoring and maintenance purposes, each device publishes a set of information to a well-known \textit{MQTT} topic after connecting to the network.
@ -28,17 +28,17 @@ By sharing the same code, all devices ensure to have a common behavior when it c
This eases configuration and allows to collect information about all devices at a central location.
As development on the devices usually happens in cycles, some of the projects would miss updates of the framework and therefor would not benefit from newly added features or fixed problems.
Regular updating of the framework version and rebuilding the firmware would often result in an easy gain of these benefits, but requires manual interaction.
Regularly updating the framework version and rebuilding the firmware would often result in an easy gain of these benefits, but requires manual interaction.
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.
In this situation, the device firmware must be updated to use the changed API, which can be an unpleasant and complex task that leads to higher latency for firmware updates.
To prevent these problems, the firmware of all devices in the hackerspace is integrated together with the framework into a larger project.
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.
Whenever a new build is started, the build system scans for all device specific folders and calls the 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 firmware images.
To avoid interferences between different build environments, and to roll out new versions as quickly as possible, the code has been integrated into a continuous integration (CI) system which is also responsible for publishing the resulting firmware images to the firmware server queried during updates and notifies the devices to check for an update.
To avoid interferences between different build environments, and to roll out new versions as quickly as possible, the code has been integrated into a continuous integration (CI) system which is also responsible for publishing the resulting firmware images to the firmware server queried during updates, and for notifying the devices to check for an update.
\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.
@ -48,7 +48,7 @@ As the image to download and flash possibly exceeds the size of free memory heap
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, the flash is split into half to contain two firmware ROM slots with different versions, one being executed and one which is being downloaded.
This standby ROM slot 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}).
In case of an error the old firmware is kept unchanged and will be used until the successful download of a newer firmware succeeds.
In case of an error, the old firmware is kept unchanged and will be used until the successful download of a newer firmware succeeds.
In addition to the two firmware ROM slots, the flash provides room for the bootloader and its configuration.
\subsection{Cryptographically securing the firmware update}
@ -59,7 +59,7 @@ The cryptographic signature for each of the two firmware images is created by th
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 in Section \ref{flashlayout}, the signature of the new firmware image can not be verified before it is written to flash.
For the same reason as stated in Section \ref{flashlayout}, the signature of the new firmware image can not be verified before it is written to flash.
Therefore, the calculation of the \textit{SHA-256} checksum required for the signature check is done while the update is downloaded and written to flash.
After the download has succeeded, the checksum is verified against the signature and the bootloader gets reconfigured iff the signature is validated successfully.
Otherwise, the bootloader will not be reconfigured and the system will not start the invalid firmware.
@ -69,9 +69,9 @@ While building a devices firmware, the meta-information file used during updates
For development, each device can be build separately by using the device type identifier as \textit{Makefile} target.
In addition, the suffix \texttt{/flash} can be used to flash a specific firmware to the device.
While building the firmware images for a device, the build environment provides some constants which are baked into the resulting firmware image.
While building the firmware images for a device, the build environment provides some constants, which are baked into the resulting firmware image.
Beside the environmental configuration like the WiFi credentials, \textit{MQTT} topics and other configurable tweaks, the current device and version identifiers are provided as compile time constants.
In addition, the public key used to verify firmware signatures during updates is derived from the private key and provided as an linker object which is linked into each firmware image (Listing~\ref{lst:public_key_object}).
In addition, the public key used to verify firmware signatures during updates is derived from the private key and provided as a linker object, which is linked into each firmware image (Listing~\ref{lst:public_key_object}).
This allows to use all the information inside the code without any overhead while being configurable during build time.
\begin{lstlisting}[caption={Creating the linker object containing the public key.},
@ -4,7 +4,7 @@ The update mechanism is split into four main phases: checking for updates, repro
\subsubsection{Checking for updates}
In order to inform the IoT devices of the availability of a new firmware version, the update server provides a file for each device type containing meta-information about the latest available firmware version.
The meta-information file has a simple line oriented ASCII format, which is easy to generate and efficient to pars within the limited constrains of the embedded device.
The meta-information file has a simple line oriented ASCII format, which is easy to generate and efficient to parse within the limited constrains of the embedded device.
It consists of the version identifier and the cryptographic signatures of both of the firmware binaries.
The version identifier can be an arbitrary string as the content is not interpreted semantically but only compared to the version identifier used during build time.
The other two lines in the meta-information file provide the hexadecimal representation of the cryptographic signatures, one line for each firmware binary file.
@ -43,7 +43,7 @@ irom0_0_seg :
For installing a firmware update, the new firmware image file is downloaded using an HTTP GET request.
\subsubsection{Verifying the cryptographic signature}
While the image is being downloaded each chunk received in the download stream is used to update the \textit{SHA256} hash before it is written to the flash.
While the image is being downloaded, each chunk received in the download stream is used to update the \textit{SHA256} hash before it is written to the flash.
When the write has been finished, the next chunk is received and the process continues until all chunks have been received.
After the download of a new ROM has been finished successfully, the calculated hash is checked against the cryptographically signed hash provided in the meta-information file. The required public key is always baked into the running firmware.
Only if the firmware is considered valid, the bootloader configuration is altered to boot into the new ROM slot and the device is rebooted.
@ -84,9 +84,5 @@ The firmware files provided on the update server are the exact same ones as used
Using the same files for flashing and updating allows better debugging by eliminating errors related to the update process itself and eases development and initial installation.
Listing~\ref{lst:choosing_rom} shows the algorithm used to determine the download address and reconfigure the bootloader.
The update server provides these files in the exact same way as it provides the meta-information files, but the path pattern differs: the suffixes \texttt{.rom0} and \texttt{.rom1} are used to provide the firmware image files for the first and second slot respectively.
For installing a firmware update, the new firmware image file is downloaded using an \textit{HTTP 1.1}\texttt{GET} request.
While the firmware image is being downloaded each chunk received in the download stream is used to update the \textit{SHA-256} hash before it is written to the flash.
When the write has been finished, the next chunk is received and the process continues until all chunks have been received.
After the download of a new firmware image has been finished successfully, the calculated hash is checked against the signature provided in the meta-information file triggering the update and the public key baked into the running firmware. Only if the firmware is considered valid, the bootloader configuration is altered to boot into the new ROM slot and the device is rebooted.
Sven Reissmann