parsed feedback until page 28

thesis/01_introduction.tex

@@ -107,7 +107,8 @@ So we design a prototype based on the common x86 architecture and use the crypto
 \emph{Trusted Platform Modules} (TPM).
 A TPM is a passive crypto coprocessor available on many modern PC platforms which has an independent storage for crypto variables and provides functions to support above mentioned features.
 
-We define a solution for installing and booting a Linux Kernel with TPM-backed integrity measurements in place.
+We define a solution for installing and booting a Linux kernel with TPM-backed integrity
+measurements in place.
 We use an attached camera as example for a biometric sensor hardware to create the dataset to
 continue with the authentication process.
 This dataset will be combined with the integrity measurements of the system and a signature from

thesis/02_background.tex

@@ -216,48 +216,66 @@ Later, when UEFI became popular, the PCR descriptions got adopted for the new pl
 \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 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
-This procedure is described in the TCG standard and the platform user has to \emph{trust} the manufacturer, that it is performed as expected.
+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 manufacturer of the motherboards do not publish their firmware code, one may have to reverse engineer the firmware to prove correct implementation of the SRTM.
+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 is the first piece of software that is executed on the platform and measures itself into PCR~0.
-It furthermore must measure all platform initialization code like embedded drivers, host platform firmware, etc.\@ as they are provided as part of the PC motherboard.
+It must measure all platform initialization code like embedded drivers, host platform firmware,
-If these measurements cannot be performed, the chain of trust is broken and consequently the platform cannot be trusted.
+etc.\@ as they are provided as part of the mainboard.
-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.
+If these measurements cannot be performed, the chain of trust is broken and consequently the
-
+platform cannot be trusted.
-\subsection{Platform handover to OS}%
+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 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 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 takes control.
+This guarantees that the chain of trust keeps intact when the bootloader/OS takes control.
 
-The Bootloader has then to continue the chain of trust by measuring the Kernel and the corresponding command line parameters into the next PCRs.
+The 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}.
+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.
+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.
+Other OS providers may not use a kernel with the required compile flags and/or do not provide
-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}.
+userland software required to manage IMA.
-
+The IMA project page describes the required kernel features for full support in their
-The process of keeping track of system integrity becomes compared to the boot process far more complex on the OS level.
+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 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.
+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.
 
@@ -275,7 +293,7 @@ These settings will be discussed in more detail in the following.
 \subsection{Integrity Log}%
 \label{ssub:integrity_log}
 
-IMA uses the emph{integrity log} do keep track of any changes of local filesystem resources.
+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}.
 
@@ -289,17 +307,21 @@ Before a file is accessed by the kernel, IMA creates an integrity log entry as i
 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.
+Finally, the template hash is the single value of the whole computation that will be extended into
+the PCR.
 The integrity log holds at the end the filedata hash, the metadata and the template hash as well as the PCR index and the logfile format.
 
 IMA knows three different file formats, where two of them can be used in recent applications.
-The only difference between these formats lie in the used and logged metadata:
+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-ng} uses, besides the filedata hash, also the filedata hash length, the
+	pathname length and the pathname to create the template hash.
 	\item \texttt{ima-sig} uses the same sources as ima-ng.
-		When available, it writes also signatures of files into the log and includes them for calculating the template hash.
+		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 replaceyble with the \texttt{ima-ng} template.
+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}%
@@ -322,12 +344,19 @@ 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{appraise\_tcb}: All executables which are run, all files mapped in memory for
-	\item \texttt{secure\_boot}: All loaded modules, firmwares, executed Kernels and IMA policies are checked. Therefore these resources need to have a provable signature to pass the check. The corresponding public key must be provided by the system manufacturere within the provided firmware or as Machine Owner Key in shim.
+	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 at the Gentoo Wiki\footnote{\url{https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture/Recipes}}.
+Some example policies can be found in the Gentoo
-It is, for example, useful to exclude constantly changing log files from being measured to reduce useless in the measurement log.
+Wiki\footnote{\url{https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture/Recipes}}.
+It is, for example, useful to exclude constantly changing log files from being measured to reduce
+useless entries in the measurement log.
 
 \subsection{IMA Extensions}%
 \label{ssub:ima_extensions}
