With the setup described in the prevoius chapter, we created a system which is able to read biometric data.
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.
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.
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}
\section{Trusted Boot}
The first part of the setup is trusted boot which is well integrated in recent releases of kernel and GRUB bootloader.
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.
Furthermore, unlocking the optional disk encryption with the TPM works seamless with the kernel, even when using the manually generated unified kernel without GRUB.
Only when updating the unified kernel, EFI might have problems loading or finding the correct EFI blob on the boot partition.
Only when performing an update for GRUB, it will modify the entries in the EFI boot manager.
This is the case when the update process modifies the EFI bootloader entries, e.g. during a GRUB update.
Consequently, we recommend a check of the boot entries after a system upgrade.
Having a backup boot option with GRUB is useful for maintenance tasks.
Especially for modifying the IMA configuration via kernel command line, it may be necessary to boot with a backup kernel.
Hence, a backup boot process is strongly recommended for test setups.
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.
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.
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}
\section{IMA}
The next part is IMA which appears to have an easy setup but a complex set of consequences.
IMA 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.
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.
\autoref{tab:boottimes} shows the performance of the used test systems 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.
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.
Rebooting starts when the \texttt{reboot} command is entered in the shell.
Again the login mask ends the rebooting process.
Again, the login mask ends the rebooting process.
%TODO measure the remaining systems with the different IMA settings
%TODO measure the remaining systems with the different IMA settings
\begin{table}
\begin{table}
\renewcommand{\arraystretch}{1.2}
\renewcommand{\arraystretch}{1.2}
@ -41,10 +42,35 @@ Again the login mask ends the rebooting process.
\bottomrule
\bottomrule
\end{tabular}
\end{tabular}
\end{table}
\end{table}
The boot procedure is an example for a file intensive process which is reproducible the system.
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.
When IMA is in fixing or enforcing mode, the corresponding log will be filled according to \autoref{tab:imalogsize}.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Nuber of entries and IMA log size}\label{tab:imalogsize}
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.
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.
Since the IMA log file is also essential for remote attestation, the information of this file must be transmitted to the DAA verifier.
When IMA is set to enforcing, some unexpected problem appeared during updating Ubuntu.
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/}.
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.
These files, however, do not have the \texttt{security.ima} attribute when the download is finished.
@ -60,8 +86,9 @@ As a result, the only way to update the kernel on this system is to boot a backu
Applying customized IMA rules might solve both problems.
Applying customized IMA rules might solve both problems.
Other challenges come up when handling the IMA log itself.
Other challenges come up when handling the IMA log itself.
This log file is an essential part of the attestation procedure.
This log file is an essential part of the attestation procedure and gets filled when IMA is either in fixing or enforcing mode.
Unfortunately the file becomes several dozens of megabytes when using a common linux setup.
Unfortunately the file size ends up at several 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.
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.
This is the reason why we only transmitted the log file hash in the DAA message.
@ -89,9 +116,13 @@ 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.
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.
\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.
Any verification procedures regarding the sha256 bank of PCR 10 are currently not implemented.
\section{Processing and Sending Biometric Data}
Capturing and processing biometric data form the user is agqin quite seamless.
Similarly, the cryptographic part of ECDAA is reliable enough for this prototype.
During the following tests, all software and hardware parts did not show any errors.
\subsection{Processing and Sending Biometric Data}
