The concept decscribed in \autoref{cha:concept} will be implemented as a prototype.
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]
@ -13,8 +13,13 @@ Although the goal is to put all these features on a highly integrated system, we
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}
@ -33,10 +38,6 @@ To keep the setup minimal, the IP addresses are static and Internet is only requ
\bottomrule
\end{tabular}
\end{table}
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.
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}.
@ -53,9 +54,10 @@ Similarly, the \texttt{tpm2-tools} must be available in a version newer than \te
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.
The most recent version of Ubuntu 20.04 LTS does fulfill above mentioned requirements by default.
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
@ -72,6 +74,8 @@ When installing Ubuntu on the prototype, we used \emph{Full Disk Encryption} (FD
\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.
@ -80,14 +84,16 @@ When installing Ubuntu on the prototype, we used \emph{Full Disk Encryption} (FD
\section{Trusted Boot}
By default, every Mainboard with support for TPM2.0 supports also 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)}.
There is however a more efficient way of booting for embedded systems since there is often only one bootable Kernel in place and the device has to boot autonomously.
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.
@ -112,20 +118,29 @@ The parameters activate also IMA which is discussed later in this chapter.
\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 and parameters and the initial ramdisk.
The memory layout is shown in \ref{tab:efilayout}
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.
%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.
So, when the BIOS hands over the system to the bootloader, all PCR values are already set.
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
