masterthesis/thesis/01_introduction.tex

\chapter{Introduction}
We all live in a world full of digital systems.
They appear as PCs, notebooks, cellular phones or embedded devices.
Especially the footprint of embedded computers became so small that they can be used in almost all electrical devices.
These embedded systems form the so called \emph{smart} devices.

All these new devices made life a lot easier in the past decades.
Many of them automate services to the public like managing the bank account, public transportation or health services.
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 the intended exchange of information, many of the services try to extract metadata as well.
Metadata answers some of the following questions.
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?
What else did the owner on the device?
This set of questions is not complete.

Aggregating metadata is not required to fulfill the function of the requested service.
However, aggregating and reselling the metadata brings the provider more margin on the product and hence more profit.
Consequently, the market for metadata is growing and yet only partly regulated.
Since metadata aggregation is one downside of using smart services, providers try to downplay or to hide these aggregation features where possible.
Often a proprietary layer is used either on the client or the server side to hide those functions.
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.
Instead, vendors provide an API where an \emph{Operating System} (OS) can connect to.
Some companies deliver complete closed source devices with internet connection.
In such cases, the feature of closed source is to protect the intellectual property of those
companies.
Any user of these closed source products must use them as black box and needs to \emph{trust} the
vendor that it is working correctly.

There is, however, a special need for users to keep sensitive data secret.
Especially when providing confidential data like passwords or biometric data, a certain level of trust is required.
This means that the user assumes that the provided sensitive data is handled properly for only the
designated usage.
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.

\section{Trust}
When using a system with an authentication method, trust plays a key role.
For black box systems this trust is cast to the vendor of the system or device.
There is however no mathematical proof that the device is indeed executing the software as intended from the vendor.

This thesis will therefore use the term \emph{trust} as a cryptographic chain of proofs, that a system is behaving in an intended way, a so called \emph{Chain of Trust}.
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).
Digidow introduces an electronic authentication system, which aims to minimize any generation of
metadata on system and network level and hence maximizes the level of privacy for their users.
The project furthermore aims to specify a scalable solution for nationwide or even worldwide applications including provable trust and integrity to the user.

\begin{figure}
	\centering
	\includegraphics[width=0.7\textwidth]{../resources/digidow-overview-interactions}
	\caption{Overview of the Digidow network with its interactions}
	\label{fig:digidow-overview}
\end{figure}
The picture in \autoref{fig:digidow-overview} provides an overview of the Digidow network.
The nodes using the Digidow network and their interactions are not fully specified at the time of
this writing.
Therefore the processes may be adapted when necessary.
DigiDow introduces five main parties which are involved in a common authentication process.
\begin{itemize}
  \item \emph{Individual}: The human user who wants to be identified via the Digidow network.
	\item\emph{Personal Identity Agent} (PIA): The PIA is the digital shadow of an individual.
		This individual is also the owner of the PIA and should be in control of sensitive data and
		software on it.
  \item \emph{Issuing Authority}: This party acts as an authority for the individual's attributes.
  These attributes show an aspect of the individula's identity.
  After identifying the individual via the Digidow network, these attributes may be used to allow
  or deny a certain action.
	\item\emph{Verifier}: This is the party that verifies the whole authentication process and may
	finally trigger the desired action.
  It is usually strongly connected with the sensor which starts the identification process.
	\item\emph{Sensor}: For authentication, an individual has to be uniquely identified.
		Therefore, the sensor records biometric data from the individual and passes it to the PIA via
		the Dididow network.
    Sensors are not limited to sensing biometric data.
    However, we focus in this thesis on developing a prototype of a biometric sensor (BS).
\end{itemize}

When an individual wants to be identified by Digidow, he will eventually step in front of a sensor.
This defines the beginning of a Digidow trancaction.
The procedure is as follows:
\begin{enumerate}
  \item The sensor will start recording a unique digital representation, triggered by the directly
  connected verifier or by hardware detection.
  \item The sensor eventually finds one or a small group of eligible PIAs, where a secure
  communication channel is established.
  \item After receiving the digital representation of the sensor, the PIA identifies the individual
  if possible.
  \item When identification was possible, the PIA eventually sends a proof of identification and a
  claim of the requested attributes to the verifier.
  \item The verifier will check the cryptographic proofs of the claim and the sensor data.
  If successful, the verififier will grant the desired action for the asking individual.
\end{enumerate}

The above illustration is an early draft of the whole setup and is under constant development.
Latest developments the whole system will be published on the Digidow project
page\footnote{\url{https://digidow.eu}}.

\section{Our Contribution: Deriving Trust from the Biometric Sensor}
The Digidow network is designed to preserve privacy and to build trust for any user.
A key feature is to show the user that all involved parts of the system are working as intended.
So we design a prototype based on the common x86 architecture and use the cryptographic features of
\emph{Trusted Platform Modules} (TPM).
A TPM is a passive crypto coprocessor available on many modern PC platforms which has an independent storage for crypto variables and provides functions to support above mentioned features.

We define a solution for installing and booting a Linux kernel with TPM-backed integrity
measurements in place.
We use an attached camera as example for a biometric sensor hardware to create the dataset to
continue with the authentication process.
This dataset will be combined with the integrity measurements of the system and a signature from
the TPM and finally sent to the PIA for verification and further computation.

By building a system with an integrated TPM, the system should be able to provide the following properties:
\begin{itemize}
	\item \emph{Sensor Monitoring.} The system should be able to monitor the hardware sensor (fingerprint sensor, camera, etc.) itself.
	\item \emph{System Monitoring.} It should be possible to track the state of the system. Especially every modification of the system at hardware level should be detected.
	\item \emph{Freshness of Sensor Data.} To prevent replay attacks, the system should prove that
	the provided biometric data is captured live.
	\item \emph{Integrity of Sensor Data.} As it is possible for an adversary to modify the provided
	data during the identification process, integrity should guarantee that the data is unmodified
	until identification is done.
	\item \emph{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}

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:
\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 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.
		This thesis focuses only on the trust part between BS and PIA.
	\item Any built system is considered secure on a hardware level.
		Any threats which are attacking the system without changing any running software on the system
		may remain undetected.
    This includes USB wire tapping or debug interfaces within the system revealing sensitive
    information.
\end{itemize}

%TODO edit pointer

\section{Description of structure}
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this
thesis.
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}.
Chapter~\ref{cha:implementation} introduces then a working implementation with all necessary parts for a working prototype.
Finally we will present the results and limitations in \autoref{cha:conclusion} and give an overview of future work.

\chapter{Related Work}\label{cha:relatedwork}
There exist already a variety projects and implementations which touch the field of trusted computing.
We will introduce some of these projects and discuss why these do not meet the purpose of this thesis.

Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud
computing.
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.
The concept of a well known virtual environment does, however, not apply to our contribution.
Furthermore, the system should be self contained as good as possible and it should be possible to
get information about the system via anonymous attestation.
%TODO what about the integrity measurements of keylime?

The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO
website\cite{fido18}

%TODO Is it noteworthy, that Xaptum claims to be compatible with FIDO ECDAA for TPM2?

\begin{itemize}
	\item What exists in the field?
	\item Keylime -- DONE
	\item Xaptum ECDAA -- part of concept
	\item FIDO 2 ECDAA -- noteworthy in background?
	\item Strongswan Attestation --
	\item Linux IMA -- mentioned in Background
	\item Secure Boot -- in difference to trusted boot
	\item Intel TXT
	\item Trusted Execution Environment (TEE)
	\item nanovm (\url{nanovms.com})
\end{itemize}