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.
137 lines
8.7 KiB
137 lines
8.7 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{Test Results and Limitations}
|
|
We describe in the following the test results and give an overview how usable the components of the setup are.
|
|
|
|
\subsection{Trusted Boot}
|
|
The first part of the setup is trusted boot which is well integrated in recent releases of kernel and GRUB bootloader.
|
|
Furthermore, unlocking the optional disk encryption with the TPM 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.
|
|
This is the case when the update process modifies the EFI bootloader entries, e.g. during a GRUB update.
|
|
Hence, a backup boot process is strongly recommended for test setups.
|
|
This requires a backup password for the disk encryption since which allows to bypass the TPM during booting.
|
|
Otherwise there are no updates possible with the current setup since the affected PCRs are used by the EFI bootloader and cannot be precomputed.
|
|
|
|
\subsection{IMA}
|
|
The next part is IMA which appears to have an easy setup but a complex set of consequences.
|
|
When setting IMA in fixing or enforcing 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.
|
|
Booting starts with pressing the power button when the system is in off state and ends when the CLI login mask appears.
|
|
Rebooting starts when \texttt{reboot} is entered in the shell.
|
|
Again the login mask ends the rebooting process.
|
|
%TODO measure the remaining systems with the different IMA settings
|
|
\begin{table}
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\centering
|
|
\caption{Booting and rebooting times with IMA} \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 is an example for a file intensive process which is reproducible the system.
|
|
When IMA is enabled the IMA log shows 2030 entries after a fresh boot.
|
|
This means---given that the (very slow) hardware TPM had to extend PCR 10 for every line in the log---the slowdown is mainly caused by the interaction with the TPM itself.
|
|
|
|
When IMA is set to enforcing, some unexpected problem appeared during updating Ubuntu.
|
|
During \texttt{apt upgrade}, the package manager downloads the deb packages into its cache folder at \texttt{/var/cache/apt/}.
|
|
These files, however, do not have the \texttt{security.ima} attribute when the download is finished.
|
|
The kernel prevents due to theses missing attributes any access and breaks the upgrade process.
|
|
It is not clear why the files are not hashed although apt is run by root and every file created by root must be hashed with the active IMA policy.
|
|
Creating a text file via text editor shows exactly this behaviour.
|
|
|
|
The missing attributes are also a problem when attemping to turn IMA off again.
|
|
This requires an updated command line and hence an updated unified kernel.
|
|
Generating the new kernel work 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 chunks.
|
|
As a result, the only way to update the kernel on this system is to boot a backup kernel and moving the file without IMA set to enforcing.
|
|
Applying customized IMA rules might solve both problems.
|
|
|
|
Other challenges come up when handling the IMA log itself.
|
|
This log file is an essential part of the attestation procedure.
|
|
Unfortunately the file becomes several dozens of megabytes when using a common linux setup.
|
|
For remote attestation the transmitted data must be as small as possible which makes sending the log directly to a verifier unusable.
|
|
This is the reason why we only transmitted the log file hash in the DAA message.
|
|
|
|
Another essential part is to use the IMA log file do recalculate the produces hashes.
|
|
This means on one hand recalculating the hash in the IMA log entry.
|
|
On the other hand the chain of hashes should result into the value held in PCR 10.
|
|
A small script shown in \autoref{code:verifyimash} tries to recalculate this value.
|
|
\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.hashes
|
|
while read i ;
|
|
do tpm2_pcrextend 16:sha1=$i ;
|
|
done < ima.hashes
|
|
tpm2_pcrread sha1:10,16
|
|
\end{lstlisting}
|
|
It uses the debug register PCR 16 which is resetable without reboot and has the same initial value as the first 10 PCRs.
|
|
When IMA is off, the log holds only one entry of the boot aggregate.
|
|
Then the SHA1 value can be computed with that script.
|
|
However, comprehending the PCR 10 value with IMA enabled was not possible.
|
|
Our tests took into account that PCR and log file could be modified when loading programs to read these resources the first time.
|
|
Loading the log several times eventually ends up in a stable log and PCR value (it does not change anymore even when reading the log another time).
|
|
The value of PCR 10 was still not reproducible.
|
|
|
|
Furthermore the documentation of calculating these vaules did 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 IMA log only provides sha1 hashes.
|
|
Any PCR 10 extensions regarding the sha256 bank are currently not verifiable.
|
|
|
|
\subsection{Processing and Sending Biometric Data}
|
|
\begin{itemize}
|
|
\item Puts together all pieces
|
|
\item payload without IMA log about 15KB
|
|
\item No encryption for payload, but doable -- depends on the way how Sensor and PIA can communicate together
|
|
\item IMA log much too large
|
|
\item Test results how long the process of capturing takes -- with and without IMA
|
|
\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.
|
|
|
|
|