@ -29,15 +29,12 @@ There are of course other purposes for delivering software in a closed source ma
Firmware of hardware vendors is usually not disclosed.
Instead, vendors provide an API where an \emph{Operating System} (OS) can connect to.
Some companies deliver complete closed source devices with internet connection.
In such cases, the feature of closed source is to protect the intellectual property of those
companies.
Any user of these closed source products must use them as black box and needs to \emph{trust} the
vendor that it is working correctly.
In such cases, the feature of closed source is to protect the intellectual property of those companies.
Any user of these closed source products must use them as black box and needs to \emph{trust} the vendor that it is working correctly.
There is, however, a special need for users to keep sensitive data secret.
Especially when providing confidential data like passwords or biometric data, a certain level of trust is required.
This means that the user assumes that the provided sensitive data is handled properly for only the
designated usage.
This means that the user assumes that the provided sensitive data is handled properly for only the designated usage.
One may argue that a password can easily be changed when revealed to the public.
Unfortunately, this does not apply to a fingerprint since a human usually has only ten of them during lifetime.
@ -51,10 +48,8 @@ By providing a Chain of Trust, a user can ask the vendor for a certification of
The Chain of Trust will be separated into two parts, namely the creation of trust on a certain system, and the transfer of trust over the network for verification purposes.
\section{Project Digidow}
The Institute for Networks and Security is heavily using the cryptographic form of trust in the
project \emph{Digital Shadow} (Digidow).
Digidow introduces an electronic authentication system, which aims to minimize any generation of
metadata on system and network level and hence maximizes the level of privacy for their users.
The Institute for Networks and Security is heavily using the cryptographic form of trust in the project \emph{Digital Shadow} (Digidow).
Digidow introduces an electronic authentication system, which aims to minimize any generation of metadata on system and network level and hence maximizes the level of privacy for their users.
The project furthermore aims to specify a scalable solution for nationwide or even worldwide applications including provable trust and integrity to the user.
\begin{figure}
@ -64,25 +59,20 @@ The project furthermore aims to specify a scalable solution for nationwide or ev
\label{fig:digidow-overview}
\end{figure}
The picture in \autoref{fig:digidow-overview} provides an overview of the Digidow network.
The nodes using the Digidow network and their interactions are not fully specified at the time of
this writing.
The nodes using the Digidow network and their interactions are not fully specified at the time of this writing.
Therefore the processes may be adapted when necessary.
DigiDow introduces five main parties which are involved in a common authentication process.
\begin{itemize}
\item\emph{Individual}: The human user who wants to be identified via the Digidow network.
\item\emph{Personal Identity Agent} (PIA): The PIA is the digital shadow of an individual.
This individual is also the owner of the PIA and should be in control of sensitive data and
software on it.
This individual is also the owner of the PIA and should be in control of sensitive data and software on it.
\item\emph{Issuing Authority}: This party acts as an authority for the individual's attributes.
These attributes show an aspect of the individula's identity.
After identifying the individual via the Digidow network, these attributes may be used to allow
or deny a certain action.
\item\emph{Verifier}: This is the party that verifies the whole authentication process and may
finally trigger the desired action.
After identifying the individual via the Digidow network, these attributes may be used to allow or deny a certain action.
\item\emph{Verifier}: This is the party that verifies the whole authentication process and may finally trigger the desired action.
It is usually strongly connected with the sensor which starts the identification process.
\item\emph{Sensor}: For authentication, an individual has to be uniquely identified.
Therefore, the sensor records biometric data from the individual and passes it to the PIA via
the Dididow network.
Therefore, the sensor records biometric data from the individual and passes it to the PIA via the Dididow network.
Sensors are not limited to sensing biometric data.
However, we focus in this thesis on developing a prototype of a biometric sensor (BS).
\end{itemize}
@ -91,60 +81,44 @@ When an individual wants to be identified by Digidow, he will eventually step in
This defines the beginning of a Digidow trancaction.
The procedure is as follows:
\begin{enumerate}
\item The sensor will start recording a unique digital representation, triggered by the directly
connected verifier or by hardware detection.
\item The sensor eventually finds one or a small group of eligible PIAs, where a secure
communication channel is established.
\item After receiving the digital representation of the sensor, the PIA identifies the individual
if possible.
\item When identification was possible, the PIA eventually sends a proof of identification and a
claim of the requested attributes to the verifier.
\item The sensor will start recording a unique digital representation, triggered by the directly connected verifier or by hardware detection.
\item The sensor eventually finds one or a small group of eligible PIAs, where a secure communication channel is established.
\item After receiving the digital representation of the sensor, the PIA identifies the individual if possible.
\item When identification was possible, the PIA eventually sends a proof of identification and a claim of the requested attributes to the verifier.
\item The verifier will check the cryptographic proofs of the claim and the sensor data.
If successful, the verififier will grant the desired action for the asking individual.
\end{enumerate}
The above illustration is an early draft of the whole setup and is under constant development.
Latest developments the whole system will be published on the Digidow project
page\footnote{\url{https://digidow.eu}}.
Latest developments the whole system will be published on the Digidow project page\footnote{\url{https://digidow.eu}}.
\section{Our Contribution: Deriving Trust from the Biometric Sensor}
The Digidow network is designed to preserve privacy and to build trust for any user.
A key feature is to show the user that all involved parts of the system are working as intended.
So we design a prototype based on the common x86 architecture and use the cryptographic features of
\emph{Trusted Platform Modules} (TPM).
So we design a prototype based on the common x86 architecture and use the cryptographic features of \emph{Trusted Platform Modules} (TPM).
A TPM is a passive crypto coprocessor available on many modern PC platforms which has an independent storage for crypto variables and provides functions to support above mentioned features.
We define a solution for installing and booting a Linux kernel with TPM-backed integrity
measurements in place.
We use an attached camera as example for a biometric sensor hardware to create the dataset to
continue with the authentication process.
This dataset will be combined with the integrity measurements of the system and a signature from
the TPM and finally sent to the PIA for verification and further computation.
We define a solution for installing and booting a Linux kernel with TPM-backed integrity measurements in place.
We use an attached camera as example for a biometric sensor hardware to create the dataset to continue with the authentication process.
This dataset will be combined with the integrity measurements of the system and a signature from the TPM and finally sent to the PIA for verification and further computation.
By building a system with an integrated TPM, the system should be able to provide the following properties:
\begin{itemize}
\item\emph{Sensor Monitoring.} The system should be able to monitor the hardware sensor (fingerprint sensor, camera, etc.) itself.
\item\emph{System Monitoring.} It should be possible to track the state of the system. Especially every modification of the system at hardware level should be detected.
\item\emph{Freshness of Sensor Data.} To prevent replay attacks, the system should prove that
the provided biometric data is captured live.
\item\emph{Integrity of Sensor Data.} As it is possible for an adversary to modify the provided
data during the identification process, integrity should guarantee that the data is unmodified
until identification is done.
\item\emph{Freshness of Sensor Data.} To prevent replay attacks, the system should prove that the provided biometric data is captured live.
\item\emph{Integrity of Sensor Data.} As it is possible for an adversary to modify the provided data during the identification process, integrity should guarantee that the data is unmodified until identification is done.
\item\emph{Confidentiality of Sensor Data.} It should not be possible to eavesdrop any sensitive data out of the system.
Furthermore almost all kinds of metadata (e.\,g. information about the system or network
information) should not be published.
\item\emph{Anonymity.} Given a message from a BS, an adversary should not be able to detect
which BS created it.
Furthermore almost all kinds of metadata (e.\,g. information about the system or network information) should not be published.
\item\emph{Anonymity.} Given a message from a BS, an adversary should not be able to detect which BS created it.
\item\emph{Unforgeability.} Only honest BS should be able to be part of the Digidow network.
Corrupt systems should not be able to send valid messages.
\end{itemize}
The thesis focuses on a working setup as basis for future research.
Since the Digidow protocols are not yet finalized, some assumptions are defined for this work and
the prototype implementation:
Since the Digidow protocols are not yet finalized, some assumptions are defined for this work and the prototype implementation:
\begin{itemize}
\item Any network discovery (Step 1 in \autoref{fig:globalview}) is omitted. BS and PIA are
assumed to be reachable directly via TCP/IP.
\item Any network discovery is omitted. BS and PIA are assumed to be reachable directly via TCP/IP.
\item We look into a protocol which proves trustworthiness from BS to PIA.
Any further proofs necessary for a Digidow Verifier are also not focused in this thesis.
\item The sensitive datasets will be transmitted in cleartext between BS and PIA.
@ -152,17 +126,12 @@ the prototype implementation:
However this should be considered in the Digidow network protocol design.
This thesis focuses only on the trust part between BS and PIA.
\item Any built system is considered secure on a hardware level.
Any threats which are attacking the system without changing any running software on the system
may remain undetected.
This includes USB wire tapping or debug interfaces within the system revealing sensitive
information.
Any threats which are attacking the system without changing any running software on the system may remain undetected.
This includes USB wire tapping or debug interfaces within the system revealing sensitive information.
\end{itemize}
%TODO edit pointer
\section{Description of structure}
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this
thesis.
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this thesis.
There is, however, scientific work that is used as scientific background to this thesis as described in \autoref{cha:background}.
This includes especially the theoretical foundations of the network protocol.
Together with that, we will introduce our theoretical solution for the previously stated problems in \autoref{cha:concept}.
@ -173,21 +142,17 @@ Finally we will present the results and limitations in \autoref{cha:conclusion}
There exist already a variety projects and implementations which touch the field of trusted computing.
We will introduce some of these projects and discuss why these do not meet the purpose of this thesis.
Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud
computing.
Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud computing.
They show in their paper how a TPM of a hypervisor can be virtualized and used by the guest operating system.
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with
existing tools for fleet management and scalability.
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with existing tools for fleet management and scalability.
The concept of a well known virtual environment does, however, not apply to our contribution.
Furthermore, the system should be self contained as good as possible and it should be possible to
get information about the system via anonymous attestation.
Furthermore, the system should be self contained as good as possible and it should be possible to get information about the system via anonymous attestation.
%TODO what about the integrity measurements of keylime?
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
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.
This standard is still in development; a draft version from February 2018 is published on the FIDO
website\cite{fido18}
This standard is still in development; a draft version from February 2018 is published on the FIDO website\cite{fido18}
%TODO Is it noteworthy, that Xaptum claims to be compatible with FIDO ECDAA for TPM2?
In this chapter we describe four main concepts which will be combined in the concept of this thesis.
The TPM standard is used to introduce trust into the used host platforms.
\emph{Trusted Boot} and the \emph{Integrity Measurement Architecture} (IMA) are two approaches to
extend trust from the TPM over the UEFI\,/\,BIOS up to the OS.
\emph{Trusted Boot} and the \emph{Integrity Measurement Architecture} (IMA) are two approaches to extend trust from the TPM over the UEFI\,/\,BIOS up to the OS.
The generated trust should then be provable by an external party---in our case the PIA---by using the protocol of \emph{Direct Anonymous Attestation} (DAA).
\section{Trusted Platform Module (TPM)}%
\label{sec:trusted_platform_module_tpm_}
The \emph{Trusted Platform Module} (TPM) is a small coprocessor that introduces a variety of cryptographic features to the platform.
This module is part of a standard developed by the Trusted Computing Group (TCG), which released
the current revision 2.0 in 2014\cite{tcg20}.
This module is part of a standard developed by the Trusted Computing Group (TCG), which released the current revision 2.0 in 2014\cite{tcg20}.
The hardware itself is strongly defined by the standard and comes in the following flavors:
\begin{itemize}
\item\emph{Dedicated device.} The TPM chip is mounted on a small board with a connector.
The user can plug it into a compatible compute platform. This gives most control to the end
user since it is easy to disable trusted computing or to switch to another TPM.
The user can plug it into a compatible compute platform. This gives most control to the end user since it is easy to disable trusted computing or to switch to another TPM.
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard.
Therefore, removing or changing the TPM is imossible.
All recent Intel and AMD platforms supporting TPM2.0 are able to manage a TPM within the BIOS,
even as mounted device.
All recent Intel and AMD platforms supporting TPM2.0 are able to manage a TPM within the BIOS, even as mounted device.
\item\emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision.
Instead of using a dedicated Coprocessor for the TPM features, this variant lives as firmware
extension within Intel's Management Engine or AMD's Platform Security Processor.
Instead of using a dedicated Coprocessor for the TPM features, this variant lives as firmware extension within Intel's Management Engine or AMD's Platform Security Processor.
Both Intel and AMD provide this extension for their platforms for several years now.
When activating this feature on BIOS level, the user gets the same behavior as when using a
mounted device.
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator. It
provides basically every feature of a TPM but cannot be used outside the OS.
When activating this feature on BIOS level, the user gets the same behavior as when using a mounted device.
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator.
It provides basically every feature of a TPM but cannot be used outside the OS.
Features like Trusted Boot or in hardware persisted keys are not available.
\end{itemize}
Dedicated and mounted devices are small microcontrollers that run the TPM features in software
giving the manufacturer the possibility to update their TPMs in the field.
Dedicated and mounted devices are small microcontrollers that run the TPM features in software giving the manufacturer the possibility to update their TPMs in the field.
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.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it
returns 23 entries\cite{mitre18}.
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.
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
library and the shutdown/boot process.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM library and the shutdown/boot process.
The last two entries describe vulnerabilities in dedicated TPM chips, which are mentioned in further detail:
\begin{itemize}
\item\emph{CVE-2017-15361}: TPMs from Infineon used a weak algorithm for finding primes during the RSA key generation process.
This weakness made brute force attacks against keys of up to 2048 bits length feasible.
According to Nemec et al.\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3
CPU months and 2048 bit keys needed 100 CPU years.
According to Nemec et al.\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3 CPU months and 2048 bit keys needed 100 CPU years.
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "\emph{TPM fail}"
\cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and
lattice attacks.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM
implementation.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "\emph{TPM fail}" \cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and lattice attacks.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM implementation.
Infineon TPM show also some non-expected behaviour, but this could not be used for data exfiltration.
STM provided an update like Infineon did for their TPMs.
Intel's fTPM required a platform firmware update to solve the issue.
@ -71,55 +58,44 @@ On top of the cryptographic hardware, the TCG provides several software interfac
However, this API provides the full set of features.
\item\emph{Enhanced System API (ESAPI).} While still providing a complete feature set, the ESAPI makes some resources transparent to the application like session handling. Consequently, this API layer is built on top of the SAPI.
\item\emph{Feature API (FAPI).} This API layer is again built on top of the ESAPI. It provides a simple to use API but the feature set is also reduced to common use cases.
Although the interface was formally published from the beginning, an implementation is
available only since end of 2019.
Although the interface was formally published from the beginning, an implementation is available only since end of 2019.
\end{itemize}
The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still
under development.
The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still under development.
The repositories are maintained by members of TCG.
At the point of writing stable interfaces are available for C and C++, but other languages like
Rust, Java, C\# will be served in the future.
At the point of writing stable interfaces are available for C and C++, but other languages like Rust, Java, C\# will be served in the future.
The repository additionally provides the tpm2-tools toolset which provides the FAPI features to the command line.
Unfortunately, the command line parameters changed several times during the major releases of
tpm2-tools\cite{pornkitprasan19-tpmtools}.
Unfortunately, the command line parameters changed several times during the major releases of tpm2-tools\cite{pornkitprasan19-tpmtools}.
\subsection{The Hardware}
\label{sssec:tpm-hardware}
With the previous mentioned software layers the TCG achieved independence of the underlying
hardware.
Hence, these layout made the different flavors of TPMs possible
With the previous mentioned software layers the TCG achieved independence of the underlying hardware.
Hence, this design made the different flavors of TPMs possible.
With the TPM2.0 standard, TCG defined a highly constrained hardware with a small feature set.
It is a passive device with some volatile and non-volatile memory, which provides hardware acceleration for a small number of crypto algorithms.
The standard allows to add some extra functionality to the device.
However, the TPMs used in this project provide just the minimal set of algorithms and also the
minimal amount of memory.
However, the TPMs used in this project provide just the minimal set of algorithms and also the minimal amount of memory.
Since TCG published its documents, several IT security teams investigated the concept and
implementations of TPMs.
Since TCG published its documents, several IT security teams investigated the concept and implementations of TPMs.
\subsection{TPM Key Hierarchies}%
\label{sub:tpm_key_hierarchies}
A TPM comes with four different key hierarchies.
These hierarchies fulfill different tasks and are used in different use cases on the whole platform.
Will Arthur et al.\cite{arthur15} provide a more detailed description on how the hierarchies work
together.
Will Arthur et al.\cite{arthur15} provide a more detailed description on how the hierarchies work together.
\begin{itemize}
\item\emph{Platform Hierarchy}: This hierarchy is managed by the platform manufacturer. The firmware of the platform is interacting with this hierarchy during the boot process.
\item\emph{Storage Hierarchy}: The storage of a platform is controlled by either an IT
department or the end user and so is the storage hierarchy of the TPM.
\item\emph{Storage Hierarchy}: The storage of a platform is controlled by either an IT department or the end user and so is the storage hierarchy of the TPM.
It offers non-privacy related features to the platform although the user may disable the TPM for her own use.
\item\emph{Endorsement Hierarchy}: This is the privacy-related hierarchy which will also provide required functionality to this project.
It is controlled by the user of the platform and provides the keys for attestation and group membership.
\item\emph{NULL Hierarchy}: The NULL hierarchy is the only non-persistent hierarchy when
rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\item\emph{NULL Hierarchy}: The NULL hierarchy is the only non-persistent hierarchy when rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\end{itemize}
Each of the persistent hiearchies represent its own tree of keys, beginning with a root key.
Since TPM2.0 was published, these root keys are not hard coded anymore and can be changed if
necessary.
Since TPM2.0 was published, these root keys are not hard coded anymore and can be changed if necessary.
The process of key generation described below is similar to all three persistent hierarchies.
\subsection{Endorsement Key}%
@ -134,45 +110,37 @@ The \emph{Endorsement Key} (EK) is the root key for the corresponding hierarchy.
\autoref{fig:ek-key-generation} illustrates the certificate chain of building a new EK.
Every TPM has, instead of the full EK, a unique key seed to derive root keys from.
This key seed comes with a corresponding certificate.
This TPM certificate is signed by the TPM manufacturer by using its own root \emph{Certificate
Authority} (CA).
This TPM certificate is signed by the TPM manufacturer by using its own root \emph{Certificate Authority} (CA).
When the platform user wants to create a new EK, a \emph{Key Derivation Function} (KDF) generates this new EK such that the TPM certificate identifies it and the chain keeps intact.
Since the platform supports root key generation, it is also possible to encrypt the key and store it on an external storage, e.g. on the platform disk.
Consequently it is quite easy to have different EKs at once to address privacy features also
between different functions of the endorsement hierarchy.
Consequently it is quite easy to have different EKs at once to address privacy features also between different functions of the endorsement hierarchy.
\section{Trusted Boot}%
\label{sec:trusted_boot}
A boot process of modern platforms consists of several steps until the OS is taking over the
platform.
A boot process of modern platforms consists of several steps until the OS is taking over the platform.
During these early steps, the hardware components of the platform are initialized and some self tests are performed.
This is controlled by either the BIOS (for legacy platforms) or the UEFI firmware.
There exists no source of trust and hence no check for integrity or intended execution in this
common boot procedure.
There exists no source of trust and hence no check for integrity or intended execution in this common boot procedure.
\subsection{Platform Configuration Register}%
\label{sub:platform_configuration_register}
The \emph{Trusted Computing Group} (TCG) introduced their first standard for a new {Trusted
Computing Module} (TPM) in 2004.
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).
The \emph{Trusted Computing Group} (TCG) introduced their first standard for a new {Trusted Computing Module} (TPM) in 2004.
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).
In this context, \emph{Measuring} means a simple cryptographic extension function:
The function "$||$" represents a concatenation of two binary strings and the hash function is
either SHA1 or SHA256.
The function "$||$" represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
Consequently, both hash results are available for further computations.
The formula shows that a new PCR value holds the information of the preceeding value as well.
This \emph{hash chain} enables the user to add an arbitrary number of hash computations.
One can clearly see that the resulting hash will also change when the order of computations changes.
Therefore, the BIOS/UEFI has to provide a deterministic way to compute the hash chain if there is
more than one operation necessary.
Therefore, the BIOS/UEFI has to provide a deterministic way to compute the hash chain if there is more than one operation necessary.
The procedure of measurements is available since the first public standard TPM1.2.
For TPM2.0, the process was only extended with the support with the newer SHA256 algorithm.
@ -218,41 +186,30 @@ Later, when UEFI became popular, the PCR descriptions got adopted for the new pl
\label{sub:static_root_of_trust_for_measurement}
The standard 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 with 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 for expected behavior.
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 with 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 for expected behavior.
It is called the \emph{Static Root of Trust for Measurement} (SRTM) and is defined in section 2.2 of the TCG PC Client Platform Firmware Profile\cite{tcg-pc19}.
As the mainboard manufacturer do not publish their firmware code, one may have to reverse engineer
the firmware to prove correct implementation of the SRTM.
As the mainboard manufacturer do not publish their firmware code, one may have to reverse engineer the firmware to prove correct implementation of the SRTM.
The SRTM is a small immutable piece of the firmware which is executed by default after the platform was reset.
It is the first piece of software that is executed on the platform and measures itself into PCR~0.
It must measure all platform initialization code like embedded drivers, host platform firmware,
etc.\@ as they are provided as part of the mainboard.
If these measurements cannot be performed, the chain of trust is broken and consequently the
platform cannot be trusted.
When PCR~0 is zeroed or filled with the hashed representation of a string of zeroes, the SRTM did
not act as expected.
It must measure all platform initialization code like embedded drivers, host platform firmware, etc.\@ as they are provided as part of the mainboard.
If these measurements cannot be performed, the chain of trust is broken and consequently the platform cannot be trusted.
When PCR~0 is zeroed or filled with the hashed representation of a string of zeroes, the SRTM did not act as expected.
This indicates a broken chain of trust and should only appear when using the TPM simulator.
\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 kernel
of either a bootloader or the OS when booting without any bootloaders.
In any case, these binaries are stored in the \emph{Master Boot Record} (MBR) or provided as EFI
blob in the EFI boot partition.
Before any further measurements are done, the control of the platform is handed over to the kernel of either a bootloader or the OS when booting without any bootloaders.
In any case, these binaries are stored in the \emph{Master Boot Record} (MBR) 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/OS takes control.
The bootloader has to continue the chain of trust by measuring the kernel and the corresponding
command line parameters into the next PCRs.
The bootloader has to continue the chain of trust by measuring the kernel and the corresponding command line parameters into the next PCRs.
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}.
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}.
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.
@ -264,18 +221,14 @@ If all values match the expectations, the chain of trust exists between the SRTM
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 do not provide
userland software required to manage IMA.
The IMA project page describes the required kernel features for full support in their
documentation\cite{ima-overview}.
Other OS providers may not use a kernel with the required compile flags and/or do not provide userland software required to manage IMA.
The IMA project page describes the required kernel features for full support in their documentation\cite{ima-overview}.
The process of keeping track of system integrity becomes far more complex on the OS level compared
to the boot process.
The process of keeping track of system integrity becomes far more complex on the OS level compared to the boot process.
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.
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.
@ -307,25 +260,23 @@ Before a file is accessed by the kernel, IMA creates an integrity log entry as i
Depending on the settings for IMA, a SHA1 or SHA256 hash is created for the file content.
The resulting \emph{filedata hash} will be concatenated with the corresponding metadata.
This concatenation will again be hashed into the so called \emph{template hash}.
Finally, the template hash is the single value of the whole computation that will be extended into
the PCR.
Finally, the template hash is the single value of the whole computation that will be extended into the PCR.
The integrity log holds at the end the filedata hash, the metadata and the template hash as well as the PCR index and the logfile format.
IMA knows three different file formats, where two of them can be used in recent applications.
The only difference between these formats lies in the used and logged metadata:
\begin{itemize}
\item\texttt{ima-ng} uses, besides the filedata hash, also the filedata hash length, the
pathname length and the pathname to create the template hash.
\item\texttt{ima-ng} uses, besides the filedata hash, also the filedata hash length, the pathname length and the pathname to create the template hash.
\item\texttt{ima-sig} uses the same sources as ima-ng.
When available, it also writes signatures of files into the log and includes them for
calculating the template hash.
When available, it also writes signatures of files into the log and includes them for calculating the template hash.
\end{itemize}
The older template \texttt{ima} uses only SHA1 and is fully replaceable with the \texttt{ima-ng}
template.
The older template \texttt{ima} uses only SHA1 and is fully replaceable with the \texttt{ima-ng} template.
Therefore, it should not be used for newer applications.
The first entry in every measurement file is called \texttt{boot\_aggregate}.
It is the trust link between trusted boot and IMA representing a cumulative hash of the PCR values 0 -- 7.
Consequently, the PCR result of trusted boot is also embedded in the measurement log and the shrresponding hash chain of PCR 10.
\ToDo{boot aggregate beschreiben}
\subsection{IMA Appraisal}%
\label{ssub:ima_appraisal}
@ -345,20 +296,14 @@ These modes set the behaviour especially when there exists no additional informa
The IMA policies define which resources are targeted with IMA.
There exist three template policies which can be used concurrently:
\begin{itemize}
\item\texttt{tcb}: All files owned by root will be measured.
\item\texttt{appraise\_tcb}: All executables which are run, all files mapped in memory for
execution, all loaded kernel modules and all files opened for read by root will be measured by
IMA.
\item\texttt{secure\_boot}: All loaded modules, firmwares, executed kernels and IMA policies are
checked. Therefore, these resources need to have a provable signature to pass the check. The
corresponding public key must be provided by the system manufacturer within the provided
firmware or as Machine Owner Key in shim.
\item\texttt{tcb}: All files owned by root will be measured when accessed for read.
\item\texttt{appraise\_tcb}: All executables which are run, all files mapped in memory for execution, all loaded kernel modules and all files opened for read by root will be measured by IMA.
\item\texttt{secure\_boot}: All loaded modules, firmwares, executed kernels and IMA policies are checked. Therefore, these resources need to have a provable signature to pass the check. The
corresponding public key must be provided by the system manufacturer within the provided firmware or as Machine Owner Key in shim.
\end{itemize}
In addition to these templates, the system owner can define custom policies.
Some example policies can be found in the Gentoo
Wiki\cite{gentoo19}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce
useless entries in the measurement log.
Some example policies can be found in the Gentoo Wiki\cite{gentoo19}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless entries in the measurement log.
\emph{Direct Anonymous Attestation} (DAA) is a cryptographic scheme which makes use of the functions provided by the TPM.
DAA implements the concept of group signatures, where multiple secret keys can create a corresponding signature.
These signatures can be verified with a single public key when private keys are member of the same
group.
These signatures can be verified with a single public key when private keys are member of the same group.
The scientific community is researching on TPM-backed DAA since the first standard of TPM went public in 2004.
Since then many different approaches of DAA were discussed.
According to Camenisch et al. in \cite{camenisch16} and \cite{camenisch17}, almost all schemes were
proven insecure, since many of them had bugs in the protocol or allowed trivial public/secret key
pairs.
According to Camenisch et al. in \cite{camenisch16} and \cite{camenisch17}, almost all schemes were proven insecure, since many of them had bugs in the protocol or allowed trivial public/secret key pairs.
This also includes the impementation of DAA im the TPM1.2 standard.
This section describes the concept by Camenisch et al.~\cite{camenisch16} including the
cryptographic elements used for DAA.
This section describes the concept by Camenisch et al.~\cite{camenisch16} including the cryptographic elements used for DAA.
Unlike the description in the original paper, we describe the practical approach, which will be used in the following concept.
\subsection{Mathematical Foundations}
@ -418,7 +359,8 @@ Unlike the description in the original paper, we describe the practical approach
\item\emph{Verify.} The verifier knows the values of $y$ and $g$, as they are usually public. The message $m$ comes with the signature values $c$ and $s$. She computes the value
\item\emph{Verify.} The verifier knows the values of $y$ and $g$, as they are usually public. The message $m$ comes with the signature values $c$ and $s$.
He computes the value
\begin{equation*}
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\,\text{.}
\end{equation*}
@ -443,14 +385,12 @@ Unlike the description in the original paper, we describe the practical approach
The Camenisch-Lysyanskaya (CL) Signature Scheme~\cite{camenisch04} is based on the LRSW
assumption and allows efficient proofs for signature posession and is the basis for the DAA
scheme discussed below.
The Camenisch-Lysyanskaya (CL) Signature Scheme~\cite{camenisch04} is based on the LRSW assumption and allows efficient proofs for signature posession and is the basis for the DAA scheme discussed below.
It is based on a bilinear group $(q, \mathbb{G}_1,\mathbb{G}_2,\mathbb{G}_T, e, g_1, g_2)$ that is available to all steps in the protocol.
\begin{itemize}
\item\emph{Setup.} Choose $x\leftarrow\mathbb{Z}_q$ and $y\leftarrow\mathbb{Z}_q$ at random. Set the secret key $sk \leftarrow(x,y)$ and the public key $pk \leftarrow(g_2^x, g_2^y)=(X,Y)$.
\item\emph{Sign.} Given a message $m$ and the secret key $sk$, choose $a$ at random and output
the signature $\sigma\leftarrow(a, a^y, a^{x+xym})=(a,b,c)$.
\item\emph{Setup.} Choose $x\leftarrow\mathbb{Z}_q$ and $y\leftarrow\mathbb{Z}_q$ at random.
Set the secret key $sk \leftarrow(x,y)$ and the public key $pk \leftarrow(g_2^x, g_2^y)=(X,Y)$.
\item\emph{Sign.} Given a message $m$ and the secret key $sk$, choose $a$ at random and output the signature $\sigma\leftarrow(a, a^y, a^{x+xym})=(a,b,c)$.
\item\emph{Verify.} Given message $m$, signature $\sigma$ and public key $pk$, verify that $a
\neq 1_{\mathbb{G}_1}$, $e(a,Y) = e(b,g_2)$ and $e(a,X)\cdot e(b,X)^m = e(c,g_2)$.
\end{itemize}
@ -461,14 +401,11 @@ Unlike the description in the original paper, we describe the practical approach
DAA is a group signature protocol, which aims with a supporting TPM to reveal no additional information about the signing host besides content and validity of the signed message $m$.
According to Camenisch et al.~\cite{camenisch16}, the DAA protocol consists of three parties:
\begin{itemize}
\item\emph{Issuer}\issuer. The issuer maintains a group and has evidence of hosts that are
members in this group.
\item\emph{Issuer}\issuer. The issuer maintains a group and has evidence of hosts that are members in this group.
\item\emph{Host}\host. The host creates a platform with the corresponding TPM \tpm{}.
Membership of groups are maintained by the TPM.
Only the key owner (TPM, passive) and the message author (Host, active) form a full group
member.
\item\emph{Verifier}\verifier. A verifier can check, whether a host with its TPM is in a
group or not. Besides the group membership, no additional information is provided.
Only the key owner (TPM, passive) and the message author (Host, active) form a full group member.
\item\emph{Verifier}\verifier. A verifier can check, whether a host with its TPM is in a group or not. Besides the group membership, no additional information is provided.
\end{itemize}
A certificate authority $\mathcal{F}_{ca}$ is providing a certificate for the issuer itself.
The basename \bsn{} is some clear text string, whereas \nym{} represent the encrypted basename $bsn^{gsk}$.
@ -476,31 +413,24 @@ Unlike the description in the original paper, we describe the practical approach
The paper of Camenisch et al.~\cite{camenisch16} introduces further variables that are necessary for their proof of correctness.
These extensions were omitted in the following to understand the protocol more easily.
\begin{itemize}
\item\emph{Setup.} During setup, \issuer{} is generating the issuer secret key $isk$ and the
corresponding issuer public key $ipk$. The public key is published and assumed to be known to
everyone.
\item\emph{Setup.} During setup, \issuer{} is generating the issuer secret key $isk$ and the corresponding issuer public key $ipk$. The public key is published and assumed to be known to everyone.
\begin{enumerate}
\item On input \textsf{SETUP}, \issuer
\begin{itemize}
\item generates $x,y \leftarrow\mathbb{Z}_q$ and sets $isk=(x,y)$ and
\item generates a proof $\pi\sassign SPK\{(x,y):X=g_2^x\wedge Y=g_2^y\}$ that the key pair
is well formed,
\item registers the public key $(X,Y,\pi)$ at $\mathcal{F}_{ca}$ and stores the secret key,
and
\item generates $x,y \leftarrow\mathbb{Z}_q$ and sets $isk=(x,y)$ and $ipk\leftarrow(g_2^x,g_2^y)=(X,Y)$. Initialize $\mathcal{L}\leftarrow\emptyset$,
\item generates a proof $\pi\sassign SPK\{(x,y):X=g_2^x\wedge Y=g_2^y\}$ that the key pair is well formed,
\item registers the public key $(X,Y,\pi)$ at $\mathcal{F}_{ca}$ and stores the secret key, and
\item outputs \textsf{SETUPDONE}.
\end{itemize}
\end{enumerate}
\item\emph{Join.} When a platform, consisting of host \host[j] and TPM \tpm[i], wants to become a member of the issuer's group, it joins the group by authenticating to the issuer \issuer.
\begin{enumerate}
\item On input \textsf{JOIN}, host \host[j] sends the message \textsf{JOIN} to \issuer.
\item Upon receiving \textsf{JOIN} from \host[j], \issuer{} chooses a fresh nonce
$n\leftarrow\{0,1\}^\tau$ and sends it back to \host[j].
\item Upon receiving \textsf{JOIN} from \host[j], \issuer{} chooses a fresh nonce $n\leftarrow\{0,1\}^\tau$ and sends it back to \host[j].
\item Upon receiving $n$ from \issuer, \host[j] forwards $n$ to \tpm[i].
\item\tpm[i] generates the secret key:
\begin{itemize}
\item Check that no completed key record exists. Otherwise, it is already a member of that
group.
\item Check that no completed key record exists. Otherwise, it is already a member of that group.
\item Choose $gsk\sassign\mathbb{Z}_q$ and store the key as $(gsk, \bot)$.
\item Set $Q \leftarrow g_1^{gsk}$ and compute $\pi_1\sassign SPK\{(gsk):Q=g_1^{gsk}\}(n)$.
\item Return $(Q,\pi_1)$ to \host[j].
@ -522,8 +452,7 @@ Unlike the description in the original paper, we describe the practical approach
\item\tpm[i] receives $(b,d,\pi_2)$ and verifies $\pi_2$. The join is completed after the record is extended to $(gsk, (b,d))$. \tpm[i] returns \textsf{JOINED} to \host[j].
\item\host[j] stores $(a,b,c,d)$ and outputs \textsf{JOINED}.
\end{enumerate}
\item\emph{Sign.}
After joining the group, a host \host[j] and TPM \tpm[i] can sign a message $m$ with respect to basename \bsn.
\item\emph{Sign.} After joining the group, a host \host[j] and TPM \tpm[i] can sign a message $m$ with respect to basename \bsn.
\begin{enumerate}
\item Upon input \textsf{SIGN}$(m,\bsn)$, \host[j] re-randomizes the CL credential:
\begin{itemize}
@ -550,8 +479,7 @@ Unlike the description in the original paper, we describe the practical approach
\end{enumerate}
\item\emph{Verify.}
Given a signed message, everyone can check, whether the signature with respect to \bsn{} is valid and the signer is member of this group.
Furthermore, a revocation list \RL{} holds the private keys of corrupted TPMs, whose
signatures are no longer accepted.
Furthermore, a revocation list \RL{} holds the private keys of corrupted TPMs, whose signatures are no longer accepted.
Upon input \textsf{VERIFY}$(m, \bsn, \sigma)$, \verifier{}
\begin{itemize}
@ -563,15 +491,12 @@ Unlike the description in the original paper, we describe the practical approach
\item outputs \textsf{VERIFIED}$(f)$.
\end{itemize}
\item\emph{Link.}
After proving validity of the signature, the verifier can test, whether two different messages
with the same basename $\bsn\neq\bot$ are generated from the same TPM.
After proving validity of the signature, the verifier can test, whether two different messages with the same basename $\bsn\neq\bot$ are generated from the same TPM.
On input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$, \verifier{} verifies the signatures
and compares the pseudonyms contained in $\sigma, \sigma'$:
On input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$, \verifier{} verifies the signatures and compares the pseudonyms contained in $\sigma, \sigma'$:
\begin{itemize}
\item Check that $\bsn\neq\bot$ and that both signatures $\sigma, \sigma'$ are valid.
\item Parse the signatures $\sigma\leftarrow(a,b,c,d,\pi,\nym)$,
$\sigma'\leftarrow(a',b',c',d',\pi',\nym')$.
\item Parse the signatures $\sigma\leftarrow(a,b,c,d,\pi,\nym)$, $\sigma'\leftarrow(a',b',c',d',\pi',\nym')$.
\item If $\nym=\nym'$, set $f\leftarrow1$, otherwise $f\leftarrow0$.
\item Output \textsf{LINK}$(f)$.
\end{itemize}
@ -580,8 +505,7 @@ Unlike the description in the original paper, we describe the practical approach
Camenisch et al.~\cite{camenisch16} extend the general group concept scheme with their concept.
The feature of linking messages together requires further security features within the DAA scheme, which the authors also prove in their paper along with the other properties of the scheme:
\begin{itemize}
\item\emph{Non-frameability}: No one can create signatures that the platform never signed, but
that link to messages signed from that platform.
\item\emph{Non-frameability}: No one can create signatures that the platform never signed, but that link to messages signed from that platform.
\item\emph{Correctness of link}: Two signatures will link when the honest platform signs it with the same basename.
\item\emph{Symmetry of Link}: It does not matter in which order the linked signatures will be proven. The link algorithm will always output the same result.
The BS itself is defined as edge device within the Digidow network.
According to the schema shown in \autoref{fig:globalview}, the BS will be placed in a public area
(e.g. a checkpoint in an airport or as access control system at a building) to interact directly
with the Digidow users.
According to the schema shown in \autoref{fig:globalview}, the BS will be placed in a public area (e.g. a checkpoint in an airport or as access control system at a building) to interact directly with the Digidow users.
There, the BS acts as interface to the to the Digidow network.
By providing a biometric property, the user should be able to authenticate itself and the network may then trigger the desired action, like granting access or logging presence.
Depending on the biometric property, the sensor may not be active all the time, but activated when an authentication process is started.
@ -21,9 +19,7 @@ The following enumeration shows the steps of the BS for identifying the interact
\item\emph{Listen}: Either the sensor hardware itself (e.g. a detection in a fingerprint sensor) or another electrical signal will start the authentication process.
\item\emph{Collect}: Measure sensor data (picture, fingerprint) and calculate a biometric
representation (attribute).
\item\emph{Discover}: Start a network discovery in the Digidow network and find the PIA
corresponding to the present person. It may be necessary to interact with more than one PIA
within this and the next steps.
\item\emph{Discover}: Start a network discovery in the Digidow network and find the PIA corresponding to the present person. It may be necessary to interact with more than one PIA within this and the next steps.
\item\emph{Transmit}: Create a trusted and secure channel to the PIA and transmit the attribute.
\item\emph{Reset}: Set the state of the system as it was before this transaction.
\end{enumerate}
@ -40,8 +36,7 @@ In addition to autonomy, the BS should also ensure proper handling of received a
The recorded dataset from a sensor is \emph{sensitive data} due to its ability to identify an individual.
Due to its narrow definition, it is affordable to protect sensitive data.
Besides that, \emph{metadata} is information generated during the whole transaction phase.
Timestamps and host information are metadata as well as connection lists, hashes and log entries
and much more (What? Where? When?)
Timestamps and host information are metadata as well as connection lists, hashes and log entries and much more (What? Where? When?).
There exists no exact definition or list of metadata which makes it hard to prevent any exposure of it.
Metadata does not directly identify an individual.
However huge network providers are able to combine lots of metadata to traces of individuals.
@ -60,96 +55,71 @@ The connection into the Digidow network may, however, based on untrusted network
Furthermore the physical environment may not be trustworthy.
Given this environment, there are a number of threats that need to be considered when building a BS:
\begin{itemize}
\item\emph{Rogue Hardware Components}: Modified components of the BS could, depending on their
contribution to the system, collect data or create a gateway to the internal processes of the
system.
\item\emph{Rogue Hardware Components}: Modified components of the BS could, depending on their contribution to the system, collect data or create a gateway to the internal processes of the system.
Although the produced hardware piece itself is fine, the firmware on it is acting in a malicious way.
This threat addresses the manufacturing and installation of the system.
\item\emph{Hardware Modification}: Similar to rogue hardware components, the system could be modified in the target environment by attaching additional hardware.
With this attack, adversaries may get direct access to memory or to data transferred from or to
attached devices.
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually
attached via USB or similar cable connection.
It is possible to log the protocol of those attached devices via Man-in-the-Middle attack on
the USB cable.
\item\emph{Attribute Extraction}: Similar to metadata extraction, the adversary might directly
access the attributes via wiretapping the USB cable.
With this attack, adversaries may get direct access to memory or to data transferred from or to attached devices.
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
It is possible to log the protocol of those attached devices via Man-in-the-Middle attack on the USB cable.
\item\emph{Attribute Extraction}: Similar to metadata extraction, the adversary might directly access the attributes via wiretapping the USB cable.
The adversary might be able to identify an individual with those attributes.
\item\emph{Modification or aggregation of sensitive data within BS}: The program which prepares
the sernsor data for transmission could modify the data before sealing it.
\item\emph{Modification or aggregation of sensitive data within BS}: The program which prepares the sernsor data for transmission could modify the data before sealing it.
The program can also just save the sensitive data for other purposes.
\item\emph{Metadata extraction on network}: During transmission of data from the sensor into the
Digidow network, there will be some metadata generated.
An adversary could use these datasets to generate tracking logs and eventually match these logs
to individuals.
\item\emph{Replay of sensor data of a rogue BS}: When retransmitting sensor data, the
authentication of an individual could again be proven.
Any grants provided to the successfully identified individual could then be given to another
person.
\item\emph{Metadata extraction on network}: During transmission of data from the sensor into the Digidow network, there will be some metadata generated.
An adversary could use these datasets to generate tracking logs and eventually match these logs to individuals.
\item\emph{Replay of sensor data of a rogue BS}: When retransmitting sensor data, the authentication of an individual could again be proven.
Any grants provided to the successfully identified individual could then be given to another person.
\item\emph{Rogue Biometric Sensor blocks transmission}: By blocking any transmission of sensor data, any transaction within the Digidow network could be blocked and therefore the whole authentication process is stopped.
\item\emph{Rogue Personal Identity Agent}: A rogue PIA might receive the sensor data instead of the honest one.
Due to this error, a wrong identity and therefore false claims would be made out of that.
\end{itemize}
Although all of these attack vectors should be mitigated when usen in production, we will address
only a subset for the prototype.
Although all of these attack vectors should be mitigated when usen in production, we will address only a subset for the prototype.
First, we assume that only authorized personnel has access to the hardware itself.
Any other person should only interact with the hardware sensor.
Therefore any threat atacking communication between internal system components will not be
addressed.
Therefore any threat atacking communication between internal system components will not be addressed.
Furthermore, we will assume an already established bidirectional channel between BS and PIA.
Any algorithms on how the BS finds the corresponding PIA exceed the focus of this work.
On the other hand, any hardware modification including firmware upgrades should be detectable by
the system.
In addition to this detection, the BS should provably behave like it is intended to, mitigating
attacks on replaying attributes, blocking attribute transmission or aggregating them while running.
On the other hand, any hardware modification including firmware upgrades should be detectable by the prototype system.
In addition to this detection the BS should generate trust by having a provable system state before a Digidow transaction is executed.
This includes mitigations against attacks on replaying attributes, blocking attribute transmission or aggregating them while running.
\section{Prototype Concept}%
\label{sec:prototype_concept}
Given the threat model and the use cases described in \autoref{sec:definition-of-the-biometric-sensor}, we will introduce a prototype which will address many of the defined requirements.
Any threats adressing the physical integrity of the BS will, however, be omitted.
These threats can be addressed with physical intrusion and vandalism protection like they are available for ATMs.
We will instead focus on the integrity of the system when the BS is operating.
Given the threat model and the use cases described in
\autoref{sec:definition-of-the-biometric-sensor}, we will introduce a prototype which will address mainly the cryptographic aspects of trust.
Furthermore we will discuss system integrity approaches and their limitations.
\subsection{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.
There are lots of different form factors available and 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 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.
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 for TPMs, the amount of available software and the ease of installation is
better on the PC platform.
However, the support for TPMs, the amount of available software and the ease of installation is better on the PC platform.
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.
The fTPM is part of larger proprietary environments from AMD and Intel which introduces, besides
implementation flaws, additional attack surfaces for the TPM.
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.
The fTPM is part of larger proprietary environments from AMD and Intel which introduces, besides 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.
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.
It is important to also include \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.
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.
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
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.
Therefore, the kernel is packed directly into an EFI file, together with its command line 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 setup starts with two sources of trust that are formally defined:
\begin{itemize}
@ -163,11 +133,9 @@ We implicitly assume that the CPU, executing all these instructions and interact
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.
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.
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.
The disk encryption is, however, only an optional feature which can be omitted in a production
environment when there is no sensitive data on the disk that must not be revealed to the public.
The disk encryption is, however, only an optional feature which can be omitted in a production environment when there is no sensitive data on the disk that must not be revealed to the public.
The system needs to check its integrity on the OS level and summarize that by publishing an attestation message, before any transaction data is used.
\begin{figure}
@ -179,16 +147,13 @@ The system needs to check its integrity on the OS level and summarize that by pu
\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.
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.
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.
When the roots of trust are honest, the trusted environment can be constructed during booting the
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.
When the roots of trust are honest, the trusted environment can be constructed during booting the 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}%
\label{sub:integrity_and_trust_on_os_level}
@ -196,8 +161,7 @@ parameters as a result.
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.
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, i.e.
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.
This policy should also include drivers and kernel modules for external hardware like a camera for attached via USB.
@ -206,40 +170,33 @@ This policy should also include drivers and kernel modules for external hardware
The features described above take care of building a trusted environment on the system level.
DAA will take care of showing the \emph{trust} to a third party which has no particular knowledge about the BS.
In the Digidow context, the PIA should get, together to the biometrical measurements, a proof that
the BS is a trusted system acting honestly.
In the Digidow context, the PIA should get, together to the biometrical measurements, a proof that the BS is a trusted system acting honestly.
To reduce the complexity of this problem, we consider two assumptions:
\begin{enumerate}
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there
exists a bidirecional channel between BS and PIA
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there exists a bidirecional channel between BS and PIA
\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.
\end{enumerate}
For the scope of this thesis, 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 are connected locally.
The BS will eventually become a member of the group of sensors managed by the issuer.
During signup, issuer and BS (member) negotiate the membership credentials over the network.
By being a member of the DAA group, the issuer fully trusts that the BS is honest and acting
according the specification.
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.
\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may
trust the BS afterwards.}
\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may trust the BS afterwards.}
\label{fig:daa-attestation}
\end{figure}
\begin{enumerate}
\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 The BS will collect the PCR values, the integrity log and the \texttt{nonce} into an
Attestation message signed with the member's secret key (SK).
\item The BS will collect the PCR values, the integrity log and the \texttt{nonce} into an attestation message signed with the member's secret key (SK).
\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.
\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}
\autoref{fig:chainoftrust} shows how the sources of trust will be represented in the final attestation message.
@ -256,26 +213,19 @@ There exists, however, no such exact definition for hardware and firmware parts
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.
The same procedure should be done for the kernel and the used OS environment and of course, the used
software.
The same procedure should be done for the kernel and the used OS environment and of course, the used software.
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.
We can then build a cryptographic representation of the chain of trust in \autoref{fig:chainoftrust}.
The TPM has a signed certificate from its manufacturer, where it derives the endorsement key (EK)
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 TPM has a signed certificate from its manufacturer, where it derives the endorsement key (EK) 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 verifier can now check the valid membership by checking the signature of the message against
the issuer's public key (PK).
Furthermore, it can check the state of the platform by comparing the PCR values against known
values.
Finally, it can check the integrity of the running software by checking the hashes in the IMA log
against known values.
The verifier can now check the valid membership by checking the signature of the message against the issuer's public key (PK).
Furthermore, it can check the state of the platform by comparing the PCR values against known 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
PIA.
If all values are good, the BS can be trusted and the Digidow transaction can be continued at the PIA.
@ -12,13 +12,11 @@ Although the goal is to put all these features on a highly integrated system, we
\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.
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.
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.
@ -48,15 +46,13 @@ The newer Gigabyte mainboards come with a proprietary 11-pin connector which is
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{Operating System}
\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}
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.
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.
@ -91,28 +87,20 @@ Ubuntu installs Grub by default, and it is used as a fallback bootloader.
\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}.
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.
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
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.
\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}
@ -134,77 +122,91 @@ as well as the sources in the file system.
All binary resources are available as blobs which can be imported directly.
Only the command line parameters need to be defined manually.
\autoref{code:tbcommandlinetxt} shows the used command line which will be saved on
\texttt{/boot/kernel-command-line.txt}.
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},
\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.
files into the initramfs}, label={code:tbtpm2hooksh}]{../../trustedboot/tpm2-hook.sh}
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.
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.
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
\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.
\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
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.
\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
\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}
%TODO Edit pointer
Similar to trusted boot, Ubuntu requires two installed packages to support the features discussed in this section:
\begin{itemize}
\item Trusted Boot with GRUB 2.04: TPM support available; PCR mapping
\item Secure Boot with unified kernel; another PCR mapping
\item Benefits and Drawbacks of both variants
\item describe automated unlocking
\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}
Limitations due to bad implementation on BIOS-Level, no Certificate Verification Infrastructure available for TPMs? Needs to be proven for correctness.
\section{Integrity Measurement Architecture}
IMA-Settings erklären.
Available on Ubuntu, RedHat and optionally Gentoo.
