@ -45,7 +45,7 @@ The used mainboards come with a dedicated TPM2.0 header which may differ from bo
A 19-pin header is available on the older platform of \emph{System 2}.
As long as TPM and mainboard have the same 19-pin connector they will be compatible to each other.
The newer Gigabyte mainboards come with a proprietary 11-pin connector which is only compatible with Gigabyte's TPM2.0\_S module.
All other modules are however electrical compatible since only unused pins of the full size connector are removed.
All modules are however electrical compatible since only unused pins of the full size connector are removed.
With a wiring adapter any TPM board would work on any mainboard supporting TPM2.0 even when coming with a prorietary header.
\section{Select the Operating System}
@ -127,9 +127,9 @@ 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 in the folder \texttt{trustedboot}.
They are tested on a Ubuntu 20.04 server minimal installation on all three devices.
These packages need to be installed beforehand on an Ubuntu minimal instance to install trusted boot:
The following shell scripts are available online\footnote{\url{TODO}} 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}
\item\texttt{binutils} for objcopy, generating unified kernel, and
\item\texttt{tpm2-tools} to interact with the onboard TPM,
@ -226,12 +226,12 @@ The first four parameters used in \autoref{code:tbcommandlinetxt} define the beh
\item\texttt{rootflags=i\_version} must be enabled when mounting the filesystem since IMA is checking that number before re-hashing the resource.
\end{itemize}
Unfortunately, the resulting IMA log is between 2000 and 3000 lines long when the system is freshly booted.
Unfortunately, the resulting integrity log is between 2000 and 3000 lines long when the system is freshly booted.
The log can blow up to several 10000 lines when uptime exceeds several days.
IMA has therefore a policy language rules for hashing files can be customized.
It might, for example, be useful to exclude log files from being hashed.
However, a thrid party can comprehend the state of the attesting system, when parsing the IMA log.
However, a thrid party can comprehend the state of the attesting system, when parsing the integrity log.
Together with the corresponding value of PCR 10, where the hashes of all entries are chained, the TPM can \texttt{certify} correctness of the log.
Besides the log entries, every hashed file gets an extended file attribute called \texttt{security.ima} holding current hash value in base64 encoding.
@ -261,13 +261,13 @@ However, an adversary may still create the file hash itself and overwrite the fi
Hence these hash values must be verified in some way before they can be trusted.
Two options are therefore available:
\begin{itemize}
\item\emph{Attest}: Let the complete IMA log be part of remote attestation and verify the hash values against a trusted known value database.
\item\emph{Attest}: Let the complete integrity log be part of remote attestation and verify the hash values against a trusted known value database.
This makes the verification part very complex but the state of the attesting system is well documented.
\item\emph{Sign}: Sign hash values for static files like executables or libraries.
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 use with DAA an attestation variant where the IMA log is part of the message.
We use with DAA an attestation variant where the integrity log is part of the message.
Details about the message design will be discussed in \autoref{ssec:daa-network-protocol}.
\section{Dynamic System Analysis}
@ -362,14 +362,14 @@ Available on Ubuntu, RedHat and optionally Gentoo.
The kernel has the correct compile options set.
\section{Using the DAA Protocol}
Direct anonymous attestation is a group signature scheme which uses the TPM as cryptoprocessor and key store.
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.
Only the \emph{trusted} state of the sensor system and the membership in the corresponding group is relevant.
Hence, the group membership is an essential part to provide trust to the users, requiring a deep knowledge on what hardware and software is installed and which vulnerabilities it might have.
The DAA group membership states that the system is provisioned from a trusted party, namely the DAA issuer.
The level of trust is ultimative since the used version of DAA is only partly dynamic by lacking support of membership removal.
During a Digidow transaction, the sensor attests its state by signing a message containing the IMA log and the PCR registers.
During a Digidow transaction, the sensor attests its state by signing a message containing the integrity log and the PCR registers.
Any party interacting with the sensor is then able to check trustworthiness via integrity and valid membership of the sensor.
We describe in the following which programs need to be installed and what configuration is required to demonstrate a working implementation of DAA.
@ -387,7 +387,7 @@ For biometric processing, we transform the image into an embedding with the face
\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 have to build the ECDAA library from source since the provided deb packages do not support Ubuntu 20.04.
We have to build the ECDAA library from source since the provided deb packages do not officially support Ubuntu 20.04.
Therefore we need the C build environment as follows:
Now, all prerequisities are installed to build and install the ECDAA network wrapper which is a contribution of this thesis.
\subsection{Installing ECDAA network wrapper}
\subsection{DAA Network Protocol}
\label{ssec:daa-network-protocol}
The network protocol provided by \texttt{ecdaa-network-wrapper} adds to the cryptographic implementation of Xaptum's ecdaa project a network communication layer.
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.
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.
\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.
\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.
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}
\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.
ima_lines: <number of entries in the integrity log>
\end{lstlisting}
Instead of putting the plain integrity log into this message, we decided to use only checksum and the number of entries to keep the message size rather small.
We continue this discussion in more detail in the next chapter.
Furthermore, the the ECDAA library limits the message size for signing to 1024 Bytes.
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}}.
Copy the folder \texttt{ecdaa-network-wrapper} to the build directory and change to this directory:
@ -453,11 +509,11 @@ 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}.
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}}
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:
@ -465,61 +521,19 @@ Then the program can be downloaded and executed:
root@amd1:~# cd bs-capture/
root@amd1:~/bs-capture# cargo run
\end{lstlisting}
Cargo creates a binary in \texttt{target/debug/bs-capture} which can then be used for this prototype.
The program assumes that a webcam is available at \texttt{/dev/video0}.
It takes a still image which is saved as \texttt{frame.jpg} in the working directory, which is in this example \texttt{~/bs-capture}.
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 contains an install script which cares about installing all dependencies for setup:
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 network protocol provided by \texttt{ecdaa-network-wrapper} adds to the cryptographic implementation of Xaptum's ecdaa project a network communication layer.
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.
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.
\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.
\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.
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}
\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 communication.
This implementation reflects the Digidow transaction workflow in mind where the sensor (=member) sends a signed message to the PIA (=verifier).
Hence, sending attestation messages with biometric information of the user will happen once per transaction in the Digidow network.
@ -72,7 +72,7 @@ System 1 holds after setup as Biometric Sensor and several system updates 156947
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.
IMA holds all runtime information as virtual files in memory, including the IMA log.
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.
Both memory and disk usage do not change between IMA's fixing and enforcing mode since enforcing only adds file access control.
@ -104,7 +104,7 @@ We split the tasks of a Digidow sensor in several parts to document the conrtibu
Join the DAA group by negotiating a secret with the DAA issuer.
\item\emph{Digidow sensor capture}: Create an image using \texttt{bs-capture} and save it to disk.
\item\emph{Digidow sensor embed}: Extract a face embedding using the tensorflow application \texttt{img2emb}.
\item\emph{Digidow sensor collect}: Collect the IMA log and save it to disk.
\item\emph{Digidow sensor collect}: Collect the integrity log and save it to disk.
Create a sha512sum of the file and put it together with all PCRs and the face embedding data into one message.
Calculate another sha512sum from the message itself and save it to disk.
\item\emph{Digidow sensor send}: Sign the message's hash with the TPM DAA key and send it together with the message to the DAA verifier.
@ -229,11 +229,11 @@ Especially the tensorflow application requires significantly more time for the f
With IMA set to enforcing, the kernel furthermore manages access to the file asked to read.
This decision does not require additional resources compared to the fixing mode.
The file must be hashed in any case.
As long as the file \emph{integrity} is intact, PCR 10 and the IMA log file have to be written as well.
As long as the file \emph{integrity} is intact, PCR 10 and the integrity log file have to be written as well.
Consequently, the difference between fixing and enforcing mode is to compare the computed filehash with the value in the extended attributes and the decision depending on that result.
Since IMA measures every loaded resource, the corresponding log file will constantly increase during testing.
Unfortunately the IMA log is required to collect the data for the Digidow attestation message.
Unfortunately the integrity log is required to collect the data for the Digidow attestation message.
Furthermore, it is clear that every Digidow transaction contributes to the log since the handover beweent the single tasks is done based on files.
Consequently, we expected a runtime dependent on the number of runs and the average and maximum runtime in \autoref{tab:wholeperformance} remains unavailable when IMA is enabled.
@ -249,21 +249,21 @@ The graphs of \autoref{fig:time-digidow-transaction} show the runtime of each of
\end{figure}
Each run is split into the four parts of a Digidow transaction.
The graphs clearly show that our expectation of a linear relation between runtime and number of runs were not satisfied.
It seems that collecting the IMA log has at least the complexity of $O(n^2)$.
It seems that collecting the integrity log has at least the complexity of $O(n^2)$.
Furthermore, it is interesting, that System 1 with the newer AMD processor seems to be faster in the beginning.
When the number of runs reach 10000, the system need significantly more time than System 3 with the Intel processor.
Since the software setup on both systems is comparable (Kernel version, Linux distro, installed programs, setup with respect to \autoref{cha:implementation}), the reason for this difference can probably be found either in the microarchitectural implementation or in (less) optimized code for the AMD CPU.
When IMA is in fixing or enforcing mode, the corresponding log will be filled with information about every accessed file.
The numbers in \autoref{tab:imalogentries} are taken from the IMA log after 10000 Digidow transaction tests.
The numbers in \autoref{tab:imalogentries} are taken from the integrity log after 10000 Digidow transaction tests.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Number of additional entries in the IMA log}
\caption{Number of additional entries in the integrity log while IMA is set to enforce}
\label{tab:imalogentries}
\begin{tabular}{lrr}
\toprule
\textit{no. of entries}&\textit{System 1}&\textit{System 3}\\
&\textit{System 1}&\textit{System 3}\\
\midrule
\textit{Root login after boot}&1912 &2159\\
\textit{Digidow sensor capture}&5 &5\\
@ -277,7 +277,7 @@ The numbers in \autoref{tab:imalogentries} are taken from the IMA log after 1000
IMA was set to enforcing and the DAA member key was already in the TPM.
The root login happens when the \texttt{inputrc} file is loaeded.
In the IMA file, this file appears roughly in line 2000.
Unfortunately, neither the number nor the sequence of entries in the IMA log is predictable in this setup.
Unfortunately, neither the number nor the sequence of entries in the integrity log is predictable in this setup.
The number depends on services and daemons started during the boot sequence.
Not every service is consistently loaded every time and---depending on its individual state---the number of files loaded by the service may differ over several boot attempts.
Predicting the sequence of entries in the log is currently not possible since the kernel is taking advantage of the multicore CPU by starting services and daemons in parallel when possible.
@ -287,15 +287,15 @@ These resources were partly used by the tensorflow application.
Consequently, these two entries are very volatile and hence hard to predict.
However, the contribution of capture, collect and send as well as every further Digidow transaction are consistent.
The six entries per Digidow transaction are the changing working files for each run and one file in \texttt{/tmp}.
Thus, after 10000 runs to start a Digidow transaction the IMA log ended up with about 65000 entries, taking the kernel already several seconds to simply output the file.
Thus, after 10000 runs to start a Digidow transaction the integrity log ended up with about 65000 entries, taking the kernel already several seconds to simply output the file.
In the current setup, the single reliable information out of the IMA log is when one of the programs were executed on the system, the corresponding entries must be somewhere in the log.
In the current setup, the single reliable information out of the integrity log is when one of the programs were executed on the system, the corresponding entries must be somewhere in the log.
Furthermore you have to uniquely identify one program or script by the single file defining it.
\begin{table}
\renewcommand{\arraystretch}{1.2}
\centering
\caption{Estimation of performance of creating an IMA log entry}
\caption{Estimation of performance of creating an integrity log entry}
\label{tab:imalogspeed}
\begin{tabular}{lrrr}
\toprule
@ -312,21 +312,20 @@ Furthermore you have to uniquely identify one program or script by the single fi
When IMA is set to enforcing, some unexpected problems appeared during updating Ubuntu.
While executing \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.
The kernel prevents any access due to this missing attribute 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 according to 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.
This requires an updated command line and thereafter 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.
The copy process seems to create the file, but it fails when trying to write the first blocks.
As a result, the only way to update the kernel on this system is to boot a backup kernel with IMA set to \texttt{fix} or \texttt{off} and moving the file to the EFI partition.
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.
Another relevant part for attestation is to use the integrity log file do recalculate the produced hashes.
This means on one hand to recalculate the hash in the integrity 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.
A small script shown in \autoref{code:verifyimash} tries to this calculation.
\begin{lstlisting}[numbers=none,float, caption={Attempt to recalculate the value of PCR 10}, label={code:verifyimash}]
#!/usr/bin/bash
set -e
@ -342,11 +341,8 @@ 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).
Loading the log at least two 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.
\texttt{tpm2\_pcrextend} requires a sha256 hash as input for the corresponding PCR bank, but the integrity log only provides sha1 hashes.
Hence, any verification procedures regarding the sha256 bank of PCR 10 are currently not implemented.
The test results show that the concept can be implemented on a basic level.
Trusted boot works fine with recent linux kernels and bootloaders if required.
It is furthermore enabled by default on many Linux distributions and works out of the box when disk encryption is not needed.
Similarly, the DAA group signature scheme is working with and without using a TPM.
It provides all necessary features for a partly dynamic group.
Members of a group cannot be removed directly, but their private member key must be added to the revocation list. TODO!
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.
\section{Limitations}
\label{sec:limitations}
@ -9,18 +22,32 @@
\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 IMA
\begin{itemize}
\item Documentation on IMA is mostly outdated and so are some tools; IMA support in Linux Distros is not clearly stated.
\item output integrity log is $O(n^2)$
\item Integrity log only attests static file resources. Dynamic Analysis of programs not possible
\item Large runtime environments bloat the integrity log - complete removal recommended
\end{itemize}
\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}
It is also noteworthy, that not every TPM 2.0 is capable of running DAA.
Older TPMs, manufactured befor 2017 must be updated.
In our case, this update was not possible since the vendor and not the manufacturer provides the firmware blob.
\section{Future Work}
\begin{itemize}
\item IMA - Further customization of rules is useful to keep integrity log size constant.
\item IMA - Is it possible to get the full integrity log into the attestation message? How large is the message allowed to be?
\item Dynamic Analysis of programs with auditd: Configuration and testing. Can this be added to the attestation message s well?
\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
@ -35,6 +62,6 @@ Activate a credential with to certify that the Membership key is in the Endorsem
Further integration in the Digidow environment if DAA is useful for that.
\section{Conclusion}
\section{Conclusion}
Hardening of the system beyond IMA useful.
Minimization also useful, because the logging gets shorter.
