Proofread 01, 02

Author: dabch

thesis/build/main.pdf

@@ -4,7 +4,7 @@
 \chapter{Introduction}\label{chapter:introduction}
 
 \acrfull{abe} promises to provide security while improving flexibility over standard cryptosystems.
-Its approach of combining \glspl{attribute} and \glslink{access-policy}{policies} describing characteristics of admissible decryption keys is closer to traditional notions of access control (e.g. Role-Based Access Control) than conventional encryption~\cite{bethencourt_ciphertext-policy_2007}.
+Its approach of combining \glspl{attribute} and \glslink{access-policy}{policies} describing admissible decryption keys is closer to traditional notions of access control (e.g. Role-Based Access Control) than conventional encryption~\cite{bethencourt_ciphertext-policy_2007}.
 
 This increased flexibility is also desirable for \acrfull{iot} applications.
 However, the \acrshort{iot} is especially affected by the trade-off between cost and security:
@@ -22,7 +22,7 @@ \chapter{Introduction}\label{chapter:introduction}
 
 For a real-world use case of such an \acrshort{abe} library in the medical field, see Figure~\ref{fig:system-architecture}. % TODO? describe the figure in words as well?
 It is assumed that the sensor (e.g. an ECG or blood glucose sensor) is unable to communicate with the internet directly.
-Therefore, the data is sent to a gateway by \acrfull{ble} and then uploaded to the cloud.
+Therefore, the data is sent to a gateway via \acrfull{ble} and then uploaded to the cloud.
 
 Note that in this use case, the sensor exclusively needs to encrypt data.
 Decryption is not required on the constrained node, which is the case in many \acrshort{iot} applications.
@@ -44,8 +44,9 @@ \chapter{Introduction}\label{chapter:introduction}
 Unfortunately, trusting either the gateway or the cloud provider is an unreasonable assumption in many scenarios.
 Therefore, we'd like to employ end-to-end \acrlong{abe}:
 Measurements are encrypted with \acrshort{abe} on the sensor before they are transmitted over \acrshort{ble} and only decrypted when read by an authorized client (e.g. the attending doctor).
+Neither the gateway nor the cloud server need to be trusted in this scenario.
 
-End-to-end \acrshort{abe} eliminates trust in the gateway and the cloud server, but it does not remove the single point of failure:
+\Acrshort{abe} does not entirely remove the single point of failure, though:
 A malicious \acrfull{kgc} could issue keys that allow decryption of arbitrary data (see section~\ref{sec:kgc}).
 However, the \acrshort{kgc} is only required to setup the \acrshort{abe} system and issue the participant's keys.
 It is not involved in any encryption or decryption operations.

thesis/chapters/01_introduction.tex

@@ -4,7 +4,8 @@ \chapter{Preliminaries}\label{chapter:background}
 \input{figures/02_key_use_comparison}
 
 \section{Confidentiality with Classic Symmetric and Asymmetric Cryptography}
-Today's conventional cryptography knows two main classes of encryption schemes: \glslink{privkes}{symmetric} and \glslink{pkes}{asymmetric encryption}. See Figure~\ref{fig:key-use} for an illustration of the differences.
+Today's conventional cryptography knows two main classes of encryption schemes: \glslink{privkes}{symmetric} and \glslink{pkes}{asymmetric encryption}.
+Figure~\ref{fig:key-use} illustrates the differences between attribute-based, symmetric and asymmetric encryption.
 
 Consider $n$ participants wanting to communicate securely (i.e. no user can read encrypted messages between two other users).
 Using a \gls{privkes}, each participant would need to agree on a unique key with every other participant, resulting in a total number of $\frac{n(n-1)}{2}$ keys.
@@ -22,9 +23,8 @@ \section{Confidentiality with Classic Symmetric and Asymmetric Cryptography}
 
 \section{Attribute-Based Encryption}\label{sec:background-abe}
 \acrfull{abe} uses a combination of attributes to define a \emph{group} of private keys that should be able to read encrypted data, instead of encrypting it for one specific private key only (as in \glspl{pkes}).
