@ -23,8 +23,6 @@ This allows faster roll-outs of updates and finer control for manual maintenance
The firmware files provided on the update server are the exact same ones as used to initially flash the chip for the according version.
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.
\begin{lstlisting}[caption={Configuring the updater to download the right firmware image and update the booloader accordingly.},
@ -43,10 +41,15 @@ if (bootconf.current_rom == 0) {
}
\end{lstlisting}
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{.rom\{0,1\}} 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.
\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.
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 the new firmware image 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.
When the write has been finished, the next chunk is received and the process continues until all chunks have been processed.
After downloading the new firmware image has been finished successfully, the calculated hash is checked against the signature of the according firmware image.
Therefore the cryptographically signed hash, which was provided in the meta-information file triggering the update, is verified against the \textit{Curve25519} public key stored as a constant in the running firmware.
Only if the checksum matches the provided signature, the firmware is considered valid and the process is continued.
\subsubsection{Reconfiguring the boot process}
@ -54,4 +57,4 @@ For the bootloader, \textit{rBoot}\cite{rBoot} has been choosen as it is integra
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 on next startup.
To switch to the updated ROM slot after successful installation, the number ROM slot to boot is changed and the device is restarted.
To switch to the updated ROM slot after successful installation, the number ROM slot to boot on startup is changed in the configuration section and the device is restarted.
@ -6,13 +6,16 @@ All of the devices running the OTA-enabled firmware have undergone multiple majo
This includes a major network configuration change and an important stability fix for the network communication stack.
All devices applied the update successfully and started to work without any manual interaction required afterwards.
While the devices from various manufacturers in the hackerspace are all delivered with a pre-installed firmware, which is thought ready for the smart home application, none of them has been provided with updates by the manufacturer so far. The update infrastructure has been the crucial point for most of our members towards the framework.
While the devices from various manufacturers in the hackerspace are all delivered with a pre-installed firmware, which is thought to be ready for smart home application, none of them has been provided with updates by the manufacturer so far.
It is not visible to the users if the current firmware of these devices is at the latest version nor which versions are installed or how to update them.
The update infrastructure has been the crucial point for most of our members towards the framework.
Enabling the developers to do updates in combination with the shared configuration and behavior provided by the framework resulted in a massive speedup when it comes to project deployment.
Before that, the cost for applying changes after deployment was estimated so high, that most projects tend to delay deployment until all required and wanted features were implemented.
Now, as the devices are deployed as soon as the hardware is considered stable, these devices start to provide functionality early and therefore the developers can get better feedback on the provided functionality.
The project will be continued to extend the functionality and security with features already being in development.
The latest development includes further security enhancements by implementing checksum verification during startup where the hash of the firmware image is checked on each boot by the bootloader.
The latest development includes further security enhancements by implementing checksum verification during startup where the hash of the firmware image is checked on each boot by the bootloader to detect tempering and defects.
It also considers including the device identifier into the signature to prevent confounding of images between different device types.
Last, the standby ROM slot will be updated right after each successful update to be more failsafe.
