@ -9,11 +9,11 @@ Many of them automate services to the public like managing the bank account, pub
The list of digital service is endless and will still grow in the future.
The list of digital service is endless and will still grow in the future.
The downside of all these digital services is that using these services generate a lot of data.
The downside of all these digital services is that using these services generate a lot of data.
Besides of the intended exchange of information, many of the services try to extract metadata as well.
Besides the intended exchange of information, many of the services try to extract metadata as well.
Metadata answers some of the following questions.
Metadata answers some of the following questions.
Which IP is connected?
Which IP address is sending or receiving?
What kind of device is that?
What kind of device is that?
Is the software of the device up to date?
Is the software of the device up to date?
Was this device here in the past?
Was this device here in the past?
What else did the owner on the device?
What else did the owner on the device?
This set of questions is not complete.
This set of questions is not complete.
@ -26,13 +26,18 @@ Often a proprietary layer is used either on the client or the server side to hid
The result is a piece of software which is provided as binary and the user cannot prove what this software is exactly doing besides the visible front end features.
The result is a piece of software which is provided as binary and the user cannot prove what this software is exactly doing besides the visible front end features.
There are of course other purposes for delivering software in a closed source manner.
There are of course other purposes for delivering software in a closed source manner.
Firmware of hardware vendors is usually not disclosed and provide an API where an \emph{Operating System} (OS) can connect to.
Firmware of hardware vendors is usually not disclosed.
Instead, vendors provide an API where an \emph{Operating System} (OS) can connect to.
Some companies deliver complete closed source devices with internet connection.
Some companies deliver complete closed source devices with internet connection.
In this case a user has no chance to detect what the device is doing in this very moment.
In such cases, the feature of closed source is to protect the intellectual property of those
companies.
Any user of these closed source products must use them as black box and needs to \emph{trust} the
vendor that it is working correctly.
There is, however, a special need for users to keep sensitive data secret.
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 sensible data is handled properly for only the designated usage.
This means that the user assumes that the provided sensitive data is handled properly for only the
designated usage.
One may argue that a password can easily be changed when revealed to the public.
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.
@ -45,84 +50,111 @@ This thesis will therefore use the term \emph{trust} as a cryptographic chain of
By providing a Chain of Trust, a user can ask the vendor for a certification of its devices and consequently comprehend the state of the system at hand.
By providing a Chain of Trust, a user can ask the vendor for a certification of its devices and consequently comprehend the state of the system at hand.
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 project \emph{Digital Shadow} (DigiDow).
The Institute for Networks and Security is heavily using the cryptographic form of trust in the
project \emph{Digital Shadow} (Digidow).
DigiDow introduces an electronic authentication system, which aims to minimize any generation of metadata on system and network level and hence maximizes the level of privacy for their users.
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.
\caption{Overview of the DigiDow authentication process}
\caption{Overview of the Digidow authentication process}
\label{fig:globalview}
\label{fig:globalview}
\end{figure}
\end{figure}
The picture in \autoref{fig:globalview} provide an overview of the authentication process within DigiDow.
The picture in \autoref{fig:globalview} provides an overview of the authentication process within
Digidow.
At the time of this writing, the exact order and definition of every step is not yet finished and may change during the progress of the whole project.
At the time of this writing, the exact order and definition of every step is not yet finished and may change during the progress of the whole project.
DigiDow introduces three main parties which are involved in a common authentication process.
DigiDow introduces three main parties which are involved in a common authentication process.
\begin{itemize}
\begin{itemize}
\item\emph{Personal Identity Agent} (PIA): The PIA is the digital shadow of an individual who wants to be authenticated.
\item\emph{Personal Identity Agent} (PIA): The PIA is the digital shadow of an individual who wants to be authenticated.
This individual is also the owner of the PIA and should be able to manage sensible data and software on it.
This individual is also the owner of the PIA and should be able to manage sensitive data and
software on it.
\item\emph{Verifier} (V): This is the party that verifies the whole authentication process and may finally trigger the desired action if all went well.
\item\emph{Verifier} (V): This is the party that verifies the whole authentication process and may finally trigger the desired action if all went well.
\item\emph{Biometric Sensor} (BS): For Authentication, an individual has to be uniquely identified.
\item\emph{Biometric Sensor} (BS): For authentication, an individual has to be uniquely
The BS records therefore biometric data from the individual and passes it into the DidiDow network.
identified.
Therefore, the BS records biometric data from the individual and passes it into the DidiDow
network.
\end{itemize}
\end{itemize}
For scalability, we assume that there are large numbers of all parties.
For scalability, we assume that there are large numbers of all parties.
The illustration also shows a draft of how which steps need to be performed between above mentioned parties during an authentivation process.
The illustration also shows a draft of how which steps need to be performed between above mentioned
parties during an authentication process.
\begin{enumerate}
\begin{enumerate}
\item[(1)] All relevant parties need to find each other via the DigiDow network. When this step is finished, it is assumed that for every step the individual hosts for communication are identifiable and ready for the authentication process.
\item[(1)] All relevant parties need to find each other via the Digidow network. When this step
\item[(2)(3)] Eventually an individual wants to authenticate itself and the BS records the biometric data.
is finished, it is assumed that for every step the individual hosts for communication are
identifiable and ready for the authentication process.
\item[(2)(3)] Eventually an individual wants to authenticate itself and the BS records the biometric data.
With this data and a corresponding unique ID, the BS knows which PIA to contact.
With this data and a corresponding unique ID, the BS knows which PIA to contact.
\item [(4)(5)(6)] The BS contacts the PIA and sends the recorded data set as well as a cryptographic signature to proof that the sensor is valid and this is an honest authentication attempt.
\item [(4)(5)(6)] The BS contacts the PIA and sends the recorded dataset as well as a
\item [(7)] The PIA proofs authenticity of the received signature and compares the data with its own saved biometric data sets.
cryptographic signature to proof that the sensor is valid and this is an honest authentication
attempt.
\item [(7)] The PIA proves authenticity of the received signature and compares the data with its
own saved biometric datasets.
Assuming all is correct, the PIA certifies that the person standing in front of the BS is indeed the owner of the PIA.
Assuming all is correct, the PIA certifies that the person standing in front of the BS is indeed the owner of the PIA.
The verifier checks the certification and finally triggers the desired action for the asking individual.
The verifier checks the certification and finally triggers 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.
A more recent version of the whole system can be found at the DigiDow Project Page\footnote{\url{https://digidow.eu}}.
A more recent version of the whole system can be found at the Digidow project
page\footnote{\url{https://digidow.eu}}.
This thesis will contribute a prototype setup the Biometric Sensor and discuss how to create trust into this system.
This thesis will contribute a prototype setup the Biometric Sensor and discuss how to create trust into this system.
\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 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 the \emph{Trusted Platform Module} (TPM).
So we design a prototype based on the common x86 architecture and use the cryptographic features of
\emph{Trusted Platform Modules} (TPM).
A TPM is a passive crypto coprocessor available on many modern PC platforms which has an independent storage for crypto variables and provides functions to support above mentioned features.
A TPM is a passive crypto coprocessor available on many modern PC platforms which has an independent storage for crypto variables and provides functions to support above mentioned features.
We define a solution for installing and booting a Linux Kernel with TPM-backed integrity measurements in place.
We define a solution for installing and booting a Linux Kernel with TPM-backed integrity measurements in place.
We use an attached camera as example for a biometric sensor hardware to create the data set to continue with the authentication process.
We use an attached camera as example for a biometric sensor hardware to create the dataset to
This data set 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 proof that the provided biometric data is captured live.
\item\emph{Freshness of Sensor Data.} To prevent replay attacks, the system should prove that
\item\emph{Integrity of Sensor Data.} As it is possible for an adversary to modify the provided data during the capturing process, integrity should guarantee that the data originates from the BS.
the provided biometric data is captured live.
\item\emph{Confidentiality of Sensor Data.} It should not be possible to eavesdrop any sensitive data out of the system.
\item\emph{Integrity of Sensor Data.} As it is possible for an adversary to modify the provided
Furthermore almost all kinds of metadata (e.\,g. information about the system or network information) should not be published
data during the identification process, integrity should guarantee that the data is unmodified
\item\emph{Anonymity.} Given a message from a BS, an adversary should not be able to detect which BS created it
until identification is done.
\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.
\item\emph{Confidentiality of Sensor Data.} It should not be possible to eavesdrop any sensitive data out of the system.
Furthermore almost all kinds of metadata (e.\,g. information about the system or network
information) should not be published.
\item\emph{Anonymity.} Given a message from a BS, an adversary should not be able to detect
which BS created it.
\item\emph{Unforgeability.} Only honest BS should be able to be part of the Digidow network.
Corrupt systems should not be able to send valid messages.
\end{itemize}
\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 the prototype implementation:
Since the Digidow protocols are not yet finalized, some assumptions are defined for this work and
the prototype implementation:
\begin{itemize}
\begin{itemize}
\item Any network discovery (Step 1 in \autoref{fig:globalview}) is omitted. BS and PIA are assumed to be reachable directly via TCP/IP
\item Any network discovery (Step 1 in \autoref{fig:globalview}) is omitted. BS and PIA are
\item We look into a protocol which proofs trustworthiness from BS to PIA.
assumed to be reachable directly via TCP/IP.
Any further proofs necessary for DigiDow's Verifier are also not focused in this thesis.
\item We look into a protocol which proves trustworthiness from BS to PIA.
\item The sensible data sets will be transmitted in cleartext between BS and PIA.
Any further proofs necessary for a Digidow Verifier are also not focused in this thesis.
\item The sensitive datasets will be transmitted in cleartext between BS and PIA.
It is considered easy to provide an additional layer of encryption for transportation.
It is considered easy to provide an additional layer of encryption for transportation.
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 may be not detected. This includes USB wire tapping or debug interfaces within the system revealing sensible information.
Any threats which are attacking the system without changing any running software on the system
may remain undetected.
This includes USB wire tapping or debug interfaces within the system revealing sensitive
information.
\end{itemize}
\end{itemize}
%TODO edit pointer
%TODO edit pointer
\section{Description of structure}
\section{Description of structure}
In Chapter~\autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this thesis.
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this
thesis.
There is, however, scientific work that is used as scientific background to this thesis as described in \autoref{cha:background}.
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}.
@ -133,17 +165,21 @@ 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 el.\,al.\@ developed a full featured trusted computing environment for cloud computing.
Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud
computing.
They show in their paper how a TPM of a hypervisor can be virtualized and used by the guest operating system.
They show in their paper how a TPM of a hypervisor can be virtualized and used by the guest operating system.
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with existing tools for fleet management and scalability\cite{keylime16}.
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with
existing tools for fleet management and scalability.
The concept of a well known virtual environment does, however, not apply to our contribution.
The concept of a well known virtual environment does, however, not apply to our contribution.
Furthermore, the the system should be self contained as good as possible and it should be possible to get information about the system via anonymous attestation.
Furthermore, the system should be self contained as good as possible and it should be possible to
get information about the system via anonymous attestation.
%TODO what about the integrity measurements of keylime?
%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 FIDO's website\footnote{/url{https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html}}.
This standard is still in development; a draft version from February 2018 is published on the FIDO
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 extend trust from the TPM over the UEFI\,/\,BIOS up to the Operating System.
\emph{Trusted Boot} and the \emph{Integrity Measurement Architecture} (IMA) are two approaches to
extend trust from the TPM over the UEFI\,/\,BIOS up to the OS.
The generated trust should then be provable by an external party---in our case the PIA---by using the protocol of \emph{Direct Anonymous Attestation} (DAA).
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 current revision is 2.0\cite{tcg20}.
This module is part of a standard developed by the Trusted Computing Group (TCG), which released
the current revision 2.0 in 2014\cite{tcg20}.
The hardware itself is strongly defined by the standard and comes in the following flavors:
The hardware itself is strongly defined by the standard and comes in the following flavors:
%TODO find source of that claim (TPM variants)
\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 user since it is easy to disable trusted computing or switch to another TPM.
The user can plug it into a compatible compute platform. This gives most control to the end
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard. Therefore any hardware modification is impossible.
user since it is easy to disable trusted computing or to switch to another TPM.
However most PC platforms provide BIOS features to control the TPM.
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard.
\item\emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision.
Therefore, removing or changing the TPM is imossible.
Firmware means in this context an extension of the CPU instruction set which provides the features of a TPM.
All recent Intel and AMD platforms supporting TPM2.0 are able to manage a TPM within the BIOS,
even as mounted device.
\item\emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision.
Instead of using a dedicated Coprocessor for the TPM features, this variant lives as firmware
extension within Intel's Management Engine or AMD's Platform Security Processor.
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, all features of Trusted Computing are available to the user.
When activating this feature on BIOS level, the user gets the same behavior as when using a
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator. It provides basically every feature of a TPM but cannot be used outside the operating system. Features like Trusted Boot or in hardware persisted keys are not available.
mounted device.
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator. It
provides basically every feature of a TPM but cannot be used outside the OS.
Features like Trusted Boot or in hardware persisted keys are not available.
\end{itemize}
\end{itemize}
Even the dedicated devices are small microcontrollers that run the TPM features in software giving the manufacturer the possibility to update their TPMs in the field.
Dedicated and mounted devices are small microcontrollers that run the TPM features in software
fTPMs will be updated with the Microcode updates of the CPU manufacturers.
giving the manufacturer the possibility to update their TPMs in the field.
fTPMs will be updated with the platform updates of the CPU manufacturers.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it returns 23 entries\footnote{\url{https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tpm}, last accessed on 15.05.2021}.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it returns 23 entries\footnote{\url{https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tpm}, last accessed on 15.05.2021}.
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 library and the shutdown\,/\,boot process.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM
library and the shutdown/boot process.
The last two entries describe vulnerabilities in dedicated TPM chips, which are mentioned in further detail:
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 \cite{Nemec17}, 1048 bit keys required in the worst case scenario 3 CPU months and 2048 bit keys needed 100 CPU years.
According to Nemec et al.\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3
CPU months and 2048 bit keys needed 100 CPU years.
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
\item\emph{CVE-2019-16863}: This vulnerability is also known as \emph{TPM fail} (\cite{moghimi20-tpmfail}) and shows how to get an Elliptic Curve private key via timing and lattice attacks.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "\emph{TPM fail}"
The authors found TPMs from STMicorelectronics vulnerable, as well as Intel's fTPM implementation.
\cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and
lattice attacks.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM
implementation.
Infineon TPM show also some non-expected behaviour, but this could not be used for data exfiltration.
Infineon TPM show also some non-expected behaviour, but this could not be used for data exfiltration.
STMicro provided an update like Insineon did for the TPMs.
STM provided an update like Infineon did for their TPMs.
Intel's fTPM lives in the Management Engine, which requires a BIOS update from the mainboard manufacturer to solve the issue.
Intel's fTPM required a platform firmware update to solve the issue.
\end{itemize}
\end{itemize}
@ -51,55 +65,65 @@ The last two entries describe vulnerabilities in dedicated TPM chips, which are
\label{sssec:tpm-usage}
\label{sssec:tpm-usage}
On top of the cryptographic hardware, the TCG provides several software interfaces for application developers:
On top of the cryptographic hardware, the TCG provides several software interfaces for application developers:
\begin{itemize}
\begin{itemize}
\item\emph{System API (SAPI).} The SAPI is a basic API where the developer has to handle the resources within the application. However this API provides the full set of features.
\item\emph{System API (SAPI).} The SAPI is a basic API where the developer has to handle the
resources within the application.
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 available since end of 2019.
Although the interface was formally published from the beginning, an implementation is
available only since end of 2019.
\end{itemize}
\end{itemize}
The reference implementation of these APIs is published at Github\cite{tpmsoftware20} and is still under development.
The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still
At the point of writing stable interfaces are available for C and C++, but other languages like Rust, Java, C\# and others will be served in the future.
under development.
The repositories are maintained by members of TCG.
At the point of writing stable interfaces are available for C and C++, but other languages like
Rust, Java, C\# will be served in the future.
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 tpm2-tools\cite{pornkitprasan19-tpmtools}.
Unfortunately, the command line parameters changed several times during the major releases of
tpm2-tools\cite{pornkitprasan19-tpmtools}.
\subsection{The Hardware}
\subsection{The Hardware}
\label{sssec:tpm-hardware}
\label{sssec:tpm-hardware}
The TCG achieved with the previous mentioned software layers independence of the underlying hardware.
With the previous mentioned software layers the TCG achieved independence of the underlying
Hence, TCG provided different flavors of of the TPM
hardware.
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.
TCG defined with the TPM2.0 standard 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 provided just the minimal set of algorithms and also the minimal amount of memory.
However, the TPMs used in this project provide just the minimal set of algorithms and also the
minimal amount of memory.
Since TCG published its documents, several IT security teams investigated concept and implementations of TPMs.
Since TCG published its documents, several IT security teams investigated the concept and
implementations of TPMs.
\subsection{TPM Key Hierarchies}%
\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 therefore 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 workt together.
Will Arthur et al.\cite{arthur15} provide a more detailed description on how the hierarchies work
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 department or the end user and so is the Storage Hierarchy of the TPM.
\item\emph{Storage Hierarchy}: The storage of a platform is controlled by either an IT
department or the end user and so is the storage hierarchy of the TPM.
It offers non-privacy related features to the platform although the user may disable the TPM for her own use.
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 rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\item\emph{NULL Hierarchy}: The NULL hierarchy is the only non-persistent hierarchy when
rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\end{itemize}
\end{itemize}
Each of the persistent hiearchies represent an 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 TPM 2.0 was published these root keys are not hard coded anymore and can be changed if necessary.
Since TPM2.0 was published, these root keys are not hard coded anymore and can be changed if
The process on key generation described below is similar to all three persistent hierarchies.
necessary.
The process of key generation described below is similar to all three persistent hierarchies.
\subsection{Endorsement Key}%
\subsection{Endorsement Key}%
\label{sub:endorsement_key}
\label{sub:endorsement_key}
The \emph{Endorsement Key} (EK) is the root key for the corresponding hierarchy.
The \emph{Endorsement Key} (EK) is the root key for the corresponding hierarchy.
@ -109,48 +133,51 @@ 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.
Finally this TPM certificate is singed by the TPM manufacturer by using its own root \emph{Certificate Authority} (CA).
This TPM certificate is signed by the TPM manufacturer by using its own root \emph{Certificate
Authority} (CA).
When the platform user wants to create a new EK, a \emph{Key Derivation Function} (KDF) generates this new EK such that the TPM certificate identifies it and the chain keeps intact.
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 between different functions of the endorsement hierarchy.
Consequently it is quite easy to have different EKs at once to address privacy features also
between different functions of the endorsement hierarchy.
\begin{itemize}
\item Attestation Identity Key
\item Key management
\end{itemize}
\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 taking over the platform.
A boot process of modern platforms consists of several steps until the OS is taking over the
platform.
During these early steps, the hardware components of the platform are initialized and some self tests are performed.
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.
In this common boot procedure exists no source of trust and hence no check for integrity or intended execution.
There exists no source of trust and hence no check for integrity or intended execution in this
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 in 2004 their first standard for a new {Trusted Computing Module} (TPM).
The \emph{Trusted Computing Group} (TCG) introduced their first standard for a new {Trusted
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).
Computing Module} (TPM) in 2004.
\emph{Measuring} means in this context a simple cryptographic extension function which works described in formula \ref{form:PCR-measurement}
As part in this standard, TCG defined a procedure where every step in the early boot process is
measured and saved in a \emph{Platform Configuration Register} (PCR).
In this context, \emph{Measuring} means a simple cryptographic extension function:
The function of $||$ represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256 hash.
The function "$||$" represents a concatenation of two binary strings and the hash function is
either SHA1 or SHA256.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
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 in addition 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 change.
One can clearly see that the resulting hash will also change when the order of computations changes.
Therefore, the BIOS\,/\,UEFI has to provide a deterministic way to compute the hash chain if there is more than one operation necessary.
Therefore, the BIOS/UEFI has to provide a deterministic way to compute the hash chain if there is
The procedure of measurements is available since the first public standard of TPM, version 1.2.
more than one operation necessary.
For the recent TPM2.0 standard, the process was only extended with the support for the newer SHA256 standard.
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.
A PCR is now useful for a sequence of measurements with similar purpose.
A PCR is now useful for a sequence of measurements with similar purpose.
When, for example, a new bootloader is installed on the main disk, the user wants to detect this with a separate PCR value.
When, for example, a new bootloader is installed on the main disk, the user wants to detect this with a separate PCR value.
The measured firmware BLOBs may be still the same.
The measured firmware blobs may still be the same.
So the TPM standard defines 24 PCRs for the PC platform, each with a special role and slightly different feature set.
So the TPM standard defines 24 PCRs for the PC platform, each with a special role and slightly different feature set.
The purpose of every PCR is well defined in Section 2.3.3 of the \emph{TCG PC Client Platform Firmware Profile}\cite{tcg-pc19} and shown in table \ref{tab:PCR}.
The purpose of every PCR is well defined in Section 2.3.3 of the \emph{TCG PC Client Platform Firmware Profile}\cite{tcg-pc19} and shown in table \ref{tab:PCR}.
Especially those PCRs involved in the boot process must only be reset according to a platform reset.
Especially those PCRs involved in the boot process must only be reset according to a platform reset.
@ -173,7 +200,7 @@ During booting and running the system these registers can only be \emph{extended
5 & Boot Manager code configuration and data and GPT\,/\,partition table\\
5 & Boot Manager code configuration and data and GPT\,/\,partition table\\
6 & Host platform manufacturer specific \\
6 & Host platform manufacturer specific \\
7 & Secure Boot Policy \\
7 & Secure Boot Policy \\
8-15 & Defined for use by the static OS \\
8--15 & Defined for use by the static OS \\
16 & Debug \\
16 & Debug \\
17--23 & Application\\
17--23 & Application\\
\bottomrule
\bottomrule
@ -228,7 +255,7 @@ The IMA project page describes the required Kernel features for full support in
The process of keeping track of system integrity becomes compared to the boot process far more complex on the OS level.
The process of keeping track of system integrity becomes compared to the boot process far more complex on the OS level.
First, there are far more file system resources involved in running a system.
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 course the corresponding system log files.
It is clear that parallelism introduces non-determinism to the order of executing processes and of course the corresponding system log files.
Hence when using PCRs, this non-determinism results in different values, as stated in \autoref{sub:platform_configuration_register}.
Hence when using PCRs, this non-determinism results in different values, as stated in \autoref{sub:platform_configuration_register}.
@ -272,7 +299,7 @@ The only difference between these formats lie in the used and logged metadata:
\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 writes also signatures of files into the log and includes them for calculating the template hash.
When available, it writes also signatures of files into the log and includes them for calculating the template hash.
\end{itemize}
\end{itemize}
The older template \texttt{ima} uses only SHA1 and is fully replaceyble with the \texttt{ima-ng} template.
The older template \texttt{ima} uses only SHA1 and is fully replaceyble with the \texttt{ima-ng} template.
Therefore, it should not be used for newer applications.
Therefore, it should not be used for newer applications.
\ToDo{boot aggregate beschreiben}
\ToDo{boot aggregate beschreiben}
\subsection{IMA Appraisal}%
\subsection{IMA Appraisal}%
@ -302,8 +329,9 @@ In addition to these templates, the system owner can define custom policies.
Some example policies can be found at the Gentoo Wiki\footnote{\url{https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture/Recipes}}.
Some example policies can be found at the Gentoo Wiki\footnote{\url{https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture/Recipes}}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless in the measurement log.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless in the measurement log.
\subsection{IMA extensions}%
\subsection{IMA Extensions}%
\label{ssub:ima_extensions}
\label{ssub:ima_extensions}
Extended Verification Module (EVM)
\section{Direct Anonymous Attestation}%
\section{Direct Anonymous Attestation}%
\label{sec:direct_anonymous_attestation}
\label{sec:direct_anonymous_attestation}
@ -312,7 +340,7 @@ DAA implements the concept of group signatures, where multiple secret keys can c
These signatures can be verified with a single public key, when these private keys are member of the same group.
These signatures can be verified with a single public key, when these private keys are member of the same group.
The scientific community is researching on TPM-backed DAA since the first standard of TPM went public in 2004.
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 the discussion in \cite{camenisch16} and \cite{camenisch17} almost all schemes were proven insecure, since many of them had bugs in the protocol or allowed trivial public\,/\,secret key pairs.
According to the discussion in \cite{camenisch16} and \cite{camenisch17} almost all schemes were proven insecure, since many of them had bugs in the protocol or allowed trivial public\,/\,secret key pairs.
This includes also the impementation of DAA im the TPM1.2 standard.
This includes also the impementation of DAA im the TPM1.2 standard.
In this chapter we define the constraints for the Biometric Sensor as well as a generic attempt for a prototype.
In this chapter we define the constraints for the Biometric Sensor as well as a generic attempt for a prototype.
The constraints include a discussion about the attack vectors to the BS.
The constraints include a discussion about the attack vectors to the BS.
We explain furthermore which requirements can and will be addressed and how sensible data is processed in the BS.
We explain furthermore which requirements can and will be addressed and how sensitive data is
processed in the BS.
\section{Definition of the Biometric Sensor}
\section{Definition of the Biometric Sensor}
\label{sec:definition-of-the-biometric-sensor}
\label{sec:definition-of-the-biometric-sensor}
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 (e.g. a checkpoint in an airport or as access control system at a building) to interact directly with the DigiDow users.
According to the schema shown in \autoref{fig:globalview}, the BS will be placed in a public area
There, the BS is the gateway to the DigiDow network.
(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 is the gateway 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.
@ -16,7 +19,9 @@ The following enumeration shows the steps of the BS for identifying the interact
\begin{enumerate}
\begin{enumerate}
\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 representation (Attribute).
\item\emph{Collect}: Measure sensor data (picture, fingerprint) and calculate a biometric representation (Attribute).
\item\emph{Discover}: Start a network discovery in the DigiDow network and find the PIA corresponding to the present person. It may be necessary to interact with more than one PIA within this and the next step.
\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 step.
\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}
@ -30,15 +35,15 @@ There should only be a connection to the Digidow network for transmitting the re
This assumption of autonomy provides independence to the probably diverse target environments and use cases.
This assumption of autonomy provides independence to the probably diverse target environments and use cases.
In addition to autonomy, the BS should also ensure proper handling of received and generated data.
In addition to autonomy, the BS should also ensure proper handling of received and generated data.
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, hash sums and log entries and much more (What? Where? When?)
Timestamps and host information are metadata as well as connection lists, hash sums and log entries and much more (What? Where? When?)
There exists no exact definition or list of metadata which makes it hard to prevent any exposure of it.
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 notwork providers are able to combine lots of metadata to traces of individuals.
However huge notwork providers are able to combine lots of metadata to traces of individuals.
Eventually an action of those traced individuals might unveil their identity.
Eventually an action of those traced individuals might unveil their identity.
Consequently, a central goal of DigiDow is to minimize the amount to minimize the risk of traces.
Consequently, a central goal of Digidow is to minimize the amount to minimize the risk of traces.
Privacy defines the ability of individuals to keep information about themselves private from others.
Privacy defines the ability of individuals to keep information about themselves private from others.
In context to the Biometric Sensor, this is related to the recorded biometric data.
In context to the Biometric Sensor, this is related to the recorded biometric data.
@ -50,18 +55,18 @@ Only the intended and trusted way of identification within the Digidow network s
To fulfill the Sensor's use case, we need to consider the following attack vectors.
To fulfill the Sensor's use case, we need to consider the following attack vectors.
\begin{itemize}
\begin{itemize}
\item\emph{Rogue Hardware Components}: Modified components of the Biometric Sensor could, depending on their contribution to the system, collect data or create a gateway to the internal processes of the system.
\item\emph{Rogue Hardware Components}: Modified components of the Biometric Sensor could, depending on their contribution to the system, collect data or create a gateway to the internal processes of the system.
Although the produced hardware piece itself is fine, the firmware on it is acting in a malicious way.
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 attached devices,
With this attack, adversaries may get direct access to memory or to data transferred from or to attached devices,
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
It is possible to log the protocol of those attached devices via Man in the Middle attack on the USB cable.
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}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
\item\emph{Attribute Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
It is possible to log the protocol of those attached devices via wiretapping the USB cable.
It is possible to log the protocol of those attached devices via wiretapping the USB cable.
With that attack, an adversary is able to directly access the attributes to identify individuals.
With that attack, an adversary is able to directly access the attributes to identify individuals.
\item\emph{Modification or aggregation of sensitive data within Biometric Sensor}: The program which prepares the sernsor data for transmission could modify the data before sealing it.
\item\emph{Modification or aggregation of sensitive data within Biometric Sensor}: The program which prepares the sernsor data for transmission could modify the data before sealing it.
The program can also just save the sensible 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 Digidow network, there will be some metadata generated.
\item\emph{Metadata extraction on Network}: During transmission of data from the sensor into the Digidow network, there will be some metadata generated.
An adversary could use this datasets to generate tracking logs and eventually match these logs to individuals.
An adversary could use this datasets to generate tracking logs and eventually match these logs to individuals.
\item\emph{Retransmission of sensor data of a rogue Biometric Sensor}: When retransmitting sensor data, the authentication of an individual could again be proven.
\item\emph{Retransmission of sensor data of a rogue Biometric Sensor}: When retransmitting sensor data, the authentication of an individual could again be proven.
@ -74,7 +79,7 @@ To fulfill the Sensor's use case, we need to consider the following attack vecto
\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 \autoref{sec:definition-of-the-biometric-sensor}, we will introduce a prototype which will address many of the defined requirements.
Any threats adressing the physical integrity of the BS will, however, be omitted.
Any threats adressing the physical integrity of the BS will, however, be omitted.
These threats can be addressed with physical intrusion and vandalism protection like they are available for ATMs.
These threats can be addressed with physical intrusion and vandalism protection like they are available for ATMs.
We will instead focus on the integrity of the system when the BS is operating.
We will instead focus on the integrity of the system when the BS is operating.
@ -108,8 +113,8 @@ This \emph{Unified Kernel} is directly measured by the UEFI\,/\,BIOS and is also
This setup starts with two sources of trust that are formally defined:
This setup starts with two sources of trust that are formally defined:
\begin{itemize}
\begin{itemize}
\item\emph{TPM}: The TPM acts as certified Root of Trust for holding the PCRs and for the cryptographic function modifying those.
\item\emph{TPM}: The TPM acts as certified Root of Trust for holding the PCRs and for the cryptographic function modifying those.
\item\emph{RTM}: The Root of Trust for Measurement is part of the mainboard's firmware.
\item\emph{RTM}: The Root of Trust for Measurement is part of the mainboard's firmware.
The tiny program just measures all parts of the firmware and feeds the TPM with the results.
The tiny program just measures all parts of the firmware and feeds the TPM with the results.
However, the program is maintained by the mainboard manufacturer and the source is not available to the public.
However, the program is maintained by the mainboard manufacturer and the source is not available to the public.
We have to trust that this piece of software is working correctly,
We have to trust that this piece of software is working correctly,
\end{itemize}
\end{itemize}
@ -119,7 +124,8 @@ All parts contributing to the boot phase will be measured into one of the PCRs b
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 can access the disk and finish the boot process in the OS.
Consequently only a \emph{known} Kernel with a \emph{known} hardware and firmware setup underneath can access the disk and finish the boot process in the OS.
The disk encryption is, however, only an optional feature which can be omitted in a production environment when there is no sensible data on the disk that must not be revealed to the public.
The disk encryption is, however, only an optional feature which can be omitted in a production
environment when there is no sensitive data on the disk that must not be revealed to the public.
The system needs to check its integrity on the OS level and summarize that by publishing an attestation message, before any transaction data is used.
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}
@ -149,17 +155,19 @@ Consequently, every file which is required for proper execution needs to be hash
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.
\subsection{Prove Trust with DAA}%
\subsection{Proving Trust with DAA}%
\label{sub:prove_trust_with_daa}
\label{sub:prove_trust_with_daa}
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 the BS is a trusted system acting honestly.
In the Digidow context, the PIA should get, together to the biometrical measurements, a proof that
the BS is a trusted system acting honestly.
To reduce the complexity of this problem, we consider two assumptions:
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 exists a bidirecional channel between BS and PIA
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
exists a bidirecional channel between BS and PIA
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
\end{enumerate}
\end{enumerate}
The DAA protocol should be applied on a simple LAN, where all parties are connected locally.
The DAA protocol should be applied on a simple LAN, where all parties are connected locally.
@ -192,7 +200,7 @@ When the BS is then authenticating an individual, the process illustrated in \au
\end{figure}
\end{figure}
The four sources of trust are defined as groups which deliver parts of the prototype, but cannot be verified on a cryptographic level.
The four sources of trust are defined as groups which deliver parts of the prototype, but cannot be verified on a cryptographic level.
Hence, suppliers must be manually added to these groups by using a well defined check for trustworthiness.
Hence, suppliers must be manually added to these groups by using a well defined check for trustworthiness.
Any TPM manufacturer has to implement the well defined standard from TCG.
Any TPM manufacturer has to implement the well defined standard from TCG.
There exists, however no such exact definition for hardware and firmware parts of the platform.
There exists, however no such exact definition for hardware and firmware parts of the platform.
Consequently, these parts should undergo a functional analysis before they are trusted.
Consequently, these parts should undergo a functional analysis before they are trusted.
Trust means that, when the platform is defined trustworthy, the corresponding PCR values should be published.
Trust means that, when the platform is defined trustworthy, the corresponding PCR values should be published.
@ -211,5 +219,6 @@ Furthermore it can check the state of the platform by compare the PCR values aga
Finally it can check the integrity of the running software by checking the hashes in the IMA log against known values.
Finally it can check the integrity of the running software by checking the hashes in the IMA log against known values.
PCR 10 represents therefore the end of the hash chain fed by the IMA log entries.
PCR 10 represents therefore the end of the hash chain fed by the IMA log entries.
If all values are good, the BS can be trusted and the DigiDow transaction can be continued at the PIA.
If all values are good, the BS can be trusted and the Digidow transaction can be continued at the
I hereby declare that the thesis submitted is my own unaided work, that I have not used other than the sources indicated, and that all direct and indirect sources are acknowledged as references.
I hereby declare that the thesis submitted is my own unaided work, that I have not used other than the sources indicated, and that all direct and indirect sources are acknowledged as references.
@ -10,7 +10,7 @@
\vskip1cm
\vskip1cm
\place, \date
\place, \date
\else
\else
\chapter*{Eidesstattliche Erklärung}
\chapter*{Eidesstattliche Erklärung}
Ich erkläre an Eides statt, dass ich die vorliegende \ifcase\type Arbeit \or Bachelorarbeit \or Masterarbeit \or Dissertation \or Diplomarbeit \fi selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe.
Ich erkläre an Eides statt, dass ich die vorliegende \ifcase\type Arbeit \or Bachelorarbeit \or Masterarbeit \or Dissertation \or Diplomarbeit \fi selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe.
@ -26,28 +26,28 @@
\else
\else
\chapter*{Kurzfassung}
\chapter*{Kurzfassung}
\fi
\fi
% Hier Abstact in der Sprache eingeben, in der die Arbeit geschrieben wurde.
% Hier Abstact in der Sprache eingeben, in der die Arbeit geschrieben wurde.
What is it all about? Why is that interesting? What is new in this thesis? Where is the solution directing to?
What is it all about? Why is that interesting? What is new in this thesis? Where is the solution directing to?
{
{
\let\clearpage\relax
\let\clearpage\relax
\ifeng
\ifeng
\selectlanguage{ngerman}
\selectlanguage{ngerman}
\chapter*{Kurzfassung}
\chapter*{Kurzfassung}
\else
\else
\selectlanguage{english}
\selectlanguage{english}
\chapter*{Abstract}
\chapter*{Abstract}
\fi
\fi
% Hier Abstact in der jeweils anderen Sprache eingeben.
% Hier Abstact in der jeweils anderen Sprache eingeben.
Das am Institut für Netzwerke und Sicherheit entwickelte Projekt \textit{Digital Shadow} benötigt in vielen Bereichen ein prüfbares Vertrauen um eine Erkennung von Nutzern anhand ihrer biometrischen Daten zu erkennen und Berechtigungen zuzuteilen.
Das am Institut für Netzwerke und Sicherheit entwickelte Projekt \textit{Digital Shadow} benötigt in vielen Bereichen ein prüfbares Vertrauen um eine Erkennung von Nutzern anhand ihrer biometrischen Daten zu erkennen und Berechtigungen zuzuteilen.
Das Vertrauen soll dem Nutzer die Möglichkeit geben, die Korrektheit des Systems schnell und einfach zu prüfen, bevor er/sie disesm System biometrische Daten zur Verfügung stellt
Das Vertrauen soll dem Nutzer die Möglichkeit geben, die Korrektheit des Systems schnell und einfach zu prüfen, bevor er/sie disesm System biometrische Daten zur Verfügung stellt
Diese Masterarbeit beschäftigt sich nun mit den existierenden Werkzeugen, die ein solches Vertrauen schaffen können.
Diese Masterarbeit beschäftigt sich nun mit den existierenden Werkzeugen, die ein solches Vertrauen schaffen können.
Das implementierte System kombiniert diese Werkzeuge, um damit sensible Daten von Nutzern aufzunehmen und im Netzwerk von Digital Shadow zu identifizieren.
Das implementierte System kombiniert diese Werkzeuge, um damit sensible Daten von Nutzern aufzunehmen und im Netzwerk von Digital Shadow zu identifizieren.
Es soll dabei sicher gestellt sein, dass eine fälschliche Verwendung der sensiblen Nutzerdaten ausgeschlossen wird.
Es soll dabei sicher gestellt sein, dass eine fälschliche Verwendung der sensiblen Nutzerdaten ausgeschlossen wird.
Anhand dieses Systems werden die Eigenschaften einer vertrauenswürdigen Umgebung für Software diskutiert und notwendige Rahmenbedingungen erläutert.
Anhand dieses Systems werden die Eigenschaften einer vertrauenswürdigen Umgebung für Software
diskutiert und notwendige Rahmenbedingungen erläutert.
