masterthesis/thesis/02_concept.tex

\chapter{Background}%
\label{cha:background}
\ToDo{TPM beschreiben und chain of trust herleiten, }

In this Chapter we describe three main concepts which contribute the fundamentals for this thesis.
\emph{Trusted Boot} and the \emph{Integrity Measurement Architecture} (IMA) are two approaches to generate trust on a system from the hardware level up to the Operating System.
The generated trust should then be provable by an external party---in our case the PIA---by using the protocol of \emph{Direct Anonymous Attestation} (DAA).
We describe the basic functionality of these three concepts in the following.
\section{Trusted Boot}%
\label{sec:trusted_boot}

A boot process of modern platforms consists of several steps until the OS taking over the platform.
During these early steps, the hardware components of the platform are initialized and some self tests are performed.
This is controlled by either the BIOS (for legacy platforms) or the UEFI firmware.
In this common boot procedure exists no source of trust and hence no check for integrity or intended execution.

\subsection{Platform Configuration Register}%
\label{sub:platform_configuration_register}

The \emph{Trusted Computing Group} (TCG) introduced in 2004 their first standard for a new {Trusted Computing Module} (TPM).
As part in this standard, TCG defined a procedure, where every step in the early boot process is measured and saved in a \emph{Platform Configuration Register} (PCR). 
\emph{Measuring} means in this context a simple cryptographic extension function which works described in formula \ref{form:PCR-measurement}
\begin{equation}
	\text{new\_PCR} = hash(\text{old\_PCR}\,||\,\text{data})
	\label{form:PCR-measurement}
\end{equation}
The function of $||$ represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256 hash.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
Consequently, both hash results are available for further computations.

The formula shows in addition that a new PCR value holds the information of the preceeding value as well.
This \emph{hash chain} enables the user to add an arbitrary number of hash computations.
One can clearly see that the resulting hash will also change when the order of computations change.
Therefore, the BIOS\,/\,UEFI has to provide a deterministic way to compute the hash chain if there is more than one operation necessary.
The procedure of measurements is available since the first public standard of TPM, version 1.2.
For the recent TPM2.0 standard, the process was only extended with the support for the newer SHA256 standard.

A PCR is now useful for a sequence of measurements with similar purpose.
When, for example, a new bootloader is installed on the main disk, the user wants to detect this with a separate PCR value.
The measured firmware BLOBs may be still the same.
So the TPM standard defines 24 PCRs for the PC platform, each with a special role and slightly different feature set.
The purpose of every PCR is well defined in Section 2.3.3 of the \emph{TCG PC Client Platform Firmware Profile}\cite{tcg-pc19} and shown in table \ref{tab:PCR}.
Especially those PCRs involved in the boot process must only be reset according to a platform reset.
During booting and running the system these registers can only be \emph{extended} with new measurements.
\begin{table}[ht]
	\centering
	\begin{sffamily}
		\caption{Usage of PCRs during an UEFI trusted boot process} \label{tab:PCR}
		%\rowcolors{2}{lightgray}{white}
		\begin{small}
			\begin{tabular}{rl}
				\toprule
				\multicolumn{1}{c}{\textit{PCR}} & \multicolumn{1}{p{5.8cm}}{\textit{Explanation}}\\
				\midrule
				0 & SRTM, BIOS, host platform extensions, embedded option ROMs and PI drivers  \\
				1 & Host platform configuration\\
				2 & UEFI driver and application code  \\
				3 & UEFI driver and application configuration and data \\
				4 & UEFI Boot Manager code and boot attempts  \\
				5 & Boot Manager code configuration and data and GPT\,/\,partition table\\
				6 & Host platform manufacturer specific  \\
				7 & Secure Boot Policy \\
				8-15 & Defined for use by the static OS  \\
				16 & Debug \\
				17--23 & Application\\
				\bottomrule
			\end{tabular}
		\end{small}
	\end{sffamily}
\end{table}

When TCG introduced Trusted Boot in 2004, UEFI was not yet available for the ordinary PC platform.
Consequently, TCG standardized the roles of every PCR only for the BIOS platform.
Later, when UEFI became popular, the PCR descriptions got adopted for the new platform.

\subsection{Static Root of Trust for Measurement}%
\label{sub:static_root_of_trust_for_measurement}