@@ -337,14 +366,18 @@ Extended Verification Module (EVM)
 \label{sec:direct_anonymous_attestation}
 \emph{Direct Anonymous Attestation} (DAA) is a cryptographic scheme which makes use of the functions provided by the TPM.
 DAA implements the concept of group signatures, where multiple secret keys can create a corresponding signature.
-These signatures can be verified with a single public key, when these private keys are member of the same group.
+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 the discussion in \cite{camenisch16} and \cite{camenisch17} almost all schemes were proven insecure, since many of them had bugs in the protocol or allowed trivial public\,/\,secret key pairs.
+According to Camenisch et al. in \cite{camenisch16} and \cite{camenisch17}, almost all schemes were
-This includes also the impementation of DAA im the TPM1.2 standard.
+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 of Camenisch et al.~\cite{camenisch16} including the cryptographic elements used for DAA.
+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}
@@ -365,7 +398,7 @@ Unlike the description in the original paper, we describe the practical approach
 
 	\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
+	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.
@@ -401,30 +434,39 @@ Unlike the description in the original paper, we describe the practical approach
 	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, g2\in\mathbb{G}_2: e(g_1,g_2)$ generates $\mathbb{G}_T$.
+		\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 proves for signature posession and is the basis for the DAA scheme discussed below.
+	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{Sign.} Given a message $m$ and the secret key $sk$, choose $a$ at random and output
-		\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)$.
+		the signature $\sigma\leftarrow(a, a^y, a^{x+xym}) = (a,b,c)$.
+		\item \emph{Verify.} Given message $m$, signature $\sigma$ and public key $pk$, verify that $a
+		\neq 1_{\mathbb{G}_1}$, $e(a,Y) = e(b,g_2)$ and $e(a,X)\cdot e(b,X)^m = e(c,g_2)$.
 	\end{itemize}
 	Camenisch et al.\@ stated in section 4.2 of their paper~\cite{camenisch16} that one has to verify the equation against $e(g_1,b)$ and $e(g_1,c)$ which is not correct.
 
 	\subsection{DAA Protocol on LRSW Assumption}
-	\label{ssec:daa-protocol-on-lrsw-assumption} %TODO extend security properties according to Camenisch
+	\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. This role equals the group manager of Bellare's generic definition.
+		\item \emph{Issuer} \issuer. The issuer maintains a group and has evidence of hosts that are
-		\item \emph{Host} \host. The Host creates a platform with the corresponding TPM \tpm{}. Membership of groups are maintained by the TPM.
+		members in this group.
-		Compared to Bellare et al., the role of a member is split into two cooperating parties, the key owner (TPM, passive) and the message author (Host, active).
+		\item \emph{Host} \host. The host creates a platform with the corresponding TPM \tpm{}.
-		\item \emph{Verifier} \verifier. A verifier can check, whether a Host with its TPM is in a group or not. Besides the group membership, no additional information is provided.
+		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}$.
@@ -432,30 +474,37 @@ Unlike the description in the original paper, we describe the practical approach
 	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{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
+			\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 $x,y \leftarrow \mathbb{Z}_q$ and sets $isk=(x,y)$ and
-				\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,
+				$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,
-				\item outputs \textsf{SETUPDONE}
+				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 \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 Upon receiving \textsf{JOIN} from \host[j], \issuer{} chooses a fresh nonce
-			\item \host[j] upon receiving $n$ from \issuer, forwards $n$ to \tpm[i].
+			$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 Check that no completed key record exists. Otherwise, it is already a member of that
+				group.
 				\item Choose $gsk\sassign\mathbb{Z}_q$ and store the key as $(gsk, \bot)$.
 				\item Set $Q \leftarrow g_1^{gsk}$ and compute $\pi_1 \sassign SPK\{(gsk):Q=g_1^{gsk}\}(n)$.
 				\item Return $(Q,\pi_1)$ to \host[j].
 			\end{itemize}
 			\item \host[j] forwards \textsf{JOINPROCEED}$(Q, \pi_1)$ to \issuer.
-			\item \issuer{} upon input \textsf{JOINPROCEED}$(Q, \pi_1)$ creates the CL-credential:
+			\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?
@@ -463,9 +512,9 @@ Unlike the description in the original paper, we describe the practical approach
 				\item Create the prove $\pi_2\sassign SPK\{(t):b=g_1^t\wedge d=Q^t\}$.
 				\item Send \textsf{APPEND}$(a,b,c,d,\pi_2)$ to \host[j]
 			\end{itemize}
-			\item \host[j] upon receiving \textsf{APPEND}$(a,b,c,d,\pi_2)$
+			\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)$.
+				\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].
@@ -474,13 +523,13 @@ Unlike the description in the original paper, we describe the practical approach
 		\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 \host[j] upon input \textsf{SIGN}$(m,\bsn)$ re-randomizes the CL credential:
