@ -40,29 +40,18 @@ Whenever a new build is started, the build system scans for all device specific
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.
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 notifies the devices to check for an update.
\subsection{Device setup and flash layout}\label{flashlayout}
\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.
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.
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.
\caption{The flash layout used for two ROM slots.}
\label{fig:memory_layout}
\end{figure}
As the image to download and flash possibly exceeds the size of free memory heap space, the received data must be written to flash directly.
As the image 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 unexpected behavior, 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 ROM slots 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}).
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.
In addition to the two firmware ROM slots, the flash provides room for the bootloader and its configuration.
\subsection{Cryptographically securing the firmware update}
\subsection{Cryptographically securing the firmware update}
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.
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 calculating and verifying the signatures of a firmware image, the \textit{SHA-256} hashing algorithm \cite{RFC6234} and an elliptic curve cipher based on \textit{Curve25519}\cite{bernstein2006curve25519} are used, which are both considered modern and secure methods for software signing (see \cite{barker2016nist, bsi}).
For calculating and verifying the signatures of a firmware image, the \textit{SHA-256} hashing algorithm \cite{RFC6234} and an elliptic curve cipher based on \textit{Curve25519}\cite{bernstein2006curve25519} are used, which are both considered modern and secure methods for software signing (see \cite{barker2016nist, bsi}).
\textit{rBoot}\cite{rBoot} has been choosen as it is integrated within the \textit{Sming} framework and allows to boot to multiple ROM slots.
\textit{rBoot}\cite{rBoot} has been choosen as it is integrated within the \textit{Sming} framework and allows to boot to multiple ROM slots.
For configuration, an \textit{rBoot} specific structure is placed in the flash at a well-known location directly after the space reserved for the bootloader code.
For configuration, an \textit{rBoot} specific structure is placed in the flash at a well-known location directly after the space reserved for the bootloader code.
This structure contains, among other things, the target offsets for all known ROM slots and the number of the ROM slot to boot from on next reboot.
This structure contains, among other things, the target offsets for all known ROM slots and the number of the ROM slot to boot from on next reboot.
The full memory layout of this approach is shown in Figure~\ref{fig:memory_layout}.
\caption{The flash layout used for two ROM slots.}
\label{fig:memory_layout}
\end{figure}
%The full memory layout of this approach is shown in Figure~\ref{fig:memory_layout}.
To calculate the origin of application data for each ROM slot, the available memory of 1 MB is split in half and an offset of the size of the bootloader code and its configuration (0x2000 bytes) is added.
To calculate the origin of application data for each ROM slot, the available memory of 1 MB is split in half and an offset of the size of the bootloader code and its configuration (0x2000 bytes) is added.
For alignment and easy debugging, the second block is also shifted by the same amount ob bytes as the first block.
For alignment and easy debugging, the second block is also shifted by the same amount ob bytes as the first block.
The unused gap of 8192 bytes is used by some applications to store data which can persist over application updates.
The unused gap of 8192 bytes is used by some applications to store data which can persist over application updates.