The standard furthermore defines which part of the platform or firmware has to perform the measurement.
Since the TPM itself is a purely passive element, executing instructions provided by the CPU, the BIOS\,/\,UEFI firmware has to initiate the measurement beginning by the binary representation of the firmware itself.
This procedure is described in the TCG standard and the platform user has to \emph{trust} the manufacturer, that it is performed as expected.
It is called the \emph{Static Root of Trust for Measurement} (SRTM) and is defined in section 2.2 of the TCG PC Client Platform Firmware Profile\cite{tcg-pc19}.
As the manufacturer of the motherboards do not publish their firmware code, one may have to reverse engineer the firmware to prove correct implementation of the SRTM.

The SRTM is a small immutable piece of the firmware which is executed by default after the platform was reset.
It is the first piece of software that is executed on the platform and measures itself into PCR[0].
It furthermore must measure all platform initialization code like embedded drivers, host platform firmware, etc.\@ as they are provided as part of the PC motherboard.
If these measurements cannot be performed, the chain of trust is broken and consequently the platform cannot be trusted.
One may see a zeroed PCR[0] or a value representing a hashed string of zeros as a strong indicator of a broken chain of trust.

\subsection{Platform handover to OS}%
\label{sub:platform_handover_to_os}

The BIOS or UEFI performs the next measurements according to table \ref{tab:PCR} until PCRs 1--7 are written accordingly.
Before any further measurements are done, the control of the platform is handed over to the first part of the OS, which is usually the bootloader either in the Master Boot Record or provided as EFI BLOB in the EFI boot partition.
It is noteworthy that the bootloader itself and its configuration payload is measured in PCR 4 and 5 before the handover is done.
This guarantees that the chain of trust keeps intact when the bootloader takes control.

The Bootloader has then to continue the chain of trust by measuring the Kernel and the corresponding command line parameters into the next PCRs.
The support and the way of how the measurements are done is not standardized.
GRUB, for example, measures all executed grub commands, the kernel command line and the module command line into PCR 8, whereas any file read by GRUB will be measured into PCR 9\cite{grub19}.

The whole process from initialization over measuring all software parts until the OS is started, is called \emph{Trusted Boot}.
The user can check the resulting values in the written PCR registers against known values.
These values can either be precomputed or just the result of a previous boot.
If all values match the expectations, the chain of trust exists between the SRTM and the Kernel.

\section{Integrity Measurement Architecture}%
\label{sec:integrity_measurement_architecture}

The \emph{Integrity Measurement Architecture} (IMA) is a Linux kernel extension to extend the chain of trust to the running application.
IMA is officialy supported by RedHat and Ubuntu and there exists documentation to enable IMA on Gentoo as well.
Other OS providers may not use a kernel with the required compile flags and\,/\,or lack of supporting software outside the kernel.
The IMA project page describes the required Kernel features for full support in their documentation\footnote{\url{https://sourceforge.net/p/linux-ima/wiki/Home/\#configuring-the-kernel}, last visited on March 30, 2021}.

The process of keeping track of system integrity becomes compared to the boot process far more complex on the OS level.
First, there are far more file system resources involved in running a system.
Even a minimal setup of a common Linux Distribution like Ubuntu or RedHat will load several hundred files until the kernel has completed its boot process. 
Second, all these files will be loaded in parallel to make effective use of the available CPU resources.
It is clear that parallelism introduces non-determinism to the order of executing processes and of course the corresponding system log files.
Hence when using PCRs, this non-determinism results in different values, as stated in \autoref{sub:platform_configuration_register}.
The system, however, might still be in a trustworthy state.

Finally, the user might know some additional data to the current value in the PCR register.
Since the value itself does not tell anything to the user, a measurement log must be written for every operation on this PCR index.

IMA comes with three property variables which set the behaviour of the architecture:
\begin{itemize}
	\item \texttt{ima\_template} sets the format of the produced log.
	\item \texttt{ima\_appraise} changes the behaviour when a file is under investigation.
	\item \texttt{ima\_policy} finally defines which resources should be analzyed.
\end{itemize}
These settings will be discussed in more detail in the following.

\subsection{Integrity Log}%
\label{ssub:integrity_log}

IMA uses the emph{integrity log} do keep track of any changes of local filesystem resources.
This is a virtual file that holds every measurement that leads to a change on the IMA PCR.
When IMA is active on the system, the integrity log can be found in \texttt{/sys/kernel/security/ima/ascii\_runtime\_measurements}.

Before a file is accessed by the kernel, IMA creates an integrity log entry as it is shown in \autoref{fig:integrity-log-entry}.
\begin{figure}
	\centering
	\includegraphics[width=0.9\textwidth]{../resources/integrity-log.pdf}
	\caption[Integrity log entry]{Overview of generating an entry in the integrity log}
	\label{fig:integrity-log-entry}
\end{figure}
Depending on the settings for IMA, a SHA1 or SHA256 hash is created for the file content.
The resulting \emph{filedata hash} will be concatenated with the corresponding metadata.
This concatenation will again be hashed into the so called \emph{template hash}.
Finally the template hash is the single value of the whole computation that will be extended into the PCR.
The integrity log holds at the end the filedata hash, the metadata and the template hash as well as the PCR index and the logfile format.

IMA knows three different file formats, where two of them can be used in recent applications.
The only difference between these formats lie in the used and logged metadata:
\begin{itemize}
	\item \texttt{ima-ng} uses besides the filedata hash also the filedata hash length, the pathname length and the pathname to create the template hash.
	\item \texttt{ima-sig} uses the same sources as ima-ng.
		When available, it writes also signatures of files into the log and includes them for calculating the template hash.
\end{itemize}
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}
\subsection{IMA Appraisal}%
\label{ssub:ima_appraisal}

IMA comes with four different runtime modes.
These modes set the behaviour especially when there exists no additional information about the file in question.
\begin{itemize}
	\item \texttt{off}: IMA is completely shut down. The integrity log just holds the entry of the boot aggregate.
	\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 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}

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

