Browse Source

started conclusion

master
Michael Preisach 4 years ago
parent
commit
a158b1bf4c
  1. 8
      resources/daa-network-join.fig
  2. BIN
      resources/daa-network-join.pdf
  3. 2
      resources/daa-network-publish.fig
  4. BIN
      resources/daa-network-publish.pdf
  5. 4
      thesis/02_background.tex
  6. 2
      thesis/04_implementation.tex
  7. 36
      thesis/05_outlook.tex
  8. BIN
      thesis/MAIN.pdf

8
resources/daa-network-join.fig

@ -26,14 +26,18 @@ Single
2 0 1.00 120.00 180.00
6975 3300 1875 3300
2 1 1 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
1875 825 1875 3825
1875 825 1875 4425
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
6975 825 6975 3825
6975 825 6975 4425
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1050 375 2700 375 2700 825 1050 825 1050 375
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6150 375 7800 375 7800 825 6150 825 6150 375
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
2 0 1.00 120.00 180.00
1875 3900 6975 3900
4 1 0 50 -1 4 14 0.0000 0 240 3855 4500 3225 4. JOINPROCEED <cred, cred.sig>\001
4 1 0 50 -1 4 14 0.0000 0 180 1485 1875 675 DAA member\001
4 1 0 50 -1 4 14 0.0000 0 180 1215 6975 675 DAA issuer\001
4 1 0 50 -1 4 14 0.0000 0 240 2880 4500 2625 3. APPEND <member.pk>\001
4 1 0 50 -1 4 14 0.0000 0 180 630 4500 3825 5. OK\001

BIN
resources/daa-network-join.pdf

Binary file not shown.

2
resources/daa-network-publish.fig

@ -23,5 +23,5 @@ Single
6150 375 7800 375 7800 825 6150 825 6150 375
4 1 0 50 -1 4 14 0.0000 0 240 2640 4500 2025 2. PUBLISH <issuer.pk>\001
4 1 0 50 -1 4 14 0.0000 0 180 1665 4500 1425 1. GETPUBLIC\001
4 1 0 50 -1 4 14 0.0000 0 240 1125 1875 675 DAA party\001
4 1 0 50 -1 4 14 0.0000 0 180 1215 6975 675 DAA issuer\001
4 1 0 50 -1 4 14 0.0000 0 180 1050 1875 675 DAA user\001

BIN
resources/daa-network-publish.pdf

Binary file not shown.

4
thesis/02_background.tex

@ -289,6 +289,8 @@ The resulting \emph{filedata hash} will be concatenated with the corresponding m
This concatenation will again be hashed into the so called \emph{template hash} which is independently of the previous algorithm a SHA1 checksum.
Finally, the template hash is the single value of the whole computation that will be extended into the PCR.
The integrity log holds at the end the filedata hash, the metadata and the template hash as well as the PCR index and the logfile format.
Unfortunately, recomputing the hash chain was not possible in the demonstration setup.
We discuss that problem in \autoref{cha:conclusion}.
IMA knows three different file formats, where two of them can be used in recent applications.
The only difference between these formats lies in the used and logged metadata:
@ -302,7 +304,7 @@ Therefore, it should not be used for newer applications.
The first entry in every measurement file is called \texttt{boot\_aggregate}.
It is the trust link between trusted boot and IMA representing a cumulative hash of the PCR values 0 -- 7.
Consequently, the PCR result of trusted boot is also embedded in the measurement log and the shrresponding hash chain of PCR 10.
Consequently, the PCR result of trusted boot is also embedded in the measurement log and the corresponding hash chain of PCR 10.
\subsection{IMA Appraisal}%
\label{ssub:ima_appraisal}

2
thesis/04_implementation.tex

@ -245,7 +245,7 @@ This means that the hash of every file is checked before it is accessed.
Before enforcing IMA, the root filesystem should be parsed to create attributes for every file.
Touching the file is not enough, the file must be openend for read, as shown in the following command:
\begin{lstlisting}[numbers=none]
time find / -fstype ext4 -type f -uid 0 -exec dd if '{}' of=/dev/null count=0 status=none \;
time find / -fstype ext4 -type f -uid 0 -exec dd if='{}' of=/dev/null count=0 status=none \;
\end{lstlisting}
This command opens every file in an ext4 filesystem for read, causing the kernel to create/update the file attributes, but does not read any data.
It takes about fifteen minutes to parse the file system on a Ubuntu minimal server system given the hardware described above.

36
thesis/05_outlook.tex

@ -1,6 +1,42 @@
\chapter{Conclusion and Outlook}
\label{cha:conclusion}
With the setup described in the prevoius chapter, we created a system which is able to read biometric data.
The system encapsultes this data into an Attestation message and sends it to the PIA which is the DAA verifier.
We show in the following section how well the different parts of the setup work together.
\section{Testing}
The first part of the setup is trusted boot which is well integrated in recent releases of kernel and GRUB bootloader.
Furthermore the optional disk encryption unlocking works fine with the kernel, even when using the manually generated unified kernel.
Only when updating the unified kernel, EFI might have problems loading or finding the correct EFI blob on the boot partition.
Although you can check the entries in the EFI boot loader very easy, you might not check that before rebooting into an updated kernel and end up fixing the boot procedure manually.
Hence, having a system maintained bootloader setup as backup is strongly recommended.
The next part is IMA which appears to have an easy setup but a complex set of consequences.
When setting IMA in fixing mode, logging is enabled and the system slows down significantly.
\autoref{tab:boottimes} shows the performance of system 1 given a setup for a biometric sensor described in \autoref{cha:implementation} with TPM backed disk encryption enabled.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Systems used for demonstration prototype} \label{tab:boottimes}
%\rowcolors{2}{lightgray}{white}
\begin{tabular}{rlll}
\toprule
&\textit{System 1}&\textit{System 2}&\textit{System 3} \\
\midrule
\textbf{Boot with IMA off} &\textasciitilde\,27\,s & &\\
\textbf{Boot with IMA fix} &\textasciitilde\,44\,s &\\
\textbf{Boot with IMA enforce} & & & \\
\textbf{Reboot with IMA off} &\textasciitilde\,28\,s & &\\
\textbf{Reboot with IMA fix} &\textasciitilde\,47\,s & & \\
\textbf{Reboot with IMA enforce} & & & \\
\bottomrule
\end{tabular}
\end{table}
The boot procedure shows basically the slowdown of a file intensive jbo on the system.
When IMA is enabled the IMA log shows 2030 which means---given that the (very slow) hardware TPM had to extend PCR 10 for every line in the log---the slowdown mainly comes from that.
\begin{itemize}
\item Trusted boot works perfectly fine---any update needs an additional reboot to generate PCR vales
\item When IMA is active (appraise or enforce), the boot procedure takes significantly more time, but the OS itself does not seem to be slower.

BIN
thesis/MAIN.pdf

Binary file not shown.
Loading…
Cancel
Save