masterthesis/thesis/02_background.tex

\chapter{Background}%
\label{cha:background}

In this chapter we describe four main concepts which will be combined in the concept of this thesis.
The TPM standard is used to introduce trust into the used host platforms.
\emph{Trusted Boot} and the \emph{Integrity Measurement Architecture} (IMA) are two approaches to
extend trust from the TPM over the UEFI\,/\,BIOS up to the OS.
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).

\section{Trusted Platform Module (TPM)}%
\label{sec:trusted_platform_module_tpm_}

The \emph{Trusted Platform Module} (TPM) is a small coprocessor that introduces a variety of cryptographic features to the platform.
This module is part of a standard developed by the Trusted Computing Group (TCG), which released
the current revision 2.0  in 2014\cite{tcg20}.

The hardware itself is strongly defined by the standard and comes in the following flavors:
\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 to switch to another TPM.
	\item \emph{Mounted device.} The dedicated chip is directly mounted on the target mainboard.
    Therefore, removing or changing the TPM is imossible.
    All recent Intel and AMD platforms supporting TPM2.0 are able to manage a TPM within the BIOS,
    even as mounted device.
	\item \emph{Firmware TPM (fTPM).} This variant was introduced with the TPM2.0 Revision.
    Instead of using a dedicated Coprocessor for the TPM features, this variant lives as firmware
    extension within Intel's Management Engine or AMD's Platform Security Processor.
		Both Intel and AMD provide this extension for their platforms for several years now.
		When activating this feature on BIOS level, the user gets the same behavior as when using a
		mounted device.
	\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 OS.
  Features like Trusted Boot or in hardware persisted keys are not available.
\end{itemize}
Dedicated and mounted devices are small microcontrollers that run the TPM features in software
giving the manufacturer the possibility to update their TPMs in the field.
fTPMs will be updated with the platform 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.
When looking up the term \emph{TPM} in the Common Vulnerabilities and Exposures database, it
returns 23 entries\cite{mitre18}.
Eight of them were filed before the new standard has been released.
Another seven entries refer to vulnerabilities in custom TPM implementations.
Six entries refer to the interaction between the TPM and the operating system, especially the TPM
library and the shutdown/boot process.
The last two entries describe vulnerabilities in dedicated TPM chips, which are mentioned in further detail:
\begin{itemize}
	\item \emph{CVE-2017-15361}: TPMs from Infineon used a weak algorithm for finding primes during the RSA key generation process.
		This weakness made brute force attacks against keys of up to 2048 bits length feasible.
	  According to Nemec et al.\cite{Nemec17}, 1024 bit keys required in the worst case scenario 3
	  CPU months and 2048 bit keys needed 100 CPU years.
		Infineon was able to fix that vulnerability per firmware update for all affected TPMs.
	\item \emph{CVE-2019-16863}: This vulnerability is also known as "\emph{TPM fail}"
	\cite{moghimi20-tpmfail} and shows how to get an elliptic curve private key via timing and
	lattice attacks.
		The authors found TPMs from STMicroelectronics vulnerable, as well as Intel's fTPM
		implementation.
		Infineon TPM show also some non-expected behaviour, but this could not be used for data exfiltration.
		STM provided an update like Infineon did for their TPMs.
		Intel's fTPM required a platform firmware update to solve the issue.
\end{itemize}


\subsection{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 only since end of 2019.
\end{itemize}

The reference implementation of these APIs is published on Github\cite{tpmsoftware20} and is still
under development.
The repositories are maintained by members of TCG.
At the point of writing stable interfaces are available for C and C++, but other languages like
Rust, Java, C\# 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}.

\subsection{The Hardware}
\label{sssec:tpm-hardware}
With the previous mentioned software layers the TCG achieved independence of the underlying
hardware.
Hence, these layout made the different flavors of TPMs possible

With the TPM2.0 standard, TCG defined 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 provide just the minimal set of algorithms and also the
minimal amount of memory.

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

\subsection{TPM Key Hierarchies}%
\label{sub:tpm_key_hierarchies}

A TPM comes with four different key hierarchies.
These hierarchies fulfill different tasks and are used in different use cases on the whole platform.
Will Arthur et al.\cite{arthur15} provide a more detailed description on how the hierarchies work
together.
\begin{itemize}
	\item \emph{Platform Hierarchy}: This hierarchy is managed by the platform manufacturer. The firmware of the platform is interacting with this hierarchy during the boot process.
	\item \emph{Storage Hierarchy}: The storage of a platform is controlled by either an IT
	department or the end user and so is the storage hierarchy of the TPM.
	It offers non-privacy related features to the platform although the user may disable the TPM for her own use.
  \item \emph{Endorsement Hierarchy}: This is the privacy-related hierarchy which will also provide required functionality to this project.
		It is controlled by the user of the platform and provides the keys for attestation and group membership.
	\item \emph{NULL Hierarchy}: The NULL hierarchy is the only non-persistent hierarchy when
	rebooting the platform. It provides many features of the other hierarchies for testing purposes.
\end{itemize}

Each of the persistent hiearchies represent its own tree of keys, beginning with a root key.
Since TPM2.0 was published, these root keys are not hard coded anymore and can be changed if
necessary.
The process of key generation described below is similar to all three persistent hierarchies.

\subsection{Endorsement Key}%
\label{sub:endorsement_key}
The \emph{Endorsement Key} (EK) is the root key for the corresponding hierarchy.
\begin{figure}
	\centering
	\includegraphics[width=0.7\textwidth]{../resources/tpmcert}
	\caption[TPM Certification]{The manufacturer certifies every TPM it produces}
	\label{fig:ek-key-generation}
\end{figure}
\autoref{fig:ek-key-generation} illustrates the certificate chain of building a new EK.
Every TPM has, instead of the full EK, a unique key seed to derive root keys from.
This key seed comes with a corresponding certificate.
This TPM certificate is signed by the TPM manufacturer by using its own root \emph{Certificate
Authority} (CA).
When the platform user wants to create a new EK, a \emph{Key Derivation Function} (KDF) generates this new EK such that the TPM certificate identifies it and the chain keeps intact.
Since the platform supports root key generation, it is also possible to encrypt the key and store it on an external storage, e.g. on the platform disk.
Consequently it is quite easy to have different EKs at once to address privacy features also
between different functions of the endorsement hierarchy.

\section{Trusted Boot}%
\label{sec:trusted_boot}

A boot process of modern platforms consists of several steps until the OS is 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.
There exists no source of trust and hence no check for integrity or intended execution in this
common boot procedure.

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

The \emph{Trusted Computing Group} (TCG) introduced their first standard for a new {Trusted
Computing Module} (TPM) in 2004.
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).
In this context, \emph{Measuring} means a simple cryptographic extension function:
\begin{equation}
	\text{new\_PCR} = hash(\text{old\_PCR}\,||\,\text{data}).
	\label{form:PCR-measurement}
