@ -132,7 +132,7 @@ IMA comes with three property variables which set the behaviour of the architect
\end{itemize}
These settings will be discussed in more detail in the following.
\subsubsection{Integrity Log}%
\subsection{Integrity Log}%
\label{ssub:integrity_log}
IMA uses the emph{integrity log} do keep track of any changes of local filesystem resources.
@ -162,7 +162,7 @@ The only difference between these formats lie in the used and logged metadata:
The older template \texttt{ima} uses only SHA1 and is fully replaceyble with the \texttt{ima-ng} template.
Therefore, it should not be used for newer applications.
\ToDo{boot aggregate beschreiben}
\subsubsection{IMA Appraisal}%
\subsection{IMA Appraisal}%
\label{ssub:ima_appraisal}
IMA comes with four different runtime modes.
@ -172,21 +172,224 @@ These modes set the behaviour especially when there exists no additional informa
\item\texttt{log}: Integrity measurements are done for all relevant resources and the integrity log is filled accordingly.
\item\texttt{fix}: In addition to writing the log file, the filedata hashes are also written as extended file attribute into the file system.
This is required for the last mode to work.
\item\texttt{enforce}: Only files that have a valid hash value are allowed to be read.
Accessing a resource without a hash or an invalid hash will be blocked by the kernel.
\item\texttt{enforce}: Only files with a valid hash value are allowed to be read.
Accessing a static resource without a hash or an invalid hash will be blocked by the kernel.
\end{itemize}
\subsubsection{IMA Policies}%
\subsection{IMA Policies}%
\label{ssub:ima_policies}
The IMA policies define which resources are targeted with IMA.
There exist three template policies which can be used concurrently:
\begin{itemize}
\item\texttt{tcb}: All files owned by root will be measured.
\item\texttt{appraise\_tcb}: All executables which are run, all files mapped in memory for execution, all loaded Kernel modules and all files opened for read by root will be measured by IMA.
\item\texttt{secure\_boot}: All loaded modules, firmwares, executed Kernels and IMA policies are checked. Therefore these resources need to have a provable signature to pass the check. The corresponding public key must be provided by the system manufacturere within the provided firmware or as Machine Owner Key in shim.
\end{itemize}
In addition to these templates, the system owner can define custom policies.
Some example policies can be found at the Gentoo Wiki\footnote{\url{https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture/Recipes}}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce useless in the measurement log.
\subsubsection{IMA extensions}%
\subsection{IMA extensions}%
\label{ssub:ima_extensions}
\section{Direct Anonymous Attestation}%
\label{sec:direct_anonymous_attestation}
\emph{Direct Anonymous Attestation} (DAA) is a cryptographic scheme which makes use of the functions provided by the TPM.
DAA implements the concept of group signatures, where multiple secret keys can create a corresponding signature.
These signatures can be verified with a single public key, when these private keys are member of the same group.
The scientific community is researching on TPM-backed DAA since the first standard of TPM went public in 2004.
Since then many different approaches of DAA were discussed.
According to the discussion in \cite{camenisch16} and \cite{camenisch17} almost all schemes were proven insecure, since many of them had bugs in the protocol or allowed trivial public\,/\,secret key pairs.
This includes also the impementation of DAA im the TPM1.2 standard.
This section describes the concept of Camenisch et. al.\cite{camenisch16} including the cryptographic elements used for DAA.
Unlike the description in the original paper, we describe the practical approach, which will be used in the following concept.
\subsection{Mathematical Foundations}
The following definitions form the mathematical building blocks for DAA.
It is noteworthy that these definitions work with RSA encryption as well as with \emph{Elliptic Curve Cryptography} (ECC).
\subsubsection{Discrete Logarithm Problem}
Given a cyclic group $G =\langle g\rangle$ of order $n$, the discrete logarithm of $y\in G$ to the base $g$ is the smallest positive integer $\alpha$ satisfying
\begin{math}
g^\alpha = y
\end{math}
if this $x$ exists.
For sufficiently large $n$ and properly chosen $G$ and $g$, it is infeasible to compute the reverse
\begin{math}
\alpha = \log_g{y}
\end{math}.
This problem is known as \emph{Discrete Logarithm Problem} and is the basis for the following cryptographic algorithms.
\subsubsection{Signature Proof of Knowledge (SPK)}
A SPK is a signature of a message which proof that the creator of this signature is in possession of a certain secret.
The secret itself is never revealed to any other party
Thus, this algorithm is a \emph{Zero Knowledge Proof of Knowledge} (ZPK).
Camenisch and Stadler\cite{camenisch97} introduced the algorithm based on the Schnorr Signature Scheme.
It only assumes a collision resistant hash function $\mathcal{H}:\{0,1\}^*\rightarrow\{0,1\}^k$ for signature creation.
For instance,
\begin{equation*}
SPK\{(\alpha):y=g^\alpha\}(m)
\end{equation*}
denotes a proof of knowledge of the secret $\alpha$, which is embedded in the signature of message $m$.
The one-way protocol consists of three procedures:
\begin{enumerate}
\item\emph{Setup.} Let $m$ be a message to be signed, $\alpha$ be a secret and $y:=g^\alpha$ be the corresponding public representation.
\item\emph{Sign.} Choose a random number $r$ and create the signature tuple $(c,s)$ as
\item\emph{Verify.} The verifier knows the values of $y$ and $g$, as they are usually public. The message $m$ comes with the signature values $c$ and $s$. She computes the value
\begin{equation*}
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\, .
\end{equation*}
The verification holds since
\begin{equation*}
g^sy^c = g^rg^{-c\alpha}g^{c\alpha} = g^r\, .
\end{equation*}
\end{enumerate}
This scheme is extensible to proof knowledge of arbitrary number of secrets as well as more complex relations between secret and public values.
\subsubsection{Bilinear Maps}
\label{ssec:bilinear-maps}
Bilinear Mapr define a special property for mathematical groups which form the basis for verifying the signatures in DAA.
Consider three mathematical groups $\mathbb{G}_1$, $\mathbb{G}_2$, with their corresponding base points $g_1$, $g_2$, and $\mathbb{G}_T$.
Let $e:\mathbb{G}_1\times\mathbb{G}_2\rightarrow\mathbb{G}_T$ that satisfies three properties\cite{camenisch04,camenisch16}:
\begin{itemize}
\item\emph{Bilinearity.} For all $P\in\mathbb{G}_1, Q\in\mathbb{G}_2$, for all $a,b \in\mathbb{Z}: e(P^a,Q^b)= e(P,Q)^{ab}$.
\item\emph{Non-degeneracy.} For all generators $g1\in\mathbb{G}_1, g2\in\mathbb{G}_2: e(g_1,g_2)$ generates $\mathbb{G}_T$.
\item\emph{Efficiency.} There exists an efficient algorithm that outputs the bilinear group\\
$(q, \mathbb{G}_1,\mathbb{G}_2,\mathbb{G}_T, e, g_1, g_2)$ and an efficient algorithm for computing $e$.
The Camenisch-Lysyanskaya (CL) Signature Scheme\cite{camenisch04} is based on the LRSW-assumption and allows efficient proofs for signature posession and is the basis for the DAA scheme discussed below.
It is based on a bilinear group $(q, \mathbb{G}_1,\mathbb{G}_2,\mathbb{G}_T, e, g_1, g_2)$ that is available to all steps in the protocol.
\begin{itemize}
\item\emph{Setup.} Choose $x\leftarrow\mathbb{Z}_q$ and $y\leftarrow\mathbb{Z}_q$ at random. Set the secret key $sk \leftarrow(x,y)$ and the public key $pk \leftarrow(g_2^x, g_2^y)=(X,Y)$
\item\emph{Sign.} Given a message $m$, and the secret key $sk$, choose $a$ at random and output the signature $\sigma\leftarrow(a, a^y, a^{x+xym})=(a,b,c)$
\item\emph{Verify.} Given message $m$, signature $\sigma$ and public key $pk$, verify, that $a \neq1_{\mathbb{G}_1}$, $e(a,Y)= e(b,g_2)$ and $e(a,X)\cdot e(b,X)^m = e(c,g_2)$
\end{itemize}
Camenisch et al.\@ stated in section 4.2 of their paper\cite{camenisch16} that one has to verify the equation against $e(g_1,b)$ and $e(g_1,c)$ which is not correct.
\ToDo{Überleitung zu IMA und IMA beschreiben. Danach DAA theoretisch beschreiben, kopie aus dem Seminarpaper}
\subsection{DAA Protocol on LRSW Assumption}
\label{ssec:daa-protocol-on-lrsw-assumption}%TODO extend security properties according to Camenisch
DAA is a group signature protocol, which aims with a supporting TPM to reveal no additional information about the signing host besides content and validity of the signed message $m$.
According to Camenisch et.\@ al.\cite{camenisch16}, the DAA protocol consists of three parties:
\begin{itemize}
\item\emph{Issuer}\issuer. The issuer maintains a group and has evidence of hosts that are members in this group. This role equals the group manager of Bellare's generic definition.
\item\emph{Host}\host. The Host creates a platform with the corresponding TPM \tpm{}. Membership of groups are maintained by the TPM.
Compared to Bellare et.\@ al., the role of a member is split into two cooperating parties, the key owner (TPM, passive) and the message author (Host, active).
\item\emph{Verifier}\verifier. A verifier can check whether a Host with its TPM is in a group or not. Besides the group membership, no additional information is provided.
\end{itemize}
A certificate authority $\mathcal{F}_{ca}$ is providing a certificate for the issuer itself.
The basename \texttt{bsn} is some clear text string, whereas \texttt{nym} represent the encrypted basename $bsn^{gsk}$.
$\mathcal{L}$ is the list of registered group members which is maintained by \issuer.
The paper of Camenisch et.\@ al.\cite{camenisch16} introduces further variables that are necessary for their proof of correctness.
These extensions were omitted in the following to understand the protocol more easily.
\begin{itemize}
\item\emph{Setup.} During Setup \issuer{} is generating the issuer secret key $isk$ and the corresponding issuer public key $ipk$. The public key is published and assumed to be known to everyone.
\begin{enumerate}
\item On input \textsf{SETUP}\issuer
\begin{itemize}
\item generates $x,y \leftarrow\mathbb{Z}_q$ and sets $isk=(x.y)$ and $ipk\leftarrow(g_2^x,g_2^y)=(X,Y)$. Initialize $\mathcal{L}\leftarrow\emptyset$,
\item generates a prove $\pi\sassign SPK\{(x,y):X=g_2^x\wedge Y=g_2^y\}$ that the key pair is well formed,
\item registers the public key $(X,Y,\pi)$ at $\mathcal{F}_{ca}$ and stores the secret key,
\item outputs \textsf{SETUPDONE}
\end{itemize}
\end{enumerate}
\item\emph{Join.} When a platform, consisting of host \host[j] and TPM \tpm[i], wants to become a member of the issuer's group, it joins the group by authenticating to the issuer \issuer.
\begin{enumerate}
\item On input \textsf{JOIN}, host \host[j] sends the message \textsf{JOIN} to \issuer.
\item\issuer\ upon receiving \textsf{JOIN} from \host[j], chooses a fresh nonce $n\leftarrow\{0,1\}^\tau$ and sends it back to \host[j].
\item\host[j] upon receiving $n$ from \issuer, forwards $n$ to \tpm[i]
\item\tpm[i] generates the secret key:
\begin{itemize}
\item Check, that no completed key record exists. Otherwise, it is already a member of that group.
\item Choose $gsk\sassign\mathbb{Z}_q$ and store the key as $(gsk, \bot)$.
\item Set $Q \leftarrow g_1^{gsk}$ and compute $\pi_1\sassign SPK\{(gsk):Q=g_1^{gsk}\}(n)$.
\item Return $(Q,\pi_1)$ to \host[j].
\end{itemize}
\item\host[j] forwards \textsf{JOINPROCEED}$(Q, \pi_1)$ to \issuer.
\item\issuer\ upon input \textsf{JOINPROCEED}$(Q, \pi_1)$ creates the CL-credential:
\begin{itemize}
\item Verify that $\pi_1$ is correct.
\item Add \tpm[i] to $\mathcal{L}$. %TODO what is the representative of the TPM?
\item Create the prove $\pi_2\sassign SPK\{(t):b=g_1^t\wedge d=Q^t\}$.
\item Send \textsf{APPEND}$(a,b,c,d,\pi_2)$ to \host[j]
\end{itemize}
\item\host[j] upon receiving \textsf{APPEND}$(a,b,c,d,\pi_2)$
\begin{itemize}
\item verifies, that $a\neq1$, $e(a,Y)=e(b,g_2)$ and $e(c,g_2)= e(a\cdot d, X)$.
\item forwards $(b,d,\pi_2)$ to \tpm[i].
\end{itemize}
\item\tpm[i] receives $(b,d,\pi_2)$ and verifies $\pi_2$. The join is completed after the record is extended to $(gsk, (b,d))$. \tpm[i] returns \textsf{JOINED} to \host[j].
\item\host[j] stores $(a,b,c,d)$ and outputs \textsf{JOINED}.
\end{enumerate}
\item\emph{Sign.}
After joining the group, a host \host[j] and TPM \tpm[i] can sign a message $m$ with respect to basename \texttt{bsn}.
\begin{enumerate}
\item\host[j] upon input \textsf{SIGN}$(m,\bsn)$ re-randomizes the CL-credential:
\begin{itemize}
\item Retrieve the join record $(a,b,c,d)$ and choose $r\sassign\mathbb{Z}_q$. \\
Set $(a',b',c',d')\leftarrow(a^r,b^r,c^r,d^r)$.
\item Send $(m, \bsn, r)$ to \tpm[i] and store $(a',b',c',d')$.
\end{itemize}
\item\tpm[i] upon receiving $(m, \bsn, r)$
\begin{itemize}
\item checks, that a complete join record $(gsk, (b,d))$ exists, and
\item stores $(m, \bsn, r)$.
\end{itemize}
\item\tpm[i] completes the signature after it gets permission to do so. %TODO Why?
\begin{itemize}
\item Retrieve group record $(gsk, (b,d))$ and message record $(m, \bsn, r)$.
\item verifies $\pi$ with respect to $(m,\bsn)$ and \nym if $\bsn\neq\bot$.
\item checks, that $a\neq1$, $b\neq1$$e(a,Y)=e(b, g_2)$ and $e(c,g_2)=e(a\cdot d,X)$,
\item checks, that for every $gsk_i \in\RL: b^{gsk_i}\neq d$,
\item sets $f\leftarrow1$ if all test pass, otherwise $f\leftarrow0$, and
\item outputs \textsf{VERIFIED}$(f)$.
\end{itemize}
\end{enumerate}
\item\emph{Link.}
After proving validity of the signature, the verifier can test, whether two different messages with the same basename $\bsn\neq\bot$ are generated from the same TPM.
\begin{enumerate}
\item\verifier\ on input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$ verifies the signatures and compares the pseudonyms contained in $\sigma, \sigma'$:
\begin{itemize}
\item Check, that $\bsn\neq\bot$ and that both signatures $\sigma, \sigma'$ are valid.
\item Parse the signatures $\sigma\leftarrow(a,b,c,d,\pi,\nym)$, $\sigma'\leftarrow(a',b',c',d',\pi',\nym')$
\item If $\nym=\nym'$, set $f\leftarrow1$, otherwise $f\leftarrow0$.
\item Output \textsf{LINK}$(f)$
\end{itemize}
\end{enumerate}
\end{itemize}
Camenisch et.\@ al.\cite{camenisch16} extend with their concept the general group concept scheme.
The feature of linking messages together requires further security features within the DAA scheme, which the authors also prove in their paper along with the other properties of the scheme:
\begin{itemize}
\item\emph{Non-frameability}: No one can create signatures that the Platform never signed, but that link to messages signed from that Platform.
\item\emph{Correctness of link}: Two signatures will link when the honest platform signs it with the same basename.
\item\emph{Symmetry of Link}: Id does not matter in which order the linked signatures will be proven. The link algorithm will always output the same result.
