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}
\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 the optional disk encryption unlocking works fine with the kernel, even when using the manually generated unified kernel.
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.
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.
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 mode, logging is enabled and the system slows down significantly.
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{Systems used for demonstration prototype}\label{tab:boottimes}
\caption{Booting and rebooting times with IMA}\label{tab:boottimes}
%\rowcolors{2}{lightgray}{white}
\begin{tabular}{rlll}
\toprule
@ -31,33 +41,57 @@ When setting IMA in fixing mode, logging is enabled and the system slows down si
\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.
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.
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.
\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.
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}]
\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.
It uses the debugging 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.
\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.
