\caption{Overview of the Digidow authentication process}
\caption{Overview of the Digidow network with its interactions}
\label{fig:globalview}
\label{fig:digidow-overview}
\end{figure}
\end{figure}
The picture in \autoref{fig:digidow-overview} provides an overview of the authentication process
The picture in \autoref{fig:globalview} provides an overview of the authentication process within
within Digidow.
Digidow.
At the time of this writing, the exact order and definition of every step is not yet finished and may change during the progress of the whole project.
At the time of this writing, the exact order and definition of every step is not yet finished and may change during the progress of the whole project.
DigiDow introduces three main parties which are involved in a common authentication process.
DigiDow introduces three main parties which are involved in a common authentication process.
\begin{itemize}
\begin{itemize}
@ -180,8 +179,8 @@ The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standar
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO
This standard is still in development; a draft version from February 2018 is published on the FIDO
@ -38,7 +38,8 @@ giving the manufacturer the possibility to update their TPMs in the field.
fTPMs will be updated with the platform updates of the CPU manufacturers.
fTPMs will be updated with the platform updates of the CPU manufacturers.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it returns 23 entries\footnote{\url{https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tpm}, last accessed on 15.05.2021}.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it
returns 23 entries\cite{mitre18}.
Eight of them were filed before the new standard has been released.
Eight of them were filed before the new standard has been released.
Another seven entries refer to vulnerabilities in custom TPM implementations.
Another seven entries refer to vulnerabilities in custom TPM implementations.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM
Six entries refer to the interaction between the TPM and the operating system, especially the TPM
@ -266,8 +267,7 @@ IMA is officialy supported by RedHat and Ubuntu and there exists documentation t
Other OS providers may not use a kernel with the required compile flags and/or do not provide
Other OS providers may not use a kernel with the required compile flags and/or do not provide
userland software required to manage IMA.
userland software required to manage IMA.
The IMA project page describes the required kernel features for full support in their
The IMA project page describes the required kernel features for full support in their
@ -101,43 +101,54 @@ We will instead focus on the integrity of the system when the BS is operating.
\label{sub:integrity_and_trust_up_to_the_kernel}
\label{sub:integrity_and_trust_up_to_the_kernel}
We decided to use the PC platform as hardware base for the prototype.
We decided to use the PC platform as hardware base for the prototype.
There are lots of different form factors available you can extend the system with a broad variety of sensors.
There are lots of different form factors available and you can extend the system with a broad
Furthermore the TPM support is implemented to support integrity analysis on the system.
variety of sensors.
Furthermore, the platform provides full TPM support to enable cryptographic and integrity features.
Finally, the platform can run almost all Linux variants and supports relevant pieces of software for this project.
Finally, the platform can run almost all Linux variants and supports relevant pieces of software for this project.
A flavour of Linux supporting all features described in this chapter, will be used as OS platform.
A flavour of Linux supporting all features described in this chapter, will be used as OS platform.
The ARM platform seem to be capable of all these features as well, however, the support of TPM, the amount of available software and the ease of installation is better on the PC platform.
The ARM platform seem to be capable of all these features as well.
However, the support for TPMs, the amount of available software and the ease of installation is
As described in \autoref{sec:trusted_platform_module_tpm_}, the TPM functions can be delivered in three different flavors: As dedicated or mounted device and as part of the processor's firmware.
better on the PC platform.
The fTPM is part of a large proprietary environment from AMD or Intel which which introduces, besides implementation flaws, additional attack surfaces for the TPM.
Hence we will use dedicated TPM chips on the platform, which are pluggable, to gain most control over the functionality.
As described in \autoref{sec:trusted_platform_module_tpm_}, the TPM functions can be delivered in
three different flavors: As dedicated or mounted device and as part of the platform firmware.
Any recent PC platform supports TPMs ans consequently Trusted Boot as mentioned in \autoref{sec:trusted_boot}.
The fTPM is part of larger proprietary environments from AMD and Intel which introduces, besides
The system will describe its hardware state in the PCRs 0\,--\,7 when the EFI\,/\,BIOS hands over to the Bootloader.
implementation flaws, additional attack surfaces for the TPM.
Hence, we will use plugged TPM chips on the platform.
Then we are able to deactivate the TPM for demonstration purposes by simply unplugging it.
Any recent PC platform supports TPMs and consequently trusted boot as mentioned in
\autoref{sec:trusted_boot}.
The system will describe its hardware state in the PCRs 0\,--\,7 when the EFI/BIOS hands over to
the bootloader.
We use these PCR values to detect any unauthorized modifications on hardware or firmware level.
We use these PCR values to detect any unauthorized modifications on hardware or firmware level.
It is important to include also \emph{epmty} PCRs to detect added hardware on the PCI bus with an Option ROM, for example.
It is important to also include \emph{epmty} PCRs to detect added hardware on the PCI bus with an
Option ROM, for example.
With these PCR values we can seal a passphrase in the TPM.
With these PCR values we can seal a passphrase in the TPM.
The disk, secured with Full Disk Encryption (FDE), can only be accessed, when the hardware underneath is not tampered with.
The disk, secured with Full Disk Encryption (FDE), can only be accessed when the hardware
underneath is not tampered with.
To further reduce the attack surface, the prototype will not use a bootloader like GRUB.
To further reduce the attack surface, the prototype will not use a bootloader like GRUB.
Instead, the kernel should be run directly from the UEFI\,/\,BIOS.
Instead, the kernel is run directly from the UEFI/BIOS.
Therefore, the kernel is packed directly into an EFI file, together with its command line
Therefore, the kernel is packed directly into an EFI file, together with its command line
parameters and the initial file system for booting.
parameters and the initial file system for booting.
This \emph{Unified Kernel} is directly measured by the UEFI\,/\,BIOS and is also capable of decrypting the disk, given the correct PCR values.
This \emph{Unified Kernel} is directly measured by the UEFI/BIOS and is also capable of decrypting
the disk, given the correct PCR values.
This setup starts with two sources of trust that are formally defined:
This setup starts with two sources of trust that are formally defined:
\begin{itemize}
\begin{itemize}
\item\emph{TPM}: The TPM acts as certified Root of Trust for holding the PCRs and for the cryptographic function modifying those.
\item\emph{TPM}: The TPM acts as certified Root of Trust for holding the PCRs and for the cryptographic function modifying those.
\item\emph{RTM}: The Root of Trust for Measurement is part of the mainboard's firmware.
\item\emph{RTM}: The Root of Trust for Measurement is part of the mainboard firmware.
The tiny program just measures all parts of the firmware and feeds the TPM with the results.
The tiny program just measures all parts of the firmware and feeds the TPM with the results.
However, the program is maintained by the mainboard manufacturer and the source is not available to the public.
However, the program is maintained by the mainboard manufacturer and the source is not available to the public.
We have to trust that this piece of software is working correctly,
We have to trust that this piece of software is working correctly.
\end{itemize}
\end{itemize}
We implicitly assume that the CPU, executing all these instructions and interacting with the TPM, is working correctly.
We implicitly assume that the CPU, executing all these instructions and interacting with the TPM, is working correctly.
All parts contributing to the boot phase will be measured into one of the PCRs before any instruction is executed.
All parts contributing to the boot phase will be measured into one of the PCRs before any instruction is executed.
Decrypting the disk can then be interpreted as authorization procedure against the encrypted disk.
Decrypting the disk can then be interpreted as authorization procedure against the encrypted disk.
Consequently only a \emph{known} kernel with a \emph{known} hardware and firmware setup underneath
Consequently, only a \emph{known} kernel with a \emph{known} hardware and firmware setup underneath
can access the disk and finish the boot process in the OS.
can access the disk and finish the boot process in the OS.
The disk encryption is, however, only an optional feature which can be omitted in a production
The disk encryption is, however, only an optional feature which can be omitted in a production
@ -151,15 +162,18 @@ The system needs to check its integrity on the OS level and summarize that by pu
\label{fig:measuements}
\label{fig:measuements}
\end{figure}
\end{figure}
\autoref{fig:measuements} illustrates how above proceses extend the trust on the system.
\autoref{fig:measuements} illustrates how above processes extend the trust on the system.
The TPM is the cryptographic root of trust, storing all measurement results and the target values for validation.
The TPM is the cryptographic root of trust, storing all measurement results and the target values for validation.
SInce the RTM is the only piece of code, which lives in the platform firmware and is executed \emph{before} it is measured, it is an important part in the trust architecture of the system.
Since the RTM is the only piece of code which lives in the platform firmware and is executed
\emph{before} it is measured, it is an important part in the trust architecture of the system.
An honest RTM will measure the binary representation of itself, which makes the code at least provable afterwards.
An honest RTM will measure the binary representation of itself, which makes the code at least provable afterwards.
Finally, the CPU is assumed to execute all the code according to its specification.
Finally, the CPU is assumed to execute all the code according to its specification.
Proving correctness of the instruction set cannot be done during the boot process.
Proving correctness of the instruction set cannot be done during the boot process.
When the roots of trust are honest, the trusted environment can be constructed during booting the platform with the PCR measurements.
When the roots of trust are honest, the trusted environment can be constructed during booting the
We get then a system, where all active parts in the booting process are trusted up to the Linux kernel with its extensions and execution parameters.
platform with the PCR measurements.
We get a trusted boot chain from firmware up to the kernel with its extensions and execution
parameters as a result.
\subsection{Integrity and Trust on OS Level}%
\subsection{Integrity and Trust on OS Level}%
\label{sub:integrity_and_trust_on_os_level}
\label{sub:integrity_and_trust_on_os_level}
@ -167,7 +181,8 @@ We get then a system, where all active parts in the booting process are trusted
With the trusted kernel and IMA, we can include the file system into the trusted environment.
With the trusted kernel and IMA, we can include the file system into the trusted environment.
According to \autoref{sec:integrity_measurement_architecture}, every file will be hashed once IMA is activated and configured accordingly.
According to \autoref{sec:integrity_measurement_architecture}, every file will be hashed once IMA is activated and configured accordingly.
By enforcing IMA, the kernel allows access to only those files having a valid hash.
By enforcing IMA, the kernel allows access to only those files having a valid hash.
Consequently, every file which is required for proper execution needs to be hashed beforehand before IMA is enforced.
Consequently, every file which is required for proper execution needs to be hashed beforehand, i.e.
before IMA is enforced.
The IMA policy in place should be \texttt{appraise\_tcb}, to analyze kernel modules, executable memory mapped files, executables and all files opened by root for read.
The IMA policy in place should be \texttt{appraise\_tcb}, to analyze kernel modules, executable memory mapped files, executables and all files opened by root for read.
This policy should also include drivers and kernel modules for external hardware like a camera for attached via USB.
This policy should also include drivers and kernel modules for external hardware like a camera for attached via USB.
@ -186,25 +201,30 @@ To reduce the complexity of this problem, we consider two assumptions:
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
\end{enumerate}
\end{enumerate}
The DAA protocol should be applied on a simple LAN, where all parties are connected locally.
For the scope of this thesis, the DAA protocol should be applied on a simple LAN, where all parties
The BS will eventually become a member of the Group of sensors, managed by the Issuer.
are connected locally.
During signup, Issuer and BS (Member) negotiate the membership credentials over the network.
The BS will eventually become a member of the group of sensors managed by the issuer.
By being a member of the DAA group, the Issuer fully trusts that the BS is honest and acting according the specification.
During signup, issuer and BS (member) negotiate the membership credentials over the network.
The Issuer will not check any group members, since they can now act independently of the Issuer.
By being a member of the DAA group, the issuer fully trusts that the BS is honest and acting
according the specification.
The issuer will not check any group members, since they can now act independently of the issuer.
When the BS is then authenticating an individual, the process illustrated in \autoref{fig:daa-attestation} will be executed.
When the BS is then authenticating an individual, the process illustrated in \autoref{fig:daa-attestation} will be executed.
\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may trust the Biometric Sensor afterwards.}
\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may
trust the BS afterwards.}
\label{fig:daa-attestation}
\label{fig:daa-attestation}
\end{figure}
\end{figure}
\begin{enumerate}
\begin{enumerate}
\item The PIA gets once and independently of any transaction the public key of the BS group.
\item The PIA gets the public key of the BS group once and independently of any transaction.
\item During the transaction, the PIA will eventually ask the BS for attestation together with a \texttt{nonce}.
\item During the transaction, the PIA will eventually ask the BS for attestation together with a \texttt{nonce}.
\item The BS will collect the PCR values, the Integrity Log and the \texttt{nonce} into an Attestation message signed with the Member SK.
\item The BS will collect the PCR values, the integrity log and the \texttt{nonce} into an
\item The Attestation Message will be sent back to the PIA.
Attestation message signed with the member's secret key (SK).
\item The PIA checks the signature of the message, checks the entries of the Integrity log against known values, and proves the PCR values accordingly.
\item The attestation message will be sent back to the PIA.
\item The PIA checks the signature of the message, checks the entries of the integrity log
against known values, and proves the PCR values accordingly.
\end{enumerate}
\end{enumerate}
\autoref{fig:chainoftrust} shows how the sources of trust will be represented in the final attestation message.
\autoref{fig:chainoftrust} shows how the sources of trust will be represented in the final attestation message.
@ -217,24 +237,29 @@ When the BS is then authenticating an individual, the process illustrated in \au
The four sources of trust are defined as groups which deliver parts of the prototype, but cannot be verified on a cryptographic level.
The four sources of trust are defined as groups which deliver parts of the prototype, but cannot be verified on a cryptographic level.
Hence, suppliers must be manually added to these groups by using a well defined check for trustworthiness.
Hence, suppliers must be manually added to these groups by using a well defined check for trustworthiness.
Any TPM manufacturer has to implement the well defined standard from TCG.
Any TPM manufacturer has to implement the well defined standard from TCG.
There exists, however no such exact definition for hardware and firmware parts of the platform.
There exists, however, no such exact definition for hardware and firmware parts of the platform.
Consequently, these parts should undergo a functional analysis before they are trusted.
Consequently, these parts should undergo a functional analysis before they are trusted.
Trust means that, when the platform is defined trustworthy, the corresponding PCR values should be published.
Trust means that, when the platform is defined trustworthy, the corresponding PCR values should be published.
The same procedure should be done for the kernel and the used OS environment and of course the used
The same procedure should be done for the kernel and the used OS environment and of course, the used
software.
software.
There, only the kernel with its parameters have a corresponding PCR value.
There, only the kernel with its parameters have a corresponding PCR value.
Furthermore a hash value should be published for any relevant file on the file system.
Furthermore, a hash value should be published for any relevant file on the file system.
We can then build a cryptographic representation of the chain of trust in \autoref{fig:chainoftrust}.
We can then build a cryptographic representation of the chain of trust in \autoref{fig:chainoftrust}.
The TPM has a signed Certificate from ist manufacturer, where it derives the Endorsement Key (EK) from it.
The TPM has a signed certificate from its manufacturer, where it derives the endorsement key (EK)
When all of the above checks against platform, OS and TPM are good, the DAA Issuer will assign the platform to the group of trusted BS.
from.
When all of the above checks against platform, OS and TPM are good, the DAA issuer will assign the
platform to the group of trusted BS.
The BS has now a member SK for signing its attestation message.
The BS has now a member SK for signing its attestation message.
The Verifier can now check the valid membership by checking the signature of the message against the Issuer's PK.
The verifier can now check the valid membership by checking the signature of the message against
Furthermore it can check the state of the platform by compare the PCR values against known values.
the issuer's public key (PK).
Finally it can check the integrity of the running software by checking the hashes in the IMA log against known values.
Furthermore, it can check the state of the platform by comparing the PCR values against known
PCR 10 represents therefore the end of the hash chain fed by the IMA log entries.
values.
Finally, it can check the integrity of the running software by checking the hashes in the IMA log
against known values.
PCR 10 represents the end of the hash chain fed by the IMA log entries.
If all values are good, the BS can be trusted and the Digidow transaction can be continued at the
If all values are good, the BS can be trusted and the Digidow transaction can be continued at the
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.
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.
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.
\caption[Prototype schematic]{Prototype setup to show DAA features and the Dataflow from BS to PIA}
\caption[Prototype schematic]{Prototype setup to show DAA features and the Dataflow from BS to PIA}
@ -11,13 +11,15 @@ Although the goal is to put all these features on a highly integrated system, we
\end{figure}
\end{figure}
\autoref{fig:prototype} shows the setup on a connection level.
\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.
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.
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.
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.
Hence, Service Discovery is done statically, every host knows the IP addresses and functions of each other directly.
\section{Hardware Setup}
\section{Hardware Setup}
For demonstrating remote attestation via DAA over a simple network infrastructure, we use 3 systems with similar configuration.
For demonstrating remote attestation via DAA over a simple network infrastructure, we use three
\autoref{tab:systems} show the specification of these systems.
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.
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.
All features used in this thesis were available on both platform types, so there were no differences found.
@ -47,14 +49,16 @@ All other modules are however electrical compatible since only unused pins of th
With a wiring adapter any TPM board would work on any mainboard supporting TPM2.0 even when coming with a prorietary header.
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}
\section{Operating System}
The Operating System need to fulfill three requirements for this prototype.
The OS needs to fulfill three requirements for this prototype.
First, the TPM must be supported by the kernel.
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.
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}.
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
Finally, the support for the Integrity Measurement Architecture (IMA) must be activated in the
kernel and supported by the OS.
kernel and supported by the OS.
This feature is available in the mainline Linux kernel, however, the according kernel compile
This feature is available in the mainline Linux kernel.
parameters must be set.
However, the corresponding kernel compile parameters must be set.
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).
Ubuntu is also supported by the Xaptum ECDAA project, although it was tested with an older version (18.04).
@ -86,23 +90,29 @@ Ubuntu installs Grub by default, and it is used as a fallback bootloader.
\section{Trusted Boot}
\section{Trusted Boot}
By default, every Mainboard with support for TPM2.0 must support 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).
When a TPM becomes available, the UEFI/BIOS itself takes all required measures until the boot
Since Ubuntu uses Grub 2.04 as bootloader, Trusted Boot is directly supported and needs just to be enabled in the configuration.
process is handed over to the OS bootloader (e.g. GRUB).
In this case, Grub will be measured from the BIOS to the PCRs 4 and 5, as shown in \ref{tab:PCR}.
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
Grub itself uses PCR 8 for executed commands, the kernel command line and all commands forwarded to
kernel modules.
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)}.
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.
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.
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.
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.
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 large EFI file contains the initramfs, kernel command line and the kernel itself.
This EFI file replaces that from Grub in the EFI boot partition.
\autoref{tab:efilayout} shows the content of the EFI blob with the corresponding offset addresses
\autoref{code:tbcommandlinetxt} shows the used command line which will be saved on \texttt{/boot/kernel-command-line.txt}
as well as the sources in the file system.
The parameters activate also IMA which is discussed later in this chapter.
\begin{table}
\begin{table}
\centering
\centering
\begin{footnotesize}
\begin{footnotesize}
@ -121,22 +131,61 @@ The parameters activate also IMA which is discussed later in this chapter.
\caption{Memory layout of the Unified Kernel EFI file}
\caption{Memory layout of the Unified Kernel EFI file}
\label{tab:efilayout}
\label{tab:efilayout}
\end{table}
\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
All binary resources are available as blobs which can be imported directly.
command line parameters and the initial file system which is held in RAM during boot.
Only the command line parameters need to be defined manually.
The memory layout of the EFI blob is shown in \autoref{tab:efilayout}
\autoref{code:tbcommandlinetxt} shows the used command line which will be saved on
With this Unified Kernel in place, no additional PCRs are used and everything is measured by the BIOS.
\texttt{/boot/kernel-command-line.txt}.
% 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.
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},
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.
If FDE is installed, the boot process need to be aware of how to decrypt the disk.
This key is saved in the TPM and sealed with the values of PCR 0--7.
Therefore, the initramfs needs the luks binaries as well as the TPM software stack to unseal the
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.
passhrase with the PCR registers.
The \emph{trusted} environment is now extended to the kernel and the modules loaded at boot.
The unseal operation itself is then done with \autoref{code:tbpassphrasesh}, which also needs to
exist in the initramfs.
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.
\lstinputlisting[float,language=bash, caption={\texttt{passphrase-from-tpm.sh}: Initramfs-script to
\autoref{code:tbinstallsh} is the main script installing disk decryption via TPM.
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.
\chapter[Appendix]{Sealing LUKS encryption key with PCRs in a TPM}
%\chapter[Appendix]{Sealing LUKS encryption key with PCRs in a TPM}
\label{adx:luks}
%\label{adx:luks}
\lstinputlisting[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{update-luks-tpm.sh}: Script for updating
\lstinputlisting[caption={\texttt{kernel-command-line.txt}: Command line for the Kernel}, label={code:tbcommandlinetxt}]{../../trustedboot/kernel-command-line.txt}
\lstinputlisting[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}
\lstinputlisting[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}
\lstinputlisting[language=bash, caption={\texttt{update-kernel.sh}: Script for updating the unified Kernel}, label={code:tbupdatekernelsh}]{../../trustedboot/update-kernel.sh}
\lstinputlisting[language=bash, caption={\texttt{install.sh}: Script to install Trusted Boot on Ubuntu}, label={code:tbinstallsh}]{../../trustedboot/install.sh}
%\chapter{TCP/IP Wrapper for the Xaptum ECDAA Protocol}
%\chapter{TCP/IP Wrapper for the Xaptum ECDAA Protocol}
%\section{Common source files for all DAA parties}
%\section{Common source files for all DAA parties}