+			\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 \tpm[i] upon receiving $(m, \bsn, r)$
+			\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)$.
@@ -499,35 +548,38 @@ Unlike the description in the original paper, we describe the practical approach
 		\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.
+			Furthermore, a revocation list \RL{} holds the private keys of corrupted TPMs, whose
-		\begin{enumerate}
+			signatures are no longer accepted.
-			\item \verifier{} upon input \textsf{VERIFY}$(m, \bsn, \sigma)$
+
+      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 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 $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 checks that for every $gsk_i \in \RL: b^{gsk_i} \neq d$,
 				\item sets $f\leftarrow 1$ if all test pass, otherwise $f\leftarrow 0$, and
 				\item outputs \textsf{VERIFIED}$(f)$.
 			\end{itemize}
-		\end{enumerate}
 		\item \emph{Link.}
-		After proving validity of the signature, the verifier can test, whether two different messages with the same basename $\bsn \neq\bot$ are generated from the same TPM.
+		After proving validity of the signature, the verifier can test, whether two different messages
-		\begin{enumerate}
+		with the same basename $\bsn \neq\bot$ are generated from the same TPM.
-			\item \verifier{} on input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$ verifies the signatures and compares the pseudonyms contained in $\sigma, \sigma'$:
+
-			\begin{itemize}
+		On input \textsf{LINK}$(\sigma, m, \sigma', m', bsn)$, \verifier{} verifies the signatures
-				\item Check, that $\bsn\neq\bot$ and that both signatures $\sigma, \sigma'$ are valid.
+		and compares the pseudonyms contained in $\sigma, \sigma'$:
-				\item Parse the signatures $\sigma\leftarrow(a,b,c,d,\pi,\nym)$, $\sigma'\leftarrow(a',b',c',d',\pi',\nym')$.
+		\begin{itemize}
-				\item If $\nym = \nym'$, set $f\leftarrow 1$, otherwise $f\leftarrow 0$.
+			\item Check that $\bsn\neq\bot$ and that both signatures $\sigma, \sigma'$ are valid.
-				\item Output \textsf{LINK}$(f)$.
+			\item Parse the signatures $\sigma\leftarrow(a,b,c,d,\pi,\nym)$,
-			\end{itemize}
+			$\sigma'\leftarrow(a',b',c',d',\pi',\nym')$.
-		\end{enumerate}
+			\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 with their concept the general group concept scheme.
+	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{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}

thesis/03_concept.tex

@@ -1,8 +1,9 @@
 \chapter{Concept}
 \label{cha:concept}
-In this chapter we define the constraints for the Biometric Sensor as well as a generic attempt for a prototype.
+In this chapter we define the constraints for the \emph{Biometric Sensor} (BS) as well as a generic
+attempt for a prototype.
 The constraints include a discussion about the attack vectors to the BS.
-We explain furthermore which requirements can and will be addressed and how sensitive data is
+We explain  which requirements can and will be addressed and how sensitive data is
 processed in the BS.
 
 \section{Definition of the Biometric Sensor}
@@ -11,17 +12,18 @@ The BS itself is defined as edge device within the Digidow network.
 According to the schema shown in \autoref{fig:globalview}, the BS will be placed in a public area
 (e.g. a checkpoint in an airport or as access control system at a building) to interact directly
 with the Digidow users.
