\ToDo{TPM beschreiben und chain of trust herleiten, }
In this Chapter we describe three main concepts which contribute the fundamentals for this thesis.
\emph{Trusted Boot} and the \emph{Integrity Measurement Architecture} (IMA) are two approaches to generate trust on a system from the hardware level up to the Operating System.
@ -13,6 +14,9 @@ During these early steps, the hardware components of the platform are initialize
This is controlled by either the BIOS (for legacy platforms) or the UEFI firmware.
In this common boot procedure exists no source of trust and hence no check for integrity or intended execution.
\subsection{Platform Configuration Register}%
\label{sub:platform_configuration_register}
The \emph{Trusted Computing Group} (TCG) introduced in 2004 their first standard for a new {Trusted Computing Module} (TPM).
As part in this standard, TCG defined a procedure, where every step in the early boot process is measured and saved in a \emph{Platform Configuration Register} (PCR).
\emph{Measuring} means in this context a simple cryptographic extension function which works described in formula \ref{form:PCR-measurement}
@ -20,7 +24,7 @@ As part in this standard, TCG defined a procedure, where every step in the early
The function of || represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256 hash.
The function of $||$ represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256 hash.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
Consequently, both hash results are available for further computations.
@ -32,16 +36,18 @@ The procedure of measurements is available since the first public standard of TP
For the recent TPM2.0 standard, the process was only extended with the support for the newer SHA256 standard.
A PCR is now useful for a sequence of measurements with similar purpose.
When, for example, a new bootloader is installed on the main disk, we want to detect this with a separate PCR value.
When, for example, a new bootloader is installed on the main disk, the user wants to detect this with a separate PCR value.
The measured firmware BLOBs may be still the same.
So the TPM standard defines 24 PCRs for the PC platform.
So the TPM standard defines 24 PCRs for the PC platform, each with a special role and slightly different feature set.
The purpose of every PCR is well defined in Section 2.3.3 of the \emph{TCG PC Client Platform Firmware Profile}\cite{tcg-pc19} and shown in table \ref{tab:PCR}.
Especially those PCRs involved in the boot process must only be reset according to a platform reset.
During booting and running the system these registers can only be \emph{extended} with new measurements.
\begin{table}[ht]
\centering
\begin{sffamily}
\caption{Usage of PCRs during an UEFI trusted boot process}\label{tab:PCR}
@ -56,9 +62,10 @@ The purpose of every PCR is well defined in Section 2.3.3 of the \emph{TCG PC Cl
7 & Secure Boot Policy \\
8-15 & Defined for use by the static OS \\
16 & Debug \\
17-23 & Application\\
17--23 & Application\\
\bottomrule
\end{tabular}
\end{small}
\end{sffamily}
\end{table}
@ -66,6 +73,9 @@ When TCG introduced Trusted Boot in 2004, UEFI was not yet available for the ord
Consequently, TCG standardized the roles of every PCR only for the BIOS platform.
Later, when UEFI became popular, the PCR descriptions got adopted for the new platform.
\subsection{Static Root of Trust for Measurement}%
\label{sub:static_root_of_trust_for_measurement}
The standard furthermore defines which part of the platform or firmware has to perform the measurement.
Since the TPM itself is a purely passive element, executing instructions provided by the CPU, the BIOS\,/\,UEFI firmware has to initiate the measurement beginning by the binary representation of the firmware itself.
This procedure is described in the TCG standard and the platform user has to \emph{trust} the manufacturer, that it is performed as expected.
@ -78,7 +88,10 @@ It furthermore must measure all platform initialization code like embedded drive
If these measurements cannot be performed, the chain of trust is broken and consequently the platform cannot be trusted.
One may see a zeroed PCR[0] or a value representing a hashed string of zeros as a strong indicator of a broken chain of trust.
The BIOS or UEFI performs then the next measurements until PCRs 1-7 are filled.
\subsection{Platform handover to OS}%
\label{sub:platform_handover_to_os}
The BIOS or UEFI performs the next measurements according to table \ref{tab:PCR} until PCRs 1--7 are written accordingly.
Before any further measurements are done, the control of the platform is handed over to the first part of the OS, which is usually the bootloader either in the Master Boot Record or provided as EFI BLOB in the EFI boot partition.
It is noteworthy that the bootloader itself and its configuration payload is measured in PCR 4 and 5 before the handover is done.
This guarantees that the chain of trust keeps intact when the bootloader takes control.
@ -87,7 +100,93 @@ The Bootloader has then to continue the chain of trust by measuring the Kernel a
The support and the way of how the measurements are done is not standardized.
GRUB, for example, measures all executed grub commands, the kernel command line and the module command line into PCR 8, whereas any file read by GRUB will be measured into PCR 9\cite{grub19}.
\ToDo{Überleitung zu IMA und IMA beschreiben. Danach DAA theoretisch beschreiben, kopie aus dem Seminarpaper. Erwähnung, dass die PCR-Register nur bei neustart zurückgesetzt werden können}
The whole process from initialization over measuring all software parts until the OS is started, is called \emph{Trusted Boot}.
The user can check the resulting values in the written PCR registers against known values.
These values can either be precomputed or just the result of a previous boot.
If all values match the expectations, the chain of trust exists between the SRTM and the Kernel.
\section{Integrity Measurement Architecture}%
\label{sec:integrity_measurement_architecture}
The \emph{Integrity Measurement Architecture} (IMA) is a Linux kernel extension to extend the chain of trust to the running application.
IMA is officialy supported by RedHat and Ubuntu and there exists documentation to enable IMA on Gentoo as well.
Other OS providers may not use a kernel with the required compile flags and\,/\,or lack of supporting software outside the kernel.
The IMA project page describes the required Kernel features for full support in their documentation\footnote{\url{https://sourceforge.net/p/linux-ima/wiki/Home/\#configuring-the-kernel}, last visited on March 30, 2021}.
The process of keeping track of system integrity becomes compared to the boot process far more complex on the OS level.
First, there are far more file system resources involved in running a system.
Even a minimal setup of a common Linux Distribution like Ubuntu or RedHat will load several hundred files until the kernel has completed its boot process.
Second, all these files will be loaded in parallel to make effective use of the available CPU resources.
It is clear that parallelism introduces non-determinism to the order of executing processes and of course the corresponding system log files.
Hence when using PCRs, this non-determinism results in different values, as stated in \autoref{sub:platform_configuration_register}.
The system, however, might still be in a trustworthy state.
Finally, the user might know some additional data to the current value in the PCR register.
Since the value itself does not tell anything to the user, a measurement log must be written for every operation on this PCR index.
IMA comes with three property variables which set the behaviour of the architecture:
\begin{itemize}
\item\texttt{ima\_template} sets the format of the produced log.
\item\texttt{ima\_appraise} changes the behaviour when a file is under investigation.
\item\texttt{ima\_policy} finally defines which resources should be analzyed.
\end{itemize}
These settings will be discussed in more detail in the following.
\subsubsection{Integrity Log}%
\label{ssub:integrity_log}
IMA uses the emph{integrity log} do keep track of any changes of local filesystem resources.
This is a virtual file that holds every measurement that leads to a change on the IMA PCR.
When IMA is active on the system, the integrity log can be found in \texttt{/sys/kernel/security/ima/ascii\_runtime\_measurements}.
Before a file is accessed by the kernel, IMA creates an integrity log entry as it is shown in \autoref{fig:integrity-log-entry}.
