@ -9,9 +9,9 @@ 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 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.
Which IP is connected?
Which IP address is sending or receiving?
What kind of device is that?
Is the software of the device up to date?
Was this device here in the past?
@ -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.
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.
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.
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.
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.
The Chain of Trust will be separated into two parts, namely the creation of trust on a certain system, and the transfer of trust over the network for verification purposes.
\section{Project DigiDow}
The Institute for Networks and Security is heavily using the cryptographic form of trust in the project \emph{Digital Shadow} (DigiDow).
\section{Project Digidow}
The Institute for Networks and Security is heavily using the cryptographic form of trust in the
project \emph{Digital Shadow} (Digidow).
DigiDow introduces an electronic authentication system, which aims to minimize any generation of metadata on system and network level and hence maximizes the level of privacy for their users.
The 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}
\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.
DigiDow introduces three main parties which are involved in a common authentication process.
\begin{itemize}
\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{Biometric Sensor} (BS): For Authentication, an individual has to be uniquely identified.
The BS records therefore biometric data from the individual and passes it into the DidiDow network.
\item\emph{Biometric Sensor} (BS): For authentication, an individual has to be uniquely
identified.
Therefore, the BS records biometric data from the individual and passes it into the DidiDow
network.
\end{itemize}
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}
\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
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.
\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 [(7)] The PIA proofs authenticity of the received signature and compares the data with its own saved biometric data sets.
\item [(4)(5)(6)] The BS contacts the PIA and sends the recorded dataset as well as a
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.
The verifier checks the certification and finally triggers the desired action for the asking individual.
\end{enumerate}
The above illustration is an early draft of the whole setup and is under constant development.
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.
\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.
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.
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.
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.
We use an attached camera as example for a biometric sensor hardware to create the dataset to
continue with the authentication process.
This dataset will be combined with the integrity measurements of the system and a signature from
the TPM and finally sent to the PIA for verification and further computation.
By building a system with an integrated TPM, the system should be able to provide the following properties:
\begin{itemize}
\item\emph{Sensor Monitoring.} The system should be able to monitor the hardware sensor (fingerprint sensor, camera, etc.) itself.
\item\emph{System Monitoring.} It should be possible to track the state of the system. Especially every modification of the system at hardware level should be detected.
\item\emph{Freshness of Sensor Data.} To prevent replay attacks, the system should proof that the provided biometric data is captured live.
\item\emph{Integrity of Sensor Data.} As it is possible for an adversary to modify the provided data during the capturing process, integrity should guarantee that the data originates from the BS.
\item\emph{Freshness of Sensor Data.} To prevent replay attacks, the system should prove that
the provided biometric data is captured live.
\item\emph{Integrity of Sensor Data.} As it is possible for an adversary to modify the provided
data during the identification process, integrity should guarantee that the data is unmodified
until identification is done.
\item\emph{Confidentiality of Sensor Data.} It should not be possible to eavesdrop any sensitive data out of the system.
Furthermore almost all kinds of metadata (e.\,g. information about the system or network information) should not be published
\item\emph{Anonymity.} Given a message from a BS, an adversary should not be able to detect which BS created it
\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.
Furthermore almost all kinds of metadata (e.\,g. information about the system or network
information) should not be published.
\item\emph{Anonymity.} Given a message from a BS, an adversary should not be able to detect
which BS created it.
\item\emph{Unforgeability.} Only honest BS should be able to be part of the Digidow network.
Corrupt systems should not be able to send valid messages.
\end{itemize}
The thesis focuses on a working setup as basis for future research.
Since the DigiDow protocols are not yet finalized some assumptions are defined for this work and the prototype implementation:
Since the Digidow protocols are not yet finalized, some assumptions are defined for this work and
the prototype implementation:
\begin{itemize}
\item Any network discovery (Step 1 in \autoref{fig:globalview}) is omitted. BS and PIA are assumed to be reachable directly via TCP/IP
\item We look into a protocol which proofs trustworthiness from BS to PIA.
Any further proofs necessary for DigiDow's Verifier are also not focused in this thesis.
\item The sensible data sets will be transmitted in cleartext between BS and PIA.
\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 We look into a protocol which proves trustworthiness from BS to PIA.
Any further proofs necessary for a Digidow Verifier are also not focused in this thesis.
\item The sensitive datasets will be transmitted in cleartext between BS and PIA.
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.
\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}
%TODO edit pointer
\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}.
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}.
@ -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.
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.
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.
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?
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on 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.
\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).
\section{Trusted Platform Module (TPM)}%
\label{sec:trusted_platform_module_tpm_}
The \emph{Trusted Platform Module} (TPM) is a small coprocessor that introduces a variety of cryptographic features to the platform.
This module is part of a standard developed by the Trusted Computing Group (TCG), which 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:
%TODO find source of that claim (TPM variants)
\begin{itemize}
\item\emph{Dedicated device.} The TPM chip is mounted on a small board with a connector.
The user can plug it into a compatible compute platform. This gives most control to the end user since it is easy to disable trusted computing or switch to another TPM.
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard. Therefore any hardware modification is impossible.
However most PC platforms provide BIOS features to control the TPM.
The user can plug it into a compatible compute platform. This gives most control to the end
user since it is easy to disable trusted computing or to switch to another TPM.
\item\emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard.
Therefore, removing or changing the TPM is imossible.
All recent Intel and AMD platforms supporting TPM2.0 are able to manage a TPM within the BIOS,
even as mounted device.
\item\emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision.
Firmware means in this context an extension of the CPU instruction set which provides the features of a TPM.
Instead of using a dedicated Coprocessor for the TPM features, this variant lives as firmware
extension within Intel's Management Engine or AMD's Platform Security Processor.
Both Intel and AMD provide this extension for their platforms for several years now.
When activating this feature on BIOS level, all features of Trusted Computing are available to the user.
\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.
When activating this feature on BIOS level, the user gets the same behavior as when using a
mounted device.
\item\emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator. It
provides basically every feature of a TPM but cannot be used outside the OS.
Features like Trusted Boot or in hardware persisted keys are not available.
\end{itemize}
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.
fTPMs will be updated with the Microcode updates of the CPU manufacturers.
Dedicated and mounted devices are small microcontrollers that run the TPM features in software
giving the manufacturer the possibility to update their TPMs in the field.
fTPMs will be updated with the platform updates of the CPU manufacturers.
The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it returns 23 entries\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.
Another seven entries refer to vulnerabilities in custom TPM implementations.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM library and the shutdown\,/\,boot process.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM
library and the shutdown/boot process.
The last two entries describe vulnerabilities in dedicated TPM chips, which are mentioned in further detail:
\begin{itemize}
\item\emph{CVE-2017-15361}: TPMs from Infineon used a weak algorithm for finding primes during the RSA key generation process.
This weakness made brute force attacks against keys of up to 2048 bits length feasible.
According to \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.
\item\emph{CVE-2019-16863}: This vulnerability is also known as \emph{TPM fail} (\cite{moghimi20-tpmfail}) and shows how to get an Elliptic Curve private key via timing and lattice attacks.
The authors found TPMs from STMicorelectronics vulnerable, as well as Intel's fTPM implementation.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "\emph{TPM fail}"
\cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and
lattice attacks.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM
implementation.
Infineon TPM show also some non-expected behaviour, but this could not be used for data exfiltration.
STMicro provided an update like Insineon did for the TPMs.
Intel's fTPM lives in the Management Engine, which requires a BIOS update from the mainboard manufacturer to solve the issue.
STM provided an update like Infineon did for their TPMs.
Intel's fTPM required a platform firmware update to solve the issue.
\end{itemize}
@ -51,51 +65,61 @@ The last two entries describe vulnerabilities in dedicated TPM chips, which are
\label{sssec:tpm-usage}
On top of the cryptographic hardware, the TCG provides several software interfaces for application developers:
\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{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}
The reference implementation of these APIs is published at Github\cite{tpmsoftware20} and is still under development.
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.
The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still
under development.
The repositories are maintained by members of TCG.
At the point of writing stable interfaces are available for C and C++, but other languages like
Rust, Java, C\# will be served in the future.
The repository additionally provides the tpm2-tools toolset which provides the FAPI features to the command line.
Unfortunately, the command line parameters changed several times during the major releases of tpm2-tools\cite{pornkitprasan19-tpmtools}.
Unfortunately, the command line parameters changed several times during the major releases of
tpm2-tools\cite{pornkitprasan19-tpmtools}.
\subsection{The Hardware}
\label{sssec:tpm-hardware}
The TCG achieved with the previous mentioned software layers independence of the underlying hardware.
Hence, TCG provided different flavors of of the TPM
With the previous mentioned software layers the TCG achieved independence of the underlying
hardware.
Hence, these layout made the different flavors of TPMs possible
TCG defined with the TPM2.0 standard 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.
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}%
\label{sub:tpm_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.
Will Arthur et.\,al\cite{arthur15} provide a more detailed description on how the hierarchies workt together.
These hierarchies fulfill different tasks and are used in different use cases on the whole platform.
Will Arthur et al.\cite{arthur15} provide a more detailed description on how the hierarchies work
together.
\begin{itemize}
\item\emph{Platform Hierarchy}: This hierarchy is managed by the platform manufacturer. The firmware of the platform is interacting with this hierarchy during the boot process.
\item\emph{Storage Hierarchy}: The storage of a platform is controlled by either an IT department or the end user and so is the Storage Hierarchy of the TPM.
\item\emph{Storage Hierarchy}: The storage of a platform is controlled by either an IT
department or the end user and so is the storage hierarchy of the TPM.
It offers non-privacy related features to the platform although the user may disable the TPM for her own use.
\item\emph{Endorsement Hierarchy}: This is the privacy-related hierarchy which will also provide required functionality to this project.
It is controlled by the user of the platform and provides the keys for attestation and group membership.
\item\emph{NULL Hierarchy}: The NULL Hierarchy is the only non-persistent hierarchy when rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\item\emph{NULL Hierarchy}: The NULL hierarchy is the only non-persistent hierarchy when
rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\end{itemize}
Each of the persistent hiearchies represent an 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.
The process on key generation described below is similar to all three persistent hierarchies.
Each of the persistent hiearchies represent its own tree of keys, beginning with a root key.
Since TPM2.0 was published, these root keys are not hard coded anymore and can be changed if
necessary.
The process of key generation described below is similar to all three persistent hierarchies.
\subsection{Endorsement Key}%
\label{sub:endorsement_key}
@ -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.
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.
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.
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.
\begin{itemize}
\item Attestation Identity Key
\item Key management
\end{itemize}
Consequently it is quite easy to have different EKs at once to address privacy features also
between different functions of the endorsement hierarchy.
\section{Trusted Boot}%
\label{sec:trusted_boot}
A boot process of modern platforms consists of several steps until the OS taking over the platform.
A boot process of modern platforms consists of several steps until the OS is taking over the
platform.
During these early steps, the hardware components of the platform are initialized and some self tests are performed.
This is controlled by either the BIOS (for legacy platforms) or the UEFI firmware.
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}%
\label{sub:platform_configuration_register}
The \emph{Trusted Computing Group} (TCG) introduced in 2004 their first standard for a new {Trusted Computing Module} (TPM).
As part in this standard, TCG defined a procedure, where every step in the early boot process is measured and saved in a \emph{Platform Configuration Register} (PCR).
\emph{Measuring} means in this context a simple cryptographic extension function which works described in formula \ref{form:PCR-measurement}
The \emph{Trusted Computing Group} (TCG) introduced their first standard for a new {Trusted
Computing Module} (TPM) in 2004.
As part in this standard, TCG defined a procedure where every step in the early boot process is
measured and saved in a \emph{Platform Configuration Register} (PCR).
In this context, \emph{Measuring} means a simple cryptographic extension function:
The function 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.
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.
One can clearly see that the resulting hash will also change when the order of computations change.
Therefore, the BIOS\,/\,UEFI has to provide a deterministic way to compute the hash chain if there is more than one operation necessary.
The procedure of measurements is available since the first public standard of TPM, version 1.2.
For the recent TPM2.0 standard, the process was only extended with the support for the newer SHA256 standard.
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.
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.
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.
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.
@ -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\\
6 & Host platform manufacturer specific \\
7 & Secure Boot Policy \\
8-15 & Defined for use by the static OS \\
8--15 & Defined for use by the static OS \\
16 & Debug \\
17--23 & Application\\
\bottomrule
@ -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}}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless in the measurement log.
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.
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}
\label{sec:definition-of-the-biometric-sensor}
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.
There, the BS is the gateway to 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.
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.
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}
\item\emph{Listen}: Either the sensor hardware itself (e.g. a detection in a fingerprint sensor) or another electrical signal will start the authentication process.
\item\emph{Collect}: Measure sensor data (picture, fingerprint) and calculate a biometric representation (Attribute).
\item\emph{Discover}: Start a network discovery in the DigiDow network and find the PIA corresponding to the present person. It may be necessary to interact with more than one PIA within this and the next 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{Reset}: Set the state of the system as it was before this transaction.
\end{enumerate}
@ -38,7 +43,7 @@ There exists no exact definition or list of metadata which makes it hard to prev
Metadata does not directly identify an individual.
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.
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.
In context to the Biometric Sensor, this is related to the recorded biometric data.
@ -61,7 +66,7 @@ To fulfill the Sensor's use case, we need to consider the following attack vecto
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.
\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.
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.
@ -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.
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.
\begin{figure}
@ -149,16 +155,18 @@ 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.
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}
The features described above take care of building a trusted environment on the system level.
DAA will take care of showing the \emph{trust} to a third party which has no particular knowledge about the BS.
In the DigiDow context, the PIA should get, together to the biometrical measurements, a proof that the BS is a trusted system acting honestly.
In the Digidow context, the PIA should get, together to the biometrical measurements, a proof that
the BS is a trusted system acting honestly.
To reduce the complexity of this problem, we consider two assumptions:
\begin{enumerate}
\item\emph{Network Discovery}: The PIA is already identified over the DigiDow network and there exists a bidirecional channel between BS and PIA
\item\emph{Network Discovery}: The PIA is already identified over the Digidow network and there
exists a bidirecional channel between BS and PIA
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
\end{enumerate}
@ -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.
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
@ -46,8 +46,8 @@ What is it all about? Why is that interesting? What is new in this thesis? Where
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.
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.
