masterthesis/thesis/04_implementation.tex

\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}[t]
	\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 three systems with similar configuration.
\autoref{tab:systems} shows 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{Select the Operating System}
The OS needs 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\cite{xaptum21}
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 corresponding 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 UEFI/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 which has TPM support by default, trusted boot just to be enabled in the GRUB configuration.
In this case, GRUB will be measured from the BIOS to the PCRs 4 and 5, as shown in \autoref{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\cite{grub19}.

Embedded systems like a productive version of the BS do not need several boot options.
Therefore we replace the bootloader EFI file with a blob containing all required information to load 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.

This large EFI file contains the initramfs, kernel command line and the kernel itself.
\autoref{tab:efilayout} shows the content of the EFI blob with the corresponding offset addresses as well as the sources in the file system.
\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}

All binary resources are available as blobs which can be imported directly.
Only the command line parameters need to be defined manually.
The following shell scripts are tested on a Ubuntu 20.04 server minimal installation on all three devices.
These packages need to be installed beforehand on an Ubuntu minimal instance to run trusted boot:
\begin{enumerate}
  \item \texttt{binutils} for objcopy, generating unified kernel, and
  \item \texttt{tpm2-tools} to interact with the onboard TPM,

\end{enumerate}

\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 will be discussed later in this chapter.
\lstinputlisting[float,caption={\texttt{kernel-command-line.txt}: Command line for the Kernel}, label={code:tbcommandlinetxt}]{../../trustedboot/kernel-command-line.txt}

If FDE is installed, the boot process need to be aware of how to decrypt the disk.
Therefore, the initramfs needs the luks binaries as well as the TPM software stack to unseal the passhrase with the PCR registers.
The unseal operation itself is then done with \autoref{code:tbpassphrasesh}, which also needs to exist in the initramfs.
\lstinputlisting[float,language=bash, caption={\texttt{passphrase-from-tpm.sh}: Initramfs-script to ask the TPM for the LUKS key}, label={code:tbpassphrasesh}]{../../trustedboot/passphrase-from-tpm.sh}
We copy the script of \autoref{code:tbtpm2hooksh} to \texttt{/etc/initramfs-tools/hooks} to enable TPM access during boot after the next initramfs update.
\lstinputlisting[float,language=bash, caption={\texttt{tpm2-hook.sh}: Script copying required TSS files into the initramfs}, label={code:tbtpm2hooksh}]{../../trustedboot/tpm2-hook.sh}
Next, a new key for FDE is created by using the random number generator of the TPM.
It is saved in clear text in \texttt{/root/keys} to be able to update the sealing operation when new PCR values are used.
The passphrase needs to be available, when an update resulted in new PCR values.
In this case, the passphrase in the TPM would not be accessible anymore.
\autoref{code:tbcreatelukssh} shows the script for creating the LUKS passphrase.
When the new phrase is added to LUKS, the user is asked for an existing FDE password.
We keep the first password as backup when decryption via TPM fails.
Finally, \autoref{code:tbupdatekernelsh} shows how the unified kernel is created with the command \texttt{objcopy} and copied on the EFI disk partition.
The offset addresses need to be chosen according to the size of the included blobs.
All steps described above are summarized in \autoref{code:tbinstallsh}.

\lstinputlisting[float,language=bash, caption={\texttt{update-kernel.sh}: Script for updating the unified Kernel}, label={code:tbupdatekernelsh}]{../../trustedboot/update-kernel.sh}
\lstinputlisting[float,language=bash, caption={\texttt{create-luks-tpm.sh}: Script to create a new LUKS key}, label={code:tbcreatelukssh}]{../../trustedboot/create-luks-tpm.sh}
\lstinputlisting[float,language=bash, caption={\texttt{install.sh}: Script to install Trusted Boot on Ubuntu}, label={code:tbinstallsh}]{../../trustedboot/install.sh}

When the unified kernel is installed, the system needs to be rebooted to generate the PCR values for the new boot chain.
The FDE decryption with the TPM will of course fail, since there is no sealed passphrase available yet.
This step is done now since the new unified kernel is measured the first time.
\autoref{code:tbupdatetpmsh} shows how the passphrase is sealed into the TPM with all relevant PCR registers.
\lstinputlisting[float,language=bash, caption={\texttt{update-luks-tpm.sh}: Script for updating the Sealing of the TPM Object with new PCR values},label={code:tbupdatetpmsh}]{../../trustedboot/update-luks-tpm.sh}
The result is a trusted boot chain which ensures, that the system only has access to the encrypted disk when the kernel with its parameter is known---and therefore trusted.

This implementation also supports updating the linux kernel.
The required steps for keeping trusted boot intact are as follows:
\begin{enumerate}
  \item \emph{System upgrade}: The system can be upgraded with the package tool of choice.
  \item \emph{Updating unified kernel}: The EFI blob needs to be upgraded since a new kernel is installed by executing the script of \autoref{code:tbupdatekernelsh}.
  \item \emph{Reboot}: The system needs to be rebooted to generate the new PCR values. The existing boot chain is, of course, broken and the optional FDE password need to be entered maually.
  \item \emph{Update TPM}: The sealing of the LUKS password can be renewed with the new PCR values.
  Since the existing seal cannot be opened anymore, the password must be available in clear text.
  This step is done by the script in \autoref{code:tbupdatetpmsh}.
\end{enumerate}

\section{Integrity Measurement Architecture}
The result of trusted boot is a measured and therefore trusted kernel with its command line parameters and modules.
IMA extends this trust to the file system as described in \autoref{sec:integrity_measurement_architecture}.
All features of IMA are already implemented in the kernel sources and do not need additional packages.
The Gentoo wiki page about IMA\cite{gentoo19} describe which kernel compiler flags are related to IMA:
\begin{lstlisting}[float,language=bash,caption={Kernel compiler flags to enable IMA},label={code:kernelflags}]
  CONFIG_INTEGRITY=y
  CONFIG_IMA=y
  CONFIG_IMA_MEASURE_PCR_IDX=10
  CONFIG_IMA_LSM_RULES=y
  CONFIG_INTEGRITY_SIGNATURE=y
  CONFIG_IMA_APPRAISE=y
  IMA_APPRAISE_BOOTPARAM=y
\end{lstlisting}

According to their blog, Redhat\footnote{\url{https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture}, last visited on 9.7.2021} supports IMA since Enterprise Linux 8 and so would the Redhat clones like CentOS.
Ubuntu enabled the required kernel compile flags by default on version 20.04 in the ubuntu kernel repository\footnote{\url{https://kernel.ubuntu.com/git/kernel-ppa/mirror/ubuntu-5.4-focal.git/tree/security/integrity/ima/Kconfig}, last visited on 9.7.2021}.
However, we found no official information on when IMA was introduced or whether IMA support will continue in future releases.

Every kernel supporting IMA creates a virtual file at \texttt{/sys/kernel/security/ima/ascii\_runtime\_measurements}.
When IMA is disabled, which is the default, this file has only one entry representing the boot aggregate.
By enabling IMA via kernel command line parameters, this file gets filled according to the policies defined.
The first four parameters used in \autoref{code:tbkernelcommandlinetxt} define the behavior of IMA and how the measurement log should look like.


%TODO Edit pointer

Similar to trusted boot, Ubuntu requires two installed packages to support the features discussed in this section:
\begin{itemize}
  \item \texttt{auditd} to analyze system calls of processes, helpful when using IMA, and
  \item \texttt{attr} for showing the file IMA hashes, which are saved as extended file attributes.
\end{itemize}

IMA-Settings erklären.
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.