\chapter{State of Work and Outlook}
\label{cha:state-of-work-and-conclusion}

\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.
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}
\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
  \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
  \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}
  \end{itemize}

  Further integration in the Digidow environment if DAA is useful for that.

\section{Conclusion}
  Hardening of the system beyond IMA useful.
  Minimization also useful, because the logging gets shorter.