The BS itself is defined as edge device within the Digidow network.
According to the schema shown in \autoref{fig:globalview}, the BS will be placed in a public area (e.g. a checkpoint in an airport or as access control system at a building) to interact directly with the Digidow users.
The BS itself is defined as edge device within the Digidow network which will be placed in a public area (e.g. a checkpoint in an airport or as access control system at a building) to interact directly with the Digidow users.
There, the BS acts as interface to the to the Digidow network.
By providing a biometric property, the user should be able to authenticate itself and the network may then trigger the desired action, like granting access or logging presence.
Depending on the biometric property, the sensor may not be active all the time, but activated when an authentication process is started.
@ -289,7 +289,7 @@ In our case, Infineon certifies its TPM with a number of intermediate CAs which
The TPM certificate is available for RSA and ECC cryptofamilies respectively.
Since the verification workflow is the same on all machines and for both cryptofamilies, we demonstrate on system 1 how the process works.
Note that this works for Infineon TPMs.
Other Vendors like STM, AMD or Intel may provide certificates via download of their website.
Other Vendors like STM, AMD or Intel may provide certificates via download on their website.
\begin{enumerate}
\item Read the certificate from the TPM NVRAM.
The RSA certificate is located at address \texttt{0x1c00002}, that for ECC on address \texttt{0x1c0000a}:
@ -315,7 +315,7 @@ Other Vendors like STM, AMD or Intel may provide certificates via download of th
\end{lstlisting}
\end{enumerate}
When OpenSSL returns \texttt{OK}, the certificate chain is intact and the TPM is indeed one from Infineon.
To be correct: The website, probably hosted by infineon, provides a certificate chain which matches and the links to the corresponding parent certificate is correct.
To be correct: The website, probably hosted by Infineon, provides a certificate chain which matches and the links to the corresponding parent certificate is correct.
Unfortunately, Infineon do neither provide any website certification nor any checksums of the provided certificates.
So, if the above described check fails, no source of trust can ensure that the root certificate is correct.
@ -356,7 +356,7 @@ Similar to trusted boot, Ubuntu requires two installed packages to support the f
\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.
@ -147,6 +147,7 @@ This would fit on most embedded devices running a Linux kernel.
However, the face embedding algorithm uses over 800\,MB and requres the majority of the computation time as shown below.
\subsection{Memory Safety}
\label{ssec:memory-safety}
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]
@ -249,7 +250,7 @@ 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 integrity log has at least the complexity of $O(n^2)$.
It seems that collecting the integrity log has an estimated 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.
In this chapter, we summarize the test results and discuss the limitations of the current prototype.
Consequently, we show a number of topics worth to investigate in the future before the we conclude this thesis.
\section{State of Work}
The test results show that the concept can be implemented on a basic level.
@ -8,59 +10,124 @@ It is furthermore enabled by default on many Linux distributions and works out o
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.
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.
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.
The different predefined rulesets work as expected but result in a large set of entries in the integrity log.
The application on top of this setup simulate the start of a Digidow transaction by capturing and processing an image.
This processed image data is then sent to the PIA acting here as a DAA verifier.
We showed in the testresults that this demo application work reliable but yet very inefficient.
The demonstration just shows a part of the workload of a full Digidow transaction.
\section{Limitations}
\label{sec:limitations}
The main contribution of the computation delay is processing the image data which is computed with a tensorflow application.
The tested systems have no GPU, requiring them to compute the neural network on the CPU.
Similarly, the image capturing part, taking about 1\,s, is very inefficient.
Capturing an image from a camera and saving it to disk should be doable in less than 0.1\,s.
Furthermore, the dedicated TPM is a quite trustworthy but slow cryptoprocessor.
Signing and sending adds another 0.25\,s to the transaction.
When capturing biometric data in an efficient way, the interaction with the TPM will be a major contribution to the whole transaction time.
Besides the slow demo implementation, we found several other limitations while building the environment.
In the context of using the TPM, we faced several problems that are not solved yet.
\begin{itemize}
\item older TPM does not support ECDAA
\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.
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
\item One TPM 2.0 module is not usable since it has an outdated firmware and we were not able to update the TPM.
The manufacturer directed us to the TPM vendor for firmware updates and the vendor seems to ignore any request in that context.
Although it is possible to update the TPM, we were not able to get a recent firmware blob for this TPM.
\item The TPM manufacturer, Infineon in our case, host the certificate chain on a website where only the domain name leads to the manufacturing company.
The website provides further cryptographic trust.
When the certificate chain is broken, it is not clear whether the user posseses a corrupt TPM or the website just provides bogus certificates.
\item The chain of trust from the TPM manufacturer is not complete since there is no cryptographic link between the certified endorsement key and the DAA member key.
The DAA member key is in the current implementation only located in the endorsement hierarchy.
\item The documentation of the TPM software stack is not beginner friendly.
On one hand, the TCG documentation is free to use and provides a narrow definition of a TPM.
On the other hand, it is optimized to be machine readable and it is usually necessary to read parts of Arthur's \emph{A Practical Guide to TPM 2.0}\cite{arthur15} to understand how the documentation is managed.
\item Using the TPM2 tools for low effort interaction with the TPM is relatively easy. Unfortunately, the parameters are incompatible over its major releases, breaking any scripts depending on that.
These differences are not documented and not announced publicly, making it hard to update any shell scripts depending on that.
\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.
Similar to using TPMs, the integrity of the sensor's hardware and software are facing some essential problems.
\begin{itemize}
\item The integrity log is currently too large to send it within the attestation message to the DAA verifier.
In the current setup, the integrity documentaaation of this log is key to generate trust between sensor and PIA.
Furthermore, it is still not defined how the PIA can efficiently compute an answer to the question whether to trust the sensor or not, given the attestation message and the integrity log.
\item IMA is only able to provide proves about staic files and resources.
Using a program which dynamically loads code from remote resources is an efficient way to circumvent any integrity restrictions.
Since the test setup is using the network interface, this is a relevant attack vector against system integrity and trust.
\item The features of IMA are poorly documented and some of the tools only support TPM1.2 which is already outdated.
Although the support of Linux distributions increases, it is not clearly stated which release supports IMA and which does not.
\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.
%\begin{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}
\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.
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.
This gap could be closed by certifying that the DAA membership key is in the endorsement hierarchy.
Since the EK has no signing property, the certification procedure uses the attestation key (AK) and the attestation identity key (AIK) to prove this link.
The theoretical concept is described by Arthur et al.\cite{arthur15} at pages 109 ff.
Eric Chieng\cite{Chieng2021} wrote on his blogpost a practical approach to impelement this certification.
This solution seems to close the missing link in the chain of trust.
Verifying the integrity of the sensor is still not solved.
There are several approaches which reduce the size of the log.
Several approaches should be investigated to mitigate this problem:
\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
\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}
\item Customize the IMA rules to omit unnecessary measurements where possible.
\item Avoid writing and reading files during a Digidow transaction.
Therefore the log should remain constant in size or at least independent of the number of transactions.
An approach for that would be to transfer the data between the different steps via pipes.
\item Sign the hashes of static files like binaries or configuration files with the kernel's extended verification module which works on top of IMA.
When files with a vaild signature are accessed, it might not be necessary to add them into the integrity log.
How are updates managed with this setup if even possible?
\item Make the root partition read only where applicable.
Every file read from this partition can be excluded from the integrity log.
A Ramdisk could then be used to hold all working files of the sensor.
This setup might satisfy similar goals compared to the previous approach, but the update procedure might be easier.
\item Include the firmware of periherals.
In the current setup, the integrity log takes only libraries and drivers into account.
However the peripherals like cameras or fingerprint sensors usually have a firmware onboard which should be measured similarly to BIOS or option ROMs.
Unfortunately we could not test a sensor which allows to extract the firmware that is acually running on the hardware.
If such hardware is available, adding the hashes into the system's attestation message should be possible.
\end{itemize}
Further integration in the Digidow environment if DAA is useful for that.
As stated in the previous section, the integrity log only measures static content.
Auditd investigates a program during execution and is able to log every system call during execution, which seems to fill the gap of dynamic execution.
It might be necessary to configure the daemon and to integrate the auditd execution log of the sensor's transaction part to the attestation message.
The results in \autoref{ssec:memory-safety} show that the memory safety is not given in every part of the demo.
This is, however, a key contribution to the system's integrity and hence the trust in it.
We recommend therefore to omit any use of scripting environments and to use memory-safe programming languages like Java or Rust.
According to this, the programs should be precompiled and installed only as binaries together with the required external resources.
The productive setup should not have any building tools installed.
Although we use an Ubuntu 20.04 server minimal setup, the majority of installed programs and services are not necessary for the Digidow sensor.
Consequently, reducing the system to a bare minimum reduces the complexity of auditing and certifying the setup as well as the resulting integrity log and attestation information.
The demonstration setup is implemented in a way that the image capturing task should be easily replaceable with another sensor setup.
Therefore, the sensor should support a variety of biometric features.
It might be required to use hardware or GPU acceleration to process these features quick enough.
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.
