You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
96 lines
6.0 KiB
96 lines
6.0 KiB
\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.
|
|
\item IMA in enforce mode breaks the package manager apt. It downloads the deb packages from the repository but cannot open it since the files do not get the \texttt{security.ima} attribute.
|
|
\begin{lstlisting}[numbers=none,float, caption={Attempt to recalculate the value of PCR 10}, label={code:verifyimash}]
|
|
#!/usr/bin/bash
|
|
set -e
|
|
tpm2_pcrreset 16
|
|
cut -d ' ' -f 2 /sys/kernel/security/ascii_runtime_measurements > ima.checksums
|
|
while read i ;
|
|
do tpm2_pcrextend 16:sha1=$i ;
|
|
done < ima.checksums
|
|
tpm2_pcrread sha1:10,16
|
|
\end{lstlisting}
|
|
\item The IMA log is not comprehensible. Using \texttt{tpm2\_pcrextend} creates the correct value only when the \texttt{boot\_aggregate} entry is in the IMA log, which means that IMA is not active.
|
|
When activating IMA, there are immediately after booting several hundred entries in this log and the value of PCR 10 was not reproducible with the script in \autoref{code:verifyimash}.
|
|
It is furthermore not clear how the SHA256 value of PCR 10 is calculated.
|
|
|
|
\item When IMA in enforce mode, any access to a filesystem not supporting extended file attributes will be blocked. This includes the EFI boot partition and the boot partition for GRUB which is usually \texttt{ext2}.
|
|
System upgrade is not possible with the policies in use---customized policies are necessary to exclude \texttt{/boot} and to handle \texttt{/var/cache/apt} properly.
|
|
\end{itemize}
|
|
|
|
\section{Limitations}
|
|
\begin{itemize}
|
|
\item Documentation available for TPM APIs, but no changelog for \texttt{tpm2-tools}.
|
|
\item Trusted boot and IMA can just handle static resources like files, kernel modules and firmware of hardware components.
|
|
Code transmitted over network or otherwse dynamically generated can not be recognized.
|
|
This is an open door for non-persistent attacks.
|
|
\item Documentation on IMA is mostly outdated and so are some tools.
|
|
Further customization of rules may be useful to reduce log size.
|
|
However major Linux distributions support IMA by default on recent releases.
|
|
\item Complexity of verifying system state is too high and is connected to system complexity.
|
|
Reducing number of dependencies and relevant file count is key for this problem.
|
|
\item Implemented DAA does not support a full dynamic group scheme.
|
|
This might be useful in the future, maybe with a custom implementation of a recent DAA version.
|
|
\end{itemize}
|
|
|
|
\section{Future Work}
|
|
\begin{itemize}
|
|
\item Remove building tools on target device - just deliver binaries
|
|
\item Remove complex runtime environments like Java, Python, etc. to reduce bloating the integrity logs
|
|
\item Set file system read only, just use e.g. a ramdisk for working files
|
|
\item Integrate USB sensors into the trusted/integrity environment, including device firmware.
|
|
\end{itemize}
|
|
\subsection{Closing the chain of trust between TPM manufacturer and DAA issuer}
|
|
Activate a credential with to certify that the Membership key is in the Endorsement hierarchy, which can be verified with the TPM certificate.
|
|
\begin{itemize}
|
|
\item Theoretical concept in the \emph{Practical Guide to TPM 2.0, pp 109 ff}
|
|
\item Practical approach: with EK, AK and AIK to show validity of EK:\\ \url{https://ericchiang.github.io/post/tpm-keys/?utm_campaign=Go%20Full-Stack&utm_medium=email&utm_source=Revue%20newsletter#credential-activation}
|
|
\end{itemize}
|
|
|
|
Further integration in the Digidow environment if DAA is useful for that.
|
|
|
|
\section{Outlook}
|
|
Hardening of the system beyond IMA useful.
|
|
Minimization also useful, because the logging gets shorter.
|
|
|
|
|