@ -256,7 +256,7 @@ By changing the parameter \texttt{ima\_appraise=enforce} in
The new parameters are activated by using the workflow for updating the kernel described in \autoref{ssec:install-and-use-trusted-boot}.
The result is a system which allows only resources with correct hash attribute to be read or executed.
An adversary may still create the file hash itself and overwrite the file with the hash.
However, an adversary may still create the file hash itself and overwrite the file with the hash.
Hence these hash values must be verified in some way before they can be trusted.
Two options are therefore available:
\begin{itemize}
@ -266,8 +266,8 @@ Two options are therefore available:
The host can directly check whether the file was tamepered with and act accordingly.
Linux kernels support this feature with the \emph{extended verification module} (EVM).
\end{itemize}
We implemented an attestation variant where the IMA log is part of the message.
Details about the message design will be discussed in \autoref{ssec:daa-network-protocol}
We use with DAA an attestation variant where the IMA log is part of the message.
Details about the message design will be discussed in \autoref{ssec:daa-network-protocol}.
\section{Dynamic System Analysis}
IMA is a comprehensive tool for checking the integrity of a file or executable or library before it gets executed.
@ -374,21 +374,20 @@ Any party interacting with the sensor is then able to check trustworthiness via
We describe in the following which programs need to be installed and what configuration is required to demonstrate a working implementation of DAA.
\subsection{Provision Hosts of Test Setup}
The demonstration setup, shown in \autoref{fig:prototype} consists of three independent hosts which are connected together via TCP/IP.
The demonstration setup, shown in \autoref{fig:prototype}, consists of three independent hosts which are connected together via TCP/IP.
Every host represent one party in the DAA scheme, each requiring additional software to support the DAA protocol.
Xaptums ECDAA library need to be installed on all three hosts.
However, the hosts representing issuer and verifier do not require TPM support.
Xaptums ECDAA library need to be installed on all three hosts but only the sensor requires TPM support.
Similar to that, the ECDAA network wrapper is required to support the network communication part.
The member needs, besides DAA protocol support, software to capture and process the image of the USB webcam.
The member needs, besides DAA protocol support, software to capture and process an image of the USB webcam.
We developed a small Rust program called \texttt{sensor-capture} for capturing a face image from a webcam.
For biometric processing, we transform the image into an embedding with the face recognition prototype of Digidow\footnote{\url{https://git.ins.jku.at/proj/digidow/prototype-facerecognition}}.
\subsection{Installing Xaptum ECDAA Library}
Xaptum's ECDAA Library provide the cryptographic functions and the protocol primitives for DAA.
A file based demonstration of the protocol is provided within the project.
We build the ECDAA library from source since the provided packages do not support Ubuntu 20.04.
Therefore we need the C build environment and some documentation extensions:
We have to build the ECDAA library from source since the provided deb packages do not support Ubuntu 20.04.
Therefore we need the C build environment as follows:
The network protocol provided by \texttt{ecdaa-network-wrapper} adds to the cryptographic implementation of Xaptum's ecdaa project a network communication layer.
\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.
\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.
\end{itemize}
\section{Limitations}
\begin{itemize}
@ -18,8 +24,6 @@ These are the test results
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