2 Commits

  1. 18
      1-introduction.tex
  2. 4
      4-requirements.tex
  3. 8
      esper-ota.tex

18
1-introduction.tex

@ -1,21 +1,25 @@
\section{Introduction} \section{Introduction}
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).
On the one hand, conventional devices (i.e., door locks, light bulbs, washing machines) are extended with smart functions for remote control and monitoring.
At the same time, completely new categories of products evolve, such as the self-driving car.
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.
On one side, it interacts with the hardware in a system specific way by implementing the specifications required by the components used in the system. On one side, it interacts with the hardware in a system specific way by implementing the specifications required by the components used in the system.
On the other side, it provides use-case dependent functionality in interaction with general purpose hardware components. On the other side, it provides use-case dependent functionality in interaction with general purpose hardware components.
Embedded systems are often thought as systems that never change their requirements or functionality. Embedded systems are often thought as systems that never change their requirements or functionality.
However, practical use shows that the environment in which these systems run do, in fact, change. However, practical use shows that the environment in which these systems run do, in fact, change.
These changes include, but are not limited to, modifications of to the expected behavior or additions to it, reconfiguration of parameters related to communication with other systems and the users as well as correcting errors that have been reported after deployment.
In almost all cases, the requirements can be accomplished by changing the firmware and do not need any modification of the hardware.
These changes include, but are not limited to, modifications to the expected behavior or additions to it, reconfiguration of parameters related to communication with other systems and the users as well as correcting errors that have been reported after deployment.
In almost all cases, the requirements can be accomplished by changing the firmware and do not need any modification to the hardware.
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 because administrators have to interact with each device physically.
For systems that are located in areas where reachability is limited the cost is increased even more.
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.
For systems that are located in areas where reachability is limited the cost increases even more.
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 installed remotely.
It also decreases the maintenance cost drastically, because updates can be triggered remotely.
\textit{OTA} updates enables administrators to apply automation methods on the update process allowing to roll out updates in a controlled fashion. I.e. updates can be done on testing devices first, followed by security-critical deployments and subordinate ones can be delayed to times where the device is not utilized. \textit{OTA} updates enables administrators to apply automation methods on the update process allowing to roll out updates in a controlled fashion. I.e. updates can be done on testing devices first, followed by security-critical deployments and subordinate ones can be delayed to times where the device is not utilized.
Information about the update status provided by the devices allows administrators to apply monitoring techniques ensuring all updates are installed and devices ar in the desired state.
Information about the update status provided by the devices allows administrators to apply monitoring techniques ensuring all updates are installed and devices are in the desired state.

4
4-requirements.tex

@ -13,6 +13,10 @@ Even if the installation of an update fails in the middle of reprogramming the c
\item Downloading the updated firmware should be done over the WiFi interface using the same network connection as used during normal operation. \item Downloading the updated firmware should be done over the WiFi interface using the same network connection as used during normal operation.
Fetching the firmware should be done side-by-side with other traffic produced during operation. Fetching the firmware should be done side-by-side with other traffic produced during operation.
\item The update process can happen over any untrusted wireless network or Internet connection without being vulnerable to attackers.
To prevent possible attackers from injecting malicious software into the embedded devices, a cryptographic signature mechanism must be implemented.
New firmware only gets accepted by the device, if the cryptographic signature of the downloaded firmware image can be verified.
\item Reducing network load and aiming for the maximum possible device uptime is critical. \item Reducing network load and aiming for the maximum possible device uptime is critical.
Therefore, the update process should only be done if a new version is available. Therefore, the update process should only be done if a new version is available.
In contrast, the release of a new update should be rolled out to all devices as fast as possible. In contrast, the release of a new update should be rolled out to all devices as fast as possible.

8
esper-ota.tex

@ -430,7 +430,11 @@ Fulda, Germany\\ Email: Dustin.Frisch@cs.hs-fulda.de}
\begin{abstract} \begin{abstract}
This article describes the implementation of durable and stable system for building firmware updates for embedded systems based on \textit{ESP8266}\cite{ESP8266} microcontrollers. This includes the mechanisms used to build the updates, distribute and install them on the device.
Over the last years, a rapidly growing number of IoT devices is found on the market, especially in the area of the so-called smart home.
These devices, which are deployed in vast numbers and frequently in use over many years, pose a risk to the internet as a whole if not provided regularly with security patches.
Hence, a fully automated process for large-scale software updates of such embedded devices must be considered.
In this article, we present an implementation of a durable and stable system for building and publishing cryptographically secure firmware updates for embedded devices based on \textit{ESP8266} microcontrollers.
This includes mechanisms to build the updates from source and automatically sign, distribute and install them on the target devices.
\end{abstract} \end{abstract}
% IEEEtran.cls defaults to using nonbold math in the Abstract. % IEEEtran.cls defaults to using nonbold math in the Abstract.
@ -443,7 +447,7 @@ Fulda, Germany\\ Email: Dustin.Frisch@cs.hs-fulda.de}
% no keywords % no keywords
\begin{IEEEkeywords} \begin{IEEEkeywords}
Anything; Something; Everything else.%
Secure Updates, Over the Air, ESP8266.
\end{IEEEkeywords} \end{IEEEkeywords}

Loading…
Cancel
Save