@ -139,27 +139,58 @@ Proving correctness of the instruction set cannot be done during the boot proces
When the roots of trust are honest, the trusted environment can be constructed during booting the platform with the PCR measurements.
When the roots of trust are honest, the trusted environment can be constructed during booting the platform with the PCR measurements.
We get then a system, where all active parts in the booting process are trusted up to the Linux kernel with its extensions and execution parameters.
We get then a system, where all active parts in the booting process are trusted up to the Linux kernel with its extensions and execution parameters.
\subsection{Integrity and Trust in the OS}%
\subsection{Integrity and Trust on OS Level}%
\label{sub:integrity_and_trust_in_the_os}
\label{sub:integrity_and_trust_on_os_level}
With the trusted kernel, we can extend the trusted environment on the file system with IMA.
With the trusted kernel and IMA, we can include the file system into the trusted environment.
According to \autoref{sec:integrity_measurement_architecture}, every file will be hashed once IMA is activated and configured accordingly.
According to \autoref{sec:integrity_measurement_architecture}, every file will be hashed once IMA is activated and configured accordingly.
By enforcing IMA, only files with a valid hash will be accessed by the kernel, assuming the whole file system to be analyzed accordingly.
By enforcing IMA, the kernel allows access to only those files having a valid hash.
Consequently, every file which is required for proper execution needs to be hashed beforehand before IMA is enforced.
After setting up the system, IMA will \texttt{fix} the attributes of all relevant files and finally be \texttt{enforced}.
The IMA policy in place should be \texttt{appraise\_tcb}, to analyze kernel modules, executable memory mapped files, executables and all files opened by root for read.
The IMA policy in place should be \texttt{appraise\_tcb}, to analyze kernel modules, executable memory mapped files, executables and all files opened by root for read.
This policy should also include drivers and kernel modules for external hardware like a camera for attached via USB.
\subsection{Prove Trust with DAA}%
\subsection{Prove Trust with DAA}%
\label{sub:prove_trust_with_daa}
\label{sub:prove_trust_with_daa}
The features described above take care of building a trusted environment on the system level.
DAA will take care of showing the \emph{trust} to a third party which has no particular knowledge about the BS.
In the DigiDow context, the PIA should get, together to the biometrical measurements, a proof that the BS is a trusted system acting honestly.
To reduce the complexity of this problem, we consider two assumptions:
\begin{enumerate}
\item\emph{Network Discovery}: The PIA is already identified over the DigiDow network and there exists a bidirecional channel between BS and PIA
\item\emph{Secure Communication Channel}: The bidirectional channel is assumed to be hardened against wire tapping, metadata extraction and tampering.
The prototype will take no further action to encrypt any payload besides the cryptographic features that come along with DAA itself.
\end{enumerate}
The DAA protocol should be applied on a simple LAN, where all parties are connected locally.
The BS will eventually become a member of the Group of sensors, managed by the Issuer.
During signup, Issuer and BS (Member) negotiate the membership credentials over the network.
By being a member of the DAA group, the Issuer fully trusts that the BS is honest and acting according the specification.
The Issuer will not check any group members, since they can now act independently of the Issuer.
When the BS is then authenticating an individual, the process illustrated in \autoref{fig:daa-attestation} will be executed.
\caption[DAA Attestation procedure]{The DAA attestation process requires 5 steps. The PIA may trust the Biometric Sensor afterwards.}
\label{fig:daa-attestation}
\end{figure}
\begin{enumerate}
\item The PIA gets once and independently of any transaction the public key of the BS group.
\item During the transaction, the PIA will eventually ask the BS for attestation together with a \texttt{nonce}.
\item The BS will collect the PCR values, the Integrity Log and the \texttt{nonce} into an Attestation message signed with the Member SK.
\item The Attestation Message will be sent back to the PIA.
\item The PIA checks the signature of the message, checks the entries of the Integrity log against known values, and proves the PCR values accordingly.
\end{enumerate}
\autoref{fig:chainoftrust} shows how the sources of trust will be represented in the final attestation message.
