@ -239,7 +239,7 @@ 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.
Secure boot uses conventional non-volatile memory instead of the TPM to store private parts of its signing keys.
Therefore, Secure and trusted boot can exist side by side on one system.
Therefore, Secure and trusted boot can exist side by side on one system.
However, Garrett shows~\cite{Garrett2012} that there exists a way to bypass secure boot without notifying the user.
However, Garrett shows that there exists a way to bypass secure boot without notifying the user~\cite{Garrett2012}.
He describes that the secure boot process only hands over environment variables to the kernel which tells that the previous boot steps were certified.
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.
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.
@ -253,6 +253,9 @@ The hypervisor can then act accordingly to defined policies or attest the integr
\subsection{Trusted Execution Environment}
\subsection{Trusted Execution Environment}
Although the name is similar to Intel's TXT, the goal of the \emph{Trusted Execution Environment} (TEE) is quite different.
Instead of \emph{trusting} the whole system, TEE is a separate portion of the main processor with separated memory and storage capabilities.
\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.)
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.)
The root certificate and the intermediate certificate need to be concatenated into one file to allow \texttt{openssl} to check the certificate chain as well.
\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.
So, if the above described check fails, no source of trust can ensure that the root certificate is correct.
So, if the above described check fails, no source of trust can ensure that the root certificate is correct.
We found that both, ECC and RSA chains of all TPMs are intact.
We found that both, ECC and RSA chains of all TPMs are intact.
For documentation reasons, we provide the OpenSSL SHA256 checksums of all used certificates in \autoref{tab:certchksum}.
For documentation reasons, we provide the OpenSSL SHA256 checksums of all used certificates in \autoref{tab:certchksum} of the Appendix.
@ -38,7 +38,7 @@ First, we show the impact on disk usage when IMA is enabled.
In this case, the file hashes will be stored as extended file attributes.
In this case, the file hashes will be stored as extended file attributes.
According to the xattr man page~\cite{XattrMan2021}, the ext4 file system creates therefore a single block per file where all extended attributes must find place.
According to the xattr man page~\cite{XattrMan2021}, the ext4 file system creates therefore a single block per file where all extended attributes must find place.
The block size of the used filesystem is 4\,KB.
The block size of the used filesystem is 4\,KB.
The number of files is determined with the following command
The number of files is determined with the following command:
\begin{lstlisting}[numbers=none]
\begin{lstlisting}[numbers=none]
find / -fstype ext4 -type f -uid 0 | wc -l
find / -fstype ext4 -type f -uid 0 | wc -l
\end{lstlisting}
\end{lstlisting}
@ -47,7 +47,7 @@ This results in estimated additional disk usage of 613\,MB when adding the \text
Further attributes, however, would not require more disk space on ext4 since every extended attribute must exist in this single block.
Further attributes, however, would not require more disk space on ext4 since every extended attribute must exist in this single block.
IMA holds all runtime information as virtual files in memory, including the integrity log.
IMA holds all runtime information as virtual files in memory, including the integrity log.
In context of memory usage, it is clear that the size of the virtual files without the redundant information (like PCR number and log format) is a rough estimation for the memory usage within the kernel since we did not analyze the corresponding data structires within the kernel.
In context of memory usage, it is clear that the size of the virtual files without the redundant information (like PCR number and log format) is a rough estimation for the memory usage within the kernel since we did not analyze the corresponding data structures within the kernel.
Both memory and disk usage do not change between IMA's fixing and enforcing mode since enforcing only adds file access control.
Both memory and disk usage do not change between IMA's fixing and enforcing mode since enforcing only adds file access control.
Saving the file to disk, uses about 2\,MB of size per 10,000 lines in the log.
Saving the file to disk, uses about 2\,MB of size per 10,000 lines in the log.
@ -252,14 +252,17 @@ The graphs of \autoref{fig:time-digidow-transaction} show the runtime of each of
\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? Klarifizieren, und mit einzelnen Testpunkten versuchen zu bestätigen)
\end{figure}
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)$.
In addition to the tests above, we measured the time of reading the IMA log file when there it held 266488 entries which is roughly 4 times the number of entries when above tests were finished.
Reading this file took the kernel of System 3 72.88\,s.
Compared to the 3.18s in the last run of above tests the slowdown is 22.91.
This result supports the complexity estimation of $O(n^2)$ when collecting the integrity log by expecting a slowdown of above 16 for a 4 times larger $n$.
Furthermore, it is interesting, that System 1 with the newer AMD processor seems to be faster in the beginning.
Furthermore, it is interesting, that System 1 with the newer AMD processor seems to be faster in the beginning.
When the number of runs reach 10,000, the system needs significantly more time than System 3 with the Intel processor.
When the number of runs reach 10,000, the system needs significantly more time than System 3 with the Intel processor, indicating an even worse asymptotic complexity.
Since the software setup on both systems is comparable (Kernel version, Linux distro, installed programs, setup with respect to \autoref{cha:implementation}), it is not clear what the reason for this difference is.
Since the software setup on both systems is comparable (Kernel version, Linux distro, installed programs, setup with respect to \autoref{cha:implementation}), it is not clear what the reason for this difference is.
It may be found either in the microarchitectural implementation or in (less) optimized code for the AMD CPU.
It may be found either in the microarchitectural implementation or in differently optimized code for the two processor architectures.
When IMA is in fixing or enforcing mode, the corresponding log will be filled with information about every accessed file.
When IMA is in fixing or enforcing mode, the corresponding log will be filled with information about every accessed file.
The numbers in \autoref{tab:imalogentries} are taken from the integrity log after 10,000 Digidow transaction tests.
The numbers in \autoref{tab:imalogentries} are taken from the integrity log after 10,000 Digidow transaction tests.
@ -282,7 +285,7 @@ The numbers in \autoref{tab:imalogentries} are taken from the integrity log afte
\end{tabular}
\end{tabular}
\end{table}
\end{table}
IMA was set to enforcing and the DAA member key was already in the TPM.
IMA was set to enforcing and the DAA member key was already in the TPM.
The root login happens when the \texttt{inputrc} file is loaeded.
The root login happens when the \texttt{inputrc} file is loaded.
In the IMA file, this file appears roughly in line 2000.
In the IMA file, this file appears roughly in line 2000.
Unfortunately, neither the number nor the sequence of entries in the integrity log is predictable in this setup.
Unfortunately, neither the number nor the sequence of entries in the integrity log is predictable in this setup.
The number depends on services and daemons started during the boot sequence.
The number depends on services and daemons started during the boot sequence.
@ -299,22 +302,6 @@ Thus, after 10000 runs to start a Digidow transaction the integrity log ended up
In the current setup, the single reliable information out of the integrity log is when one of the programs were executed on the system, the corresponding entries must be somewhere in the log.
In the current setup, the single reliable information out of the integrity log is when one of the programs were executed on the system, the corresponding entries must be somewhere in the log.
Furthermore you have to uniquely identify one program or script by the single file defining it.
Furthermore you have to uniquely identify one program or script by the single file defining it.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Estimation of performance of creating an integrity log entry}
\label{tab:imalogspeed}
\begin{tabular}{lrrr}
\toprule
&{slowdown}&{log entries}&{per entry}\\
\midrule
\textit{System 1}&14.87 &2,162 &6.88\,ms\\
\textit{System 3}&34.24 &2,561 &13.43\,ms\\
\bottomrule
\end{tabular}
\end{table}
\section{Further Test Experiences}
\section{Further Test Experiences}
When IMA is set to enforcing, some unexpected problems appeared during updating Ubuntu.
When IMA is set to enforcing, some unexpected problems appeared during updating Ubuntu.
While executing \texttt{apt upgrade}, the package manager downloads the deb packages into its cache folder at \texttt{/var/cache/apt/}.
While executing \texttt{apt upgrade}, the package manager downloads the deb packages into its cache folder at \texttt{/var/cache/apt/}.
@ -327,7 +314,17 @@ 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? dd von partition und zurückspielen. Funktioniert das?)
However, we found two other ways to change the IMA setting of the kernel.
One way is to boot a backup kernel with IMA set to \texttt{fix} or \texttt{off} and moving the generated file to the EFI partition.
The second option is to create a backup of the complete EFI partition when IMA is not in enforcing mode.
Creating a backup is done with the following command:
\begin{lstlisting}[numbers=none]
dd if=/dev/nvme0n1p1 of=/root/efi-backup.img
\end{lstlisting}
When the kernel runs with IMA in enforcing mode, the keernel still allows to restore the backup with:
\begin{lstlisting}[numbers=none]
dd if=/root/efi-backup.img of=/dev/nvme0n1p1
\end{lstlisting}
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.
@ -48,13 +48,13 @@ In the context of using the TPM, we faced several problems that are not solved y
Although it is possible to update the TPM, we were not able to get a recent firmware blob for this TPM.
Although it is possible to update the TPM, we were not able to get a recent firmware blob for this TPM.
\item The TPM manufacturer, Infineon in our case, hosts the certificate chain on a website where only the domain name leads to the manufacturing company.
\item The TPM manufacturer, Infineon in our case, hosts the certificate chain on a website where only the domain name leads to the manufacturing company.
The website does not provide further cryptographic trust.
The website does not provide further cryptographic trust.
When the certificate chain is broken, it may not be clear whether the user posseses a corrupt TPM or the website just provides bogus certificates.\ToDo(Is this really that much of an issue?)
When the certificate chain is broken, it may not be clear whether the user posseses a corrupt TPM or the website just provides bogus certificates.
\item The chain of trust between TPM manufacturer and DAA member key is not complete in the current implementation since there is no cryptographic link between the certified endorsement key and the DAA member key.
\item The chain of trust between TPM manufacturer and DAA member key is not complete in the current implementation since there is no cryptographic link between the certified endorsement key and the DAA member key.
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.
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.
Although complex documentation is usual for standards, an interested developer may need more time as expected for understanding the interfaces.
\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.
% Hier Abstact in der Sprache eingeben, in der die Arbeit geschrieben wurde.
% Hier Abstact in der Sprache eingeben, in der die Arbeit geschrieben wurde.
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.
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 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.
@ -37,6 +37,7 @@ Based on the implemented system, we discuss the properties of a trustworthy envi
{
{
\let\clearpage\relax
\let\clearpage\relax
\vskip-4ex
\ifeng
\ifeng
\selectlanguage{ngerman}
\selectlanguage{ngerman}
\chapter*{Kurzfassung}
\chapter*{Kurzfassung}
@ -44,7 +45,7 @@ Based on the implemented system, we discuss the properties of a trustworthy envi
\selectlanguage{english}
\selectlanguage{english}
\chapter*{Abstract}
\chapter*{Abstract}
\fi
\fi
\vskip-2.5ex
% 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 Nutzer 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.