-In Figure~\ref{fig:key-use}, this is represented by a tree.
 
-The combination of attributes may be as restrictive or permissive as needed.
+This group of keys may be as restrictive or permissive as needed.
 It is possible to create ciphertexts that can be read by almost all members of an \acrshort{abes}, and ciphertexts that can be read by nobody except a few selected participants.
 
 Figure~\ref{fig:abe-system} shows how the participants interact in a small \acrshort{abe} system.
@@ -127,11 +127,11 @@ \subsection{Access Trees}\label{sec:access-trees}
 
 \input{figures/02_sample_access_tree}
 
-Explicitly specifying an \gls{access-structure} is not feasible, as its size may be exponential in the size of the attribute universe.
+Explicitly specifying a \glspl{access-structure} is not feasible as their size may be exponential in the size of the attribute universe.
 Therefore, we will use the construction of \emph{access trees} defined by Goyal~et~al.~\cite{goyal_attribute-based_2006}.
 \Glspl{access-tree} are similar to the tree representation of boolean formulas, but slightly more powerful:
 Each leaf of this tree is labelled with an attribute.
-Each inner node has a number of children and is labelled with an integer. 
+Each inner node is labelled with an integer and has two or more children.% and is labelled with an integer. 
 This integer represents the number of children that need to be satisfied in order to satisfy the inner node~\cite{goyal_attribute-based_2006}.
 
 Figure~\ref{fig:sample-access-tree} illustrates an example for an \gls{access-tree}. It is satisfied by any set of attributes that contains two of $A, B$ and either $C$ or $D$.
@@ -143,7 +143,7 @@ \subsection{Access Trees}\label{sec:access-trees}
 
     An interal node $x$ of an \gls{access-tree} is defined by its children and a threshold value $d_x$.
     The threshold value satisfies $0 < d_x \leq num_x$ with $num_x$ being the number of children.
-    A leaf node $x$ is defined by an attribute and a threshold value $k_x = 1$.
+    A leaf node $x$ is defined by an attribute and a threshold value $d_x = 1$.
 
     The parent of a node $x$ in the \gls{access-tree} is denoted by $\text{parent}(x)$.
     If $x$ is a leaf node, $\text{att}(x)$ denotes the attribute associated with $x$; otherwise it is undefined.
@@ -153,7 +153,7 @@ \subsection{Access Trees}\label{sec:access-trees}
 \begin{definition}
     Satisfying Access Trees~\cite{goyal_attribute-based_2006}.
 
-    Let $\mathcal{T}$ be an \gls{access-tree} with root r and $\mathcal{T}_x$ the subtree with $x$ as its root.
+    Let $\mathcal{T}$ be an \gls{access-tree} with root $r$ and $\mathcal{T}_x$ the subtree with $x$ as its root.
     If a set of attributes $\gamma$ satisfies the \gls{access-tree} $\mathcal{T}_x$, we write $\mathcal{T}_x(\gamma) = 1$; otherwise $\mathcal{T}_x(\gamma) = 0$.\\
     If $x$ is a leaf node, then $\mathcal{T}_x(\gamma) = 1$ if and only if $\text{attr}(x) \in \gamma$.
 
@@ -165,7 +165,7 @@ \subsection{Access Trees}\label{sec:access-trees}
 Using the \gls{access-tree} construction, we can express \emph{A AND B} as a node with two children $A$ and $B$ and threshold $2$, and express \emph{A OR B} as a node with two children $A$ and $B$ and threshold $1$~\cite{yao_lightweight_2015}.
 
 \subsection{Revocation}
-So far, it is not possible to take privileges away from a user:
+In a simple \acrshort{abe} system is not possible to take privileges away from a user:
 Once the private key has been issued, it can not be taken back.
 A user's capabilities can only be extended (e.g. by giving out a key with additional attributes).
 This is is a problem, e.g. if their private key is compromised~\cite{boldyreva_identity-based_2008}.
