@ -53,7 +53,8 @@ The Chain of Trust will be separated into two parts, namely the creation of trus
\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.
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}
@ -62,42 +63,49 @@ The project furthermore aims to specify a scalable solution for nationwide or ev
\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 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.
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{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 sensitive data and
\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{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.
Therefore, the BS records biometric data from the individual and passes it into the DidiDow
network.
\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}
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 authentication process.
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[(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 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.
\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.
A more recent version of the whole system can be found at the Digidow project
Latest developments the whole system will be published on 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 to build trust for any user.
@ -54,10 +54,11 @@ Furthermore, to prevent tracking, any interaction with a sensor should not be ma
information.
Only the intended and trusted way of identification within the Digidow network should be possible.
\subsection{Threat Model}
\label{ssec:threatmodel}
To fulfill the sensor's use case, we need to consider the following attack vectors:
When a BS is working in production, it will usually be in an exposed environment.
There may be an instance of a verifier next to the BS.
The connection into the Digidow network may, however, based on untrusted networks.
Furthermore the physical environment may not be trustworthy.
Given this environment, there are a number of threats that need to be considered when building a BS:
\begin{itemize}
\item\emph{Rogue Hardware Components}: Modified components of the BS could, depending on their
contribution to the system, collect data or create a gateway to the internal processes of the
@ -67,13 +68,13 @@ To fulfill the sensor's use case, we need to consider the following attack vecto
\item\emph{Hardware Modification}: Similar to rogue hardware components, the system could be modified in the target environment by attaching additional hardware.
With this attack, adversaries may get direct access to memory or to data transferred from or to
attached devices.
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
\item\emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually
attached via USB or similar cable connection.
It is possible to log the protocol of those attached devices via Man-in-the-Middle attack on
the USB cable.
\item\emph{Attribute Extraction}: The actual sensor, like camera or fingerprint sensor, is
usually attached via USB or a similar cable connection.
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{Attribute Extraction}: Similar to metadata extraction, the adversary might directly
access the attributes via wiretapping the USB cable.
The adversary might be able to identify an individual with those attributes.
\item\emph{Modification or aggregation of sensitive data within BS}: The program which prepares
the sernsor data for transmission could modify the data before sealing it.
The program can also just save the sensitive data for other purposes.
@ -90,6 +91,20 @@ To fulfill the sensor's use case, we need to consider the following attack vecto
Due to this error, a wrong identity and therefore false claims would be made out of that.
\end{itemize}
Although all of these attack vectors should be mitigated when usen in production, we will address
only a subset for the prototype.
First, we assume that only authorized personnel has access to the hardware itself.
Any other person should only interact with the hardware sensor.
Therefore any threat atacking communication between internal system components will not be
addressed.
Furthermore, we will assume an already established bidirectional channel between BS and PIA.
Any algorithms on how the BS finds the corresponding PIA exceed the focus of this work.
On the other hand, any hardware modification including firmware upgrades should be detectable by
the system.
In addition to this detection, the BS should provably behave like it is intended to, mitigating
attacks on replaying attributes, blocking attribute transmission or aggregating them while running.
\section{Prototype Concept}%
\label{sec:prototype_concept}
Given the threat model and the use cases described in \autoref{sec:definition-of-the-biometric-sensor}, we will introduce a prototype which will address many of the defined requirements.
