\chapter{State of Work and Outlook}
\label{cha:state-of-work-and-conclusion}
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.

We summarize in this chapter the test results and discuss the limitations of the current prototype.
Consequently, we show a number of topics worth to investigate in the future.

\section{State of Work}
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.
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 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.
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 simulates 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 test results that this demo application works 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 to 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 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, hosts the certificate chain on a website where only the domain name leads to the manufacturing company.
  The website does not provide further cryptographic trust.
  When the certificate chain is broken, it may not be clear whether the user posseses a corrupt TPM or the website just provides bogus certificates.
  \item The chain of trust between TPM manufacturer and DAA member key is not complete in the current implementation since there is no cryptographic link between the certified endorsement key and the DAA member key.
  The member key is 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 et al. \emph{A Practical Guide to TPM~2.0}~\cite{arthur15} to understand how the documentation is managed.
  Although complex documentation is usual for standards, an interested developer may need more time as expected for understanding the interfaces.
  \item Using the TPM~2.0 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}

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 documentation 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 proofs about static 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 TPM~1.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}

%\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 top 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{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 currently no widespread public library available in the public.

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. at pages 109 ff~\cite{arthur15}.
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 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 valid signature are accessed, it might not be necessary to add them into the integrity log.
  \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 peripherals.
  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}

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 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 build 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.