@ -40,12 +40,16 @@ This is a brief description of the process of authentication:
derive the use case of the Biometric sensor out of the above model.
%TODO description of BS in DigiDow
\section{Definitions and Requirements}
\section{Goals and Definitions}
You should be able to attach a variety of sensors to the system.
The system should then fulfill the followin requirements
\begin{itemize}
\item privacy
\item integrity
\item trust
\item security
\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 biometrc data is captured live.
\item\emph{Integrity of Sensor Data.} As it is possible for an attacker to modify the provided data during the capturing process, integrity should guarantee that the data comes from the sensor in an unmodified manner.
\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
@ -3,13 +3,6 @@ The theoretical tool that should be formed to one whole system implementation in
\section{Definition of the Biometric Sensor}
What part fulfills the BS and what needs to be done.
Record Sensor data, Network Discovery, send sensor data via trusted channel to PIA
\subsection{Definitions}
\begin{itemize}
\item Sensitive Data
\item Privacy
\item Metadata
\item Attribute
\end{itemize}
\subsection{What has the BS to do?}
\begin{enumerate}
@ -34,19 +27,98 @@ Record Sensor data, Network Discovery, send sensor data via trusted channel to P
\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 modifiacation before transmission
\item Rogue BS Sensor data modification before transmission
\end{itemize}
\section{Trust and Security}
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}
All trust systems are built on the standards of Trusted Computing Group.
\subsection{Secure Boot, TXT, \ldots}
Trusted Boot is not the same as Secure Boot. Explain the difference
\subsection{TPM1.2}
Initial Version of the Cryptocoprocessor, successfully spread into many systems, but hardly any integration in Trust/security Software
Initial Version of the crypto-coprocessor, successfully spread into many systems, but hardly any integration in Trust/security Software
%TODO this is an attempt to describe TPM from the beginning.
\subsection{TPM2.0}
Current Version (published 2014) with some improvements.
The \emph{Trusted Platform Module} (TPM) is a small cryptocoprocessor that introduces a variety of new 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}.
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.
\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.
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.
\end{itemize}
Even the dedicated devices are small microcontrollers that run the TPM features in software which gives the manufacturer the possibility to update their TPMs in the field.
FTPMs will be updated with the Microcode 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.
Since TCG published the new standard in 2014 only six CVE-Entries handled vulnerabilities with TPMs\footnote{\url{https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=\%22Trusted+Platform+Module\%22}}.
Only two of them had impact on the implementation of a dedicated chip:
\begin{itemize}
\item\emph{CVE-2017-15361}
\end{itemize}
\subsubsection{Using the TPM}
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{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.
\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 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}.
\subsubsection{The Hardware}
The TCG achieved with the previous mentioned software layers independence of the underlying hardware.
Hence, TCG provided different flavors of of the TPM
TCG defined with the TPM2.0 standard 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.
Since TCG published its documents, several IT security teams investigated concept and implementations of TPMs.
\begin{itemize}
\item security problems with some implementations
\end{itemize}
\begin{itemize}
\item Hierarchies
\item Endorsement Key
@ -60,4 +132,4 @@ The Kernel can measure many different types of Resources.
What is a useful set of measurements
\section{Verify Trust (DA and DAA)}
Use the TPM to proof trustwothiness to other instances like the PIA
Use the TPM to proof trustworthiness to other instances like the PIA
