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}
	\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:tbcommandlinetxt} define the behavior of IMA and how the measurement log should look like.
\begin{itemize}
  \item \texttt{ima\_appraise=fix} appends the filehash as an extended file attribute for every accessed file.
  \item \texttt{ima\_policy=appraise\_tcb, ima\_policy=tcb} analyzes resources owned by root and opened for execution.
  \item \texttt{ima\_hash=sha256} sets the hashing algorithm.
  \item \texttt{rootflags=i\_version} must be enabled when mounting the filesystem since IMA is checking that number before re-hashing the resource.
\end{itemize}

Unfoortunately, the resulting IMA log is between 2000 and 3000 lines long when the system is freshly booted.
The log can blow up to several 10000 entries when uptime exceeds several days.
However, a thrid party can comprehend the state of the attesting system, when parsing the IMA log.
Together with the corresponding PCR value, where the hashes of all entries are chained the TPM can \texttt{certify} correctness of the log.


\section{Interaction with TPM2}
\subsection{Prove Certificate Chain}
Every TPM has a corresponding certificate which is part of a certificate chain maintained by the TPM manufacturer.
In our case, Infineon certifies its TPM with a number of intermediate CAs which itself are certified with Infineon's root CA.
The TPM certificate is available for RSA and ECC cryptofamilies respectively.
Since the verification workflow is the same on all machines and for both cryptofamilies, we demonstrate on system 1 how the process works.
Note that this works for Infineon TPMs.
Other Vendors like STM, AMD or Intel may provide certificates via download of their website.
\begin{enumerate}
  \item Read the certificate from the TPM NVRAM.
  The RSA certificate is located at address \texttt{0x1c00002}, that for ECC on address \texttt{0x1c0000a}:
  \begin{lstlisting}[numbers=none]
    root@amd1:~# tpm2_nvread -C o 0x1c0000a -o amd1_ecc.crt
  \end{lstlisting}
  \item Download the certificates from the intermediate and root CA from infineon's website:
  \begin{lstlisting}[numbers=none]
    root@amd1:~# wget https://www.infineon.com/dgdl/Infineon-TPM_ECC_Root_CA-C-v01_00-EN.cer?fileId=5546d46253f65057015404843f751cdc -O infineon_ecc_root_ca.crt #Infineon root CA
    root@amd1:~# wget https://www.infineon.com/dgdl/Infineon-OPTIGA-ECC-Manufacturing-CA_036-Issued_by_RootCA.crt-C-v01_00-EN.crt?fileId=5546d46262475fbe0162486417b73cbe -O infineon_ecc_intermediate_ca_036.crt #Infineon intermediate CA
  \end{lstlisting}
  \item Convert all certificates into PEM format. OpenSSL can only verify a chain in PEM format.
  \begin{lstlisting}[numbers=none]
    root@amd1:~# openssl x509 -inform DER -outform PEM -in infineon_ecc_root_ca.crt -out infineon_ecc_root_ca.pem
    root@amd1:~# openssl x509 -inform DER -outform PEM -in infineon_ecc_intermediate_ca_036.crt -out infineon_ecc_intermediate_ca_036.pem
    root@amd1:~# openssl x509 -inform DER -outform PEM -in amd1_ecc.crt -out amd1_ecc.pem
  \end{lstlisting}
  \item Check the certificate chain with OpenSSL.
  The option \texttt{-untrusted} is required since the provided root CA is not in the OS' trust store and hence of unknown trust.
   \begin{lstlisting}[numbers=none]
     root@amd1:~# openssl verify -verbose -CAfile infineon_ecc_root_ca.pem -untrusted infineon_ecc_intermediate_ca_036.pem amd1_ecc.pem
     amd1_ecc.pem: OK
   \end{lstlisting}
\end{enumerate}
When OpenSSL returns \texttt{OK}, the certificate chain is intact and the TPM is indeed one from Infineon.
To be correct: The website, probably hosted by infineon, provides a certificate chain which matches and the links to the corresponding parent certificate is correct.
Unfortunately, Infineon do neither provide any website certification nor any checksums of the provided certificates.
So, if the above described check fails, no source of trust can ensure that the root certificate is correct.

We found, that both, ECC and RSA chains of all TPMs are intact.
For documentation reasons, we provide the OpenSSL SHA256 checksums of all used certificates in \autoref{tab:certchksum}.
These chaecksums were generated with:
\begin{lstlisting}[numbers=none]
  openssl x509 -noout -fingerprint -sha256 -inform pem -in amd1_ecc.pem
\end{lstlisting}

