tech-doc: describe protocol

master
S.J.R. van Schaik 7 years ago
parent 933780321b
commit 71f7cb40dc
  1. 51
      tech-doc/tech-spec.tex

@ -143,26 +143,20 @@ The untrusted images to be booted by the Whitebox can be signed by one or more a
\section{Protocol}
In the most simplistic model, the boot procedure that will be performed is as follows:
\begin{itemize}
\item The trusted image is read from SPI NOR flash and booted.
\item The read-only trusted stage enumerates the available images.
\item The read-only trusted stage selects an image to boot and verifies this image in co-operation with the TBM.
\item Once an image has been selected and verified, the read-only trusted stage informs the TBM that it will boot this image whereupon the TBM will keep track of the image that was selected and where it will then enter a restrictive state.
\item The read-only trusted stage boots the image.
\end{itemize}
The communication between the host device and the TBM follows a client-server model where the host devices sends requests to the TBM over serial.
\subsection{Design}
After the TBM has powered up, the TBM will power up the host device to ensure that the TBM is in full control of the host device.
The host device will then boot the ROTS image from the SPI NOR flash.
More specifically, the host device will load and boot the u-boot SPL, which will then load and boot u-boot.
Once u-boot has booted up, u-boot will probe the SPI NOR flash device and read the kernel and the initramfs from the SPI NOR flash and execute the kernel.
As the SPI NOR flash should be fully write-protected, all these images are read-only and cannot be tampered with.
Hence, when the kernel has been booted up and once the initramfs has been mounted, the host device has reached the Read-Only Trusted State (ROTS).
In this state, the host device is allowed to send any kind of request to the TBM to fetch the time, the certificates and any other information required to determine which image to boot.
\begin{figure}[H]
\centering
\begin{adjustbox}{width=\textwidth,center}
\begin{tikzpicture}
\draw[thick,draw=gray!70,->] (-0.2,0) node[left] {\tt\small\uppercase{TBM}} -- (15,0);
\draw[thick,draw=gray!70,->] (-0.2,4) node[left] {\tt\small\uppercase{ROTS}} -- (15,4);
\draw[thick,draw=gray!70,->] (-0.2,0) node[left] {\tt\small\uppercase{TBM}} -- (13.25,0);
\draw[thick,draw=gray!70,->] (-0.2,4) node[left] {\tt\small\uppercase{ROTS}} -- (13.25,4);
\draw[thick,draw=green!70!black,dashed] (0,0) -- ++(0,4) node[midway, sloped, above] {\color{green!70!black}\tt\small\uppercase{trusted}};
@ -189,8 +183,35 @@ The communication between the host device and the TBM follows a client-server mo
\end{tikzpicture}
\end{adjustbox}
\caption{protocol diagram.}
\label{fig:proto-dia}
\end{figure}
Figure~\ref{fig:proto-dia} shows the interaction between the TBM and the ROTS after both device have booted up and entered the trusted state.
In the Read-Only Trusted State, the TBM is passive and will not send any messages to the host device, while the host device is active and will send requests for the TBM to respond to.
Requests start with a command for the TBM to execute followed by zero or more arguments separated by spaces and terminated with a \emph{Carriage Return} ({\tt 0x13}).
If an argument consists of two or more words separated by spaces, then it must be enclosed in quotes, such that the TBM will treat it is as a single argument instead of multiple.
In case input has to be provided to a command, the input must follow the command and must be terminated with an \emph{End of Transmission} character ({\tt 0x04}).
In all cases, the response of the TBM may include output terminated by an \emph{End of Transmission} character.
The \emph{End of Transmission} character must always be present in the response, even is there is no output to signal that there is no output.
An exit code or error message must follow the output and must also be terminated with an \emph{End of Transmission} character.
The commands available to the ROTS are: {\tt hi}, {\tt ls}, {\tt cat}, {\tt time}, and {\tt booting}.
The {\tt hi} command must be followed with the version of the ROTS on the host device and is used to initiate a handshake with the TBM.
The TBM must respond with {\tt hello} followed by the version of the TBM.
The {\tt ls} command is used to list the files in a directory and may be followed with a path on the filesystem.
If no path has been provided, the root of the filesystem will be assumed.
On success, the TBM must respond with a list of filenames.
The {\tt cat} command is used to read a file on the filesystem and must be followed with the path of the file to read.
On success, the TBM must respond with the file contents.
The {\tt time} command is used to get the current time as a UNIX timestamp and requires no arguments.
On success, the TBM must respond with the current time encoded as a UNIX timestamp.
The {\tt booting} command is used to indicate that the host device will boot an untrusted kernel, thus switch to an untrusted state and must be followed with exactly one argument indicating the version of the image that will be booted.
On success, the TBM must restrict access to the commands to the commands that should be available in the untrusted state.
The commands available to the untrusted state are: {\tt booting ok}.
The {\tt booting ok} command has no further arguments and is used to indicate that the kernel has been booted.
\subsection{Clock Drift}
To cope with clock drift the real-time clock has to be synchronised with an external clock. The most straight-forward method to support this within the protocol is to allow an absolute time to be set. However, this should only be allowed from the read-only trusted stage. An alternative method is to allow the clock to be corrected by introducing a limited amount of additional ticks or to stop the clock for a limited amount of ticks. By having limited correction, the clock can still be synchronised while an attacker cannot change the clock by more than a negligible factor each year.

Loading…
Cancel
Save