\chapter{Implementation}
\label{cha:implementation}
The concept decscribed in \autoref{cha:concept} will be implemented as a prototype to demonstrate a working implementation and to analyze the speed of those parts of a transaction.
Although the goal is to put all these features on a highly integrated system, we decided to start with widely available hardware based on Intel's x86 architecture.

\begin{figure}[ht]
	\centering
	\includegraphics[width=0.6\textwidth]{../resources/networkview3}
	\caption[Prototype schematic]{Prototype setup to show DAA features and the Dataflow from BS to PIA}
	\label{fig:prototype}
\end{figure}
\autoref{fig:prototype} shows the setup on a connection level.
To show the features of DAA, it is necessary to have three independent systems which are connected via a TCP/IP network.
Every host is connected via Ethernet to the other systems.
To keep the setup minimal, the IP addresses are static and Internet is only required during installation.
Hence, Service Discovery is done statically, every host knows the IP addresses and functions of each other directly.

\section{Hardware Setup}
For demonstrating remote attestation via DAA over a simple network infrastructure, we use 3 systems with similar configuration.
\autoref{tab:systems} show the specification of these systems.
We decided to order one system with an AMD processor in it to find differences in handling the TPM between Intel and AMD systems.
All features used in this thesis were available on both platform types, so there were no differences found.

\begin{table}[ht]
	\renewcommand{\arraystretch}{1.2}
	\centering
	\caption{Systems used for demonstration prototype} \label{tab:systems}
	%\rowcolors{2}{lightgray}{white}
	\begin{tabular}{rp{3.7cm}p{3.7cm}p{3.7cm}}
		\toprule
		&\textit{System 1}&\textit{System 2}&\textit{System 3} \\
		\midrule
		\textbf{Processor}	&AMD Athlon 240GE &Intel Pentium G4560T &Intel Pentium G4560T\\
		\textbf{Mainboard}	&Gigabyte B450I Aorus Pro Wifi	&Gigybyte GA H110N	&Gigabyte GA H310N\\
		\textbf{Memory} &8GB DDR4	&8GB DDR4	&8GB DDR4\\
		\textbf{Storage} &NVMe SSD 128GB &NVMe SSD 128GB   &NVMe SSD 128GB  \\
		\textbf{TPM}   &Gigabyte TPM2.0\_L	&Gigabyte TPM2.0\_L   &Gigabyte TPM2.0\_L   \\
		\bottomrule
	\end{tabular}
\end{table}

The used mainboards come with a dedicated TPM2.0 header which may differ from board to board.
A 19-pin header is available on the older platform of \emph{System 2}.
As long as TPM and mainboard have the same 19-pin connector they will be compatible to each other.
The newer Gigabyte mainboards come with a proprietary 11-pin connector which is only compatible with Gigabyte's TPM2.0\_S module.
All other modules are however electrical compatible since only unused pins of the full size connector are removed.
With a wiring adapter any TPM board would work on any mainboard supporting TPM2.0 even when coming with a prorietary header.