\end{equation}
The function "$||$" represents a concatenation of two binary strings and the hash function is
either SHA1 or SHA256.
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 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 changes.
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 TPM1.2.
For TPM2.0, the process was only extended with the support with the newer SHA256 algorithm.

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 still be 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 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 with 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 for expected behavior.
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 mainboard manufacturer 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 must measure all platform initialization code like embedded drivers, host platform firmware,
etc.\@ as they are provided as part of the mainboard.
If these measurements cannot be performed, the chain of trust is broken and consequently the
platform cannot be trusted.
When PCR~0 is zeroed or filled with the hashed representation of a string of zeroes, the SRTM did
not act as expected.
This indicates a broken chain of trust and should only appear when using the TPM simulator.

\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 kernel
of either a bootloader or the OS when booting without any bootloaders.
In any case, these binaries are stored in the \emph{Master Boot Record} (MBR) 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/OS takes control.

The bootloader has 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 do not provide
userland software required to manage IMA.
The IMA project page describes the required kernel features for full support in their
documentation\cite{ima-overview}.

The process of keeping track of system integrity becomes far more complex on the OS level compared
to the boot process.
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} to 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 lies 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 also writes 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 replaceable 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 manufacturer 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 in the Gentoo
Wiki\cite{gentoo19}.
It is, for example, useful to exclude constantly changing log files from being measured to reduce
useless entries in the measurement log.

\subsection{IMA Extensions}%
\label{ssub:ima_extensions}
Extended Verification Module (EVM)

\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 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 Camenisch et al. 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 also includes the impementation of DAA im the TPM1.2 standard.

This section describes the concept by 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 proves 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)\text{.}}
		\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\,\text{.}
		\end{equation*}
		The verification holds since
		\begin{equation*}
		g^sy^c = g^rg^{-c\alpha}g^{c\alpha} = g^r\,\text{.}
		\end{equation*}
	\end{enumerate}
	This scheme is extensible to prove knowledge of an arbitrary number of secrets as well as more complex relations between secret and public values.

	\subsubsection{Bilinear Maps}
	\label{ssec:bilinear-maps}
	Bilinear Maps 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 $g_1\in\mathbb{G}_1, g_2\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}
	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.
		\item \emph{Host} \host. The host creates a platform with the corresponding TPM \tpm{}.
		Membership of groups are maintained by the TPM.
		Only the key owner (TPM, passive) and the message author (Host, active) form a full group
		member.
		\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 \bsn{} is some clear text string, whereas \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 proof $\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,
				and
				\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 Upon receiving \textsf{JOIN} from \host[j], \issuer{} chooses a fresh nonce
			$n\leftarrow\{0,1\}^\tau$ and sends it back to \host[j].
			\item Upon receiving $n$ from \issuer, \host[j] 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 Upon input \textsf{JOINPROCEED}$(Q, \pi_1)$, \issuer{} 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 Upon receiving \textsf{APPEND}$(a,b,c,d,\pi_2)$, \host[j]
			\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)$, and
				\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 \bsn.
		\begin{enumerate}
			\item Upon input \textsf{SIGN}$(m,\bsn)$, \host[j] 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 Upon receiving $(m, \bsn, r)$, \tpm[i]
			\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.

      Upon input \textsf{VERIFY}$(m, \bsn, \sigma)$, \verifier{}
			\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}
		\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.

		On input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$, \verifier{} 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{itemize}

	Camenisch et al.~\cite{camenisch16} extend the general group concept scheme with their concept.
	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}: It does not matter in which order the linked signatures will be proven. The link algorithm will always output the same result.
	\end{itemize}