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.
291 lines
16 KiB
291 lines
16 KiB
\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.
|
|
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 performing an update for GRUB, it will modify the entries in the EFI boot manager.
|
|
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.
|
|
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, 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}
|
|
\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 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.
|
|
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.
|
|
|
|
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.
|
|
\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 verification procedures regarding the sha256 bank of PCR 10 are currently not implemented.
|
|
|
|
\section{Processing and Sending Biometric Data}
|
|
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 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 and revocation lists and group management are 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.
|
|
|
|
\begin{table}
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\centering
|
|
\caption{Memory usage measured with Valgrind} \label{tab:memoryusage}
|
|
%\rowcolors{2}{lightgray}{white}
|
|
\begin{tabular}{rr}
|
|
\toprule
|
|
\textit{Memory Usage} &\textit{[Bytes]} \\
|
|
\midrule
|
|
\textbf{DAA TPM key generation} &10160 \\
|
|
\textbf{DAA TPM join} &23864 \\
|
|
\textbf{DAA join without TPM} &19296 \\
|
|
\textbf{Image capturing} & \\
|
|
\textbf{Image processing} &209617927\\
|
|
\textbf{Compiling DAA message} & \\
|
|
\textbf{Sending DAA message} & \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
During these memory tests, valgrind showed a large number of possible memory leaks in the python binary itself.
|
|
The following example is executed:
|
|
\begin{lstlisting}[numbers=none]
|
|
root@amd1:~/jetson-nano-facerecognition# valgrind python3 img2emb.py data/test-images/test2.jpg
|
|
\end{lstlisting}
|
|
Valgrind ends with the report as follows:
|
|
\begin{lstlisting}[numbers=none]
|
|
==41612== HEAP SUMMARY:
|
|
==41612== in use at exit: 28,959,222 bytes in 224,623 blocks
|
|
==41612== total heap usage: 714,004 allocs, 489,381 frees, 209,617,927 bytes allocated
|
|
==41612==
|
|
==41612== LEAK SUMMARY:
|
|
==41612== definitely lost: 2,976 bytes in 25 blocks
|
|
==41612== indirectly lost: 0 bytes in 1 blocks
|
|
==41612== possibly lost: 514,141 bytes in 12,827 blocks
|
|
==41612== still reachable: 28,442,105 bytes in 211,770 blocks
|
|
==41612== of which reachable via heuristic:
|
|
==41612== stdstring : 543,526 bytes in 12,048 blocks
|
|
==41612== newarray : 8,920 bytes in 5 blocks
|
|
==41612== suppressed: 0 bytes in 0 blocks
|
|
==41612== Rerun with --leak-check=full to see details of leaked memory
|
|
==41612==
|
|
==41612== Use --track-origins=yes to see where uninitialised values come from
|
|
==41612== For lists of detected and suppressed errors, rerun with: -s
|
|
==41612== ERROR SUMMARY: 29126 errors from 678 contexts (suppressed: 4 from 1)
|
|
\end{lstlisting}
|
|
This report shows that the Python binary (here Python 3.8 from Ubuntu 20.04) is not memory safe, which is a significant drawback for the system and software integrity.
|
|
Any binary which is directly involved in the DAA protocol frees every allocated block.
|
|
Furthrmore any binary in the TPM2 software stack is memory safe according to valgrind.
|
|
The used shell commands may not free every allocated block, however valgrind still finds no errors in these programs.
|
|
|
|
|
|
\begin{table}
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\centering
|
|
\caption{Performance results of joining a DAA group and sending a Digidow message} \label{tab:wholeperformance}
|
|
\begin{tabular}{rrrrrrr}
|
|
\toprule
|
|
\textit{Performance} &\multicolumn{3}{c}{\textit{Join~[s]}} &\multicolumn{3}{c}{\textit{Digidow start~[s]}} \\
|
|
&min &avg &max &min &avg &max\\
|
|
\midrule
|
|
\textbf{Sys1 IMA off} &&&& \\
|
|
\textbf{Sys1 IMA fix} &&&& \\
|
|
\textbf{Sys1 IMA enf} &&&& \\
|
|
\textbf{Sys3 IMA off} &&&& \\
|
|
\textbf{Sys3 IMA fix} &&&& \\
|
|
\textbf{Sys3 IMA enf} &&&& \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\begin{table}
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\centering
|
|
\caption{Performance results of each step when sending a Digidow message} \label{tab:stepperformance}
|
|
\begin{small}
|
|
\begin{tabular}{rrrrrrrrrrrrr}
|
|
\toprule
|
|
\textit{Performance} &\multicolumn{3}{c}{\textit{Capture~[s]}} &\multicolumn{3}{c}{\textit{Process~[s]}} &\multicolumn{3}{c}{\textit{Collect~[s]}} &\multicolumn{3}{c}{\textit{Send~[s]}} \\
|
|
&min &avg &max &min &avg &max &min &avg &max &min &avg &max\\
|
|
\midrule
|
|
\textbf{Sys1 IMA off} &&&& \\
|
|
\textbf{Sys1 IMA fix} &&&& \\
|
|
\textbf{Sys1 IMA enf} &&&& \\
|
|
\textbf{Sys3 IMA off} &&&& \\
|
|
\textbf{Sys3 IMA fix} &&&& \\
|
|
\textbf{Sys3 IMA enf} &&&& \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{small}
|
|
\end{table}
|
|
|
|
|
|
|
|
When IMA is in fixing or enforcing mode, the corresponding log will be filled according to \autoref{tab:imalogentries}.
|
|
\begin{table}
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\centering
|
|
\caption{Number of additional entries in the IMA log} \label{tab:imalogentries}
|
|
|
|
\begin{tabular}{rl}
|
|
\toprule
|
|
&\textit{Additional log entries} \\
|
|
\midrule
|
|
\textbf{Boot} &\textasciitilde 2000\\
|
|
\textbf{DAA TPM enrollment} &\\
|
|
\textbf{Image capturing} & \\
|
|
\textbf{Image processing} &\\
|
|
\textbf{Compiling DAA message} & \\
|
|
\textbf{Sending DAA message} & \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
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.
|
|
|
|
\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.
|
|
|
|
|