@ -73,9 +73,13 @@ In addition to the two firmware ROMs, the flash provides room for the bootloader
\subsection{Cryptographically securing the firmware update}
To ensure only valid firmware is running on the device, the update process is calculating and checking the firmwares signature.
To do so, \textit{curve25519}\cite{curve25519} and \textit{sha512}\cite{sha512} is used which is a modern secure method for signatures \cite{crypto-ftw}.
To do so, \textit{curve25519}\cite{curve25519} and \textit{sha256}\cite{sha256} is used which is a modern secure method for signatures \cite{crypto-ftw}.
The signature is created by the build system for each of the two firmware ROMs during build time and is provided as meta-information beside the firmware binaries.
Therefor the build system must be equipped with the private key used to create the signatures.
In contrast, the Microcontroller does only need to know the according public key.
For the same reasons as stated above, the new firmware binary can not be downloaded and verified before it's written to flash.
Therefore the calculation of the checksum required for the signature is done while the update is downloaded and written to the flash.
After the download has succeeded, the signature is verified.
If the signature is invalid, the bootloader will not be reconfigured and the system will not reboot into the invalid firmware.
The implementation of the update mechanism consists of three parts which interact closely: checking for updates, reprogramming the device and reconfiguring the boot process.
This sections describes all three of these parts in detail.
The implementation of the update mechanism consists of four parts which interact closely: checking for updates, reprogramming the device, calculating and verifying the firmware signature and reconfiguring the boot process.
This sections describes all four of these parts in detail.
The build-time configuration was extended to include a new option called \texttt{UPDATER\_URL}, which is the base URL used to query the update server.
Each device requires to have this option set to make the update work.
@ -10,10 +10,13 @@ Skipping the option results in the exclusion of the code for update management d
\subsubsection{Checking for updates}
Initially, each device queries the update server regularly for the current firmware version and initializes the update process if remote and local versions differ.
To do so, the update server provides a file for each device type containing the available version identifier, which is stored beside the firmware binary files with other meta-information.
Each device queries the update server regularly for the current firmware version and initializes the update process if remote and local versions differ.
To do so, the update server provides a file for each device type containing meta-information about the available firmware which consists of the version identifier and the signatures of both of the firmware binaries.
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).
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 meta-information file has a very simple line oriented, ASCII based format which is easy to generate and efficient to pars in the limited constrains of the embedded device.
The first line is the version identifier which 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 remaining lines is the hexadecimal representation of the firmware signatures, one line for each firmware.
Each device tries to fetch the meta-information file once every hour.
After the file has been downloaded successfully, the version identifier is extracted and compared to the version identifier provided during build time.
@ -73,11 +76,13 @@ if (bootconf.current_rom == 0) {
}
\end{lstlisting}
For installing a firmware update, the new firmware binary file is downloaded using an HTTP GET request.
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 binary files for the first and second slot respectively.
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 makes development and initial installation very easy.
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 binary files for the first and second slot respectively.
After the download of a new ROM has been finished successfully, the bootloader configuration is altered to boot to the new ROM slot and the device is rebooted.
For installing a firmware update, the new firmware binary file is downloaded using an HTTP GET request.
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 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.
