@ -76,7 +76,12 @@ It is a passive device with some volatile and non-volatile memory, which provide
The standard allows to add some extra functionality to the device.
The standard allows to add some extra functionality to the device.
However, the TPMs used in this project provide just the minimal set of algorithms and also the minimal amount of memory.
However, the TPMs used in this project provide just the minimal set of algorithms and also the minimal amount of memory.
Since TCG published its documents, several IT security teams investigated the concept and implementations of TPMs. \ToDo (With what outcome? references? AW Matthew Garrett references?)
Since TCG published its documents for the TPM~2.0 standard, only few vulnerabilities were found in hardware implementations, as we showed in \autoref{sec:trusted_platform_module_tpm_}.
This is caused by a firm hardware definition and by using widely used and well proven cryptographic algorithms.
Only the group signature scheme is the relatively new implementation of Camenisch et al.~\cite{camenisch16b}, \cite{camenisch17}.
They discuss a variety of concepts with their provable flaws \cite{camenisch16} and show thereafter an own implementation.
The prove of their concept is still valid at the time of this writing.
Thus, we assume a hardware TPM~2.0 to be a reliable source for cryptographic algorithms.
\subsection{TPM Key Hierarchies}%
\subsection{TPM Key Hierarchies}%
\label{sub:tpm_key_hierarchies}
\label{sub:tpm_key_hierarchies}
@ -201,15 +206,16 @@ This indicates a broken chain of trust and should only appear when using the TPM
\subsection{Platform Handover to OS}%
\subsection{Platform Handover to OS}%
\label{sub:platform_handover_to_os}
\label{sub:platform_handover_to_os}
The BIOS or UEFI performs the next measurements according to table \ref{tab:PCR} until PCRs 1--7 are written accordingly.
The BIOS or UEFI performs the next measurements according to table \ref{tab:PCR} until PCRs 0--7 are written accordingly as shown in section 2.2.3 of the TCG PC Client Platform Firmware Profile~\cite{tcg-pc19}.
Before any further measurements are done, the control of the platform is handed over to the kernel of either a bootloader or the OS when booting without any bootloaders.
Before any further measurements are done, the control of the platform is handed over to the kernel of either a bootloader or the OS when booting without any bootloaders.
In any case, these binaries are stored in the \emph{Master Boot Record} (MBR) or provided as EFI blob in the EFI boot partition.
In any case, these binaries are stored in the \emph{Master Boot Record} (MBR) or provided as EFI blob in the EFI boot partition.
It is noteworthy that the bootloader itself and its configuration payload is measured in PCR 4 and 5 before the handover is done.
It is noteworthy that the bootloader itself and its configuration payload is measured in PCR 4 and 5 before the handover is done.
This guarantees that the chain of trust keeps intact when the bootloader/OS takes control.
This guarantees that the chain of trust keeps intact when the bootloader/OS takes control.
The bootloader has to continue the chain of trust by measuring the kernel and the corresponding command line parameters into the next PCRs.
The bootloader has to continue the chain of trust by measuring the kernel and the corresponding command line parameters into the next PCRs.
The support and the way how the measurements are done is not standardized.
The support and the way how the measurements are done in PCR 8 and higher is not defined by TCG.
GRUB, for example, measures all executed GRUB commands, the kernel command line and the module command line into PCR 8, whereas any file read by GRUB will be measured into PCR 9~\cite{grub19}. \ToDo (Any example for a bootloader that does it differently)
They only reserver PCR 8--15 for the OS.
GRUB, for example, measures all executed GRUB commands, the kernel command line and the module command line by default into PCR 8, whereas any file read by GRUB will be measured into PCR 9~\cite{grub19}.
The whole process from initialization over measuring all software parts until the OS is started, is called \emph{Trusted Boot}.
The whole process from initialization over measuring all software parts until the OS is started, is called \emph{Trusted Boot}.
The user can check the resulting values in the written PCR registers against known values.
The user can check the resulting values in the written PCR registers against known values.
@ -231,10 +237,22 @@ The binary is signed with the official PK and uses itself a self signed CA to si
A detailed description how shim works on Ubuntu is shown on their corresponding Wiki page~\cite{ubuntuwiki20}.
A detailed description how shim works on Ubuntu is shown on their corresponding Wiki page~\cite{ubuntuwiki20}.
Only this workflow enables secure boot when using Linux OSes.
Only this workflow enables secure boot when using Linux OSes.
Secure boot uses conventional non-volatile memory instead of the TPM to store private parts of its signing keys. \ToDo Although there exists a signature chain for any software involved in Microsoft's boot process, using alternative OSes breaks the signature chain.
Secure boot uses conventional non-volatile memory instead of the TPM to store private parts of its signing keys.
When using an own PK, you loose the benefit of having externally created and signed hash values for checking during booting.
Therefore, Secure and trusted boot can exist side by side on one system.
Secure and trusted boot can, however, exist side by side on one system. \ToDo (Why? Due to not working with a TPM? If yes, that's also the case with Secure Boot for a Microsoft OS, right?)
However, Garrett shows~\cite{Garrett2012} that there exists a way to bypass secure boot without notifying the user.
The benefit of using it seems to be very limited when not using a Microsoft OS. \ToDo (Unless you cite such a statement it seems to be inappropriate for this part of your thesis)
He describes that the secure boot process only hands over environment variables to the kernel which tells that the previous boot steps were certified.
An attacker could easily pass the same variables to the kernel, which boots then without noticing the broken secure boot process which breaks the effective trust in this system.
\subsection{Intel Trusted Execution Technology}
As TPM~1.2 chips became available, Intel published an own standard for trusted virtual environments which they called \emph{Trusted Execution Technology} (TXT)~\cite{Intel2012}.
It extends the standard from TCG by defining a measured launch, similar to trusted boot, for virtual machines.
When booting a VM, it measures the boot process and provides the results to the hypervisor.
As soon as the measuring results are available, the hypervisor is able to check those against known values and detect modified (= untrusted) machines.
The hypervisor can then act accordingly to defined policies or attest the integrity of the guest machine.
\subsection{Trusted Execution Environment}
\ToDo(In deinem Fall würde ich empfehlen, Intel TXT (sehr kurz, ein Absatz reicht) und TEE allgemeiner (konkrete ARM Trustzone) etwas ausführlicher (nicht mehr als eine halbe Seite, dafür vielleicht mit ein paar Referenzen wofür ARM TEEs schon heute verwendet werden, was als teilweise Ersatz von TPMs gesehen werden könnte) zu erwähnen. Aber noch weiter würde ich die Runde nicht ziehen.)
\ToDo(In deinem Fall würde ich empfehlen, Intel TXT (sehr kurz, ein Absatz reicht) und TEE allgemeiner (konkrete ARM Trustzone) etwas ausführlicher (nicht mehr als eine halbe Seite, dafür vielleicht mit ein paar Referenzen wofür ARM TEEs schon heute verwendet werden, was als teilweise Ersatz von TPMs gesehen werden könnte) zu erwähnen. Aber noch weiter würde ich die Runde nicht ziehen.)
@ -147,8 +147,7 @@ The system needs to check its integrity on the OS level and summarize that by pu
\autoref{fig:measuements} illustrates how above processes extend the trust on the system.
\autoref{fig:measuements} illustrates how above processes extend the trust on the system.
The TPM is the cryptographic root of trust, storing all measurement results and the target values for validation.
The TPM is the cryptographic root of trust, storing all measurement results and the target values for validation.
Since the RTM is the only piece of code which lives in the platform firmware and is executed \emph{before} it is measured, it is an important part in the trust architecture of the system.
Since the RTM is the only piece of code which lives in the platform firmware and is executed \emph{before} it is measured, it is an important part in the trust architecture of the system.
An honest RTM will measure the binary representation of itself, which makes the code at least provable afterwards. \ToDo (not really since you can still not distinguish this from an dishonest RTM)
The CPU is assumed to execute all the code according to its specification.
Finally, the CPU is assumed to execute all the code according to its specification.
Proving correctness of the instruction set cannot be done during the boot process.
Proving correctness of the instruction set cannot be done during the boot process.
When the roots of trust are honest, the trusted environment can be constructed during booting the platform with the PCR measurements.
When the roots of trust are honest, the trusted environment can be constructed during booting the platform with the PCR measurements.
@ -87,7 +87,10 @@ Ubuntu installs Grub by default, which we will use in the following as a fallbac
\section{Trusted Boot}\ToDo(Für das Master-Projekt: FDE mit TPM klingt im ersten Moment nach einem guten Teil, der als "Add-on" definiert werden könnte zum ursprünglichen Auftrag für die Masterarbeit (Attestation, Trusted Boot und IMA sind hier näher am eigentlichen Kern). Vielleicht sollten wir das als Projekt herausschneiden und mit einem eigenen kurzen Dokument bzw. einer Abgabe definieren? Das Dokument kann auch z.B. ein "HOWTO Setup" für FDE mit TPM für Standard-Debian/Ubuntu sein, das du vermutlich in anderer Form schon als Markdown-Doc hast, wenn es einfach nur mit einem Titel und Hinweis aus Master-Projekt versehen wird.)
\section{Trusted Boot}
Parts of this section contain results of the master project which documented how to build an Linux environment with TPM backed full disk encryption.
This includes the evaluation which Linux distributions support trusted boot, the scripts to handle the encryption key in the TPM and the documentation how to build the unified kernel.
By default, every mainboard with support for TPM~2.0 must support trusted boot.
By default, every mainboard with support for TPM~2.0 must support trusted boot.
When a TPM becomes available, the UEFI/BIOS itself takes all required measures until the boot process is handed over to the OS bootloader (e.g. Grub).
When a TPM becomes available, the UEFI/BIOS itself takes all required measures until the boot process is handed over to the OS bootloader (e.g. Grub).
Since Ubuntu uses GRUB 2.04 as bootloader which has TPM support by default, trusted boot needs just to be enabled in the Grub configuration.
Since Ubuntu uses GRUB 2.04 as bootloader which has TPM support by default, trusted boot needs just to be enabled in the Grub configuration.
@ -211,7 +214,7 @@ The first four parameters used in the kernel command line as shown in \autoref{c
\item\texttt{ima\_appraise=fix} appends the filehash as an extended file attribute for every accessed file.
\item\texttt{ima\_appraise=fix} appends the filehash as an extended file attribute for every accessed file.
\item\texttt{ima\_policy=appraise\_tcb} together with \texttt{ima\_policy=tcb} analyze files owned by root and opened for execution.
\item\texttt{ima\_policy=appraise\_tcb} together with \texttt{ima\_policy=tcb} analyze files owned by root and opened for execution.
\item\texttt{ima\_hash=sha256} sets the hashing algorithm.
\item\texttt{ima\_hash=sha256} sets the hashing algorithm.
\item\texttt{rootflags=i\_version} must be enabled when mounting the filesystem since IMA is checking that number before re-hashing the resource. \ToDo(what number)
\item\texttt{rootflags=i\_version} must be enabled when mounting the filesystem since IMA is checking the \texttt{i\_version} number before re-hashing the resource. When it is disabled, the kernel has to hash the resource every time.
\end{itemize}
\end{itemize}
Unfortunately, the resulting integrity log is between 2000 and 3000 lines long when the system is freshly booted.
Unfortunately, the resulting integrity log is between 2000 and 3000 lines long when the system is freshly booted.
@ -299,12 +302,13 @@ Other vendors like STM, AMD or Intel may provide certificates via download on th
The option \texttt{-untrusted} is required since the provided root CA is not in the OS trust store and hence of unknown trust. \ToDo(I'm a bit surprised thet openSSL checks against the system trust store even when providing a specific CA file. Have you checked that verification fails if you di not provide the CA file/if the CA file is incorrect/etc.)
The option \texttt{-untrusted} is required since the provided root CA is not in the OS trust store and hence of unknown trust. \ToDo(I'm a bit surprised thet openSSL checks against the system trust store even when providing a specific CA file. Have you checked that verification fails if you did not provide the CA file/if the CA file is incorrect/etc.)
\ToDo(Check Sigflag Link - andere Variante fürs checken)
When OpenSSL returns \texttt{OK}, the certificate chain is intact and the TPM is indeed one from Infineon.
When OpenSSL returns \texttt{OK}, the certificate chain is intact and the TPM is indeed one from Infineon.
To be exact: The website, probably hosted by Infineon, provides a certificate chain which matches and the links to the corresponding parent certificate are correct.
To be exact: The website, probably hosted by Infineon, provides a certificate chain which matches and the links to the corresponding parent certificate are correct.
Unfortunately, Infineon does neither provide any website certification nor any checksums of the provided certificates.
Unfortunately, Infineon does neither provide any website certification nor any checksums of the provided certificates.
@ -341,7 +345,7 @@ These checksums were generated with:
\bottomrule
\bottomrule
\end{tabular}
\end{tabular}
\end{table}
\end{table}
\ToDo (table into Appendix?)
\ToDo (table into Appendix? mit genau einem Satz)
\section{Using the DAA Protocol}
\section{Using the DAA Protocol}
Direct anonymous attestation uses the TPM as cryptoprocessor and key store.
Direct anonymous attestation uses the TPM as cryptoprocessor and key store.
The feature of identifiable instances of sensors is not required when interacting with the Digidow network.
The feature of identifiable instances of sensors is not required when interacting with the Digidow network.
@ -424,7 +428,9 @@ It is designed to match the workflow of a Digidow transaction, affecting the dec
This protocol requires the group public key to be present at the DAA member.
This protocol requires the group public key to be present at the DAA member.
If this is not the case, the member asks for it automatically.
If this is not the case, the member asks for it automatically.
The procedure is a four-way handshake, as shown in \autoref{fig:daa-network-join}.
The procedure is a four-way handshake, as shown in \autoref{fig:daa-network-join}.
We describe in \autoref{ssec:daa-protocol-on-lrsw-assumption} that the key exchange is cryptographically secure, meaning that no adversary can extract any private keys when getting access to these messages. \ToDo(Please clarify that you completely skip any endorsement in the practical implementation)
We describe in \autoref{ssec:daa-protocol-on-lrsw-assumption} that the key exchange is cryptographically secure, meaning that no adversary can extract any private keys when getting access to these messages.
When the member is eventually part of the DAA group, it is \emph{tusted} by the Issuer, requiring a thorough inspection of the member beforehand.
Since we only show a working demo of the cryptographic concept, we skipped any efforts to check the member system in this implementation.
\caption{Time consumption of a Digidow transaction on the tested systems}
\caption{Time consumption of a Digidow transaction on the tested systems}
\label{fig:time-digidow-transaction}
\label{fig:time-digidow-transaction}
\end{figure}\ToDo (Does this really indicate quadratic or exponential trend?)
\end{figure}\ToDo (Does this really indicate quadratic or exponential trend? Klarifizieren, und mit einzelnen Testpunkten versuchen zu bestätigen)
Each run is split into the four parts of a Digidow transaction.
Each run is split into the four parts of a Digidow transaction.
The graphs clearly show that our expectation of a linear relation between runtime and number of runs were not satisfied.
The graphs clearly show that our expectation of a linear relation between runtime and number of runs were not satisfied.
It seems that collecting the integrity log has an estimated complexity of $O(n^2)$.
It seems that collecting the integrity log has an estimated complexity of $O(n^2)$.
@ -327,7 +327,7 @@ The missing attributes are also a problem when attemping to turn IMA off again.
This requires an updated command line and thereafter an updated unified kernel.
This requires an updated command line and thereafter an updated unified kernel.
Generating the new kernel works fine but moving the blob into the EFI partition fails due to the missing support of extended file attributes.
Generating the new kernel works fine but moving the blob into the EFI partition fails due to the missing support of extended file attributes.
The copy process seems to create the file, but it fails when trying to write the first blocks.
The copy process seems to create the file, but it fails when trying to write the first blocks.
As a result, the only way to update the kernel on this system is to boot a backup kernel with IMA set to \texttt{fix} or \texttt{off} and moving the file to the EFI partition. \ToDo(what about overwriting the whole partition with a new image?)
As a result, the only way to update the kernel on this system is to boot a backup kernel with IMA set to \texttt{fix} or \texttt{off} and moving the file to the EFI partition. \ToDo(what about overwriting the whole partition with a new image? dd von partition und zurückspielen. Funktioniert das?)
Another relevant part for attestation is to use the integrity log file do recalculate the produced hashes.
Another relevant part for attestation is to use the integrity log file do recalculate the produced hashes.
This means on one hand to recalculate the hash in the integrity log entry.
This means on one hand to recalculate the hash in the integrity log entry.
@ -353,4 +353,3 @@ The value of PCR 10 was still not reproducible.
Furthermore the documentation of calculating these values does not mention how the sha256 hash in PCR 10 is calculated.
Furthermore the documentation of calculating these values does not mention how the sha256 hash in PCR 10 is calculated.
\texttt{tpm2\_pcrextend} requires a sha256 hash as input for the corresponding PCR bank, but the integrity log only provides sha1 hashes.
\texttt{tpm2\_pcrextend} requires a sha256 hash as input for the corresponding PCR bank, but the integrity log only provides sha1 hashes.
Hence, any verification procedures regarding the sha256 bank of PCR 10 are currently not implemented.
Hence, any verification procedures regarding the sha256 bank of PCR 10 are currently not implemented.
\ToDo (Does ascii\_runtime\_measurements contain the SHA1 hashes of the file or the history of PCR 10 values after appending the file hash into it?) Figure 2.2 (p16) shows that this should be the template hash
@ -53,7 +53,8 @@ In the context of using the TPM, we faced several problems that are not solved y
The member key is only located in the endorsement hierarchy.
The member key is only located in the endorsement hierarchy.
\item The documentation of the TPM software stack is not beginner friendly.
\item The documentation of the TPM software stack is not beginner friendly.
On one hand, the TCG documentation is free to use and provides a narrow definition of a TPM.
On one hand, the TCG documentation is free to use and provides a narrow definition of a TPM.
On the other hand, it is optimized to be machine readable and it is usually necessary to read parts of Arthur et al. \emph{A Practical Guide to TPM~2.0}~\cite{arthur15} to understand how the documentation is managed. \ToDo(How does this guide not solce the gap? AW: I NEED a guide to be able to read the docs.)
On the other hand, it is optimized to be machine readable and it is usually necessary to read parts of Arthur et al. \emph{A Practical Guide to TPM~2.0}~\cite{arthur15} to understand how the documentation is managed.
Although complex documentation is usual for standards, an interested developer may need more time as expected for understanding the system.
\item Using the TPM~2.0 tools for low effort interaction with the TPM is relatively easy. Unfortunately, the parameters are incompatible over its major releases, breaking any scripts depending on that.
\item Using the TPM~2.0 tools for low effort interaction with the TPM is relatively easy. Unfortunately, the parameters are incompatible over its major releases, breaking any scripts depending on that.
These differences are not documented and not announced publicly, making it hard to update any shell scripts depending on that.
These differences are not documented and not announced publicly, making it hard to update any shell scripts depending on that.
\end{itemize}
\end{itemize}
@ -81,7 +82,7 @@ Similar to using TPMs, the integrity of the sensor's hardware and software are f
Given the limitations in the current setup, we provide some thoughts which might be worth implementing on top of this contribution.
Given the limitations in the current setup, we provide some thoughts which might be worth implementing on top of this contribution.
Depending on the usage model, it might be worth extending the DAA scheme into a full dynamic group signature scheme.
Depending on the usage model, it might be worth extending the DAA scheme into a full dynamic group signature scheme.
Camenisch et al.~\cite{camenisch17} discuss how the existing scheme could be extended to support the features of dynamic groups by implementing signature based revocation.
Camenisch et al.~\cite{camenisch17} discuss how the existing scheme could be extended to support the features of dynamic groups by implementing signature based revocation.
Although their concept seems to work, there is no implementation available in the public and it is not recommended to implement cryptographic algorithms by oneself. \ToDo(Well, that does not really hold in this case)
Although their concept seems to work, there is currently no widespread public library available in the public.
We discussed in the previous section a missing link in the chain of trust of the TPM.
We discussed in the previous section a missing link in the chain of trust of the TPM.
This gap could be closed by certifying that the DAA membership key is in the endorsement hierarchy.
This gap could be closed by certifying that the DAA membership key is in the endorsement hierarchy.
% Hier Abstact in der Sprache eingeben, in der die Arbeit geschrieben wurde.
% Hier Abstact in der Sprache eingeben, in der die Arbeit geschrieben wurde.
What is it all about? Why is that interesting? What is new in this thesis? Where is the solution directing to?
The \textit{Digital Shadow} project, developed at the Institute for Networks and Security, requires verifiable trust in many areas in order to recognize and authorize users based on their biometric data.
This trust should give the user the opportunity to check the correctness of the system quickly and easily before he or she provides the system with biometric data.
This master's thesis deals with the existing tools that can create such trust.
The implemented system combines these tools in order to identify users in the Digital Shadow network with their biometric data.
Incorrect use of this sensitive data should be excluded and the smallest possible set of metadata should be generated.
Based on the implemented system, we discuss the properties of a trustworthy environment for software and explain the necessary framework requirements.
{
{
\let\clearpage\relax
\let\clearpage\relax
@ -41,13 +46,12 @@ What is it all about? Why is that interesting? What is new in this thesis? Where
\fi
\fi
% Hier Abstact in der jeweils anderen Sprache eingeben.
% Hier Abstact in der jeweils anderen Sprache eingeben.
Das am Institut für Netzwerke und Sicherheit entwickelte Projekt \textit{Digital Shadow} benötigt in vielen Bereichen ein prüfbares Vertrauen um eine Erkennung von Nutzern anhand ihrer biometrischen Daten zu erkennen und Berechtigungen zuzuteilen.
Das am Institut für Netzwerke und Sicherheit entwickelte Projekt \textit{Digital Shadow} benötigt in vielen Bereichen ein prüfbares Vertrauen um Nutzer anhand ihrer biometrischen Daten zu erkennen und Berechtigungen zuzuteilen.
Das Vertrauen soll dem Nutzer die Möglichkeit geben, die Korrektheit des Systems schnell und einfach zu prüfen, bevor er/sie disesm System biometrische Daten zur Verfügung stellt
Das Vertrauen soll dem Nutzer die Möglichkeit geben, die Korrektheit des Systems schnell und einfach zu prüfen, bevor er/sie disesm System biometrische Daten zur Verfügung stellt.
Diese Masterarbeit beschäftigt sich nun mit den existierenden Werkzeugen, die ein solches Vertrauen schaffen können.
Diese Masterarbeit beschäftigt sich mit den existierenden Werkzeugen, die ein solches Vertrauen schaffen können.
Das implementierte System kombiniert diese Werkzeuge, um damit sensible Daten von Nutzern aufzunehmen und im Netzwerk von Digital Shadow zu identifizieren.
Diese Werkzeuge werden kombiniert, um Nutzer im Digital Shadow Netzwerk mittels biometrischen Daten identifizieren zu können.
Es soll dabei sicher gestellt sein, dass eine fälschliche Verwendung der sensiblen Nutzerdaten ausgeschlossen wird.
Es soll dabei eine fälschliche Verwendung dieser sensiblen Daten ausgeschlossen sein und ein möglichst kleines Set von Metadaten erzeugt werden.
Anhand dieses Systems werden die Eigenschaften einer vertrauenswürdigen Umgebung für Software
Anhand des implementierten Systems werden die Eigenschaften einer vertrauenswürdigen Umgebung für Software diskutiert und notwendige Rahmenbedingungen erläutert.
diskutiert und notwendige Rahmenbedingungen erläutert.
