They appear as PCs, notebooks, cellular phones or embedded devices.
Especially the footprint of embedded computers became so small that they can be used in almost all electrical devices.
@ -130,40 +133,16 @@ Since the Digidow protocols are not yet finalized, some assumptions are defined
This includes USB wire tapping or debug interfaces within the system revealing sensitive information.
\end{itemize}
\section{Description of structure}
In \autoref{cha:relatedwork} we will outline a variety of projects which do not contribute to this thesis.
There is, however, scientific work that is used as scientific background to this thesis as described in \autoref{cha:background}.
This includes especially the theoretical foundations of the network protocol.
\section{Organization}
In the next chapter, we will indroduce and discuss existing contributions in the targeted scientific area.
This includes especially the theoretical foundations of the network protocol which is part of our contribution.
Together with that, we will introduce our theoretical solution for the previously stated problems in \autoref{cha:concept}.
Chapter~\ref{cha:implementation} introduces then a working implementation with all necessary parts for a working prototype.
\autoref{cha:implementation} introduces then a working implementation with all necessary parts for provisioning the environment and the used hosts accordingly.
Finally we will present the results and limitations in \autoref{cha:conclusion} and give an overview of future work.
\chapter{Related Work}\label{cha:relatedwork}
There exist already a variety projects and implementations which touch the field of trusted computing.
We will introduce some of these projects and discuss why these do not meet the purpose of this thesis.
Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud computing.
They show in their paper how a TPM of a hypervisor can be virtualized and used by the guest operating system.
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with existing tools for fleet management and scalability.
The concept of a well known virtual environment does, however, not apply to our contribution.
Furthermore, the system should be self contained as good as possible and it should be possible to get information about the system via anonymous attestation.
%TODO what about the integrity measurements of keylime?
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO website\cite{fido18}
%TODO Is it noteworthy, that Xaptum claims to be compatible with FIDO ECDAA for TPM2?
\begin{itemize}
\item What exists in the field?
\item Keylime -- DONE
\item Xaptum ECDAA -- part of concept
\item FIDO 2 ECDAA -- noteworthy in background?
\item Strongswan Attestation --
\item Linux IMA -- mentioned in Background
\item Secure Boot -- in difference to trusted boot
@ -17,15 +17,15 @@ The hardware itself is strongly defined by the standard and comes in the followi
\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.
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.
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.
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.
@ -39,23 +39,22 @@ The last two entries describe vulnerabilities in dedicated TPM chips, which are
\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 when using one core of an Intel Xeon E5-2650 v3 CPU.
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 when using one core of an Intel Xeon E5-2650 v3 CPU.
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.
\item\emph{CVE-2019-16863}: This vulnerability is also known as "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.
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.
@ -88,8 +87,8 @@ Will Arthur et al.\cite{arthur15} provide a more detailed description on how the
\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 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}
@ -217,6 +216,26 @@ The user can check the resulting values in the written PCR registers against kno
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.
\subsection{Secure Boot}%
\label{sub:secure_boot}
Secure boot is another technology to prevent malware from being executed before the OS kernel is loaded.
Microsoft describe on their Documentation for Windows and UEFI what requirements are needed and how the secure boot process looks like\cite{microsoft14}.
It is part of the UEFI specification and uses, similar to trusted boot, checksums of firmware, option roms and the boot loader.
These checksums are checked against a signature database, which is held within the platform's NVRAM.
The signatures are created with the platform key (PK) which is by default owned and managed by Microsoft.
Although it is possible to install a new own PK and sign relevant software with it, you can only boot software signed from Microsoft by default when secure boot is enabled.
Shim is the gatekeeper for OSes not maintained by Microsoft.
The binary is signed with the official PK and uses itself a self signed CA to sign further executables.
A detailed description how shim works on Ubuntu is shown on their corresponding Wiki page\cite{ubuntuwiki20}.
Only this workflow enables secure boot when using Linux OSes.
Secure boot uses instead of the TPM conventional NVRAM to store private parts of its signing keys.Although there exists a signature chain for any software involved in Microsoft's boot process, using alternative OSes breaks the signature chain.
When using an own PK, you loose the benefit of having externally created and signed hash values for checking during booting.
Secure and trusted boot can, however, exist side by side on one system.
The benefit of using it seems to be very limited when not using a Microsoft OS.
\section{Integrity Measurement Architecture}%
\label{sec:integrity_measurement_architecture}
@ -300,15 +319,20 @@ There exist three template policies which can be used concurrently:
\item\texttt{tcb}: All files owned by root will be measured when accessed for read.
\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.
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)
\subsection{Other System Integrity Approaches}%
\label{sub:other_system_integrity_approaches}
Schear et al.\,\cite{keylime16} developed a full featured trusted computing environment for cloud computing.
They show in their paper how a TPM of a hypervisor can be virtualized and used by the guest operating system.
This includes trusted bootstrapping, integrity monitoring, virtualization, compatibility with existing tools for fleet management and scalability.
The concept of a well known virtual environment does, however, not apply to our use case.
Instead, the system should be self contained as good as possible and it should be possible to get information about the system via anonymous attestation.
\section{Direct Anonymous Attestation}%
\label{sec:direct_anonymous_attestation}
@ -325,173 +349,173 @@ This section describes the concept by Camenisch et al.~\cite{camenisch16} includ
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
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
\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$.
He computes the value
\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$.
He computes the value
\begin{equation*}
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\,\text{.}
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
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{}.
\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.
\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}
\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.
\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}
\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 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\neq1$, $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}
\begin{itemize}
\item verifies that $a\neq1$, $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.
\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}
\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}
\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}
\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'$:
@ -501,13 +525,22 @@ Unlike the description in the original paper, we describe the practical approach
\item If $\nym=\nym'$, set $f\leftarrow1$, otherwise $f\leftarrow0$.
\item Output \textsf{LINK}$(f)$.
\end{itemize}
\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}
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}
%TODO Überleitung zum nächsten Kapitel und FIDO einbauen
\subsection{Standardization of DAA}%
\label{sub:standardization_of_daa}
The \emph{Fast IDentity Online} Alliance (FIDO) is an organization which standardizes online authentication algorithms.
When the first generation of TPMs were available, the consortium defined a standard for Direct Anonymous Attestation with Elliptic Curve cryptography (ECDAA).
When the newer standard, TPM 2.0, was published, FIDO decided to update their algorithm to be compatible with recent developments.
This standard is still in development; a draft version from February 2018 is published on the FIDO website\cite{fido18}
This standard implements a close variant of the previously described concept.
