diff --git a/references/Brickell-DAA Concept.pdf b/references/Brickell-DAA Concept.pdf deleted file mode 100644 index e796981..0000000 Binary files a/references/Brickell-DAA Concept.pdf and /dev/null differ diff --git a/references/Camenisch-Efficient_DAA_Scheme.pdf b/references/Chen-Efficient_DAA_Scheme.pdf similarity index 100% rename from references/Camenisch-Efficient_DAA_Scheme.pdf rename to references/Chen-Efficient_DAA_Scheme.pdf diff --git a/references/TPM-Fail.pdf b/references/TPM-Fail.pdf new file mode 100644 index 0000000..3c3cad9 Binary files /dev/null and b/references/TPM-Fail.pdf differ diff --git a/references/nemec_roca_ccs17_preprint.pdf b/references/nemec_roca_ccs17_preprint.pdf new file mode 100644 index 0000000..8195ad3 Binary files /dev/null and b/references/nemec_roca_ccs17_preprint.pdf differ diff --git a/references/sec16_paper_raj.pdf b/references/sec16_paper_raj.pdf new file mode 100644 index 0000000..d09bb70 Binary files /dev/null and b/references/sec16_paper_raj.pdf differ diff --git a/thesis/01_introduction.tex b/thesis/01_introduction.tex index 0714dcd..aea9fd1 100644 --- a/thesis/01_introduction.tex +++ b/thesis/01_introduction.tex @@ -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 \item Usage Model of Biometric Sensor \end{itemize} diff --git a/thesis/02_concept.tex b/thesis/02_concept.tex index 1d3a980..d2bb450 100644 --- a/thesis/02_concept.tex +++ b/thesis/02_concept.tex @@ -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 \ No newline at end of file +Use the TPM to proof trustworthiness to other instances like the PIA \ No newline at end of file diff --git a/thesis/03_implementation.tex b/thesis/03_implementation.tex index 5116714..c758fe3 100644 --- a/thesis/03_implementation.tex +++ b/thesis/03_implementation.tex @@ -22,5 +22,5 @@ Available on all major releases after summer 2019. Fallback is using the TPM2 ESAPI or SAPI, which is available on almost all Linux distributions. \section{Direct Anonymous Attestation} -DAA Project from Xaptum: Working DAA handshakt and possible TPM integration. +DAA Project from Xaptum: Working DAA handshake and possible TPM integration. Requires an Attestation Key which is secured with a password policy. diff --git a/thesis/MAIN.pdf b/thesis/MAIN.pdf index 3af1921..19ef9ec 100644 Binary files a/thesis/MAIN.pdf and b/thesis/MAIN.pdf differ diff --git a/thesis/literature.bib b/thesis/literature.bib index cc3c363..41f511d 100644 --- a/thesis/literature.bib +++ b/thesis/literature.bib @@ -88,7 +88,7 @@ doi = {10.1007/978-1-4302-6584-9} } -@book{book, +@book{proudler14, author = {Proudler, Graeme and Chen, Liqun and Dalton, Chris}, year = {2014}, month = {01}, @@ -103,7 +103,7 @@ month = {07}, title = {Full Disk Encryption on Arch Linux backed by TPM 2.0}, url = {https://medium.com/@pawitp/full-disk-encryption-on-arch-linux-backed-by-tpm-2-0-c0892cab9704}, - urldate = {27.02.2020} + urldate = {2020-02-27} } @online{pornkitprasan19-tpmtools, @@ -112,7 +112,7 @@ month = {10}, title = {Its certainly annoying that TPM2-Tools like to change their command line parameters}, url = {https://medium.com/@pawitp/its-certainly-annoying-that-tpm2-tools-like-to-change-their-command-line-parameters-d5d0f4351206}, - urldate = {27.02.2020} + urldate = {2020-02-27} } @online{pornkitprasan19-secureboot, @@ -121,7 +121,7 @@ month = {07}, title = {The Correct Way to use Secure Boot with Linux}, url = {https://medium.com/@pawitp/the-correct-way-to-use-secure-boot-with-linux-a0421796eade}, - urldate = {27.02.2020} + urldate = {2020-02-27} } @online{tevora18, @@ -130,7 +130,15 @@ month = {06}, title = {Configuring Secure Boot + TPM 2}, url = {https://threat.tevora.com/secure-boot-tpm-2/}, - urldate = {27.02.2020} + urldate = {2020-02-27} +} + +@online{tpmsoftware20, + author = {TPM2 Software Community}, + year = {2020}, + title = {TPM2 Tools}, + url = {https://github.com/tpm2-software/tpm2-tools}, + urldate = {2020-05-15} } @online{smith18-dealing-sb, @@ -139,7 +147,7 @@ month = {07}, title = {Managing EFI Boot Loaders for Linux: Dealing with Secure Boot}, url = {https://www.rodsbooks.com/efi-bootloaders/secureboot.html}, - urldate = {27.02.2020} + urldate = {2020-02-27} } @online{smith18-controlling-sb, @@ -148,7 +156,7 @@ month = {07}, title = {Managing EFI Boot Loaders for Linux: Controlling Secure Boot}, url = {https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html}, - urldate = {27.02.2020} + urldate = {2020-02-27} } @online{corbet16, @@ -157,7 +165,7 @@ month = {02}, title = {Protecting systems with the TPM}, url = {https://lwn.net/Articles/674751/}, - urldate = {27.02.2020} + urldate = {2020-02-27} } @online{kernelsecurity18, @@ -166,7 +174,7 @@ month = {03}, title = {Linux Kernel Integrity}, url = {https://kernsec.org/wiki/index.php/Linux_Kernel_Integrity}, - urldate = {27.02.2020} + urldate = {2020-02-27} } @inproceedings{chevalier19, @@ -188,4 +196,23 @@ title = {BIOS chronomancy: Fixing the core root of trust for measurement}, journal = {Proceedings of the ACM Conference on Computer and Communications Security}, doi = {10.1145/2508859.2516714} -} \ No newline at end of file +} + +@inproceedings{moghimi20-tpmfail, + title = {{TPM-FAIL: {TPM} meets Timing and Lattice Attacks}}, + author = {Daniel Moghimi and Berk Sunar and Thomas Eisenbarth and Nadia Heninger}, + booktitle = {29th {USENIX} Security Symposium ({USENIX} Security 20)}, + year = {2020}, + address = {Boston, MA}, + url = {https://www.usenix.org/conference/usenixsecurity20/presentation/moghimi}, + publisher = {{USENIX} Association}, + month = aug, +} + +@online{tcg20, + author = {}, + year = {2019}, + title = {The TPM Library Specification}, + url = {https://trustedcomputinggroup.org/resource/tpm-library-specification/}, + urldate = {2020-05-16} +}