\section{Operating System}
The Operating System need to fulfill three requirements for this prototype.
First, the TPM must be supported by the kernel.
Second, the OS has to support a recent version of the TPM Software Stack (TSS 3.0.x or newer at the point of writing) for using the Xaptum ECDAA\footnote{\url{https://github.com/xaptum/ecdaa}} project with enabled hardware TPM.
Similarly, the \texttt{tpm2-tools} must be available in a version newer than \texttt{4.0.0}.
Finally, the support for the Integrity Measurement Architecture (IMA) must be activated in the
kernel and supported by the OS.
This feature is available in the mainline Linux kernel, however, the according kernel compile
parameters must be set.

Ubuntu 20.04 LTS does fulfill above mentioned requirements by default.
Ubuntu is also supported by the Xaptum ECDAA project, although it was tested with an older version (18.04).
When installing Ubuntu on the prototype, we used \emph{Full Disk Encryption} (FDE) which leads to the disk allocation described in \autoref{tab:disklayout}.
Ubuntu installs Grub by default, and it is used as a fallback bootloader.

\begin{table}
	\centering
	\begin{tabular}{llll}
		\toprule
		\emph{Partition}	&\emph{Size}	&\emph{Mountpoint}	&\emph{Comment}\\
		\midrule
		\texttt{nvme0n1p1}	&512M	&\texttt{/boot/efi}	&EFI boot partition\\
		\texttt{nvme0n1p2}	&1G		&\texttt{/boot}		&Bootloader partition (Grub)\\
		\texttt{nvme0n1p3}	&118G	&	&lvm on dm\_crypt\\
		\texttt{ubuntu--vg-ubuntu--lv}	&118G	&\texttt{/}	&root partition on lvm\\
		\bottomrule
	\end{tabular}
	\caption{Disk layout of the BS prototype}
	\label{tab:disklayout}
\end{table}


%In the next section we describe the basic setup of the OS to prepare Trusted Boot.
%The DAA implementation of Xaptum\footnote{\url{https://github.com/xaptum/ecdaa}} supports Debian Linux and Ubuntu as operating system when interacting with a hardware TPM.

%At the time of writinng, the most recent version of Ubuntu 20.04 LTS supports the TPM2.0 as well as the Xaptum DAA library and the Integrity features which are integrated in the Kernel



\section{Trusted Boot}
By default, every Mainboard with support for TPM2.0 must support Trusted Boot.
When a TPM becomes available, the BIOS itself takes all required measures until the boot process is handed over to the OS bootloader (e.g. Grub).
Since Ubuntu uses Grub 2.04 as bootloader, Trusted Boot is directly supported and needs just to be enabled in the configuration.
In this case, Grub will be measured from the BIOS to the PCRs 4 and 5, as shown in \ref{tab:PCR}.
Grub itself uses PCR 8 for executed commands, the kernel command line and all commands forwarded to
kernel modules.
PCR 9 is used to measure all files read by Grub\footnote{\url{https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html} (visited on 19.11.2020)}.

Embedded systems like a productive version of the BS do not need several boot options.
Therefore we replace the bootloader by loading the kernel directly.
This kernel decrypts the disk and boots the remaining system.
Pawit Pornkitprasam \cite{pornkitprasan19-diskencryption}\cite{pornkitprasan19-tpmtools} and Karl O from Tevora \cite{tevora-secureboot} introduced the concept of a \emph{Unified Kernel} for Ubuntu and Arch respectively.

We create a large EFI file which contains the initramfs, kernel command line and the kernel itself.
This EFI file replaces that from Grub in the EFI boot partition.
\autoref{code:tbcommandlinetxt} shows the used command line which will be saved on \texttt{/boot/kernel-command-line.txt}
The parameters activate also IMA which is discussed later in this chapter.
\begin{table}
	\centering
	\begin{footnotesize}
		\begin{tabular}{lll}
			\toprule
			\emph{Address}	&\emph{Source path}	&\emph{Comment}\\
			\midrule
			\texttt{0x0000000}	&\texttt{/usr/lib/systemd/boot/efi/linuxx64.efi.stub}	&Linux EFI Stub\\
			\texttt{0x0020000}	&\texttt{/usr/lib/os-release}		&Linux OS release information\\
			\texttt{0x0030000}	&\texttt{/boot/kernel-command-line.txt}	&Kernel command line parameters\\
			\texttt{0x0040000}	&\texttt{/boot/vmlinuz}	&latest kernel image\\
			\texttt{0x3000000}	&\texttt{/boot/initrd}	&latest initial ramdisk\\
			\bottomrule
		\end{tabular}
	\end{footnotesize}
	\caption{Memory layout of the Unified Kernel EFI file}
	\label{tab:efilayout}
\end{table}
The shell script shown in \autoref{code:tbupdatekernelsh} uses the command \texttt{objcopy} to
create a single EFI file which contains the kernel with corresponding release information, its
command line parameters and the initial file system which is held in RAM during boot.
The memory layout of the EFI blob is shown in \autoref{tab:efilayout}
With this Unified Kernel in place, no additional PCRs are used and everything is measured by the BIOS.
% It furthermore omits the bootloader which is not necessary since the BS is ideally an embedded system with a single boot option in the end.

When the BIOS hands over the system to the bootloader, all PCR values are already set.
The Trusted Boot chain can now be used to authenticate the kernel against the system.
Therefore a second key is added to the LUKS header, which is a random number of 32 byte length.
This key is saved in the TPM and sealed with the values of PCR 0--7.
If the BIOS measurements calculate the same values as those of the sealing, the TPM is able to reveal the key for the FDE and the boot process can continue.
The \emph{trusted} environment is now extended to the kernel and the modules loaded at boot.

Although the disk encryption is optional for this project, it might be useful to encrypt the disk when any sensitive data is stored on the device.
\autoref{code:tbinstallsh} is the main script installing disk decryption via TPM.
%TODO Edit pointer
\begin{itemize}
	\item update initramfs with tpmtools
	\item hook script takes PCRs to unseal key, optional use secondary key for manual decryption (admin access)
	\item compile unified kernel
	\item optional update kernel and tpm values after system upgrade -- one reboot required for generating the PCR values; impossible to precompute.
\end{itemize}


\begin{itemize}
	\item Trusted Boot with GRUB 2.04: TPM support available; PCR mapping
	\item Secure Boot with unified kernel; another PCR mapping
	\item Benefits and Drawbacks of both variants
	\item describe automated unlocking
\end{itemize}

Limitations due to bad implementation on BIOS-Level, no Certificate Verification Infrastructure available for TPMs? Needs to be proven for correctness.

\section{Integrity Measurement Architecture}
Available on Ubuntu, RedHat and optionally Gentoo.
The kernel has the correct compile options set.

\subsection{Handling external hardware}4
How can camera and fingerprint sensor be trusted?
What is the limitation of this solution?

\section{Interaction with TPM2}
tpm2-tools 4.x are usable to interact with the TPM from the command line.
Available on all major releases after summer 2019.
Fallback is using the TPM2 ESAPI or SAPI, which is available on almost all Linux distributions.

\section{Direct Anonymous Attestation}
DAA Project from Xaptum: Working DAA handshake and possible TPM integration.
Requires an Attestation Key which is secured with a password policy.