\begin{table}
  \renewcommand{\arraystretch}{1.2}
  \centering
  \caption{ECC certificate chain of used TPMs} \label{tab:certchksum}
  %\rowcolors{2}{lightgray}{white}
  \begin{tabular}{rp{9.9cm}}
    \toprule
    \textit{Certificate}&\textit{SHA256 checksum} \\
    \midrule
    \textbf{ECC root CA}	&\texttt{CF:EB:02:FE:CD:55:AD:7A:73:C6:E1:D1:19:85:D4:C4: 7D:EE:24:8A:B6:3D:CB:66:09:1A:24:89:66:04:43:C3}\\
    \textbf{ECC intermediate CA 036}	&\texttt{2C:BF:6D:6C:39:94:47:0A:EC:D2:B1:F8:7F:5D:21:11: 08:D1:E0:A4:A8:1E:D9:CB:A2:6B:D2:98:96:5D:E0:1C}\\
    \textbf{ECC intermediate CA 011}	&\texttt{B5:59:A8:4E:63:32:A7:B4:E3:2B:4D:37:39:E3:72:E3: C5:17:BA:5A:4C:CF:FE:E1:DA:AF:80:BC:64:16:28:EE}\\
    \textbf{ECC System 1 TPM}	&\texttt{D8:C3:21:3E:BB:C2:CB:96:EA:14:2F:D5:57:61:79:04: BB:DE:8A:F9:21:2A:11:7D:4B:2E:FC:64:BD:35:C1:6E}\\
    \textbf{ECC System 2 TPM}	&\texttt{FE:1B:EF:42:8B:68:35:D3:FC:5A:13:A0:AE:12:19:BA: A1:60:D6:59:38:1D:79:8E:76:50:48:BE:5C:BD:83:A5}\\
    \textbf{ECC System 3 TPM}	&\texttt{92:29:68:6D:50:EE:34:08:30:DF:E7:30:D8:F3:C0:C7: 13:3C:DF:F0:6D:9E:2B:2E:0F:54:76:AE:B8:D6:1A:DA}\\
    \textbf{RSA root CA}	&\texttt{89:9E:35:47:4C:98:07:EB:4C:7F:2F:7A:12:DA:00:28: FB:25:0C:D0:21:54:D0:00:9F:CA:7D:9C:66:57:4F:3B}\\
    \textbf{RSA intermediate CA 036}	&\texttt{21:6C:47:D2:77:FC:40:CE:90:F0:86:83:21:CB:5E:F5: 91:FC:1D:D8:D0:E4:FD:A1:A2:C8:3C:17:BE:01:B0:7E}\\
    \textbf{RSA intermediate CA 011}	&\texttt{A8:33:79:F9:2A:34:1B:EB:61:B6:7F:03:50:66:44:94: 0F:EB:4B:85:EA:50:4A:9D:22:13:BC:A5:2C:88:9F:89}\\
    \textbf{RSA System 1 TPM}	&\texttt{F1:C7:6A:00:CF:2B:63:4D:38:C0:2E:73:3C:84:BF:30: 5C:C2:D3:61:DF:34:D8:95:BB:F1:0F:FB:6B:0C:79:E2}\\
    \textbf{RSA System 2 TPM}	&\texttt{CB:1F:7D:20:FE:B2:11:C4:2B:20:6B:4F:66:A6:14:1A: 37:94:5F:85:93:6D:2E:92:85:57:BF:3A:BF:9E:DA:DD}\\
    \textbf{RSA System 3 TPM}	&\texttt{BF:0B:4E:77:80:18:86:9A:EF:09:06:96:E2:4D:72:A3: 47:B6:E3:8F:AA:F9:9C:2E:C0:13:AB:70:E3:E4:5D:93}\\
    \bottomrule
  \end{tabular}
\end{table}



%TODO Edit pointer
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.

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}
How can camera and fingerprint sensor be trusted?
What is the limitation of this solution?



\section{Using the DAA Protocol}
Direct anonymous attestation is a group signature scheme which uses the TPM as cryptoprocessor and key store.
The feature of identifiable instances of sensors is not required when interacting with the Digidow network.
Only the \emph{trusted} state of the sensor system and the membership in the corresponding group is relevant.
Hence, the group membership is an essential part to provide trust to the users, requiring a deep knowledge on what hardware and software is installed and which vulnerabilities it might have.

The DAA group membership states that the system is provisioned from a trusted party, namely the DAA issuer.
The level of trust is ultimative since the used version of DAA is only partly dynamic by lacking support of membership removal.
During a Digidow transaction, the sensor attests its state by signing a message containing the IMA log and the PCR registers.
Any party interacting with the sensor is then able to check trustworthiness via integrity and valid membership of the sensor.

We describe in the following which programs need to be installed and what configuration is required to demonstrate a working implementation of DAA.

\subsection{Provision Hosts of Test Setup}
The demonstration setup, shown in \autoref{fig:prototype} consists of three independent hosts which are connected together via TCP/IP.
Every host represent one party in the DAA scheme, each requiring additional software to support the DAA protocol over TCP/IP.
Xaptums ECDAA library need to be installed on all three hosts.
However, the hosts representing issuer and verifier do not require TPM support.
Similar to that, the ECDAA network wrapper has to be installed on every host.

The member needs, besides DAA protocol support, software to capture and process the image of the USB webcam.
We use a small program called \texttt{sensor-capture} for capturing a face image from a webcam.
For biometric processing, we transform the image into an embedding.
This is done with the face recognition prototype of Digidow\footnote{\url{https://git.ins.jku.at/proj/digidow/prototype-facerecognition}}.

\subsubsection{Installing Xaptum ECDAA Library}


\begin{itemize}
  \item \emph{DAA issuer}: The issuer needs the Xaptum ecdaa library and the ecdaa network wrapper which is provided with
\end{itemize}


DAA Project from Xaptum: Working DAA handshake and possible TPM integration.
Requires an Attestation Key which is secured with a password policy.