masterthesis/thesis/03_concept.tex

\chapter{Concept}
\label{cha:concept}
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.

\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.
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.

The following enumeration shows the steps of the BS for identifying the interacting person.
\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{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}

Since the BS handles biometric data---which must be held confidential outside the defined use cases---a number of potential threats must be considered when designing the BS.

\section{Attack Vectors and Threat Model}
As mentioned before, the BS will work in an exposed environment.
Neither the user providing biometric data nor the network environment should be trusted for proper function.
There should only be a connection to the Digidow network for transmitting the recorded data.
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.
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.
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?)
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.
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.

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.
Furthermore, to prevent tracking. any interaction with a Sensor should not be matched to personal 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.
\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. 
		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.
	\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. 
		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. 
		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. 
	\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.
		Any grants provided to this individual could then given to another person.
	\item \emph{Rogue Biometric Sensor blocks transmission}: By blocking any transmission of sensor data, any transaction within the Digidow network could be blocked and therefore the whole authentication process is stopped.
	\item \emph{Rogue Personal Identity Agent}: A rogue PIA might receive the sensor data instead of the honest one.
		Due to this error, a wrong identity and therefore false claims would be made out of that.
\end{itemize}

\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.
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.
We will instead focus on the integrity of the system when the BS is operating.

\subsection{Integrity and Trust up to the Kernel}%
\label{sub:integrity_and_trust_up_to_the_kernel}

We decided to use the PC platform as hardware base for the prototype.
There are lots of different form factors available you can extend the system with a broad variety of sensors.
Furthermore the TPM support is implemented to support integrity analysis on the system.
Finally, the platform can run almost all Linux variants and supports relevant pieces of software for this project.
A flavour of Linux supporting all features described in this chapter, will be used as OS platform.
The ARM platform seem to be capable of all these features as well, however, the support of TPM, the amount of available software and the ease of installation is better on the PC platform.

As described in \autoref{sec:trusted_platform_module_tpm_}, the TPM functions can be delivered in three different flavors: As dedicated or mounted device and as part of the processor's firmware.
The fTPM is part of a large proprietary environment from AMD or Intel which which introduces, besides implementation flaws, additional attack surfaces for the TPM.
Hence we will use dedicated TPM chips on the platform, which are pluggable, to gain most control over the functionality.

Any recent PC platform supports TPMs ans consequently Trusted Boot as mentioned in \autoref{sec:trusted_boot}.
The system will describe its hardware state in the PCRs 0\,--\,7 when the EFI\,/\,BIOS hands over to the Bootloader.
We use these PCR values to detect any unauthorized modifications on hardware or firmware level.
It is important to include also \emph{epmty} PCRs to detect added hardware on the PCI bus with an Option ROM, for example.

With these PCR values we can seal a passphrase in the TPM.
The disk, secured with Full Disk Encryption (FDE), can only be accessed, when the hardware underneath is not tampered with.

To further reduce the attack surface, the prototype will not use a bootloader like GRUB.
Instead, the Kernel should be run directly from the UEFI\,/\,BIOS.
Therefore, the Kernel is packed directly into an EFI file, together with its command line parameters and the initial file system for booting.
This \emph{Unified Kernel} is directly measured by the UEFI\,/\,BIOS and is also capable of decrypting the disk, given the correct PCR values.

This setup starts with two sources of trust that are formally defined:
\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{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. 
		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,
\end{itemize}
We implicitly assume that the CPU, executing all these instructions and interacting with the TPM, is working correctly.

All parts contributing to the boot phase will be measured into one of the PCRs before any instruction is executed.
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 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}
	\centering
	\includegraphics[width=0.8\linewidth]{../resources/chainoftrust.pdf}
	\caption{Overview of the Chain of Trust of the BS}%
	\label{fig:chainoftrust}
\end{figure}
\begin{itemize}
	\item DONE Definition of sensitive data / privacy / metadata
	\item This version of BS is not owned by the user, there is no personal data in the System
	\item Rogue Personal Identity Agent (PIA)
	\item Metadata Extraction
	\item Attribute extraction
	\item Sensor Data Modification/manipulation
	\item Wiretap between Sensor and System (USB or network)
	\item Physical Manipulation of the BS-System
	\item Network - Retransmission of sensor data of a rogue BS
	\item Network - Blocking Data transmission of a rogue BS
	\item Rogue BS Sensor Data aggregation
	\item Rogue BS Sensor data modification before transmission
