\ToDo{TPM beschreiben und chain of trust herleiten, }
In this Chapter we describe three main concepts which contribute the fundamentals for this thesis.
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.
\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.
@ -13,6 +14,9 @@ During these early steps, the hardware components of the platform are initialize
This is controlled by either the BIOS (for legacy platforms) or the UEFI firmware.
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.
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).
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).
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}
\emph{Measuring} means in this context a simple cryptographic extension function which works described in formula \ref{form:PCR-measurement}
@ -20,7 +24,7 @@ As part in this standard, TCG defined a procedure, where every step in the early
The function of || represents a concatenation of two binary strings and the hash function is either SHA1 or SHA256 hash.
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.
In recent TPM-platforms, both hashing algorithms can be performed for each measurement.
Consequently, both hash results are available for further computations.
Consequently, both hash results are available for further computations.
@ -32,33 +36,36 @@ The procedure of measurements is available since the first public standard of TP
For the recent TPM2.0 standard, the process was only extended with the support for the newer SHA256 standard.
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.
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, we want to detect this with a separate PCR value.
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.
The measured firmware BLOBs may be still the same.
So the TPM standard defines 24 PCRs for the PC platform.
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}.
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]
\begin{table}[ht]
\centering
\centering
\begin{sffamily}
\begin{sffamily}
\caption{Usage of PCRs during an UEFI trusted boot process}\label{tab:PCR}
\caption{Usage of PCRs during an UEFI trusted boot process}\label{tab:PCR}
0 & SRTM, BIOS, host platform extensions, embedded option ROMs and PI drivers \\
\midrule
1 & Host platform configuration\\
0 & SRTM, BIOS, host platform extensions, embedded option ROMs and PI drivers \\
2 & UEFI driver and application code \\
1 & Host platform configuration\\
3 & UEFI driver and application configuration and data \\
2 & UEFI driver and application code \\
4 & UEFI Boot Manager code and boot attempts \\
3 & UEFI driver and application configuration and data \\
5 & Boot Manager code configuration and data and GPT\,/\,partition table\\
4 & UEFI Boot Manager code and boot attempts \\
6 & Host platform manufacturer specific \\
5 & Boot Manager code configuration and data and GPT\,/\,partition table\\
7 & Secure Boot Policy \\
6 & Host platform manufacturer specific \\
8-15 & Defined for use by the static OS \\
7 & Secure Boot Policy \\
16 & Debug \\
8-15 & Defined for use by the static OS \\
17-23 & Application\\
16 & Debug \\
\bottomrule
17--23 & Application\\
\end{tabular}
\bottomrule
\end{tabular}
\end{small}
\end{sffamily}
\end{sffamily}
\end{table}
\end{table}
@ -66,6 +73,9 @@ When TCG introduced Trusted Boot in 2004, UEFI was not yet available for the ord
Consequently, TCG standardized the roles of every PCR only for the BIOS 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.
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.
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.
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.
This procedure is described in the TCG standard and the platform user has to \emph{trust} the manufacturer, that it is performed as expected.
@ -78,7 +88,10 @@ It furthermore must measure all platform initialization code like embedded drive
If these measurements cannot be performed, the chain of trust is broken and consequently the platform cannot be trusted.
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.
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.
The BIOS or UEFI performs then the next measurements until PCRs 1-7 are filled.
\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.
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.
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.
This guarantees that the chain of trust keeps intact when the bootloader takes control.
@ -87,7 +100,93 @@ The Bootloader has then to continue the chain of trust by measuring the Kernel a
The support and the way of how the measurements are done is not standardized.
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}.
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}.
\ToDo{Überleitung zu IMA und IMA beschreiben. Danach DAA theoretisch beschreiben, kopie aus dem Seminarpaper. Erwähnung, dass die PCR-Register nur bei neustart zurückgesetzt werden können}
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.
\subsubsection{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}.
\ToDo{Überleitung zu IMA und IMA beschreiben. Danach DAA theoretisch beschreiben, kopie aus dem Seminarpaper}
\chapter{Concept}
\chapter{Concept}
\label{cha:concept}
\label{cha:concept}
@ -135,24 +234,24 @@ Only the intended and trusted way of identification within the Digidow network s
To fulfill the Sensor's use case in an exposed environment, we need to consider the following attack vectors.
To fulfill the Sensor's use case in an exposed environment, we need to consider the following attack vectors.
\begin{itemize}
\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.
\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.
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.
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.
\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,
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.
\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.
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.
\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.
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.
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.
\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.
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.
\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.
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.
\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.
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 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.
\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.
Due to this error, a wrong identity and therefore false claims would be made out of that.
\end{itemize}
\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.
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.
@ -214,13 +313,13 @@ The hardware itself is strongly defined by the standard and comes in the followi
%TODO find source of that claim (TPM variants)
%TODO find source of that claim (TPM variants)
\begin{itemize}
\begin{itemize}
\item\emph{Dedicated device.} The TPM chip is mounted on a small board with a connector.
\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.
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.
\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.
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.
\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.
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.
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.
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.
\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}
\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.
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.
@ -239,7 +338,7 @@ On top of the cryptographic hardware, the TCG provides several software interfac
\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{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{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.
\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.
Although the Interface was formally published from the beginning, an implementation is available since end of 2019.
\end{itemize}
\end{itemize}
The reference implementation of these APIs is published at Github\cite{tpmsoftware20} and is still under development.
The reference implementation of these APIs is published at Github\cite{tpmsoftware20} and is still under development.
@ -324,7 +423,7 @@ Given a cyclic group $G = \langle g\rangle$ of order $n$, the discrete logarithm
if this $x$ exists.
if this $x$ exists.
For sufficiently large $n$ and properly chosen $G$ and $g$, it is infeasible to compute the reverse
For sufficiently large $n$ and properly chosen $G$ and $g$, it is infeasible to compute the reverse
\begin{math}
\begin{math}
\alpha = \log_g{y}
\alpha = \log_g{y}
\end{math}.
\end{math}.
This problem is known as \emph{Discrete Logarithm Problem} and is the basis for the following cryptographic algorithms.
This problem is known as \emph{Discrete Logarithm Problem} and is the basis for the following cryptographic algorithms.
@ -341,18 +440,18 @@ The one-way protocol consists of three procedures:
\begin{enumerate}
\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{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{Sign.} Choose a random number $r$ and create the signature tuple $(c,s)$ as
\item\emph{Verify.} The verifier knows the values of $y$ and $g$, as they are usually public. The message $m$ comes with the signature values $c$ and $s$. She computes the value
\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*}
\begin{equation*}
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\, .
c':=\mathcal{H}(m\,||\,y\,||\,g\,||\,g^sy^c)\quad\text{and verifies, that}\quad c' = c\, .
\end{equation*}
\end{equation*}
The verification holds since
The verification holds since
\begin{equation*}
\begin{equation*}
g^sy^c = g^rg^{-c\alpha}g^{c\alpha} = g^r\, .
g^sy^c = g^rg^{-c\alpha}g^{c\alpha} = g^r\, .
\end{equation*}
\end{equation*}
\end{enumerate}
\end{enumerate}
Camenisch and Stadler\cite{camenisch97} state, that this scheme is extensible to proof knowledge of arbitrary number of secrets.
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.
Furthermore, complex relations between secret and public values can be represented with that scheme.
@ -367,7 +466,7 @@ Let $e:\mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$ that satisfies
\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{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{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\\
\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$.
$(q, \mathbb{G}_1,\mathbb{G}_2,\mathbb{G}_T, e, g_1, g_2)$ and an efficient algorithm for computing $e$.
@ -419,92 +518,92 @@ $\mathcal{L}$ is the list of registered group members which is maintained by \is
%TODO describe \tau
%TODO describe \tau
\begin{itemize}
\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{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}
\begin{enumerate}
\item On input \textsf{SETUP}\issuer
\item On input \textsf{SETUP}\issuer
\begin{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 $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 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 registers the public key $(X,y,\pi)$ at $\mathcal{F}_{ca}$ and stores the secret key,
\item outputs \textsf{SETUPDONE}
\item outputs \textsf{SETUPDONE}
\end{itemize}
\end{itemize}
\end{enumerate}
\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}
\begin{enumerate}
\item On input \textsf{JOIN}, host \host[j] sends the message \textsf{JOIN} to \issuer.
\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\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\host[j] upon receiving $n$ from \issuer, forwards $n$ to \tpm[i]
\item\tpm[i] generates the secret key:
\item\tpm[i] generates the secret key:
\begin{itemize}
\begin{itemize}
\item Check, that no completed key record exists. Otherwise, it is already a member of that group.
\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 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 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].
\item Return $(Q,\pi_1)$ to \host[j].
\end{itemize}
\end{itemize}
\item\host[j] forwards \textsf{JOINPROCEED}$(Q, \pi_1)$ to \issuer.
\item\host[j] forwards \textsf{JOINPROCEED}$(Q, \pi_1)$ to \issuer.
\item\issuer\ upon input \textsf{JOINPROCEED}$(Q, \pi_1)$ creates the CL-credential:
\item\issuer\ upon input \textsf{JOINPROCEED}$(Q, \pi_1)$ creates the CL-credential:
\begin{itemize}
\begin{itemize}
\item Verify that $\pi_1$ is correct.
\item Verify that $\pi_1$ is correct.
\item Add \tpm[i] to $\mathcal{L}$. %TODO what is the representative of the TPM?
\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 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]
\item Send \textsf{APPEND}$(a,b,c,d,\pi_2)$ to \host[j]
\end{itemize}
\end{itemize}
\item\host[j] upon receiving \textsf{APPEND}$(a,b,c,d,\pi_2)$
\item\host[j] upon receiving \textsf{APPEND}$(a,b,c,d,\pi_2)$
\begin{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)$.
\item verifies, that $a\neq1$, $e(a,Y)=e(b,g_2)$ and $e(c,g_2)= e(a\cdot d, X)$.
\item forwards $(b,d,\pi_2)$ to \tpm[i].
\item forwards $(b,d,\pi_2)$ to \tpm[i].
\end{itemize}
\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\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}.
\item\host[j] stores $(a,b,c,d)$ and outputs \textsf{JOINED}.
\end{enumerate}
\end{enumerate}
\item\emph{Sign.}
\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}.
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}
\begin{enumerate}
\item\host[j] upon input \textsf{SIGN}$(m,\bsn)$ re-randomizes the CL-credential:
\item\host[j] upon input \textsf{SIGN}$(m,\bsn)$ re-randomizes the CL-credential:
\begin{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 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')$.
\item Send $(m, \bsn, r)$ to \tpm[i] and store $(a',b',c',d')$.
\end{itemize}
\end{itemize}
\item\tpm[i] upon receiving $(m, \bsn, r)$
\item\tpm[i] upon receiving $(m, \bsn, r)$
\begin{itemize}
\begin{itemize}
\item checks, that a complete join record $(gsk, (b,d))$ exists, and
\item checks, that a complete join record $(gsk, (b,d))$ exists, and
\item stores $(m, \bsn, r)$.
\item stores $(m, \bsn, r)$.
\end{itemize}
\end{itemize}
\item\tpm[i] completes the signature after it gets permission to do so. %TODO Why?
\item\tpm[i] completes the signature after it gets permission to do so. %TODO Why?
\begin{itemize}
\begin{itemize}
\item Retrieve group record $(gsk, (b,d))$ and message record $(m, \bsn, r)$.
\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 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 $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 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 sets $f\leftarrow1$ if all test pass, otherwise $f\leftarrow0$, and
\item outputs \textsf{VERIFIED}$(f)$.
\item outputs \textsf{VERIFIED}$(f)$.
\end{itemize}
\end{itemize}
\end{enumerate}
\end{enumerate}
\item\emph{Link.}
\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.
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}
\begin{enumerate}
\item\verifier\ on input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$ verifies the signatures and compares the pseudonyms contained in $\sigma, \sigma'$:
\item\verifier\ on input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$ verifies the signatures and compares the pseudonyms contained in $\sigma, \sigma'$:
\begin{itemize}
\begin{itemize}
\item Check, that $\bsn\neq\bot$ and that both signatures $\sigma, \sigma'$ are valid.
\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 Parse the signatures $\sigma\leftarrow(a,b,c,d,\pi,\nym)$, $\sigma'\leftarrow(a',b',c',d',\pi',\nym')$
\item If $\nym=\nym'$, set $f\leftarrow1$, otherwise $f\leftarrow0$.
\item If $\nym=\nym'$, set $f\leftarrow1$, otherwise $f\leftarrow0$.
\item Output \textsf{LINK}$(f)$
\item Output \textsf{LINK}$(f)$
\end{itemize}
\end{itemize}
\end{enumerate}
\end{enumerate}
\end{itemize}
\end{itemize}
%TODO: Discussion: sid removed, RL only works with private keys, etc.
%TODO: Discussion: sid removed, RL only works with private keys, etc.
