You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
109 lines
6.0 KiB
109 lines
6.0 KiB
\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 elctrical devices.
|
|
This product category form the so called \emph{smart} devices.
|
|
|
|
With all these new devices a lot of societal problems could be solved in the past few 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 next decades.
|
|
|
|
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.
|
|
Metadata answers some of the following questions.
|
|
Which IP is connected?
|
|
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 list of questions can be continued arbitrarily.
|
|
Reselling the metadata brings the product manufacturer more margin on the product and hence more profit.
|
|
Consequently the market for metadata is growing with the Internet itself.
|
|
The result is a loss of trust in all kind of connected devices and software.
|
|
A User cannot know what is happening on a device she is using.
|
|
|
|
The Institute for Networks and Security therefore introduced the project DigiDow.
|
|
It introduces a digital authentication system, which minimizes the generation of metadata and hence preserves privacy for all users of the system.
|
|
|
|
\section{Project DigiDow}
|
|
The Project \emph{Digital Shadow} is under ongoing development at the Institute of Networks and Security and creates a scalable system for authentication.
|
|
Key feature is privacy by design and a provable system to create trust to the end user.
|
|
|
|
At this early stage the interfaces and interaction points are not fully defined.
|
|
|
|
This is a brief description of the process of authentication:
|
|
%TODO paste image here and describe it
|
|
|
|
\section{Biometric Sensor use case in DigiDow}
|
|
derive the use case of the Biometric sensor out of the above model.
|
|
%TODO description of BS in DigiDow
|
|
|
|
\section{Goals and Definitions}
|
|
You should be able to attach a variety of sensors to the system.
|
|
The system should then fulfill the following requirements
|
|
\begin{itemize}
|
|
\item \emph{Sensor Monitoring.} The System should be able to monitor the sensor itself.
|
|
\item \emph{System Monitoring.} It should be possible to track the state of the system. Especially every modification of the system 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{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}
|
|
|
|
Usage Model of Biometric Sensor
|
|
|
|
This thesis will describe a system, which is part of the Digital Shadow network.
|
|
Therefore it has to meet the common principles in information security, namely:
|
|
\begin{itemize}
|
|
\item \emph{Availability}:
|
|
\item \emph{Integrity}: ISO 27000 (Data Integrity)
|
|
\item \emph{Confidentiality}: ISO 27000
|
|
\end{itemize}
|
|
|
|
Upon AIC it should be possible for users to prove honesty of the system.
|
|
This is what \emph{trust} defines in information security
|
|
|
|
\subsection{Requirements}
|
|
\begin{itemize}
|
|
\item given a set of software, this system should provide information that exactly this version of software is running on the system. (Integrity)
|
|
\item The system must furthermore show that it is a member of valid biometric sensors (Attestation)
|
|
\item All the given information should be anonymized. It should not be possible to gain any other information about the system (Anonymity)
|
|
\item It should be ensured that no sensitive data is stored at the biometric sensor
|
|
\end{itemize}
|
|
Scope of this thesis is on implementing the system from from hardware to application layer.
|
|
Is is not supposed to think about the network communication.
|
|
|
|
\section{Description of structure}
|
|
\begin{enumerate}
|
|
\item What exists out there?
|
|
\item What is the theoretical solution
|
|
\item What about the implementations used - what is the limitation of the used tools?
|
|
\item How far are we? what has to be considered next?
|
|
\end{enumerate}
|
|
|
|
\chapter{Related Work}
|
|
There exist already many interesting 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.
|
|
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}.
|
|
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.
|
|
%TODO what about the integrity measurements of keylime?
|
|
|
|
\begin{itemize}
|
|
\item What exists in the field?
|
|
\item Keylime - DONE
|
|
\item Xaptum ECDAA
|
|
\item FIDO 2 ECDAA
|
|
\item Strongswan Attestation
|
|
\item Linux IMA
|
|
\item Secure Boot
|
|
\item Intel TXT
|
|
\item Trusted Execution Environment (TEE)
|
|
\item nanovm (\url{nanovms.com})
|
|
|
|
\end{itemize}
|