In todays marketplace, an explosive growth can be observed in the area of so-called smart devices, often referred to as Internet of Things (IoT).
In todays marketplace, an explosive growth can be observed in the area of so-called smart devices, often referred to as Internet of Things (IoT).
Conventional devices (i.e., door locks, light bulbs, washing machines) are extended with smart functions for remote control and monitoring.
Conventional devices (e.g., door locks, light bulbs, washing machines) are extended with smart functions for remote control and monitoring.
To implement the additional smart functions, small embedded computer systems are getting integrated into the devices, allowing them to connect to the local WiFi network.
To implement the additional smart functions, small embedded computer systems are getting integrated into the devices, allowing them to connect to the local WiFi network.
In embedded systems, the software, also known as firmware, is an essential part of the system.
In embedded systems, the software, also known as firmware, is an essential part of the system.
@ -13,7 +13,7 @@ In almost all cases, the requirements can be accomplished by changing the firmwa
For updating the firmware on a system being deployed, the system must provide an interface for altering the firmware.
For updating the firmware on a system being deployed, the system must provide an interface for altering the firmware.
In addition, such an interface should provide mechanisms to check which firmware is currently installed and which configuration parameters are used.
In addition, such an interface should provide mechanisms to check which firmware is currently installed and which configuration parameters are used.
Even if systems are equipped with an interface for applying updates, the maintenance cost can still be enormous if an administrator has to interact with each device physically if the systems are located in areas where reachability is limited.
Even if systems are equipped with an interface for applying updates, the maintenance cost can still be enormous if an administrator has to interact with each device physically and the systems are located in areas where reachability is limited.
If a system is already able to communicate over a network interface, this can be leveraged to apply updates on these system - this is typically referred to as \textit{Over the Air (OTA)}.
If a system is already able to communicate over a network interface, this can be leveraged to apply updates on these system - this is typically referred to as \textit{Over the Air (OTA)}.
By reusing the existing communication channels, the dedicated update interface can be omitted which leads to smaller packaging and reduces production cost.
By reusing the existing communication channels, the dedicated update interface can be omitted which leads to smaller packaging and reduces production cost.
It also decreases the maintenance cost drastically, because updates can be triggered remotely.
It also decreases the maintenance cost drastically, because updates can be triggered remotely.
@ -11,7 +11,7 @@ It integrates a Tensilica L106 32-bit micro controller unit (MCU) with a maximum
According to the manufacturer, the ESP8266 is among the most integrated WiFi-capable chips in the industry.
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 \textit{Sonoff}\cite{sonoff} wireless smart switches product series offered by \textit{ITEAD}.
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 \textit{Sonoff}\cite{sonoff} wireless smart switches product series offered by \textit{ITEAD}.
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}.
The firmware for all of the \textit{ESP8266}-based devices in the hackerspace has been implemented using 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.
\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.
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.
@ -6,7 +6,7 @@ For the implementation of an OTA update mechanism, the following requirements we
\subsubsection{}\label{req1}
\subsubsection{}\label{req1}
The systems must be able to perform updates on the release of new software without manual interaction.
The systems must be able to perform updates on the release of new software without manual interaction.
If a new firmware version is published for a type of devices, the target devices must fetch and install the new software version automatically, and start using it subsequently, if no errors have occurred during the update.
If a new firmware version is published for a type of devices, the target devices must fetch and install the new software version automatically, and start using it subsequently if no errors have occurred during the update.
\subsubsection{}\label{req2}
\subsubsection{}\label{req2}
To ensure minimal maintenance effort, the update process should be insusceptible to errors as much as possible.
To ensure minimal maintenance effort, the update process should be insusceptible to errors as much as possible.
@ -11,9 +11,9 @@ The base topology, as well as the specific components used is shown in Figure \r
The source code of the \textit{ESPer} project is published into a \textit{Git}\cite{git} source code repository.
The source code of the \textit{ESPer} project is published into a \textit{Git}\cite{git} source code repository.
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.
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.
It is also in charge of assembling and publishing meta-information consisting of version number and cryptographic signature required for the update process.
The CI systems is described in detail in the following section.
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.
Updates to the devices firmware are either triggered actively (e.g. manual or by the CI) or on a regular schedule by the devices themselves.
This process is described in section \ref{flashlayout}.
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.
For monitoring and maintenance purposes, each device publishes a set of information to a well-known \textit{MQTT} topic after connecting to the network.
@ -4,11 +4,11 @@ The update mechanism is split into four main phases: checking for updates, repro
\subsubsection{Checking for updates}
\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.
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 parse 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 constraints of the embedded device.
It consists of the version identifier and the cryptographic signatures of both of the firmware binaries.
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 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.
The other two lines in the meta-information file provide the hexadecimal representation of the cryptographic signatures, one line for each firmware binary file.
These meta-information files are provided by the update server using \textit{HTTP 1.1}\cite{HTTP_1.1} under the following path pattern: \texttt{\$\{DEVICE\}.version} (whereas \texttt{\$\{DEVICE\}}is the device type name).
These meta-information files are provided by the update server using \textit{HTTP 1.1}\cite{HTTP_1.1} under the following path pattern: \texttt{\$\{DEVICE\}.version} (whereas \texttt{\$\{DEVICE\}}gets replaced by the device type name).
Each device queries the update server regularly (initially when the boot process is finished and periodically once an hour) for the currently available firmware version.
Each device queries the update server regularly (initially when the boot process is finished and periodically once an hour) for the currently available firmware version.
It uses the \texttt{UPDATER\_URL} option to identify the update server.
It uses the \texttt{UPDATER\_URL} option to identify the update server.
@ -45,7 +45,7 @@ For installing a firmware update, the new firmware image file is downloaded usin
\subsubsection{Verifying the cryptographic signature}
\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.
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.
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 triggering the update using the \textit{curve25519} public key provided by 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.
Only if the firmware is considered valid, the bootloader configuration is altered to boot into the new ROM slot and the device is rebooted.
Implementing \textit{OTA} updates under the given requirements involves multiple components, which interact closely.
Implementing \textit{OTA} updates under the given requirements involves multiple components, which interact closely.
The continuous integration system is in charge of building the firmware from source, calculating cryptographic signatures, and publishing the built firmware images.
The continuous integration system is in charge of building the firmware from source, calculating cryptographic signatures, and publishing the built firmware images.
The deployment infrastructure provides resources for downloading the firmware images and triggering the update on all devices.
The deployment infrastructure provides resources for downloading the firmware images and triggering the update on all devices.
Finally, the implementation of the update mechanism as a part of the firmware running on the embedded device is responsible for downloading and installing the updates.
Finally, the implementation of the update mechanism, as a part of the firmware running on the embedded device, is responsible for downloading and installing the updates.