\end{itemize}
\section{Trust and Security}
\label{sec:trust}
Trust is an essential term in this thesis.
In the world of IT security, the term \emph{trusted computing} defines a secured environment where special or confidential computing jobs are dispatched.
This environment or product usually meets the following requirements
\begin{itemize}
	\item \emph{Minimalization.} The number of features and hence the complexity must be as low as possible.
	\item \emph{Sound definitions.} Every function should be well defined. There should be no margin for interpretation left. Security Engineers should be involved in the development. 
	\item \emph{Complete testing.} Testing for trusted computing includes a threat analysis and exhaustive testing if possible. 
\end{itemize}
Since software and hardware testing is never complete, it is hard to find a good balance between feature set and testing completeness.

However trust in IT is not equal to security.
It defines a subset of IT security where this small well defined environment is embedded in a larger system which is usually untrusted.
Claiming a system \emph{secure} spans the constraints of trust over the complete system, which is not affordable for commodity computers these days.
However it is possible to use the trusted environment to get some guarantees on the untrusted parts of a system as well
In Chapter 3 we will show how trust will be extended in a commodity PC.
%TODO reference to TPM section how to extend trust into untrusted parts of PC

%TODO describe verifiable trust in addition to the previous definition (with example of the ATM?)


Differentiation between trust and security --- and the problem that not everyone is using that right.
\section{Systems of Trust}
\label{sec:trustsystems}
All trust systems are built on the standards of Trusted Computing Group.
\subsection{Secure Boot, TXT, \ldots}
\label{ssec:secureboot-txt}
Trusted Boot is not the same as Secure Boot. Explain the difference
\subsection{TPM1.2}
\label{ssec:tpm12}
Initial Version of the crypto-coprocessor, successfully spread into many systems, but hardly any integration in Trust/security Software



\begin{figure}
	\centering
	\includegraphics[width=0.7\textwidth]{../resources/tpmattest}
	\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may trust the Biometric Sensor afterwards.}
	\label{fig:daa-attestation}
\end{figure}

\section{Trusted Boot}

\section{Integrity Measurements}
As described in the previous section, when the boot process is eventually finished, the OS is then responsible for extending the chain of trust.
Given a valid trusted boot procedure, the binary representation of the kernel is already measured.
Therefore the Kernel itself has the responsibility to keep track of everything happening on the platform from the OS point of view.

Soon after the first TPM standard was published, the \emph{Integrity Measurement Architecture} (IMA) for the Linux Kernel was introduced.
Since Kernel 3.7 it is possible to use all IMA features, when the compiler options of the Kernel are set correspondingly.

IMA 


Extend the Chain of Trust beyond the boot process.
The Kernel can measure many different types of Resources.
What is a useful set of measurements

\section{Verify Trust with DAA}

\subsection{DAA History}
Direct Anonymous Attestation (DAA) is a cryptographic protocol, which aims to provide evidence that a device is a honest member of a group without providing any identification information.
Brickell, Camenisch and Chen\cite{BriCamChe04} introduce DAA and implement the protocol for the TPM 1.2 standard.
However it supports only RSA and has limitations in verifying attestation signatures.
Hence, DAA is not used with the TPM 1.2 standard.

Since the DAA protocol is quite complex, it is difficult to provide a sound security model for DAA and formally prove the security properties of it.
Chen, Morissey and Smart\cite{chen09} add linkability to the protocol.
Their approach for a formal proof is not correct, since a trivial key can be used for pass verification\cite{camenisch16}


%TODO Chronic of DAA until Camenisch16, Discussion about broken Proofs in previous papers.

Camenisch, Drijvers and Lehmann\cite{camenisch16} developed a DAA scheme for the new TPM 2.0 standard.
It supports linkability and the proves for security and correctness still hold.
Furthermore, RSA and ECC cryptography is supported which makes it practicable for a wider variety of use cases.
However, Camenisch et al.\@ proposed a fix in the TPM 2.0 API to guarantee all requirements necessary for DAA.
Xaptum implemented this DAA-variant including the fixes in the TPM API.
The implementation will be discussed in Chapter 4.%TODO Reference to Xaptum discussion

Analyzing the security and integrity of this scheme would exceed the scope of this thesis.
Hence this thesis describes the DAA protocol and assumes the correctness and integrity.

%TODO: Discussion: sid removed, RL only works with private keys, etc.