@@ -230,7 +230,7 @@ \subsection{Revocation}
 
 \section{Shamir's Secret Sharing}
 To implement \acrshort{abe}, we need a way to embed secrets in \glspl{access-tree}.
-For this, a secret sharing scheme introduced by \citeauthor{shamir_how_1979}~\cite{shamir_how_1979} is used.
+For this, the secret sharing scheme introduced by \citeauthor{shamir_how_1979}~\cite{shamir_how_1979} is used.
 
 Secret sharing schemes allows a secret $s$, which is generally just a number, to be shared among $n$ participants.
 The shares are computed such that $s$ can be reconstructed if and only if at least $k$ participants meet and combine their shares.
@@ -240,7 +240,7 @@ \subsection{Lagrange interpolation}
 Shamir's scheme makes use of a property of polynomials: A polynomial of degree $d$ is unambiguously determined by $d+1$ points $(x_i, y_i)$.
 In other words, any polynomial of degree $d$ can be unambiguously interpolated (reconstructed) from $d+1$ distinct points.
 
-To interpolate a polynomial of degree $d$ from $d+1$ given points $(x_1, y_1), \dots, (x_{d+1}, y_{d+1})$, we can make use of the lagrange basis polynomials:~\cite{yao_lightweight_2015}
+To interpolate a polynomial of degree $d$ from $d+1$ given points $(x_1, y_1), \dots, (x_{d+1}, y_{d+1})$, we can make use of the lagrange basis polynomials~\cite{yao_lightweight_2015}:
 
 \begin{definition}
     Lagrange interpolation: Given a set of $d+1$ points $(x_1, y_1), \dots, (x_{d+1}, y_{d+1})$.
@@ -336,11 +336,11 @@ \subsection{Group Axioms}\label{sec:group}
 
 
 This notation (``$+$'' for the group operation and $0$ for neutral element) is called \emph{additive notation}.
-Sometimes, \emph{multiplicative notation} is used: The group operation is denoted by ``$\cdot''$ and the neutral element by ``$1$''.
+Sometimes, \emph{multiplicative notation} is used: The group operation is denoted by ``$\cdot$'' and the neutral element by ``$1$''.
+In multiplicative notation, the group exponentiation of $g \in \mathbb{G}$ with $m \in \mathbb{N}^+$ is written as $g^m$.
 
 It is important to remember that even though the symbols $+$ and $\cdot$ are used, they might be defined completely differently from regular addition and multiplication!
 
-In multiplicative notation, the group exponentiation of $g \in \mathbb{G}$ with $m \in \mathbb{N}^+$ is written as $g^m$, in additive groups it is written as $m \cdot g$.
 
 \begin{definition}
     An (additive) group $\mathbb{G}$ is cyclic if there is an element $g \in \mathbb{G}$ that generates $\mathbb{G}$, i.e. $\mathbb{G} = \langle g \rangle = \{k \cdot g | k \in \mathbb{Z}\}$.
@@ -374,7 +374,7 @@ \subsection{Point Addition}
 Using this intersecting line, we can define an operation on curve points:
 \begin{definition}
     \label{def:point-add}
-    Given an \gls{ec} $E(\mathbb{Z}_p)$, we define a binary operation called \emph{(point) addition} and denoted by $+$:~\cite{katz_introduction_2015}\\
+    Given an \gls{ec} $E(\mathbb{Z}_p)$, we define a binary operation called \emph{(point) addition} and denoted by $+$~\cite{katz_introduction_2015}:\\
     Let $P_1, P_2 \in E(\mathbb{Z}_p)$.
 
     \begin{itemize}
@@ -393,16 +393,6 @@ \subsection{Point Addition}
     \label{fig:ecc-point-addition}
 \end{figure}
 
-We will be adding points to themselves a lot. Therefore, we define for ease of notation:
-\begin{definition}
-    Point-Scalar multiplication: Given a point $P \in E(\mathbb{Z}_p)$ and a scalar $d \in \mathbb{N}$: 
-    \begin{equation}
-        d \cdot P = \underbrace{P + P + \cdots + P}_{d \text{ times}}
-    \end{equation}
-\end{definition}
- 
-That is exactly the definition of group exponentiation, applied to our additive \gls{ec} group. Note that the product of a scalar with a point is again a point on our curve.\\
-
 \subsection{Groups on Elliptic Curves}
 \begin{theorem}
     The points of an \gls{ec} $E(\mathbb{Z}_p)$ plus the addition law as stated in Definition~\ref{def:point-add} form an abelian (commutative) group~\cite{katz_introduction_2015, washington_elliptic_2008}:
@@ -417,9 +407,19 @@ \subsection{Groups on Elliptic Curves}
     \end{itemize}
 \end{proof}
 
-Of particular interest to cryptography are \emph{cyclic} groups on \glspl{ec}:
 
+We will be adding points to themselves a lot. Therefore, we define for ease of notation:
+\begin{definition}
+    Point-Scalar multiplication: Given a point $P \in E(\mathbb{Z}_p)$ and a scalar $d \in \mathbb{N}$: 
+    \begin{equation}
+        d \cdot P = \underbrace{P + P + \cdots + P}_{d \text{ times}}
+    \end{equation}
+\end{definition}
+ 
+That is exactly the definition of group exponentiation, applied to our additive \gls{ec} group.
+Note that the product of a scalar with a point is again a point on our curve.
 
+Of particular interest to cryptography are cyclic groups on \glspl{ec}.
 Translated to our \glspl{ec}, this means that there is a generator point $P \in E(\mathbb{Z}_p)$, such that every point $Q \in E(\mathbb{Z}_p)$ can be obtained by repeatedly adding $P$ to itself using the point addition from Definition~\ref{def:point-add}.
 
 \begin{theorem}\cite{katz_introduction_2015}

thesis/chapters/02_background.tex

@@ -35,7 +35,7 @@ \section{Theoretical work on ABE schemes}
 Their main construction uses a \glslink{small-universe}{small attribute universe}, but they also propose a \gls{large-universe} construction.
 
 The first expressive \acrlong{cp-abe} scheme was proposed by Bethencourt, Sahai and Waters in~\cite{bethencourt_ciphertext-policy_2007}.
-It is a large-universe construction and uses \glspl{access-tree}.
+% It is a large-universe construction and uses \glspl{access-tree}.
 Waters \cite{waters_ciphertext-policy_2011} later also introduces the first \acrshort{cp-abe} schemes with a security proof in the \gls{standard-model}, not only in the \gls{ggm}.
 
 Both the schemes in~\cite{goyal_attribute-based_2006} and in~\cite{bethencourt_ciphertext-policy_2007} only support monotone \glspl{access-structure}.
@@ -72,7 +72,7 @@ \section{Theoretical work on ABE schemes}
 Herranz argues that it is not possible to build secure \acrshortpl{abes} in the (non-bilinear) discrete-logarithm setting (i.e. on elliptic curves without bilinear pairings).
 For this reason, the security of pairing-free schemes like \cite{yao_lightweight_2015,sowjanya_efficient_2020,tan_enhancement_2019} remains questionable, even if further improved.
 
-\section{Implementation on unconstrained hardware}
+\section{Implementation on unconstrained devices}
 One of the first notable pairing implementations was the \emph{Pairing-Based Cryptography Library (PBC)}~\cite{lynn_pairing-based_nodate, lynn_implementation_2007}.
 The efficiency improvements implemented by the PBC library were first described by its author, Ben Lynn, in~\cite{lynn_implementation_2007}.
 This implementation runs sufficiently fast on standard PC hardware, e.g. it takes 20.5ms to compute a pairing on a 224-bit MNT curve on a 2.4\,GHz Intel Core i5 processor~\cite{akinyele_self-protecting_2010}.
@@ -86,7 +86,7 @@ \section{Implementation on unconstrained hardware}
 This implementation uses the PBC library and 224-bit MNT curve from~\cite{lynn_implementation_2007}.
 They conclude that for policies with less than 30 leaf nodes, decryption on a smartphone is feasible (taking around 2 to 7 seconds, depending on the scheme) \cite{akinyele_self-protecting_2010}.
 
-In \cite{sanchez_neon_2013}, a pairing library and \acrshort{abes} is implemented using the NEON instructions, a set of \acrshort{simd} vector instructions for ARM processors.
+In \cite{sanchez_neon_2013}, a pairing library and \acrshort{abes} are implemented using NEON, a set of \acrshort{simd} vector instructions for ARM processors.
 They evaluate their implementations on several ARM Cortex A9 and A15 processors with clock frequencies between 1GHz and 1.7GHz.
 The use of NEON improves performance by 20-50\%, depending on the chip.
 Note that the NEON instruction set is not available on our SoC. 
@@ -114,12 +114,12 @@ \section{Implementation on constrained devices}
 The authors of \cite{ambrosin_feasibility_2015} test their \acrshort{abe} implementation on \gls{iot} devices in \cite{ambrosin_feasibility_2016}.
 They evaluate the performance of the same library on full-fledged \acrshort{iot} devices (among others, on a Raspberry Pi Zero with 1\,GHz ARM11 CPU) and conclude that \acrshort{abe} is feasible on these devices, too.
 However, they note that especially lower security levels are suitable and that the penalty for increasing the security level is very high (e.g. increasing the security level from 80 to 128 bits without increasing the encryption time requires reduction of the number of attributes by a factor of 10)~\cite{ambrosin_feasibility_2016}.
-In contrast to the SoC used in this thesis, their devices are significantly more powerful and run a full operating system.
+In contrast to the SoC used in this thesis, their devices are significantly more powerful and run full operating systems.
 
 The setting in \cite{borgh_attribute-based_2016} is much closer to ours: \acrshort{abe} is implemented bare-metal (i.e. without operating system) on a sensor equipped with an STM32L151VCT6 SoC with a maximum clock frequency of 32\,MHz.
 They use the pairing library \emph{RELIC Toolkit}~\cite{aranha_relic_nodate} at a security level of 128 bits and evaluate a C implementation of the \acrshort{cp-abe} scheme in \cite{waters_ciphertext-policy_2011}.
 Only encryption is evaluated; decryption is not implemented on the SoC.
-The author again concludes that \acrshort{abe} encryption on the sensor is feasible if the policy size is rather small and the runtime of several seconds is acceptable~\cite{borgh_attribute-based_2016}.
+The author again concludes that \acrshort{abe} encryption on the sensor is feasible if the policy size is rather small and a runtime of several seconds is acceptable~\cite{borgh_attribute-based_2016}.
 In this case, the encryption time is over 10\,s for just six attributes~\cite{borgh_attribute-based_2016}.
 In contrast to our work, the hardware is slightly less powerful and the evaluated scheme is \acrshort{cp-abe}.
 

thesis/chapters/03_related-work.tex

@@ -75,7 +75,7 @@
   description={type of encryption scheme where the same key is used for encryption and decryption. This means that the key has to be shared among all parties via some secure channel (e.g. a personal meeting).}
 }
 
-\newacronym[see={[Glossary:]{gls-kgc}}]{kgc}{KGC}{Key Generation Center\glsadd{gls-kgc}}
+\newacronym[see={[Glossary:]{gls-kgc}}]{kgc}{KGC}{key generation center\glsadd{gls-kgc}}
 % \newacronym{kgc}{KGC}{Key Generation Center}
 
 \newglossaryentry{ibe}{