-There, the BS is the gateway to the Digidow network.
+There, the BS acts as interface to the to the Digidow network.
 By providing a biometric property, the user should be able to authenticate itself and the network may then trigger the desired action, like granting access or logging presence.
 Depending on the biometric property, the sensor may not be active all the time, but activated when an authentication process is started.
 
 The following enumeration shows the steps of the BS for identifying the interacting person.
 \begin{enumerate}
 	\item \emph{Listen}: Either the sensor hardware itself (e.g. a detection in a fingerprint sensor) or another electrical signal will start the authentication process.
-	\item \emph{Collect}: Measure sensor data (picture, fingerprint) and calculate a biometric representation (Attribute).
+	\item \emph{Collect}: Measure sensor data (picture, fingerprint) and calculate a biometric
+	representation (attribute).
 	\item \emph{Discover}: Start a network discovery in the Digidow network and find the PIA
 	corresponding to the present person. It may be necessary to interact with more than one PIA
-	within this and the next step.
+	within this and the next steps.
 	\item \emph{Transmit}: Create a trusted and secure channel to the PIA and transmit the attribute.
 	\item \emph{Reset}: Set the state of the system as it was before this transaction.
 \end{enumerate}
@@ -38,39 +40,51 @@ In addition to autonomy, the BS should also ensure proper handling of received a
 The recorded dataset from a sensor is \emph{sensitive data} due to its ability to identify an individual.
 Due to its narrow definition, it is affordable to protect sensitive data.
 Besides that, \emph{metadata} is information generated during the whole transaction phase.
-Timestamps and host information are metadata as well as connection lists, hash sums and log entries and much more (What? Where? When?)
+Timestamps and host information are metadata as well as connection lists, hashes and log entries
+and much more (What? Where? When?)
 There exists no exact definition or list of metadata which makes it hard to prevent any exposure of it.
 Metadata does not directly identify an individual.
-However huge notwork providers are able to combine lots of metadata to traces of individuals.
+However huge network providers are able to combine lots of metadata to traces of individuals.
 Eventually an action of those traced individuals might unveil their identity.
 Consequently, a central goal of Digidow is to minimize the amount to minimize the risk of traces.
 
 Privacy defines the ability of individuals to keep information about themselves private from others.
-In context to the Biometric Sensor, this is related to the recorded biometric data.
+In the context of the BS, this is related to the recorded biometric data.
-Furthermore, to prevent tracking. any interaction with a Sensor should not be matched to personal information.
+Furthermore, to prevent tracking, any interaction with a sensor should not be matched to personal
+information.
 Only the intended and trusted way of identification within the Digidow network should be possible.
 
 \subsection{Threat Model}
 \label{ssec:threatmodel}
 
-To fulfill the Sensor's use case, we need to consider the following attack vectors.
+To fulfill the sensor's use case, we need to consider the following attack vectors:
 \begin{itemize}
-	\item \emph{Rogue Hardware Components}: Modified components of the Biometric Sensor could, depending on their contribution to the system, collect data or create a gateway to the internal processes of the system.
+	\item \emph{Rogue Hardware Components}: Modified components of the BS could, depending on their
+	contribution to the system, collect data or create a gateway to the internal processes of the
+	system.
 		Although the produced hardware piece itself is fine, the firmware on it is acting in a malicious way.
 		This threat addresses the manufacturing and installation of the system.
 	\item \emph{Hardware Modification}: Similar to rogue hardware components, the system could be modified in the target environment by attaching additional hardware.
