@ -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.
Firmware of hardware vendors is usually not disclosed.
Instead, vendors provide an API where an \emph{Operating System} (OS) can connect to.
Instead, vendors provide an API where an \emph{Operating System} (OS) can connect to.
Some companies deliver complete closed source devices with internet connection.
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
In such cases, the feature of closed source is to protect the intellectual property of those companies.
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.
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.
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.
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
This means that the user assumes that the provided sensitive data is handled properly for only the designated usage.
designated usage.
One may argue that a password can easily be changed when revealed to the public.
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.
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.
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}
\section{Project Digidow}
The Institute for Networks and Security is heavily using the cryptographic form of trust in the
The Institute for Networks and Security is heavily using the cryptographic form of trust in the project \emph{Digital Shadow} (Digidow).
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.
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.
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}
\begin{figure}
@ -64,25 +59,20 @@ The project furthermore aims to specify a scalable solution for nationwide or ev
\label{fig:digidow-overview}
\label{fig:digidow-overview}
\end{figure}
\end{figure}
The picture in \autoref{fig:digidow-overview} provides an overview of the Digidow network.
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
The nodes using the Digidow network and their interactions are not fully specified at the time of this writing.
this writing.
Therefore the processes may be adapted when necessary.
Therefore the processes may be adapted when necessary.
DigiDow introduces five main parties which are involved in a common authentication process.
DigiDow introduces five main parties which are involved in a common authentication process.
\begin{itemize}
\begin{itemize}
\item\emph{Individual}: The human user who wants to be identified via the Digidow network.
\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.
\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
This individual is also the owner of the PIA and should be in control of sensitive data and software on it.
software on it.
\item\emph{Issuing Authority}: This party acts as an authority for the individual's attributes.
\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.
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
After identifying the individual via the Digidow network, these attributes may be used to allow or deny a certain action.
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.
\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.
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.
\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
Therefore, the sensor records biometric data from the individual and passes it to the PIA via the Dididow network.
the Dididow network.
Sensors are not limited to sensing biometric data.
Sensors are not limited to sensing biometric data.
However, we focus in this thesis on developing a prototype of a biometric sensor (BS).
However, we focus in this thesis on developing a prototype of a biometric sensor (BS).
\end{itemize}
\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.
This defines the beginning of a Digidow trancaction.
The procedure is as follows:
The procedure is as follows:
\begin{enumerate}
\begin{enumerate}
\item The sensor will start recording a unique digital representation, triggered by the directly
\item The sensor will start recording a unique digital representation, triggered by the directly connected verifier or by hardware detection.
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 The sensor eventually finds one or a small group of eligible PIAs, where a secure
\item After receiving the digital representation of the sensor, the PIA identifies the individual if possible.
communication channel is established.
\item When identification was possible, the PIA eventually sends a proof of identification and a claim of the requested attributes to the verifier.
\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.
\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.
If successful, the verififier will grant the desired action for the asking individual.
\end{enumerate}
\end{enumerate}
The above illustration is an early draft of the whole setup and is under constant development.
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
Latest developments the whole system will be published on the Digidow project page\footnote{\url{https://digidow.eu}}.
page\footnote{\url{https://digidow.eu}}.
\section{Our Contribution: Deriving Trust from the Biometric Sensor}
\section{Our Contribution: Deriving Trust from the Biometric Sensor}
The Digidow network is designed to preserve privacy and to build trust for any user.
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.
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
So we design a prototype based on the common x86 architecture and use the cryptographic features of \emph{Trusted Platform Modules} (TPM).
\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.
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
We define a solution for installing and booting a Linux kernel with TPM-backed integrity measurements in place.
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.
We use an attached camera as example for a biometric sensor hardware to create the dataset to
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.
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:
By building a system with an integrated TPM, the system should be able to provide the following properties:
\begin{itemize}
\begin{itemize}
\item\emph{Sensor Monitoring.} The system should be able to monitor the hardware sensor (fingerprint sensor, camera, etc.) itself.
\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{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
\item\emph{Freshness of Sensor Data.} To prevent replay attacks, the system should prove that the provided biometric data is captured live.
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{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.
\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
Furthermore almost all kinds of metadata (e.\,g. information about the system or network information) should not be published.
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{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.
\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.
Corrupt systems should not be able to send valid messages.
\end{itemize}
\end{itemize}
The thesis focuses on a working setup as basis for future research.
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
Since the Digidow protocols are not yet finalized, some assumptions are defined for this work and the prototype implementation:
the prototype implementation:
\begin{itemize}
\begin{itemize}
\item Any network discovery (Step 1 in \autoref{fig:globalview}) is omitted. BS and PIA are
\item Any network discovery is omitted. BS and PIA are assumed to be reachable directly via TCP/IP.
assumed to be reachable directly via TCP/IP.
\item We look into a protocol which proves trustworthiness from BS to PIA.
\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.
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.
\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.
However this should be considered in the Digidow network protocol design.
This thesis focuses only on the trust part between BS and PIA.
This thesis focuses only on the trust part between BS and PIA.
\item Any built system is considered secure on a hardware level.
\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
Any threats which are attacking the system without changing any running software on the system may remain undetected.
may remain undetected.
This includes USB wire tapping or debug interfaces within the system revealing sensitive information.
This includes USB wire tapping or debug interfaces within the system revealing sensitive
information.
\end{itemize}
\end{itemize}
%TODO edit pointer
\section{Description of structure}
\section{Description of structure}
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this thesis.
thesis.
There is, however, scientific work that is used as scientific background to this thesis as described in \autoref{cha:background}.
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.
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}.
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.
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.
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
Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud computing.
computing.
They show in their paper how a TPM of a hypervisor can be virtualized and used by the guest operating system.
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
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with existing tools for fleet management and scalability.
existing tools for fleet management and scalability.
The concept of a well known virtual environment does, however, not apply to our contribution.
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
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.
get information about the system via anonymous attestation.
%TODO what about the integrity measurements of keylime?
%TODO what about the integrity measurements of keylime?
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
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 first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO
This standard is still in development; a draft version from February 2018 is published on the FIDO website\cite{fido18}
website\cite{fido18}
%TODO Is it noteworthy, that Xaptum claims to be compatible with FIDO ECDAA for TPM2?
%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.
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.
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
\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.
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).
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)}%
\section{Trusted Platform Module (TPM)}%
\label{sec: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.
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
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 current revision 2.0 in 2014\cite{tcg20}.
The hardware itself is strongly defined by the standard and comes in the following flavors:
The hardware itself is strongly defined by the standard and comes in the following flavors:
\begin{itemize}
\begin{itemize}
\item\emph{Dedicated device.} The TPM chip is mounted on a small board with a connector.
\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
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.
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.
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard.
Therefore, removing or changing the TPM is imossible.
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,
All recent Intel and AMD platforms supporting TPM2.0 are able to manage a TPM within the BIOS, even as mounted device.
even as mounted device.
\item\emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision.
\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
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.
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.
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
When activating this feature on BIOS level, the user gets the same behavior as when using a mounted device.
mounted device.
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator.
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator. It
It provides basically every feature of a TPM but cannot be used outside the OS.
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.
Features like Trusted Boot or in hardware persisted keys are not available.
\end{itemize}
\end{itemize}
Dedicated and mounted devices are small microcontrollers that run the TPM features in software
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.
giving the manufacturer the possibility to update their TPMs in the field.
fTPMs will be updated with the platform updates of the CPU manufacturers.
fTPMs will be updated with the platform updates of the CPU manufacturers.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it returns 23 entries\cite{mitre18}.
returns 23 entries\cite{mitre18}.
Eight of them were filed before the new standard has been released.
Eight of them were filed before the new standard has been released.
Another seven entries refer to vulnerabilities in custom TPM implementations.
Another seven entries refer to vulnerabilities in custom TPM implementations.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM
Six entries refer to the interaction between the TPM and the operating system, especially the TPM library and the shutdown/boot process.
library and the shutdown/boot process.
The last two entries describe vulnerabilities in dedicated TPM chips, which are mentioned in further detail:
The last two entries describe vulnerabilities in dedicated TPM chips, which are mentioned in further detail:
\begin{itemize}
\begin{itemize}
\item\emph{CVE-2017-15361}: TPMs from Infineon used a weak algorithm for finding primes during the RSA key generation process.
\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.
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
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.
CPU months and 2048 bit keys needed 100 CPU years.
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
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}"
\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.
\cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM implementation.
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.
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.
STM provided an update like Infineon did for their TPMs.
Intel's fTPM required a platform firmware update to solve the issue.
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.
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{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.
\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
Although the interface was formally published from the beginning, an implementation is available only since end of 2019.
available only since end of 2019.
\end{itemize}
\end{itemize}
The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still
The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still under development.
under development.
The repositories are maintained by members of TCG.
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
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.
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.
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
Unfortunately, the command line parameters changed several times during the major releases of tpm2-tools\cite{pornkitprasan19-tpmtools}.
tpm2-tools\cite{pornkitprasan19-tpmtools}.
\subsection{The Hardware}
\subsection{The Hardware}
\label{sssec:tpm-hardware}
\label{sssec:tpm-hardware}
With the previous mentioned software layers the TCG achieved independence of the underlying
With the previous mentioned software layers the TCG achieved independence of the underlying hardware.
hardware.
Hence, this design made the different flavors of TPMs possible.
Hence, these layout made the different flavors of TPMs possible
With the TPM2.0 standard, TCG defined a highly constrained hardware with a small feature set.
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.
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.
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
However, the TPMs used in this project provide just the minimal set of algorithms and also the minimal amount of memory.
minimal amount of memory.
Since TCG published its documents, several IT security teams investigated the concept and
Since TCG published its documents, several IT security teams investigated the concept and implementations of TPMs.
implementations of TPMs.
\subsection{TPM Key Hierarchies}%
\subsection{TPM Key Hierarchies}%
\label{sub:tpm_key_hierarchies}
\label{sub:tpm_key_hierarchies}
A TPM comes with four different 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.
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
Will Arthur et al.\cite{arthur15} provide a more detailed description on how the hierarchies work together.
together.
\begin{itemize}
\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{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
\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.
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.
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.
\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.
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
\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.
rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\end{itemize}
\end{itemize}
Each of the persistent hiearchies represent its own tree of keys, beginning with a root key.
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
Since TPM2.0 was published, these root keys are not hard coded anymore and can be changed if necessary.
necessary.
The process of key generation described below is similar to all three persistent hierarchies.
The process of key generation described below is similar to all three persistent hierarchies.
\subsection{Endorsement Key}%
\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.
\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.
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 key seed comes with a corresponding certificate.
This TPM certificate is signed by the TPM manufacturer by using its own root \emph{Certificate
This TPM certificate is signed by the TPM manufacturer by using its own root \emph{Certificate Authority} (CA).
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.
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.
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
Consequently it is quite easy to have different EKs at once to address privacy features also between different functions of the endorsement hierarchy.
between different functions of the endorsement hierarchy.
\section{Trusted Boot}%
\section{Trusted Boot}%
\label{sec:trusted_boot}
\label{sec:trusted_boot}
A boot process of modern platforms consists of several steps until the OS is taking over the
A boot process of modern platforms consists of several steps until the OS is taking over the platform.
platform.
During these early steps, the hardware components of the platform are initialized and some self tests are performed.
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.
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
There exists no source of trust and hence no check for integrity or intended execution in this common boot procedure.
common boot procedure.
\subsection{Platform Configuration Register}%
\subsection{Platform Configuration Register}%
\label{sub:platform_configuration_register}
\label{sub:platform_configuration_register}
The \emph{Trusted Computing Group} (TCG) introduced their first standard for a new {Trusted
The \emph{Trusted Computing Group} (TCG) introduced their first standard for a new {Trusted Computing Module} (TPM) in 2004.
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).
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:
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
The function "$||$" represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256.
either SHA1 or SHA256.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
Consequently, both hash results are available for further computations.
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.
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.
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.
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
Therefore, the BIOS/UEFI has to provide a deterministic way to compute the hash chain if there is more than one operation necessary.
more than one operation necessary.
The procedure of measurements is available since the first public standard TPM1.2.
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.
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}
\label{sub:static_root_of_trust_for_measurement}
The standard defines which part of the platform or firmware has to perform the 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
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.
BIOS/UEFI firmware has to initiate the measurement beginning with the binary representation of the
This procedure is described in the TCG standard and the platform user has to \emph{trust} the manufacturer for expected behavior.
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}.
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
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 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.
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 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,
It must measure all platform initialization code like embedded drivers, host platform firmware, etc.\@ as they are provided as part of the mainboard.
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.
If these measurements cannot be performed, the chain of trust is broken and consequently the
When PCR~0 is zeroed or filled with the hashed representation of a string of zeroes, the SRTM did not act as expected.
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.
This indicates a broken chain of trust and should only appear when using the TPM simulator.
\subsection{Platform Handover to OS}%
\subsection{Platform Handover to OS}%
\label{sub: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.
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
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.
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.
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.
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.
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
The bootloader has to continue the chain of trust by measuring the kernel and the corresponding command line parameters into the next PCRs.
command line parameters into the next PCRs.
The support and the way of how the measurements are done is not standardized.
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
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}.
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 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.
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.
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.
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
Other OS providers may not use a kernel with the required compile flags and/or do not provide userland software required to manage IMA.
userland software required to manage IMA.
The IMA project page describes the required kernel features for full support in their documentation\cite{ima-overview}.
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
The process of keeping track of system integrity becomes far more complex on the OS level compared to the boot process.
to the boot process.
First, there are far more file system resources involved in running a system.
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.
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.
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
It is clear that parallelism introduces non-determinism to the order of executing processes and, of course, the corresponding system log files.
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}.
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.
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.
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.
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}.
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
Finally, the template hash is the single value of the whole computation that will be extended into the PCR.
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.
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.
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:
The only difference between these formats lies in the used and logged metadata:
\begin{itemize}
\begin{itemize}
\item\texttt{ima-ng} uses, besides the filedata hash, also the filedata hash length, the
\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.
pathname length and the pathname to create the template hash.
\item\texttt{ima-sig} uses the same sources as ima-ng.
\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
When available, it also writes signatures of files into the log and includes them for calculating the template hash.
calculating the template hash.
\end{itemize}
\end{itemize}
The older template \texttt{ima} uses only SHA1 and is fully replaceable with the \texttt{ima-ng}
The older template \texttt{ima} uses only SHA1 and is fully replaceable with the \texttt{ima-ng} template.
template.
Therefore, it should not be used for newer applications.
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}%
\subsection{IMA Appraisal}%
\label{ssub: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.
The IMA policies define which resources are targeted with IMA.
There exist three template policies which can be used concurrently:
There exist three template policies which can be used concurrently:
\begin{itemize}
\begin{itemize}
\item\texttt{tcb}: All files owned by root will be measured.
\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
\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.
execution, all loaded kernel modules and all files opened for read by root will be measured by
\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
IMA.
corresponding public key must be provided by the system manufacturer within the provided firmware or as Machine Owner Key in shim.
\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}
\end{itemize}
In addition to these templates, the system owner can define custom policies.
In addition to these templates, the system owner can define custom policies.
Some example policies can be found in the Gentoo
Some example policies can be found in the Gentoo Wiki\cite{gentoo19}.
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.
It is, for example, useful to exclude constantly changing log files from being measured to reduce
\emph{Direct Anonymous Attestation} (DAA) is a cryptographic scheme which makes use of the functions provided by the TPM.
\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.
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
These signatures can be verified with a single public key when private keys are member of the same group.
group.
The scientific community is researching on TPM-backed DAA since the first standard of TPM went public in 2004.
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.
Since then many different approaches of DAA were discussed.
According to Camenisch et al. in \cite{camenisch16} and \cite{camenisch17}, almost all schemes were
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.
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 also includes the impementation of DAA im the TPM1.2 standard.
This section describes the concept by Camenisch et al.~\cite{camenisch16} including the
This section describes the concept by Camenisch et al.~\cite{camenisch16} including the cryptographic elements used for DAA.
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.
Unlike the description in the original paper, we describe the practical approach, which will be used in the following concept.
\subsection{Mathematical Foundations}
\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*}
\begin{equation*}
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\,\text{.}
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\,\text{.}
\end{equation*}
\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
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.
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.
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}
\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{Setup.} Choose $x\leftarrow\mathbb{Z}_q$ and $y\leftarrow\mathbb{Z}_q$ at random.
\item\emph{Sign.} Given a message $m$ and the secret key $sk$, choose $a$ at random and output
Set the secret key $sk \leftarrow(x,y)$ and the public key $pk \leftarrow(g_2^x, g_2^y)=(X,Y)$.
the signature $\sigma\leftarrow(a, a^y, a^{x+xym})=(a,b,c)$.
\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
\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)$.
\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}
\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$.
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:
According to Camenisch et al.~\cite{camenisch16}, the DAA protocol consists of three parties:
\begin{itemize}
\begin{itemize}
\item\emph{Issuer}\issuer. The issuer maintains a group and has evidence of hosts that are
\item\emph{Issuer}\issuer. The issuer maintains a group and has evidence of hosts that are members in this group.
members in this group.
\item\emph{Host}\host. The host creates a platform with the corresponding TPM \tpm{}.
\item\emph{Host}\host. The host creates a platform with the corresponding TPM \tpm{}.
Membership of groups are maintained by the 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
Only the key owner (TPM, passive) and the message author (Host, active) form a full group member.
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.
\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}
\end{itemize}
A certificate authority $\mathcal{F}_{ca}$ is providing a certificate for the issuer itself.
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}$.
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.
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.
These extensions were omitted in the following to understand the protocol more easily.
\begin{itemize}
\begin{itemize}
\item\emph{Setup.} During setup, \issuer{} is generating the issuer secret key $isk$ and the
\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.
corresponding issuer public key $ipk$. The public key is published and assumed to be known to
everyone.
\begin{enumerate}
\begin{enumerate}
\item On input \textsf{SETUP}, \issuer
\item On input \textsf{SETUP}, \issuer
\begin{itemize}
\begin{itemize}
\item generates $x,y \leftarrow\mathbb{Z}_q$ and sets $isk=(x,y)$ 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 generates a proof $\pi\sassign SPK\{(x,y):X=g_2^x\wedge Y=g_2^y\}$ that the key pair
\item registers the public key $(X,Y,\pi)$ at $\mathcal{F}_{ca}$ and stores the secret key, and
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}.
\item outputs \textsf{SETUPDONE}.
\end{itemize}
\end{itemize}
\end{enumerate}
\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.
\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}
\begin{enumerate}
\item On input \textsf{JOIN}, host \host[j] sends the message \textsf{JOIN} to \issuer.
\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
\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].
$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 Upon receiving $n$ from \issuer, \host[j] forwards $n$ to \tpm[i].
\item\tpm[i] generates the secret key:
\item\tpm[i] generates the secret key:
\begin{itemize}
\begin{itemize}
\item Check that no completed key record exists. Otherwise, it is already a member of that
\item Check that no completed key record exists. Otherwise, it is already a member of that group.
group.
\item Choose $gsk\sassign\mathbb{Z}_q$ and store the key as $(gsk, \bot)$.
\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 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].
\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\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}.
\item\host[j] stores $(a,b,c,d)$ and outputs \textsf{JOINED}.
\end{enumerate}
\end{enumerate}
\item\emph{Sign.}
\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.
After joining the group, a host \host[j] and TPM \tpm[i] can sign a message $m$ with respect to basename \bsn.
\begin{enumerate}
\begin{enumerate}
\item Upon input \textsf{SIGN}$(m,\bsn)$, \host[j] re-randomizes the CL credential:
\item Upon input \textsf{SIGN}$(m,\bsn)$, \host[j] re-randomizes the CL credential:
\begin{itemize}
\begin{itemize}
@ -550,8 +479,7 @@ Unlike the description in the original paper, we describe the practical approach
\end{enumerate}
\end{enumerate}
\item\emph{Verify.}
\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.
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
Furthermore, a revocation list \RL{} holds the private keys of corrupted TPMs, whose signatures are no longer accepted.
signatures are no longer accepted.
Upon input \textsf{VERIFY}$(m, \bsn, \sigma)$, \verifier{}
Upon input \textsf{VERIFY}$(m, \bsn, \sigma)$, \verifier{}
\begin{itemize}
\begin{itemize}
@ -563,15 +491,12 @@ Unlike the description in the original paper, we describe the practical approach
\item outputs \textsf{VERIFIED}$(f)$.
\item outputs \textsf{VERIFIED}$(f)$.
\end{itemize}
\end{itemize}
\item\emph{Link.}
\item\emph{Link.}
After proving validity of the signature, the verifier can test, whether two different messages
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.
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
On input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$, \verifier{} verifies the signatures and compares the pseudonyms contained in $\sigma, \sigma'$:
and compares the pseudonyms contained in $\sigma, \sigma'$:
\begin{itemize}
\begin{itemize}
\item Check that $\bsn\neq\bot$ and that both signatures $\sigma, \sigma'$ are valid.
\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)$,
\item Parse the signatures $\sigma\leftarrow(a,b,c,d,\pi,\nym)$, $\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 If $\nym=\nym'$, set $f\leftarrow1$, otherwise $f\leftarrow0$.
\item Output \textsf{LINK}$(f)$.
\item Output \textsf{LINK}$(f)$.
\end{itemize}
\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.
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:
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}
\begin{itemize}
\item\emph{Non-frameability}: No one can create signatures that the platform never signed, but
\item\emph{Non-frameability}: No one can create signatures that the platform never signed, but that link to messages signed from that platform.
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{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.
\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.
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
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.
(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.
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.
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.
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{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
\item\emph{Collect}: Measure sensor data (picture, fingerprint) and calculate a biometric
representation (attribute).
representation (attribute).
\item\emph{Discover}: Start a network discovery in the Digidow network and find the PIA
\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.
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{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.
\item\emph{Reset}: Set the state of the system as it was before this transaction.
\end{enumerate}
\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.
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.
Due to its narrow definition, it is affordable to protect sensitive data.
Besides that, \emph{metadata} is information generated during the whole transaction phase.
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
Timestamps and host information are metadata as well as connection lists, hashes and log entries and much more (What? Where? When?).
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.
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.
Metadata does not directly identify an individual.
However huge network providers are able to combine lots of metadata to traces of individuals.
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.
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:
Given this environment, there are a number of threats that need to be considered when building a BS:
\begin{itemize}
\begin{itemize}
\item\emph{Rogue Hardware Components}: Modified components of the BS could, depending on their
\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.
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.
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.
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.
\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
With this attack, adversaries may get direct access to memory or to data transferred from or to attached devices.
attached devices.
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually
It is possible to log the protocol of those attached devices via Man-in-the-Middle attack on the USB cable.
attached via USB or similar cable connection.
\item\emph{Attribute Extraction}: Similar to metadata extraction, the adversary might directly access the attributes via wiretapping the USB cable.
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.
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
\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 sernsor data for transmission could modify the data before sealing it.
The program can also just save the sensitive data for other purposes.
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
\item\emph{Metadata extraction on network}: During transmission of data from the sensor into the Digidow network, there will be some metadata generated.
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.
An adversary could use these datasets to generate tracking logs and eventually match these logs
\item\emph{Replay of sensor data of a rogue BS}: When retransmitting sensor data, the authentication of an individual could again be proven.
to individuals.
Any grants provided to the successfully identified individual could then be given to another person.
\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 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.
\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.
Due to this error, a wrong identity and therefore false claims would be made out of that.
\end{itemize}
\end{itemize}
Although all of these attack vectors should be mitigated when usen in production, we will address
Although all of these attack vectors should be mitigated when usen in production, we will address only a subset for the prototype.
only a subset for the prototype.
First, we assume that only authorized personnel has access to the hardware itself.
First, we assume that only authorized personnel has access to the hardware itself.
Any other person should only interact with the hardware sensor.
Any other person should only interact with the hardware sensor.
Therefore any threat atacking communication between internal system components will not be
Therefore any threat atacking communication between internal system components will not be addressed.
addressed.
Furthermore, we will assume an already established bidirectional channel between BS and PIA.
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.
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
On the other hand, any hardware modification including firmware upgrades should be detectable by the prototype system.
the system.
In addition to this detection the BS should generate trust by having a provable system state before a Digidow transaction is executed.
In addition to this detection, the BS should provably behave like it is intended to, mitigating
This includes mitigations against attacks on replaying attributes, blocking attribute transmission or aggregating them while running.
attacks on replaying attributes, blocking attribute transmission or aggregating them while running.
\section{Prototype Concept}%
\section{Prototype Concept}%
\label{sec: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.
Given the threat model and the use cases described in
Any threats adressing the physical integrity of the BS will, however, be omitted.
\autoref{sec:definition-of-the-biometric-sensor}, we will introduce a prototype which will address mainly the cryptographic aspects of trust.
These threats can be addressed with physical intrusion and vandalism protection like they are available for ATMs.
Furthermore we will discuss system integrity approaches and their limitations.
We will instead focus on the integrity of the system when the BS is operating.
\subsection{Integrity and Trust up to the Kernel}%
\subsection{Integrity and Trust up to the Kernel}%
\label{sub:integrity_and_trust_up_to_the_kernel}
\label{sub:integrity_and_trust_up_to_the_kernel}
We decided to use the PC platform as hardware base for the prototype.
We decided to use the PC platform as hardware base for the prototype.
There are lots of different form factors available and you can extend the system with a broad
There are lots of different form factors available and you can extend the system with a broad variety of sensors.
variety of sensors.
Furthermore, the platform provides full TPM support to enable cryptographic and integrity features.
Furthermore, the platform provides full TPM support to enable cryptographic and integrity features.
Finally, the platform can run almost all Linux variants and supports relevant pieces of software for this project.
Finally, the platform can run almost all Linux variants and supports relevant pieces of software for this project.
A flavour of Linux supporting all features described in this chapter, will be used as OS platform.
A flavour of Linux supporting all features described in this chapter, will be used as OS platform.
The ARM platform seem to be capable of all these features as well.
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
However, the support for TPMs, the amount of available software and the ease of installation is better on the PC platform.
better on the PC platform.
As described in \autoref{sec:trusted_platform_module_tpm_}, the TPM functions can be delivered in
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.
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.
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.
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.
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
Any recent PC platform supports TPMs and consequently trusted boot as mentioned in \autoref{sec:trusted_boot}.
\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.
The system will describe its hardware state in the PCRs 0\,--\,7 when the EFI/BIOS hands over to
the bootloader.
We use these PCR values to detect any unauthorized modifications on hardware or firmware level.
We use these PCR values to detect any unauthorized modifications on hardware or firmware level.
It is important to also include \emph{epmty} PCRs to detect added hardware on the PCI bus with an
It is important to also include \emph{epmty} PCRs to detect added hardware on the PCI bus with an Option ROM, for example.
Option ROM, for example.
With these PCR values we can seal a passphrase in the TPM.
With these PCR values we can seal a passphrase in the TPM.
The disk, secured with Full Disk Encryption (FDE), can only be accessed when the hardware
The disk, secured with Full Disk Encryption (FDE), can only be accessed when the hardware underneath is not tampered with.
underneath is not tampered with.
To further reduce the attack surface, the prototype will not use a bootloader like GRUB.
To further reduce the attack surface, the prototype will not use a bootloader like GRUB.
Instead, the kernel is run directly from the UEFI/BIOS.
Instead, the kernel is run directly from the UEFI/BIOS.
Therefore, the kernel is packed directly into an EFI file, together with its command line
Therefore, the kernel is packed directly into an EFI file, together with its command line parameters and the initial file system for booting.
parameters and the initial file system for booting.
This \emph{Unified Kernel} is directly measured by the UEFI/BIOS and is also capable of decrypting the disk, given the correct PCR values.
This \emph{Unified Kernel} is directly measured by the UEFI/BIOS and is also capable of decrypting
the disk, given the correct PCR values.
This setup starts with two sources of trust that are formally defined:
This setup starts with two sources of trust that are formally defined:
\begin{itemize}
\begin{itemize}
@ -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.
All parts contributing to the boot phase will be measured into one of the PCRs before any instruction is executed.
Decrypting the disk can then be interpreted as authorization procedure against the encrypted disk.
Decrypting the disk can then be interpreted as authorization procedure against the encrypted disk.
Consequently, only a \emph{known} kernel with a \emph{known} hardware and firmware setup underneath
Consequently, only a \emph{known} kernel with a \emph{known} hardware and firmware setup underneath can access the disk and finish the boot process in the OS.
can access the disk and finish the boot process in the OS.
The disk encryption is, however, only an optional feature which can be omitted in a production
The disk encryption is, however, only an optional feature which can be omitted in a production environment when there is no sensitive data on the disk that must not be revealed to the public.
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.
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}
\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.
\autoref{fig:measuements} illustrates how above processes extend the trust on the system.
The TPM is the cryptographic root of trust, storing all measurement results and the target values for validation.
The TPM is the cryptographic root of trust, storing all measurement results and the target values for validation.
Since the RTM is the only piece of code which lives in the platform firmware and is executed
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.
\emph{before} it is measured, it is an important part in the trust architecture of the system.
An honest RTM will measure the binary representation of itself, which makes the code at least provable afterwards.
An honest RTM will measure the binary representation of itself, which makes the code at least provable afterwards.
Finally, the CPU is assumed to execute all the code according to its specification.
Finally, the CPU is assumed to execute all the code according to its specification.
Proving correctness of the instruction set cannot be done during the boot process.
Proving correctness of the instruction set cannot be done during the boot process.
When the roots of trust are honest, the trusted environment can be constructed during booting the
When the roots of trust are honest, the trusted environment can be constructed during booting the platform with the PCR measurements.
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.
We get a trusted boot chain from firmware up to the kernel with its extensions and execution
parameters as a result.
\subsection{Integrity and Trust on OS Level}%
\subsection{Integrity and Trust on OS Level}%
\label{sub:integrity_and_trust_on_os_level}
\label{sub:integrity_and_trust_on_os_level}
@ -196,8 +161,7 @@ parameters as a result.
With the trusted kernel and IMA, we can include the file system into the trusted environment.
With the trusted kernel and IMA, we can include the file system into the trusted environment.
According to \autoref{sec:integrity_measurement_architecture}, every file will be hashed once IMA is activated and configured accordingly.
According to \autoref{sec:integrity_measurement_architecture}, every file will be hashed once IMA is activated and configured accordingly.
By enforcing IMA, the kernel allows access to only those files having a valid hash.
By enforcing IMA, the kernel allows access to only those files having a valid hash.
Consequently, every file which is required for proper execution needs to be hashed beforehand, i.e.
Consequently, every file which is required for proper execution needs to be hashed beforehand, i.e. before IMA is enforced.
before IMA is enforced.
The IMA policy in place should be \texttt{appraise\_tcb}, to analyze kernel modules, executable memory mapped files, executables and all files opened by root for read.
The IMA policy in place should be \texttt{appraise\_tcb}, to analyze kernel modules, executable memory mapped files, executables and all files opened by root for read.
This policy should also include drivers and kernel modules for external hardware like a camera for attached via USB.
This policy should also include drivers and kernel modules for external hardware like a camera for attached via USB.
@ -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.
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.
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
In the Digidow context, the PIA should get, together to the biometrical measurements, a proof that the BS is a trusted system acting honestly.
the BS is a trusted system acting honestly.
To reduce the complexity of this problem, we consider two assumptions:
To reduce the complexity of this problem, we consider two assumptions:
\begin{enumerate}
\begin{enumerate}
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there exists a bidirecional channel between BS and PIA
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.
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
\end{enumerate}
\end{enumerate}
For the scope of this thesis, the DAA protocol should be applied on a simple LAN, where all parties
For the scope of this thesis, the DAA protocol should be applied on a simple LAN, where all parties are connected locally.
are connected locally.
The BS will eventually become a member of the group of sensors managed by the issuer.
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.
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
By being a member of the DAA group, the issuer fully trusts that the BS is honest and acting according the specification.
according the specification.
The issuer will not check any group members, since they can now act independently of the issuer.
The issuer will not check any group members, since they can now act independently of the issuer.
When the BS is then authenticating an individual, the process illustrated in \autoref{fig:daa-attestation} will be executed.
When the BS is then authenticating an individual, the process illustrated in \autoref{fig:daa-attestation} will be executed.
\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may
\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may trust the BS afterwards.}
trust the BS afterwards.}
\label{fig:daa-attestation}
\label{fig:daa-attestation}
\end{figure}
\end{figure}
\begin{enumerate}
\begin{enumerate}
\item The PIA gets the public key of the BS group once and independently of any transaction.
\item The PIA gets the public key of the BS group once and independently of any transaction.
\item During the transaction, the PIA will eventually ask the BS for attestation together with a \texttt{nonce}.
\item During the transaction, the PIA will eventually ask the BS for attestation together with a \texttt{nonce}.
\item The BS will collect the PCR values, the integrity log and the \texttt{nonce} into an
\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).
Attestation message signed with the member's secret key (SK).
\item The attestation message will be sent back to the PIA.
\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
\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.
against known values, and proves the PCR values accordingly.
\end{enumerate}
\end{enumerate}
\autoref{fig:chainoftrust} shows how the sources of trust will be represented in the final attestation message.
\autoref{fig:chainoftrust} shows how the sources of trust will be represented in the final attestation message.
@ -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.
Consequently, these parts should undergo a functional analysis before they are trusted.
Trust means that, when the platform is defined trustworthy, the corresponding PCR values should be published.
Trust means that, when the platform is defined trustworthy, the corresponding PCR values should be published.
The same procedure should be done for the kernel and the used OS environment and of course, the used
The same procedure should be done for the kernel and the used OS environment and of course, the used software.
software.
There, only the kernel with its parameters have a corresponding PCR value.
There, only the kernel with its parameters have a corresponding PCR value.
Furthermore, a hash value should be published for any relevant file on the file system.
Furthermore, a hash value should be published for any relevant file on the file system.
We can then build a cryptographic representation of the chain of trust in \autoref{fig:chainoftrust}.
We can then build a cryptographic representation of the chain of trust in \autoref{fig:chainoftrust}.
The TPM has a signed certificate from its manufacturer, where it derives the endorsement key (EK)
The TPM has a signed certificate from its manufacturer, where it derives the endorsement key (EK) from.
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.
When all of the above checks against platform, OS and TPM are good, the DAA issuer will assign the
platform to the group of trusted BS.
The BS has now a member SK for signing its attestation message.
The BS has now a member SK for signing its attestation message.
The verifier can now check the valid membership by checking the signature of the message against
The verifier can now check the valid membership by checking the signature of the message against the issuer's public key (PK).
the issuer's public key (PK).
Furthermore, it can check the state of the platform by comparing the PCR values against known values.
Furthermore, it can check the state of the platform by comparing the PCR values against known
Finally, it can check the integrity of the running software by checking the hashes in the IMA log against known values.
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.
PCR 10 represents the end of the hash chain fed by the IMA log entries.
If all values are good, the BS can be trusted and the Digidow transaction can be continued at the
If all values are good, the BS can be trusted and the Digidow transaction can be continued at the 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.
\autoref{fig:prototype} shows the setup on a connection level.
To show the features of DAA, it is necessary to have three independent systems which are connected via a TCP/IP network.
To show the features of DAA, it is necessary to have three independent systems which are connected via a TCP/IP network.
Every host is connected via ethernet to the other systems.
Every host is connected via ethernet to the other systems.
To keep the setup minimal, the IP addresses are static and internet is only required during
To keep the setup minimal, the IP addresses are static and internet is only required during installation.
installation.
Hence, Service Discovery is done statically, every host knows the IP addresses and functions of each other directly.
Hence, Service Discovery is done statically, every host knows the IP addresses and functions of each other directly.
\section{Hardware Setup}
\section{Hardware Setup}
For demonstrating remote attestation via DAA over a simple network infrastructure, we use three
For demonstrating remote attestation via DAA over a simple network infrastructure, we use three systems with similar configuration.
systems with similar configuration.
\autoref{tab:systems} shows the specification of these systems.
\autoref{tab:systems} shows the specification of these systems.
We decided to order one system with an AMD processor in it to find differences in handling the TPM between Intel and AMD systems.
We decided to order one system with an AMD processor in it to find differences in handling the TPM between Intel and AMD systems.
All features used in this thesis were available on both platform types, so there were no differences found.
All features used in this thesis were available on both platform types, so there were no differences found.
@ -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.
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.
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.
The OS needs to fulfill three requirements for this prototype.
First, the TPM must be supported by the kernel.
First, the TPM must be supported by the kernel.
Second, the OS has to support a recent version of the TPM software stack (TSS 3.0.x or newer at the
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}
point of writing) for using the Xaptum ECDAA\cite{xaptum21}
project with enabled hardware TPM.
project with enabled hardware TPM.
Similarly, the \texttt{tpm2-tools} must be available in a version newer than \texttt{4.0.0}.
Similarly, the \texttt{tpm2-tools} must be available in a version newer than \texttt{4.0.0}.
Finally, the support for the Integrity Measurement Architecture (IMA) must be activated in the
Finally, the support for the Integrity Measurement Architecture (IMA) must be activated in the kernel and supported by the OS.
kernel and supported by the OS.
This feature is available in the mainline Linux kernel.
This feature is available in the mainline Linux kernel.
However, the corresponding kernel compile parameters must be set.
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}
\section{Trusted Boot}
By default, every mainboard with support for TPM2.0 must support trusted boot.
By default, every mainboard with support for TPM2.0 must support trusted boot.
When a TPM becomes available, the UEFI/BIOS itself takes all required measures until the 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).
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.
Since Ubuntu uses GRUB 2.04 as bootloader which has TPM support by default, trusted boot just to be
In this case, GRUB will be measured from the BIOS to the PCRs 4 and 5, as shown in \autoref{tab:PCR}.
enabled in the GRUB configuration.
Grub itself uses PCR 8 for executed commands, the kernel command line and all commands forwarded to kernel modules.
In this case, GRUB will be measured from the BIOS to the PCRs 4 and 5, as shown in
PCR 9 is used to measure all files read by GRUB\cite{grub19}.
\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.
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
Therefore we replace the bootloader EFI file with a blob containing all required information to load the kernel directly.
load the kernel directly.
This kernel decrypts the disk and boots the remaining system.
This kernel decrypts the disk and boots the remaining system.
Pawit Pornkitprasam \cite{pornkitprasan19-diskencryption}, \cite{pornkitprasan19-tpmtools} and Karl
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
O from Tevora \cite{tevora-secureboot} introduced the concept of a \emph{Unified Kernel} for Ubuntu
and Arch respectively.
and Arch respectively.
This large EFI file contains the initramfs, kernel command line and the kernel itself.
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
\autoref{tab:efilayout} shows the content of the EFI blob with the corresponding offset addresses as well as the sources in the file system.
as well as the sources in the file system.
\begin{table}
\begin{table}
\centering
\centering
\begin{footnotesize}
\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.
All binary resources are available as blobs which can be imported directly.
Only the command line parameters need to be defined manually.
Only the command line parameters need to be defined manually.
\autoref{code:tbcommandlinetxt} shows the used command line which will be saved on
The following shell scripts are tested on a Ubuntu 20.04 server minimal installation on all three devices.
\texttt{/boot/kernel-command-line.txt}.
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.
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.
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
Therefore, the initramfs needs the luks binaries as well as the TPM software stack to unseal the passhrase with the PCR registers.
passhrase with the PCR registers.
The unseal operation itself is then done with \autoref{code:tbpassphrasesh}, which also needs to exist in the initramfs.
The unseal operation itself is then done with \autoref{code:tbpassphrasesh}, which also needs to
\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}
exist in the initramfs.
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{passphrase-from-tpm.sh}: Initramfs-script to
\lstinputlisting[float,language=bash, caption={\texttt{tpm2-hook.sh}: Script copying required TSS files into the initramfs}, label={code:tbtpm2hooksh}]{../../trustedboot/tpm2-hook.sh}
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}
Next, a new key for FDE is created by using the random number generator of the TPM.
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
It is saved in clear text in \texttt{/root/keys} to be able to update the sealing operation when new PCR values are used.
new PCR values are used.
The passphrase needs to be available, when an update resulted in new PCR values.
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.
In this case, the passphrase in the TPM would not be accessible anymore.
\autoref{code:tbcreatelukssh} shows the script for creating the LUKS passphrase.
\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.
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.
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
Finally, \autoref{code:tbupdatekernelsh} shows how the unified kernel is created with the command \texttt{objcopy} and copied on the EFI disk partition.
\texttt{objcopy} and copied on the EFI disk partition.
The offset addresses need to be chosen according to the size of the included blobs.
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}.
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{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{create-luks-tpm.sh}: Script to create a new
\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.
\lstinputlisting[float,language=bash, caption={\texttt{install.sh}: Script to install Trusted Boot
The FDE decryption with the TPM will of course fail, since there is no sealed passphrase available yet.
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.
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
\autoref{code:tbupdatetpmsh} shows how the passphrase is sealed into the TPM with all relevant PCR registers.
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}
\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.
This implementation also supports updating the linux kernel.
The result is a trusted boot chain which ensures, that the system only has access to the encrypted
The required steps for keeping trusted boot intact are as follows:
disk when the kernel with its parameter is known---and therefore trusted.
\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}
\begin{itemize}
\item Trusted Boot with GRUB 2.04: TPM support available; PCR mapping
\item\texttt{auditd} to analyze system calls of processes, helpful when using IMA, and
\item Secure Boot with unified kernel; another PCR mapping
\item\texttt{attr} for showing the file IMA hashes, which are saved as extended file attributes.
\item Benefits and Drawbacks of both variants
\item describe automated unlocking
\end{itemize}
\end{itemize}
Limitations due to bad implementation on BIOS-Level, no Certificate Verification Infrastructure available for TPMs? Needs to be proven for correctness.
IMA-Settings erklären.
\section{Integrity Measurement Architecture}
Available on Ubuntu, RedHat and optionally Gentoo.
Available on Ubuntu, RedHat and optionally Gentoo.