\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
		\begin{equation*}
			c:=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^r) \quad\text{and}\quad s:=r-c\alpha \quad\text{(mod n) .}
		\end{equation*}

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

	\subsubsection{Camenisch-Lysyanskaya Signature Scheme}
	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 \neq 1_{\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.

	\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 Choose $r\sassign\mathbb{Z}_q$ and compute $a\leftarrow g_1^r$, $b\leftarrow a^y$, $c\leftarrow a^x\cdot Q^{rxy}$, $d\leftarrow Q^{ry}$.
				\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\neq 1$, $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 Compute $b'\leftarrow b^r, d'\leftarrow d^r$.
				\item If $\bsn = \bot$ set $\nym \leftarrow\bot$ and compute \\
					$\pi \sassign SPK\{(gsk):d'=b'^{gsk}\}(m, \bsn)$
				\item If $\bsn \neq \bot$ set $\nym\leftarrow H_1(\bsn)^{gsk}$ and compute \\
					$\pi \sassign SPK\{(gsk):\nym=H_1(\bsn)^{gsk}\wedge d'=b'^{gsk}\}(m, \bsn)$.
				\item Send $(\pi,\nym)$ to \host[j].
			\end{itemize}
			\item \host[j] assembles the signature $\sigma \leftarrow (a', b', c', d', \pi, \nym)$ and outputs \textsf{SIGNATURE}$(\sigma)$
		\end{enumerate}
		\item \emph{Verify.}
		Given a signed message, everyone can check whether the signature with respect to \bsn\ is valid and the signer is member of this group.
		Furthermore a revocation list \RL\ holds the private keys of corrupted TPMs, whose signatures are no longer accepted.
		\begin{enumerate}
			\item \verifier\ upon input \textsf{VERIFY}$(m, \bsn, \sigma)$
			\begin{itemize}
				\item parses $\sigma\leftarrow(a,b,c,d,\pi,\nym)$,
				\item verifies $\pi$ with respect to $(m,\bsn)$ and \nym if $\bsn\neq\bot$.
				\item checks, that $a\neq 1$, $b\neq 1$ $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\leftarrow 1$ if all test pass, otherwise $f\leftarrow 0$, 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\leftarrow 1$, otherwise $f\leftarrow 0$.
				\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.
	\end{itemize}

\chapter{Concept}
\label{cha:concept}
The theoretical tool that should be formed to one whole system implementation in this thesis.
\section{Definition of the Biometric Sensor}
\label{definitions}
What part fulfills the BS and what needs to be done.
Record Sensor data, Network Discovery, send sensor data via trusted channel to PIA

\subsection{What has the BS to do?}
\label{sec:bs-usecase}
\begin{enumerate}
	\item Listen for a Trigger to start the Authentication Process
	\item Collect Sensor Data (Picture, Fingerprint) and calculate a biometric representation
	\item Start Network Discovery and find the PIA of this person
	\item Create a trusted and secure channel and transmit the attributes for verification
	\item Restore the state of the system as it was before this transaction
\end{enumerate}

\section{Attack Vectors and Threat Model}
The Biometric Sensor will work in an exposed environment.
Neither the user providing biometric data nor the network environment should be trusted for proper function.
There should only be a connection to the Digidow network for transmitting the recorded data.
This assumption of autonomy provides independence to the probably diverse target environments and use cases.

In addition to autonomy, the Biometric Sensor should also ensure proper handling of received and generated data.
The recorded dataset from a sensor is \emph{sensitive data} due to its ability to identify an individual (Who?). 
Due to its narrow definition, it is affordable to protect sensitive data.
Besides that, \emph{metadata} is information generated during the whole transaction phase. 
Timestamps and host information are metadata as well as connection lists, hash sums and log entries and much more (What? Where? When?)
There exists no exact definition or list of metadata which makes it hard to prevent any exposure of it.
Metadata does not directly identify an individual.
However huge notwork providers are able to combine lots of metadata to traces of individuals.
Eventually an action of those traced individuals might unveil their identity. 
Consequently, a central goal of Digidow is to minimize the amount to minimize the risk of traces.

Privacy defines the ability of individuals to keep information about themselves private from others.
In context to the Biometric Sensor, this is related to the recorded biometric data.
Furthermore, to prevent tracking. any interaction with a Sensor should not be matched to personal information.
Only the intended and trusted way of identification within the Digidow network should be possible.

\subsection{Threat Model}
\label{ssec:threatmodel}

To fulfill the Sensor's use case in an exposed environment, we need to consider the following attack vectors.
\begin{itemize}
	\item \emph{Rogue Hardware Components}: Modified components of the Biometric Sensor could, depending on their contribution to the system, collect data or create a gateway to the internal processes of the system. 
		Although the produced hardware piece itself is fine, the firmware on it is acting in a malicious way.
		This threat addresses the manufacturing and installation of the system.
	\item \emph{Hardware Modification}: Similar to rogue hardware components, the system could be modified in the target environment by attaching additional hardware.
		With this attack, adversaries may get direct access to memory or to data transferred from or to attached devices,
	\item \emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection. 
		It is possible to log the protocol of those attached devices via Man in the Middle attack on the USB cable.
	\item \emph{Attribute Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection. 
		It is possible to log the protocol of those attached devices via wiretapping the USB cable. 
		With that attack, an adversary is able to directly access the attributes to identify individuals.
	\item \emph{Modification or aggregation of sensitive data within Biometric Sensor}: The program which prepares the sernsor data for transmission could modify the data before sealing it.
		The program can also just save the sensible data for other purposes. 
	\item \emph{Metadata extraction on Network}: During transmission of data from the sensor into the Digidow network, there will be some metadata generated.
		An adversary could use this datasets to generate tracking logs and eventually match these logs to individuals.
	\item \emph{Retransmission of sensor data of a rogue Biometric Sensor}: When retransmitting sensor data, the authentication of an individual could again be proven.
		Any grants provided to this individual could then given to another person.
	\item \emph{Rogue Biometric Sensor blocks transmission}: By blocking any transmission of sensor data, any transaction within the Digidow network could be blocked and therefore the whole authentication process is stopped.
	\item \emph{Rogue Personal Identity Agent}: A rogue PIA might receive the sensor data instead of the honest one.
		Due to this error, a wrong identity and therefore false claims would be made out of that.
\end{itemize}

Given this threat model and the use cases described in \autoref{sec:bs-usecase}, we will introduce an approach to minimize most of the attack vectors.

\begin{itemize}
	\item DONE Definition of sensitive data / privacy / metadata
	\item This version of BS is not owned by the user, there is no personal data in the System
	\item Rogue Personal Identity Agent (PIA)
	\item Metadata Extraction
	\item Attribute extraction
	\item Sensor Data Modification/manipulation
	\item Wiretap between Sensor and System (USB or network)
	\item Physical Manipulation of the BS-System
	\item Network - Retransmission of sensor data of a rogue BS
	\item Network - Blocking Data transmission of a rogue BS
	\item Rogue BS Sensor Data aggregation
	\item Rogue BS Sensor data modification before transmission
\end{itemize}
\section{Trust and Security}
\label{sec:trust}
Trust is an essential term in this thesis.
In the world of IT security, the term \emph{trusted computing} defines a secured environment where special or confidential computing jobs are dispatched.
This environment or product usually meets the following requirements
\begin{itemize}
	\item \emph{Minimalization.} The number of features and hence the complexity must be as low as possible.
	\item \emph{Sound definitions.} Every function should be well defined. There should be no margin for interpretation left. Security Engineers should be involved in the development. 
	\item \emph{Complete testing.} Testing for trusted computing includes a threat analysis and exhaustive testing if possible. 
\end{itemize}
Since software and hardware testing is never complete, it is hard to find a good balance between feature set and testing completeness.

However trust in IT is not equal to security.
It defines a subset of IT security where this small well defined environment is embedded in a larger system which is usually untrusted.
Claiming a system \emph{secure} spans the constraints of trust over the complete system, which is not affordable for commodity computers these days.
However it is possible to use the trusted environment to get some guarantees on the untrusted parts of a system as well
In Chapter 3 we will show how trust will be extended in a commodity PC.
%TODO reference to TPM section how to extend trust into untrusted parts of PC

%TODO describe verifiable trust in addition to the previous definition (with example of the ATM?)


Differentiation between trust and security --- and the problem that not everyone is using that right.
\section{Systems of Trust}
\label{sec:trustsystems}
All trust systems are built on the standards of Trusted Computing Group.
\subsection{Secure Boot, TXT, \ldots}
\label{ssec:secureboot-txt}
Trusted Boot is not the same as Secure Boot. Explain the difference
\subsection{TPM1.2}
\label{ssec:tpm12}
Initial Version of the crypto-coprocessor, successfully spread into many systems, but hardly any integration in Trust/security Software

%TODO this is an attempt to describe TPM from the beginning.
\subsection{TPM2.0}
\label{ssec:tpm20}
The \emph{Trusted Platform Module} (TPM) is a small cryptocoprocessor that introduces a variety of new features to the platform.
This module is part of a standard developed by the Trusted Computing Group (TCG), which current revision is 2.0\cite{tcg20}.

The hardware itself is strongly defined by the standard and comes in the following flavors:
%TODO find source of that claim (TPM variants)
\begin{itemize}
	\item \emph{Dedicated device.} The TPM chip is mounted on a small board with a connector. 
		The user can plug it into a compatible compute platform. This gives most control to the end user since it is easy to disable trusted computing or switch to another TPM.
	\item \emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard. Therefore any hardware modification is impossible.
		However most PC platforms provide BIOS features to control the TPM.
	\item \emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision. 
		Firmware means in this context an extension of the CPU instruction set which provides the features of a TPM.
		Both Intel and AMD provide this extension for their platforms for several years now.
		When activating this feature on BIOS level, all features of Trusted Computing are available to the user.
	\item \emph{TPM Simulator.} For testing reasons, it is possible to install a TPM simulator. It provides basically every feature of a TPM but cannot be used outside the operating system. Features like Trusted Boot or in hardware persisted keys are not available.
\end{itemize}
Even the dedicated devices are small microcontrollers that run the TPM features in software which gives the manufacturer the possibility to update their TPMs in the field. 
FTPMs will be updated with the Microcode updates of the CPU manufacturers.

The combination of well constrained hardware and features, an interface for updates and well defined software interfaces make TPMs trustworthy and reliable.
Since TCG published the new standard in 2014 only six CVE-Entries handled vulnerabilities with TPMs\footnote{\url{https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=\%22Trusted+Platform+Module\%22}}.
Only two of them had impact on the implementation of a dedicated chip:
\begin{itemize}
	\item \emph{CVE-2017-15361}
\end{itemize}
\subsubsection{Using the TPM}
\label{sssec:tpm-usage}
On top of the cryptographic hardware, the TCG provides several software interfaces for application developers:
\begin{itemize}
	\item \emph{System API (SAPI).} The SAPI is a basic API where the developer has to handle the resources within the application. However this API provides the full set of features. 
	\item \emph{Enhanced System API (ESAPI).} While still providing a complete feature set, the ESAPI makes some resources transparent to the application like session handling. Consequently, this API layer is built on top of the SAPI.
	\item \emph{Feature API (FAPI).} This API layer is again built on top of the ESAPI. It provides a simple to use API but the feature set is also reduced to common use cases.
		Although the Interface was formally published from the beginning, an implementation is available since end of 2019.
\end{itemize}

The reference implementation of these APIs is published at Github\cite{tpmsoftware20} and is still under development.
At the point of writing stable interfaces are available for C and C++, but other languages like Rust, Java, C\# and others will be served in the future.
The repository additionally provides the tpm2-tools toolset which provides the FAPI features to the command line.
Unfortunately, the command line parameters changed several times during the major releases of tpm2-tools\cite{pornkitprasan19-tpmtools}.



\subsubsection{The Hardware}
\label{sssec:tpm-hardware}
The TCG achieved with the previous mentioned software layers independence of the underlying hardware.
Hence, TCG provided different flavors of of the TPM


TCG defined with the TPM2.0 standard a highly constrained hardware with a small feature set.
It is a passive device with some volatile and non-volatile memory, which provides hardware acceleration for a small number of crypto algorithms.
The standard allows to add some extra functionality to the device.
However the TPMs used in this project provided just the minimal set of algorithms and also the minimal amount of memory.


Since TCG published its documents, several IT security teams investigated concept and implementations of TPMs.



\begin{itemize}
	\item security problems with some implementations
\end{itemize}
\begin{itemize}
	\item Hierarchies
	\item Endorsement Key
	\item Attestation Identity Key
	\item Key management
\end{itemize}

\begin{figure}
	\centering
	\includegraphics[width=0.7\textwidth]{../resources/tpmcert}
	\caption[TPM Certification]{The manufacturer certifies every TPM it produces}
	\label{fig:tboot-overview}
\end{figure}


\begin{figure}
	\centering
	\includegraphics[width=0.7\textwidth]{../resources/tpmattest}
	\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}

\section{Trusted Boot}

\section{Integrity Measurements}
As described in the previous section, when the boot process is eventually finished, the OS is then responsible for extending the chain of trust.
Given a valid trusted boot procedure, the binary representation of the kernel is already measured.
Therefore the Kernel itself has the responsibility to keep track of everything happening on the platform from the OS point of view.

Soon after the first TPM standard was published, the \emph{Integrity Measurement Architecture} (IMA) for the Linux Kernel was introduced.
Since Kernel 3.7 it is possible to use all IMA features, when the compiler options of the Kernel are set correspondingly.

IMA 


Extend the Chain of Trust beyond the boot process.
The Kernel can measure many different types of Resources.
What is a useful set of measurements

\section{Verify Trust with DAA}

\subsection{Definitions}
For the definition of the algorithm, some notations and definitions are summarized in the following.
Greek letters denote a secret that is not known to the verifier whereas all other variable can be used to verify the desired properties.
The symbol $||$ is a concatenation of binary strings or binary representations of integers.

Given an integer $q$, $\mathbb{Z}_q$ denotes the ring of integers modulo $q$ and $\mathbb{Z}_q^*$ denotes the multiplicative group modulo $q$\cite{camenisch97}.

\subsection{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 $x$ 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.

\subsection{Signatures of Knowledge}
Camenisch and Stadler\cite{camenisch97} describe an efficient scheme for proving knowledge of a secret without providing it.
They assume a collision resistant hash function $\mathcal{H}:\{0,1\}^*\rightarrow\{0,1\}^k$ for signature creation.
Furthermore, the algorithm is based on the Schnorr signature scheme\cite{schnorr91}.
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 
		\begin{equation*}
			c:=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^r) \quad\text{and}\quad s:=r-c\alpha \quad\text{(mod n) .}
		\end{equation*} 

	\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}
