They appear as PCs, notebooks, cellular phones or embedded devices.
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 electrical devices.
Especially the footprint of embedded computers became so small that they can be used in almost all electrical devices.
@ -130,40 +133,16 @@ Since the Digidow protocols are not yet finalized, some assumptions are defined
This includes USB wire tapping or debug interfaces within the system revealing sensitive information.
This includes USB wire tapping or debug interfaces within the system revealing sensitive information.
\end{itemize}
\end{itemize}
\section{Description of structure}
\section{Organization}
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this thesis.
In the next chapter, we will indroduce and discuss existing contributions in the targeted scientific area.
There is, however, scientific work that is used as scientific background to this thesis as described in \autoref{cha:background}.
This includes especially the theoretical foundations of the network protocol which is part of our contribution.
This includes especially the theoretical foundations of the network protocol.
Together with that, we will introduce our theoretical solution for the previously stated problems in \autoref{cha:concept}.
Together with that, we will introduce our theoretical solution for the previously stated problems in \autoref{cha:concept}.
Chapter~\ref{cha:implementation} introduces then a working implementation with all necessary parts for a working prototype.
\autoref{cha:implementation} introduces then a working implementation with all necessary parts for provisioning the environment and the used hosts accordingly.
Finally we will present the results and limitations in \autoref{cha:conclusion} and give an overview of future work.
Finally we will present the results and limitations in \autoref{cha:conclusion} and give an overview of future work.
\chapter{Related Work}\label{cha:relatedwork}
There exist already a variety 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 et al.\,\cite{keylime16} 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.
The concept of a well known virtual environment does, however, not apply to our contribution.
Furthermore, 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?
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO website\cite{fido18}
%TODO Is it noteworthy, that Xaptum claims to be compatible with FIDO ECDAA for TPM2?
\begin{itemize}
\begin{itemize}
\item What exists in the field?
\item What exists in the field?
\item Keylime -- DONE
\item Xaptum ECDAA -- part of concept
\item FIDO 2 ECDAA -- noteworthy in background?
\item Strongswan Attestation --
\item Strongswan Attestation --
\item Linux IMA -- mentioned in Background
\item Secure Boot -- in difference to trusted boot
@ -41,14 +41,13 @@ The last two entries describe vulnerabilities in dedicated TPM chips, which are
This weakness made brute force attacks against keys of up to 2048 bits length feasible.
This weakness made brute force attacks against keys of up to 2048 bits length feasible.
According to Nemec et al.\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3 CPU months and 2048 bit keys needed 100 CPU years when using one core of an Intel Xeon E5-2650 v3 CPU.
According to Nemec et al.\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3 CPU months and 2048 bit keys needed 100 CPU years when using one core of an Intel Xeon E5-2650 v3 CPU.
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "\emph{TPM fail}" \cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and lattice attacks.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "TPM fail" \cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and lattice attacks.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM implementation.
The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM implementation.
Infineon TPM show also some non-expected behaviour, but this could not be used for data exfiltration.
Infineon TPM show also some non-expected behaviour, but this could not be used for data exfiltration.
STM provided an update like Infineon did for their TPMs.
STM provided an update like Infineon did for their TPMs.
Intel's fTPM required a platform firmware update to solve the issue.
Intel's fTPM required a platform firmware update to solve the issue.
\end{itemize}
\end{itemize}
\subsection{Using the TPM}
\subsection{Using the TPM}
\label{sssec:tpm-usage}
\label{sssec:tpm-usage}
On top of the cryptographic hardware, the TCG provides several software interfaces for application developers:
On top of the cryptographic hardware, the TCG provides several software interfaces for application developers:
@ -217,6 +216,26 @@ The user can check the resulting values in the written PCR registers against kno
These values can either be precomputed or just the result of a previous boot.
These values can either be precomputed or just the result of a previous boot.
If all values match the expectations, the chain of trust exists between the SRTM and the kernel.
If all values match the expectations, the chain of trust exists between the SRTM and the kernel.
\subsection{Secure Boot}%
\label{sub:secure_boot}
Secure boot is another technology to prevent malware from being executed before the OS kernel is loaded.
Microsoft describe on their Documentation for Windows and UEFI what requirements are needed and how the secure boot process looks like\cite{microsoft14}.
It is part of the UEFI specification and uses, similar to trusted boot, checksums of firmware, option roms and the boot loader.
These checksums are checked against a signature database, which is held within the platform's NVRAM.
The signatures are created with the platform key (PK) which is by default owned and managed by Microsoft.
Although it is possible to install a new own PK and sign relevant software with it, you can only boot software signed from Microsoft by default when secure boot is enabled.
Shim is the gatekeeper for OSes not maintained by Microsoft.
The binary is signed with the official PK and uses itself a self signed CA to sign further executables.
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.
Secure boot uses instead of the TPM conventional NVRAM to store private parts of its signing keys.Although there exists a signature chain for any software involved in Microsoft's boot process, using alternative OSes breaks the signature chain.
When using an own PK, you loose the benefit of having externally created and signed hash values for checking during booting.
Secure and trusted boot can, however, exist side by side on one system.
The benefit of using it seems to be very limited when not using a Microsoft OS.
\section{Integrity Measurement Architecture}%
\section{Integrity Measurement Architecture}%
\label{sec:integrity_measurement_architecture}
\label{sec:integrity_measurement_architecture}
@ -306,9 +325,14 @@ In addition to these templates, the system owner can define custom policies.
Some example policies can be found in the Gentoo Wiki\cite{gentoo19}.
Some example policies can be found in the Gentoo Wiki\cite{gentoo19}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless entries in the measurement log.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless entries in the measurement log.
\subsection{IMA Extensions}%
\subsection{Other System Integrity Approaches}%
\label{ssub:ima_extensions}
\label{sub:other_system_integrity_approaches}
Extended Verification Module (EVM)
Schear et al.\,\cite{keylime16} 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.
The concept of a well known virtual environment does, however, not apply to our use case.
Instead, the system should be self contained as good as possible and it should be possible to get information about the system via anonymous attestation.
\section{Direct Anonymous Attestation}%
\section{Direct Anonymous Attestation}%
\label{sec:direct_anonymous_attestation}
\label{sec:direct_anonymous_attestation}
@ -511,3 +535,12 @@ Unlike the description in the original paper, we describe the practical approach
\item\emph{Symmetry of Link}: It does not matter in which order the linked signatures will be proven. The link algorithm will always output the same result.
\item\emph{Symmetry of Link}: It does not matter in which order the linked signatures will be proven. The link algorithm will always output the same result.
\end{itemize}
\end{itemize}
%TODO Überleitung zum nächsten Kapitel und FIDO einbauen
\subsection{Standardization of DAA}%
\label{sub:standardization_of_daa}
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO website\cite{fido18}
This standard implements a close variant of the previously described concept.