-		With this attack, adversaries may get direct access to memory or to data transferred from or to attached devices,
+		With this attack, adversaries may get direct access to memory or to data transferred from or to
+		attached devices.
 	\item \emph{Metadata Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
-		It is possible to log the protocol of those attached devices via Man in the Middle attack on the USB cable.
+		It is possible to log the protocol of those attached devices via Man-in-the-Middle attack on
-	\item \emph{Attribute Extraction}: The actual sensor like camera or fingerprint sensor is usually attached via USB or similar cable connection.
+		the USB cable.
+	\item \emph{Attribute Extraction}: The actual sensor, like camera or fingerprint sensor, is
+	usually attached via USB or a similar cable connection.
 		It is possible to log the protocol of those attached devices via wiretapping the USB cable.
 		With that attack, an adversary is able to directly access the attributes to identify individuals.
-	\item \emph{Modification or aggregation of sensitive data within Biometric Sensor}: The program which prepares the sernsor data for transmission could modify the data before sealing it.
+	\item \emph{Modification or aggregation of sensitive data within BS}: The program which prepares
+	the sernsor data for transmission could modify the data before sealing it.
 		The program can also just save the sensitive 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
-		An adversary could use this datasets to generate tracking logs and eventually match these logs to individuals.
+	Digidow network, there will be some metadata generated.
-	\item \emph{Retransmission of sensor data of a rogue Biometric Sensor}: When retransmitting sensor data, the authentication of an individual could again be proven.
+		An adversary could use these datasets to generate tracking logs and eventually match these logs
-		Any grants provided to this individual could then given to another person.
+		to individuals.
+	\item \emph{Replay of sensor data of a rogue BS}: When retransmitting sensor data, the
+	authentication of an individual could again be proven.
+		Any grants provided to the successfully identified individual could then be given to another
+		person.
 	\item \emph{Rogue Biometric Sensor blocks transmission}: By blocking any transmission of sensor data, any transaction within the Digidow network could be blocked and therefore the whole authentication process is stopped.
 	\item \emph{Rogue Personal Identity Agent}: A rogue PIA might receive the sensor data instead of the honest one.
 		Due to this error, a wrong identity and therefore false claims would be made out of that.
@@ -106,8 +120,9 @@ With these PCR values we can seal a passphrase in the TPM.
 The disk, secured with Full Disk Encryption (FDE), can only be accessed, when the hardware underneath is not tampered with.
 
 To further reduce the attack surface, the prototype will not use a bootloader like GRUB.
-Instead, the Kernel should be run directly from the UEFI\,/\,BIOS.
+Instead, the kernel should be run directly from the UEFI\,/\,BIOS.
-Therefore, the Kernel is packed directly into an EFI file, together with its command line parameters and the initial file system for booting.
+Therefore, the kernel is packed directly into an EFI file, together with its command line
+parameters and the initial file system for booting.
 This \emph{Unified Kernel} is directly measured by the UEFI\,/\,BIOS and is also capable of decrypting the disk, given the correct PCR values.
 
 This setup starts with two sources of trust that are formally defined:
@@ -122,7 +137,8 @@ We implicitly assume that the CPU, executing all these instructions and interact
 
 All parts contributing to the boot phase will be measured into one of the PCRs before any instruction is executed.
 Decrypting the disk can then be interpreted as authorization procedure against the encrypted disk.
-Consequently only a \emph{known} Kernel with a \emph{known} hardware and firmware setup underneath can access the disk and finish the boot process in the OS.
+Consequently only a \emph{known} kernel with a \emph{known} hardware and firmware setup underneath
+can access the disk and finish the boot process in the OS.
 
 The disk encryption is, however, only an optional feature which can be omitted in a production
 environment when there is no sensitive data on the disk that must not be revealed to the public.
@@ -131,7 +147,7 @@ The system needs to check its integrity on the OS level and summarize that by pu
 \begin{figure}
 	\centering
 	\includegraphics[width=0.8\linewidth]{../resources/measurements.pdf}
-	\caption{Extending trust from the Roots of Trust up to the Kernel}%
+	\caption{Extending trust from the Roots of Trust up to the kernel}%
 	\label{fig:measuements}
 \end{figure}
 
@@ -205,8 +221,9 @@ There exists, however no such exact definition for hardware and firmware parts o
 Consequently, these parts should undergo a functional analysis before they are trusted.
 Trust means that, when the platform is defined trustworthy, the corresponding PCR values should be published.
 
-The same procedure should be done for the Kernel and the used OS environment and of course the used software.
+The same procedure should be done for the kernel and the used OS environment and of course the used
-There, only the Kernel with its parameters have a corresponding PCR value.
+software.
+There, only the kernel with its parameters have a corresponding PCR value.
 Furthermore a hash value should be published for any relevant file on the file system.
 
 We can then build a cryptographic representation of the chain of trust in \autoref{fig:chainoftrust}.

thesis/04_implementation.tex

@@ -16,7 +16,7 @@ To keep the setup minimal, the IP addresses are static and Internet is only requ
 Hence, Service Discovery is done statically, every host knows the IP addresses and functions of each other directly.
 
 \section{Hardware Setup}
-For demonstrating remote attestation via DAA over a simple network infrastructure, we use 3 systems with similar configuration. 
+For demonstrating remote attestation via DAA over a simple network infrastructure, we use 3 systems with similar configuration.
 \autoref{tab:systems} show the specification of these systems.
 We decided to order one system with an AMD processor in it to find differences in handling the TPM between Intel and AMD systems.
 All features used in this thesis were available on both platform types, so there were no differences found.
@@ -48,11 +48,13 @@ With a wiring adapter any TPM board would work on any mainboard supporting TPM2.
 
 \section{Operating System}
 The Operating System need to fulfill three requirements for this prototype.
-First, the TPM must be supported by the Kernel.
+First, the TPM must be supported by the kernel.
 Second, the OS has to support a recent version of the TPM Software Stack (TSS 3.0.x or newer at the point of writing) for using the Xaptum ECDAA\footnote{\url{https://github.com/xaptum/ecdaa}} project with enabled hardware TPM.
 Similarly, the \texttt{tpm2-tools} must be available in a version newer than \texttt{4.0.0}.
-Finally, the support for the Integrity Measurement Architecture (IMA) must be activated in the Kernel and supported by the OS. 
+Finally, the support for the Integrity Measurement Architecture (IMA) must be activated in the
-This feature is available in the mainline Linux Kernel, however, the according Kernel compile parameters must be set.
+kernel and supported by the OS.
+This feature is available in the mainline Linux kernel, however, the according kernel compile
+parameters must be set.
 
 Ubuntu 20.04 LTS does fulfill above mentioned requirements by default.
 Ubuntu is also supported by the Xaptum ECDAA project, although it was tested with an older version (18.04).
@@ -71,7 +73,7 @@ Ubuntu installs Grub by default, and it is used as a fallback bootloader.
 		\texttt{ubuntu--vg-ubuntu--lv}	&118G	&\texttt{/}	&root partition on lvm\\
 		\bottomrule
 	\end{tabular}
-	\caption{Disk layout of the BS prototype} 
+	\caption{Disk layout of the BS prototype}
 	\label{tab:disklayout}
 \end{table}
 
@@ -88,15 +90,16 @@ By default, every Mainboard with support for TPM2.0 must support Trusted Boot.
 When a TPM becomes available, the BIOS itself takes all required measures until the boot process is handed over to the OS bootloader (e.g. Grub).
 Since Ubuntu uses Grub 2.04 as bootloader, Trusted Boot is directly supported and needs just to be enabled in the configuration.
 In this case, Grub will be measured from the BIOS to the PCRs 4 and 5, as shown in \ref{tab:PCR}.
-Grub itself uses PCR 8 for executed commands, the Kernel command line and all commands forwarded to Kernel modules.
+Grub itself uses PCR 8 for executed commands, the kernel command line and all commands forwarded to
+kernel modules.
 PCR 9 is used to measure all files read by Grub\footnote{\url{https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html} (visited on 19.11.2020)}.
 
 Embedded systems like a productive version of the BS do not need several boot options.
-Therefore we replace the bootloader by loading the Kernel directly. 
+Therefore we replace the bootloader by loading the kernel directly.
-This Kernel decrypts the disk and boots the remaining system.
+This kernel decrypts the disk and boots the remaining system.
 Pawit Pornkitprasam \cite{pornkitprasan19-diskencryption}\cite{pornkitprasan19-tpmtools} and Karl O from Tevora \cite{tevora-secureboot} introduced the concept of a \emph{Unified Kernel} for Ubuntu and Arch respectively.
 
-We create a large EFI file which contains the initramfs, Kernel command line and the Kernel itself.
+We create a large EFI file which contains the initramfs, kernel command line and the kernel itself.
 This EFI file replaces that from Grub in the EFI boot partition.
 \autoref{code:tbcommandlinetxt} shows the used command line which will be saved on \texttt{/boot/kernel-command-line.txt}
 The parameters activate also IMA which is discussed later in this chapter.
@@ -110,25 +113,27 @@ The parameters activate also IMA which is discussed later in this chapter.
 			\texttt{0x0000000}	&\texttt{/usr/lib/systemd/boot/efi/linuxx64.efi.stub}	&Linux EFI Stub\\
 			\texttt{0x0020000}	&\texttt{/usr/lib/os-release}		&Linux OS release information\\
 			\texttt{0x0030000}	&\texttt{/boot/kernel-command-line.txt}	&Kernel command line parameters\\
-			\texttt{0x0040000}	&\texttt{/boot/vmlinuz}	&latest Kernel image\\
+			\texttt{0x0040000}	&\texttt{/boot/vmlinuz}	&latest kernel image\\
 			\texttt{0x3000000}	&\texttt{/boot/initrd}	&latest initial ramdisk\\
 			\bottomrule
 		\end{tabular}
 	\end{footnotesize}
-	\caption{Memory layout of the Unified Kernel EFI file} 
+	\caption{Memory layout of the Unified Kernel EFI file}
 	\label{tab:efilayout}
 \end{table}
-The shell script shown in \autoref{code:tbupdatekernelsh} uses the command \texttt{objcopy} to create a single EFI file which contains the Kernel with corresponding release information, its command line parameters and the initial file system which is held in RAM during boot.
+The shell script shown in \autoref{code:tbupdatekernelsh} uses the command \texttt{objcopy} to
+create a single EFI file which contains the kernel with corresponding release information, its
+command line parameters and the initial file system which is held in RAM during boot.
 The memory layout of the EFI blob is shown in \autoref{tab:efilayout}
 With this Unified Kernel in place, no additional PCRs are used and everything is measured by the BIOS.
 % It furthermore omits the bootloader which is not necessary since the BS is ideally an embedded system with a single boot option in the end.
 
 When the BIOS hands over the system to the bootloader, all PCR values are already set.
-The Trusted Boot chain can now be used to authenticate the Kernel against the system.
+The Trusted Boot chain can now be used to authenticate the kernel against the system.
 Therefore a second key is added to the LUKS header, which is a random number of 32 byte length.
 This key is saved in the TPM and sealed with the values of PCR 0--7.
 If the BIOS measurements calculate the same values as those of the sealing, the TPM is able to reveal the key for the FDE and the boot process can continue.
-The \emph{trusted} environment is now extended to the Kernel and the modules loaded at boot.
+The \emph{trusted} environment is now extended to the kernel and the modules loaded at boot.
 
 Although the disk encryption is optional for this project, it might be useful to encrypt the disk when any sensitive data is stored on the device.
 \autoref{code:tbinstallsh} is the main script installing disk decryption via TPM.
@@ -143,23 +148,23 @@ Although the disk encryption is optional for this project, it might be useful to
 
 \begin{itemize}
 	\item Trusted Boot with GRUB 2.04: TPM support available; PCR mapping
-	\item Secure Boot with Unified Kernel; another PCR mapping
+	\item Secure Boot with unified kernel; another PCR mapping
 	\item Benefits and Drawbacks of both variants
-	\item describe automated unlocking 
+	\item describe automated unlocking
 \end{itemize}
 
 Limitations due to bad implementation on BIOS-Level, no Certificate Verification Infrastructure available for TPMs? Needs to be proven for correctness.
 
 \section{Integrity Measurement Architecture}
 Available on Ubuntu, RedHat and optionally Gentoo.
-The Kernel has the correct compile options set.
+The kernel has the correct compile options set.
 
 \subsection{Handling external hardware}4
 How can camera and fingerprint sensor be trusted?
 What is the limitation of this solution?
 
 \section{Interaction with TPM2}
-tpm2-tools 4.x are usable to interact with the TPM from the command line. 
+tpm2-tools 4.x are usable to interact with the TPM from the command line.
 Available on all major releases after summer 2019.
 Fallback is using the TPM2 ESAPI or SAPI, which is available on almost all Linux distributions.