Camenisch and Stadler\cite{camenisch97} state, that this scheme is extensible to proof knowledge of arbitrary number of secrets. 
Furthermore, complex relations between secret and public values can be represented with that scheme.

\subsection{Bilinear Maps}
The Camenisch-Lysyanskaya (CL) Signature Scheme\cite{camenisch04} is used for the DAA-Protocol.
Furthermore, the CL-Scheme itself is based on Bilinear Maps.

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

\subsection{Camenisch-Lysyanskaya Signature Scheme}
The Camenisch-Lysyanskaya (CL) Signature Scheme…\cite{camenisch04} allows efficient proofs for signature posession and is the basis for the DAA scheme discussed in section XY. %TODO reference to DAA section
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 \neq 1_{\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 proven wrong here.

\subsection{DAA History}
Direct Anonymous Attestation (DAA) is a cryptographic protocol, which aims to provide evidence that a device is a honest member of a group without providing any identification information.
Brickell, Camenisch and Chen\cite{BriCamChe04} introduce DAA and implement the protocol for the TPM 1.2 standard.
However it supports only RSA and has limitations in verifying attestation signatures.
Hence, DAA is not used with the TPM 1.2 standard.

Since the DAA protocol is quite complex, it is difficult to provide a sound security model for DAA and formally proof the security properties of it.
Chen, Morissey and Smart\cite{chen09} add linkability to the protocol.
Their approach for a formal proof is not correct, since a trivial key can be used for pass verification\cite{camenisch16}


%TODO Chronic of DAA until Camenisch16, Discussion about broken Proofs in previous papers.

Camenisch, Drijvers and Lehmann\cite{camenisch16} developed a DAA scheme for the new TPM 2.0 standard.
It supports linkability and the proofs for security and correctness still hold.
Furthermore, RSA and ECC cryptography is supported which makes it practicable for a wider variety of use cases.
However, Camenisch et.\,al.\cite{camenisch17} proposed a fix in the TPM 2.0 API to guarantee all requirements necessary for DAA.
Xaptum implemented this DAA-variant including the fixes in the TPM API.
The implementation will be discussed in Chapter 4.%TODO Reference to Xaptum discussion

Analyzing the security and integrity of this scheme would exceed the scope of this thesis.
Hence this thesis describes the DAA protocol and assumes the correctness and integrity.

\subsection{DAA Protocol}
\label{ssec:daa-protocol}
DAA is a group signature protocol, which aims to reveal no additional information about the signing host.
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.
	\item \emph{Host} \host. The Host creates a platform with the corresponding TPM \tpm\. Membership of groups are maintained by the TPM.
	\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.
\texttt{bsn} and \texttt{nym} %TODO
Session ids $sid$ is already available with communication session on the network or on the link between host and TPM. %TODO check that
$\mathcal{L}$ is the list of registered group members which is maintained by \issuer. %TODO
%TODO describe \tau
\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 Choose $r\sassign\mathbb{Z}_q$ and compute $a\leftarrow g_1^r$, $b\leftarrow a^y$, $c\leftarrow a^x\cdot Q^{rxy}$, $d\leftarrow Q^{ry}$.
					\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\neq 1$, $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 Compute $b'\leftarrow b^r, d'\leftarrow d^r$.
					\item If $\bsn = \bot$ set $\nym\leftarrow\bot$ and compute \\$\pi \sassign SPK\{(gsk):d'=b'^{gsk}\}(m, \bsn)$
					\item If $\bsn \neq \bot$ set $\nym\leftarrow H_1(\bsn)^{gsk}$ and compute $\pi \sassign SPK\{(gsk):\nym=H_1(\bsn)^{gsk}\wedge d'=b'^{gsk}\}(m, \bsn)$.
					\item Send $(\pi,\nym)$ to \host[j].
				\end{itemize}
			\item \host[j] assembles the signature $\sigma \leftarrow (a', b', c', d', \pi, \nym)$ and outputs \textsf{SIGNATURE}$(\sigma)$
		\end{enumerate}
	\item \emph{Verify.}
		Given a signed message, everyone can check whether the signature with respect to \bsn\ is valid and the signer is member of this group.
		Furthermore a revocation list \RL\ holds the private keys of corrupted TPMs, whose signatures are no longer accepted.
		\begin{enumerate}
			\item \verifier\ upon input \textsf{VERIFY}$(m, \bsn, \sigma)$
				\begin{itemize}
					\item parses $\sigma\leftarrow(a,b,c,d,\pi,\nym)$,
					\item verifies $\pi$ with respect to $(m,\bsn)$ and \nym if $\bsn\neq\bot$.
					\item checks, that $a\neq 1$, $b\neq 1$ $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\leftarrow 1$ if all test pass, otherwise $f\leftarrow 0$, 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\leftarrow 1$, otherwise $f\leftarrow 0$.
					\item Output \textsf{LINK}$(f)$
				\end{itemize}
		\end{enumerate}
\end{itemize}

%TODO: Discussion: sid removed, RL only works with private keys, etc.