You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
67 lines
3.9 KiB
67 lines
3.9 KiB
\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.
|
|
|