This document covers the installation and configuration of the \emph{Trusted Boot Module} (TBM) and the \emph{Read-Only Trusted System} (ROTS).
The TBM is an additional board that consists of a \emph{microcontroller unit} or MCU to manage the boot procedure of the host device in a secure fashion by managing keys, logs and other files related to trusted boot management.
Furthermore, the host device will be restricted to only boot from one read-only storage device that will contain a trusted image or the \emph{Read-Only Trusted System} (ROTS).
Once this image has been booted, the hosted device is in a trusted state from which it will be able to execute a minimal software stack to enumerate the images to boot, to verify these images and to select what image to boot.
Once the image has been booted, the host device will enter an untrusted stage and the TBM will only allow for restricted access.
This implementation allows the host device to only boot images that are trusted and prevents attackers from tampering with the host device or the TBM to boot untrusted images as long as they don't have physical access and as long as there are no vulnerabilities.
\caption{a high-level overview of the interaction between the host device and the Trusted Boot Module}
\label{fig:tbm-overview}
\end{figure}
Figure~\ref{fig:tbm-overview} shows a high-level overview of the design.
Once the device receives power the \emph{Trusted Boot Module} will boot and at some point the TBM will power on the host device.
The host device will then read the trusted image from the SPI NOR flash.
Because the device has been configured to be restricted to boot from the SPI NOR flash and because the SPI NOR flash has been configured to be read-only, the host device will be in a trusted state.
The image that has been booted is designed to be minimal and only contains the software necessary to perform the boot procedure.
Furthermore, the image does not contain a network stack to reduce the amount of possible vulnerabilities and thus to minimise the attack vector.
Once the trusted image has been booted, the host device will enumerate the images to boot and co-operate with the TBM to verify images and to select the image to boot.
This co-operation happens by means of serial communication with the TBM, where the TBM will grant access to the key storage to the ROTS.
Once an image has been selected to boot, the ROTS will inform the TBM that it will boot this image and enter the untrusted stage.
From there on the TBM will only allow for restricted access.
At the moment of writing, the mainline version of u-boot does not have support for SPI NOR flash on Allwinner SoCs such as the Allwinner A10, A20 and the A64.
A driver model compatible SPI driver for u-boot is has been worked on and the code can be found at \url{https://github.com/StephanvanSchaik/u-boot/tree/sunxi-spi}.
This driver has been tested on the following boards:
\begin{itemize}[noitemsep]
\item H2+ Orange Pi Zero with Macronix MX25L1605D 16 Mbit
\item A20 OLinuXino LIME 2 with Winbond W25Q128BV 128 Mbit
As the ROTS image will be read-only once it has been flashed to the SPI NOR flash, it is encouraged to build a minimal kernel images to reduce the amount of possible bugs and vulnerabilities.
More specifically, it is recommended to build a kernel without any support for networking, graphics and audio.
In order to be able to program the SPI NOR flash with an external programmer, we will need an external programmer such as the BusPirate v3.6a or the BusPirate v4.0 and SOIC clip.
Figure~\ref{fig:winbond-pinout} illustrates the pin-out of a Winbond W25Q128.V SPI NOR flash, but any SPI NOR flash chip should be compatible with this pin-out.
The SPI NOR flash should have a circular shape at one of the corners, this corner should be bottom-right corner.
Once the pins of the SPI NOR flash are aligned with the pin-out in figure~\ref{fig:winbond-pinout}, we can clip the SPI NOR flash chip between the SOIC clip.
Figure~\ref{fig:bp36-connect} shows how to connect the BusPirate v3.6a with the SPI NOR flash chip.
Connect the \emph{Chip Select} (CS) pins using the white cable, the \emph{Master In Slave Out} (MISO) pin with the \emph{Data Out} (DO) pin using the black cable, the \emph{Master Out Slave In} (MOSI) pin with the \emph{Data In} (DI) pin using the grey cable and the \emph{Clock} (CLK) pins using the purple cable.
Further, the \emph{Ground} (GND) pins should be connected using the brown cable and the 5V and the VCC pins should be connected with the orange cable.
In order for the SPI NOR flash chip to function, the H/R pin of the SPI NOR flash chip should be pulled high, this can be done by connecting the 5V pin with the H/R pin.
Finally, to be able to program the chip in case write-protection has been configured before, we have to make sure that the \emph{Write-Protect} (WP) is pulled high to disable write-protection.
Because the configuration of write-protection is vendor-specific, the mainline version of \emph{flashrom} does not support configuring write-protection.
Therefore, to be able to configure the write-protection of the SPI NOR flash chip, we have to use Google's fork of \emph{flashrom}.
Unlike the mainline version of flashrom, Google's fork has two flags to get the name and the
flashrom v0.9.4 : bc6cab1 : Oct 30 2014 07:32:01 UTC on Linux 4.9.4-gentoo (x86_64), built with libpci 3.1.10, GCC 4.8.x-google 20140307 (prerelease), little endian
flashrom v0.9.4 : bc6cab1 : Oct 30 2014 07:32:01 UTC on Linux 4.9.4-gentoo (x86_64), built with libpci 3.1.10, GCC 4.8.x-google 20140307 (prerelease), little endian
We can then write \path{u-boot.bin}, \path{bzImage} and \path{initramfs.cpio.gz} to the SPI NOR flash chip by using the respective names of the regions.
To speed up the process of writing these images, we have to disable parsing the fmap and the verification of unmodified regions.
Furthermore, to maintain an optimal stability, an SPI speed of no more than 2 MHz is recommended when using the BusPirate v3.6a:
flashrom v0.9.4 : bc6cab1 : Oct 30 2014 07:32:01 UTC on Linux 4.9.4-gentoo (x86_64), built with libpci 3.1.10, GCC 4.8.x-google 20140307 (prerelease), little endian
The ROTS kernel will now boot up and mount the initramfs as the rootfs.
At some point the kernel will run the init script in the initramfs.
When this happens the ROTS will start communicating with the TBM to fetch the time as well as the certificates.
Once these have been retrieved from the TBM, the ROTS will mount the external media such as hard disks and enumerate and verify possible boot images on those media.