@ -81,7 +81,7 @@ DigiDow introduces five main parties which are involved in a common authenticati
\end{itemize}
When an individual wants to be identified by Digidow, he will eventually step in front of a sensor.
This defines the beginning of a Digidow trancaction.
This defines the beginning of a Digidow transaction.
The procedure is as follows:
\begin{enumerate}
\item The sensor will start recording a unique digital representation, triggered by the directly connected verifier or by hardware detection.
@ -123,7 +123,7 @@ Since the Digidow protocols are not yet finalized, some assumptions are defined
\begin{itemize}
\item Any network discovery is omitted. BS and PIA are assumed to be reachable directly via TCP/IP.
\item We look into a protocol which proves trustworthiness from BS to PIA.
Any further proofs necessary for a Digidow Verifier are also not focused in this thesis.
Any further proofs necessary for a verifier are also not focused in this thesis.
\item The sensitive datasets will be transmitted in cleartext between BS and PIA.
It is considered easy to provide an additional layer of encryption for transportation.
However this should be considered in the Digidow network protocol design.
@ -140,10 +140,9 @@ Together with that, we will introduce our theoretical solution for the previousl
\autoref{cha:implementation} introduces then a working implementation with all necessary parts for provisioning the environment and the used hosts accordingly.
Finally we will present the results and limitations in \autoref{cha:conclusion} and give an overview of future work.
\begin{itemize}
\item What exists in the field?
\item Strongswan Attestation --
\item Intel TXT
\item Trusted Execution Environment (TEE)
\item nanovm (\url{nanovms.com})
\end{itemize}
%\begin{itemize}
%\item Strongswan Attestation -- declared
%\item Intel TXT - not sure if relevant
%\item Trusted Execution Environment (TEE) - not yet mentioned
%\item nanovm (\url{nanovms.com}) - not yet mentioned
@ -236,12 +236,6 @@ When using an own PK, you loose the benefit of having externally created and sig
Secure and trusted boot can, however, exist side by side on one system.
The benefit of using it seems to be very limited when not using a Microsoft OS.
\subsection{Intel TXT}%
\label{sub:intel_txt}
Intel developed a solution to build a trusted environment on a hypervisor which they call \emph{Trusted Execution Technology} (TXT).
It requires an enabled TPM on the hypervisor as well as an activated trusted boot workflow.
\ToDo
\section{Integrity Measurement Architecture}%
\label{sec:integrity_measurement_architecture}
@ -343,6 +337,12 @@ This includes trusted bootstrapping, integrity monitoring, virtualization, compa
The concept of a well known virtual environment does, however, not apply to our use case.
Instead, the system should be self contained as good as possible and it should be possible to get information about the system via anonymous attestation.
%Intel published in 2008 a solution to build a trusted environment on a hypervisor which they call \emph{Trusted Execution Technology} (TXT) which is since then available in many of Intel's processors.
%According to the Linux kernel documentation\footnote{\url{https://www.kernel.org/doc/Documentation/intel_txt.txt}}, this technology allows to replace the SRTM with a \emph{dynamic RTM} (DRTM).
%A DRTM in place enables a hypervisor to provide a chain of trust for each guest OS.
%It requires an enabled TPM on the hypervisor as well as an activated trusted boot workflow on the Host and the guest to work properly.
%Since this contribution does not use OS virtualization, Intel's TXT is not required to run this work.
\section{Direct Anonymous Attestation}%
\label{sec:direct_anonymous_attestation}
\emph{Direct Anonymous Attestation} (DAA) is a cryptographic scheme which makes use of the functions provided by the TPM.
@ -428,7 +428,6 @@ It is based on a bilinear group $(q, \mathbb{G}_1,\mathbb{G}_2,\mathbb{G}_T, e,
\item\emph{Verify.} Given message $m$, signature $\sigma$ and public key $pk$, verify that $a
\neq 1_{\mathbb{G}_1}$, $e(a,Y) = e(b,g_2)$ and $e(a,X)\cdot e(b,X)^m = e(c,g_2)$.
\end{itemize}
Camenisch et al.\@ stated in section 4.2 of their paper~\cite{camenisch16} that one has to verify the equation against $e(g_1,b)$ and $e(g_1,c)$ which is not correct.
\subsection{DAA Protocol on LRSW Assumption}
\label{ssec:daa-protocol-on-lrsw-assumption}
@ -441,6 +440,8 @@ According to Camenisch et al.~\cite{camenisch16}, the DAA protocol consists of t
Only the key owner (TPM, passive) and the message author (Host, active) form a full group member.
\item\emph{Verifier}\verifier. A verifier can check, whether a host with its TPM is in a group or not. Besides the group membership, no additional information is provided.
\end{itemize}
Please note that these entities are different to the Digidow roles although they have the same name.
When leaving the DAA context after this section, the DAA entities will clearly be qualified (e.g. \emph{DAA} verifier).
A certificate authority $\mathcal{F}_{ca}$ is providing a certificate for the issuer itself.
The basename \bsn{} is some clear text string, whereas \nym{} represent the encrypted basename $bsn^{gsk}$.
$\mathcal{L}$ is the list of registered group members which is maintained by \issuer.
@ -127,7 +127,7 @@ Only the command line parameters need to be customized.
\subsection{Install and use Trusted Boot}
\label{ssec:install-and-use-trusted-boot}
The following shell scripts are available online\footnote{\url{TODO}} and in the folder \texttt{trustedboot/}.
The following shell scripts are available online\footnote{\url{https://git.ins.jku.at/proj/digidow/trustedboot}} and in the folder \texttt{trustedboot/}.
All are tested on a Ubuntu 20.04 server minimal installation on all three devices.
These packages need to be installed beforehand to make use of the scripts:
\begin{itemize}
@ -351,16 +351,6 @@ These chaecksums were generated with:
\end{tabular}
\end{table}
Similar to trusted boot, Ubuntu requires two installed packages to support the features discussed in this section:
\begin{itemize}
\item\texttt{auditd} to analyze system calls of processes, helpful when using IMA, and
\item\texttt{attr} for showing the file IMA hashes, which are saved as extended file attributes.
\end{itemize}
TODO
IMA-Settings erklären.
Available on Ubuntu, RedHat and optionally Gentoo.
The kernel has the correct compile options set.
\section{Using the DAA Protocol}
Direct anonymous attestation uses the TPM as cryptoprocessor and key store.
The feature of identifiable instances of sensors is not required when interacting with the Digidow network.
@ -381,7 +371,7 @@ Xaptums ECDAA library need to be installed on all three hosts but only the senso
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 an image of the USB webcam.
We developed a small Rust program called \texttt{sensor-capture} for capturing a face image from a webcam.
We developed a small Rust program called \texttt{bs-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}
@ -426,38 +416,38 @@ The network protocol provided by \texttt{ecdaa-network-wrapper} adds to the cryp
It is designed to match the workflow of a Digidow transaction, affecting the decision which party is defined as listener and which as sender.
\begin{itemize}
\item\emph{Start issuer listener}: During startup of the issuer server, the program loads the public/private key pair if present.
\item\emph{Start DAA issuer listener}: During startup of the issuer server, the program loads the public/private key pair if present.
Otherwise, a new key pair will be created.
The issuer listener is always active to manage group membership and queries for the issuer's publiic key.
\item\emph{Broadcast issuer's public key}: The DAA group public key created by the issuer is necessary for group enrollment and for verification of any messages signed by a DAA group member.
Consequently, verifier and (potential) member must get this key first.
The DAA issuer listener is always active to manage group subscriptions and queries for the group publiic key.
\item\emph{Broadcast DAA group public key}: The group public key created by the DAA issuer is necessary for group enrollment and for verification of any messages signed by a DAA group member.
Consequently, DAA verifier and (potential) DAA member must get this key first.
\autoref{fig:daa-network-publish} shows the two steps that are visible on the network.
Since this communication contains only public data, no additional privacy measurenments are required.
\caption{Protocol to get the DAA issuer's public key}
\label{fig:daa-network-publish}
\end{figure}
\item\emph{Enroll member to issuer's group}: This step extends the DAA group and transfers the trust of the DAA group to the new member.
This protocol requires the issuer's public key to be present at the member.
\item\emph{Enroll member to issuer's DAA group}: This step extends the DAA group and transfers the trust of the DAA group to the new member.
This protocol requires the group public key to be present at the DAA member.
If this is not the case, the member asks for it automatically.
The procedure is a four-way handshake, as shown in \autoref{fig:daa-network-join}.
We describe in \autoref{ssec:daa-protocol-on-lrsw-assumption} that the key exchange is cryptographically secure, meaning that no adversary can extract any private keys when getting access to these messages.
\caption{Protocol to add a new member to the issuer's group}
\caption{Protocol to add a new member to the issuer's DAA group}
\label{fig:daa-network-join}
\end{figure}
\item\emph{Send signed messages}: The diagram in \autoref{fig:daa-network-attest} shows that the verifier listens and the member initiates the connection.
\item\emph{Send signed messages}: The diagram in \autoref{fig:daa-network-attest} shows that the DAA verifier listens and the member initiates the connection.
\caption{Protocol to send an attestation message to the verifier}
\caption{Protocol to send an attestation message to the DAA verifier}
\label{fig:daa-network-attest}
\end{figure}
This implementation reflects the Digidow transaction workflow in mind where the sensor (=member) sends a signed message to the PIA (=verifier).
This implementation reflects the Digidow transaction workflow in mind where the sensor (=member) sends a signed message to the PIA (=DAA verifier).
Hence, sending attestation messages with biometric information of the user will happen once per transaction in the Digidow network.
\end{itemize}
@ -475,7 +465,7 @@ Furthermore, the the ECDAA library limits the message size for signing to 1024 B
Thus, we created a sha512 sum of the message and signed only this hash allowing us to send messages of arbitrary size and constant effort for signing.
\subsection{Installing the DAA Network Protocol}
The Network Wrapper is located at \texttt{ecdaa-network-wrapper/} or can be downloaded from the Git repo\footnote{\url{TODO}}.
The Network Wrapper is located at \texttt{ecdaa-network-wrapper/} or can be downloaded from the Git repo\footnote{\url{https://git.ins.jku.at/proj/digidow/ecdaa-network-wrapper}}.
Copy the folder \texttt{ecdaa-network-wrapper} to the build directory and change to this directory:
\item\texttt{ecdaa\_issuer}: Creates the binary for the issuer.
\item\texttt{ecdaa\_member}: Builds the member executable without TPM support.
\item\texttt{ecdaa\_issuer}: Creates the binary for the DAA issuer.
\item\texttt{ecdaa\_member}: Builds the DAA member executable without TPM support.
This should only be used for testing purposes.
\item\texttt{ecdaa\_member\_tpm}: The member binary with TPM support.
\item\texttt{ecdaa\_verifier}: Creates the verifier binary.
\item\texttt{ecdaa\_member\_tpm}: The DAA member binary with TPM support.
\item\texttt{ecdaa\_verifier}: Creates the DAA verifier binary.
\item\texttt{ecdaa\_all}: Builds every binary listed above at once.
\end{itemize}
@ -509,7 +499,7 @@ When all above steps are finished successfully, the host is capable of taking it
For demonstration purposes, we use an USB webcam to take a photo of the person being in front of the sensor.
This photo is then processed to generate a face embedding, which is small enough to be sent with the DAA attestation message.
The first part is done with a small Rust program called \texttt{bs-capture}, which is available in the folder \texttt{bs-capture/} as well as online\footnote{\url{TODO}}
The first part is done with a small Rust program called \texttt{bs-capture}, which is available in the folder \texttt{bs-capture/} as well as online\footnote{\url{https://git.ins.jku.at/preisach/bs-capture}}
It uses the libraries from the video4linux project to capture a still image and saving it to disk.
Ubuntu 20.04 requires the following packages to be installed:
\begin{lstlisting}[numbers=none]
@ -527,13 +517,15 @@ It takes a still image which is saved as \texttt{frame.jpg} in the working direc
This image needs then to be processed to generate the face embedding data.
Therefore we use the project \emph{Prototype Facerecognition} which uses a trained tensorflow network to generate embeddings.
The Git repository\footnote{\url{https://git.ins.jku.at/proj/digidow/prototype-facerecognition}} contains an install script which cares about installing all dependencies for setup:
The branch \texttt{retinaface-tflite} of the Git repository\footnote{\url{https://git.ins.jku.at/proj/digidow/prototype-facerecognition}} contains an install script which cares about installing all dependencies for setup:
@ -32,57 +32,60 @@ According to these results, we assume that less than 10\,KB are used to hold the
\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:bootperformance} 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.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Booting and rebooting times with IMA (n=10)}
The boot procedure is an example for a reproducible file intensive process.
It 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.
First, we show the impact on disk usage when IMA is enabled.
In this case, 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 extended attributes must find place.
The block size of the used filesystem 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.
For example, system 1 holds after setup as Biometric Sensor and several system updates 156947 files.
This results in estimated additional disk usage of 613\,MB when adding the \texttt{xattr} block for each file.
Further attributes, however, will not require more disk space on ext4 since every extended attribute must exist in this single block.
Further attributes, however, would not require more disk space on ext4 since every extended attribute must exist in this single block.
IMA holds all runtime information as virtual files in memory, including the integrity 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.
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 since we did not analyze the corresponding data structires 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.
Saving the file to disk, uses 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.
Generating the iniramfs blob and compiling programs from source generates together several 10000 lines in the log.
When looking into the performance of IMA, there is a huge drop when it is enable, especially when files are read the first time.
We show in \autoref{tab:bootperformance} the reboot performance of the used test systems given a setup for a biometric sensor described in \autoref{cha:implementation} with TPM backed disk encryption enabled.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Average rebooting times with IMA (n=10)}
\label{tab:bootperformance}
\begin{tabular}{r|ccc|ccc}
\toprule
{Reboot time [s]}&\multicolumn{3}{c|}{\textit{System 1}}&\multicolumn{3}{c}{\textit{System 3}}\\
This is an example for a reproducible, file intensive process where all resources have to pass IMA.
The procedure was captured via camera and split into 4 stages.
\emph{Shutdown} represents the time from entering \texttt{reboot} into the shell until the monitor stops displaying content.
Since all systems use the disk encryption feature supported with the TPM, we measured how log it takes to ask the TPM for the passphrase (\emph{Boot to disk encryption}) and how long the query itself is executed (\emph{Decrypt disk}).
With boot disk and kernel available, the system starts all services until the login prompt on the CLI appears (\emph{Boot with disk}).
This ends the reboot procedure.
Although the number of runs is very small, the test clearly shows that enabling IMA doubles the time for rebooting.
Furthermore, asking the TPM for the decryption key and decrypting the disk takes around 4\,s in any case.
This may caused by the \texttt{tpm2\_unseal} operation which computes multiple relatively complex cryptographic instructions before the task is done.
\section{Processing and Sending Biometric Data}
Capturing and processing biometric data from the user is quite seamless and the cryptographic part of ECDAA is reliable enough for this prototype.
@ -126,11 +129,11 @@ It measures the the maximum resident size im memory during lifetime, which inclu
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Maximum memory usage measured with \texttt{/usr/bin/time} in KB}
\caption{Maximum memory usage measured with \texttt{/usr/bin/time}}
@ -12,8 +12,8 @@ Similarly, the DAA group signature scheme is working with and without using a TP
It provides all necessary features for a partly dynamic group.
Adding a device requires a controlled environment, where the sensor's hardware and software is analyzed before it gets the ultimate trust of the group.
This environment is usually only available when building and provisioning the device.
A member key can only be invalidated by adding it to the revocation list.
Since the member key should never leave the TPM, it seems to be hard to remove a corrupted sensor from the group.
A DAA member key can only be invalidated by adding it to the revocation list.
Since the DAA member key should never leave the TPM, it seems to be hard to remove a corrupted sensor from the group.
Linux distributions provide more and more support for IMA in recent years.
Ubuntu's first LTS release with IMA was 20.04 which we used for this work.
@ -74,7 +74,7 @@ Similar to using TPMs, the integrity of the sensor's hardware and software are f
\section{Future Work}
Given the limitations in the current setup, we provide some thoughts which might be worth implementing on thop of this contribution.
Depending on the usage model, it might be worth extending the DAA scheme into a full dynamic group signature scheme.
Camenisch et al.\cite{TODO} discuss how the existing scheme could be extended to support the features of dynamic groups.
Camenisch et al.\cite{camenisch17} discuss how the existing scheme could be extended to support the features of dynamic groups by implementing signature based revocation.
Although their concept seems to work, there is no implementation available in the public and it is not recommended to implement cryptographic algorithms by oneself.
We discussed in the previous section a missing link in the chain of trust of the TPM.
@ -128,7 +128,9 @@ Ideally the transaction delay is independent of which sensor type is used.
Many of the measures above make the computation and hence the transaction time more efficient.
It is therefore necessary to define timing constraints to see whether further measures need to be implemented.
\section{Conclusion}
Hardening of the system beyond IMA useful.
Minimization also useful, because the logging gets shorter.
We are able to demonstrate in this contribution a working prototype for a Digidow sensor.
Although only a minimal feature set is implemented, it shows a direction where developments can step forward.
Furthermore, this setup is one of the first applications using a group signature scheme.
In context of the Digidow project, a working DAA demo can be useful for other use cases as well.
Consequently, this contribution is essential for further research and development in the Digidow project.
