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.
\chapter{Testing}
\label{cha:testing}
With the setup described in the prevoius chapter, we created a system which is able to capture and process biometric data.
The system encapsulates 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 each part of the setup work.
Furthermore we analyze the footprint in memory and on the disk as well as timing if applicable.
\section{Trusted Boot}
The first part of the setup is trusted boot which is well integrated in recent releases of kernel and GRUB bootloader.
@ -16,13 +17,19 @@ 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.
GRUB already supports trusted boot and activation requires a line in the corresponding config file.
Unlike GRUB, the unified kernel does not perform any measurements.
Only when asking the TPM for the disk encryption key, the initramfs must have the TPM stack available.
These files use about 62\,KB of space in initramfs which is negligible to the complete image at \texttt{/boot/initrd.img-5.4.0-84-generic} using about 80\,MB.
Furthermore, only in this case exists a measurable difference in the boot performace since asking the TPM takes around 1\,s.
This is the time when the boot process posts \texttt{unlocking via TPM} and stays there until the disk is unlocked.
The used amount of memory was not tested here, but it should be comparable to the results when generating a TPM key for the member.
According to these results, we assume that less than 10\,KB are used to hold the TPM stack in memory.
\section{IMA}
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.
\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.
Rebooting starts when the \texttt{reboot} command is entered in the shell.
Again, the login mask ends the rebooting process.
When setting IMA in fixing or enforcing mode, the system's performance drop is significant.
We show in \autoref{tab:boottimes} the boot performance of the used test systems given a setup for a biometric sensor described in \autoref{cha:implementation} with TPM backed disk encryption enabled.
%TODO measure the remaining systems with the different IMA settings
\begin{table}
\renewcommand{\arraystretch}{1.2}
@ -42,36 +49,36 @@ Again, the login mask ends the rebooting process.
\bottomrule
\end{tabular}
\end{table}
The boot procedure is an example for a file intensive process which is reproducible the system.
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.
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.
The boot procedure is an example for a reproducible file intensive process.
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 the \texttt{reboot} command is entered in the shell.
Again, the CLI login mask ends the rebooting process.
Further timing tests comparing the different IMA states are shown in the next section.
When enabling IMA, the file hashes will be stored as extended file attributes.
According to the xattr man page\cite{XattrMan2021}, the ext4 file system creates therefore a single block per file where all attributes must find place.
The block size of the used systems is 4\,KB.
The number of files is determined with the following command
\begin{lstlisting}[numbers=none]
find / -fstype ext4 -type f -uid 0 | wc -l
\end{lstlisting}
System 1 holds after setup as Biometric Sensor and several system updates 156947 files.
This results in additional disk space of 613\,MB when adding a block for each file.
Additional attributes will, however, add no more disk space on ext4.
IMA holds all runtime information as virtual files in memory, including the IMA log.
In context of memory usage, it is clear that the size of the virtual files without the redundant information (like PCR number and log format) is a rough estimation for the memory usage within the kernel.
Both memory and disk usage do not change between IMA's fixing and enforcing mode since enforcing only adds file access control.
Saving the file to disk, takes about 2\,MB of size per 10000 lines in the log.
This indicates a linear dependency to the number of accessed files for the log and the kernel's memory usage.
The log can easily get over 100000 entries when the system is running long enough.
System 1, for example, had a log file with 214561 lines after about 15 days of uptime, resulting in about 40\,MB of size.
Saving that file on disk took several seconds which indicates that extracting the log from the kernel is very inefficient.
The log file showed that a major impact on the size was the performed system update.
Generating the iniramfs blob and compiling programs from source generates combined several 10000 lines in the log.
When IMA is set to enforcing, some unexpected problems 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.
@ -85,14 +92,7 @@ The copy process seems to create the file, but it fails when trying to write the
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 and gets filled when IMA is either in fixing or enforcing mode.
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.
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.
Another relevant part for attestation 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.
@ -119,9 +119,43 @@ Furthermore the documentation of calculating these vaules did not mention how th
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.
Capturing and processing biometric data from the user is 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.
During the following tests, all software and hardware parts worked as expected.
Analyzing disk and memory usage is only meaningful for the member.
The implemented protoype of the issuer does only negotiate the membership key.
Revocation lists and group management is not implemented yet.
Similarly, the DAA verifier only checks the signature.
In productive state it must hold the revocation list and perform further checks with respect to received attestation message.
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.
Since the IMA log file is also essential for remote attestation, the information of this file must be transmitted to the DAA verifier.
