[taler-anastasis] branch master updated: related work edits

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new 46bcc29  related work edits
46bcc29 is described below

commit 46bcc2938221c1f34c80be899ee93593c4656291
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Jun 7 01:03:11 2020 +0200

    related work edits
---
 doc/thesis/.gitignore             |   1 +
 doc/thesis/project_management.tex |  10 +-
 doc/thesis/related_work.tex       | 522 ++++++++++++++++++++++++++++++++------
 3 files changed, 447 insertions(+), 86 deletions(-)

diff --git a/doc/thesis/.gitignore b/doc/thesis/.gitignore
new file mode 100644
index 0000000..f109c26
--- /dev/null
+++ b/doc/thesis/.gitignore
@@ -0,0 +1 @@
+thesis.toc
diff --git a/doc/thesis/project_management.tex 
b/doc/thesis/project_management.tex
index c7941cb..1afa6eb 100644
--- a/doc/thesis/project_management.tex
+++ b/doc/thesis/project_management.tex
@@ -4,10 +4,8 @@ This section describes the project planing of Anastasis. A 
detailed
 reflection on the work on Anastasis is in the work journal in the
 appendix.
 
-\subsection{Project plan}
-
-The following graphic shows our project plan how we planed to
-implement Anastasis and write our Bachelor's thesis.
+Figure~\ref{fig:project_plan_anastasis} shows our original project
+plan for implementing Anastasis and writing our Bachelor's thesis.
 
 \begin{figure}[H]
                \includegraphics[scale=0.5]{images/project_plan_anastasis.png}
@@ -15,9 +13,7 @@ implement Anastasis and write our Bachelor's thesis.
        \label{fig:project_plan_anastasis}
 \end{figure}
 
-\subsection{Project plan reflection}
-
-We were able to write our thesis nearly according to our original
+We were able to write our thesis roughly according to our original
 project plan.  The software development took a bit longer, as we had
 to relearn certain aspects of the C language and understand many APIs
 used by the overall system.  Because of this, we cut the
diff --git a/doc/thesis/related_work.tex b/doc/thesis/related_work.tex
index 48e19fb..a0e5da1 100644
--- a/doc/thesis/related_work.tex
+++ b/doc/thesis/related_work.tex
@@ -1,127 +1,491 @@
 \section{Related work}
-\subsection{Prerequisites}
-This chapter explains some important cryptographic functions and why they are 
useful for Anastasis.
 
-\subsubsection{PRG and PRF)}
-A pseudo random generator (PRG) is an algorithm producing an infinite sequence 
of bits for which there is no efficient algorithm to distinguish it from a 
truly random sequence~\cite{vadhan2012}. The algorithm "takes as input a short, 
perfectly random seed"~\cite{vadhan2012} which determines the output value.\\
+This chapter explains some important cryptographic functions and which
+are used in Anastasis or related to our work. We also describe issues
+with existing solutions in this domain.
 
-A pseudo random function (PRF) is a deterministic function which output is 
finite and indistinguishable from a true random function.~\cite{nielsen2002} 
PRFs can be constructed using PRGs.~\cite{GGM1986}
+\subsection{Cryptographic primitives}
+
+\subsubsection{Pseudo-randomness}
+
+A pseudo random generator (PRG) is an algorithm producing an infinite
+sequence of bits for which there is no efficient algorithm to
+distinguish it from a truly random sequence~\cite{vadhan2012}. The
+algorithm ``takes as input a short, perfectly random
+seed''~\cite{vadhan2012} which determines the output value.\\
+
+A pseudo random function (PRF) is a deterministic function which
+output is finite and indistinguishable from a true random
+function.~\cite{nielsen2002} PRFs can be constructed using
+PRGs.~\cite{GGM1986}
 
 \subsubsection{Hash function}
-Hash functions "compress a string of arbitrary length to a string of fixed 
length [...]"~\cite{Preneel1999}. The output of a hash function often is called 
a "hash".  Hash functions in general should be very fast to compute. 
Cryptographic hash functions need to fulfil additional security requirements 
which are called:
+
+Hash functions "compress a string of arbitrary length to a string of
+fixed length [...]"~\cite{Preneel1999}. The output of a hash function
+often is called a "hash".  Hash functions in general should be very
+fast to compute. Cryptographic hash functions need to fulfil
+additional security requirements which are
+
 \begin{itemize}
-       \item pre-image resistance
-       \item second pre-image resistance
-       \item collision resistance
-       \item pseudo randomness
-       \item avalanche effect
+ \item (first) pre-image resistance,
+ \item second pre-image resistance,
+ \item collision resistance,
+ \item pseudo randomness, and the
+ \item avalanche effect.
 \end{itemize}
-Pre-image resistance, also called "one way property", means that for a given 
hash function H and a hash value H(x), it is computationally infeasible to find 
x \cite{SG2012}. For example, since in Anastasis we derive the key to encrypt 
the personal details required for user authentication (e.g. the mobile phone 
number for authentication via SMS) using functions based on hash functions (see 
HKDF), it is very important that you cannot derive the corresponding input 
values from the key.\\
-The second pre-image resistance is described by following: For a given hash 
function H and a hash value H(x), it is computationally infeasible to find x 
and x' such that H(x) = H(x') \cite{SG2012}. In Anastasis hash functions also 
are involved in signing our so called recovery document. Hence an attacker 
should not be able to create a malicious recovery document with the same hash 
value as the original one.\\ 
-The definition of collision resistance slightly differs from the second 
pre-image resistance: For a given hash function H, it is computationally 
infeasible to find a pair (x, y) such that H(x) = H(y) \cite{SG2012}. As we are 
using HKDFs for deriving keys in Anastasis, an attacker should not be able to 
find some other input values also leading to the same keys we use.\\
-A cryptographic hash function should also behave as a pseudo random function. 
This means that although a hash function is purely deterministic, the output 
must not be predictable.\\
-The avalanche effect describes the property of an algorithm that causes a 
significant change of the output value, usually a bit flipping of more than 
half the output is desired, if the input is changed slightly (for example, 
flipping a single bit).~\cite{RK2011} The more bits are flipping in the output 
value the higher the entropy of the randomness of the hash function.
 
-There are several applications for cryptographic hash functions. For example 
you can store the hash value of a passphrase instead of the passphrase itself 
in a computer to protect the passphrase. Another important application is 
verification of message integrity: Before and after transmission of a message 
you can calculate the hash values of it and compare them to determine if the 
message changed during transmission.\\
+Pre-image resistance, also called the ``one way property'', means that
+for a given hash function $H$ and a hash value $H(x)$, it is
+computationally infeasible to find $x$.~\cite{SG2012} For example,
+since in Anastasis we derive the key to encrypt the personal details
+required for user authentication (e.g. the mobile phone number for
+authentication via SMS) using functions based on hash functions (see
+HKDF), it is very important that you cannot derive the corresponding
+input values from the key.
+
+The second pre-image resistance is described by following: For a given
+hash function $H$ and a hash value $H(x)$, it is computationally
+infeasible to find $x$ and $x'$ such that $H(x) = H(x')$ and $x \not=
+x'$.~\cite{SG2012} In Anastasis hash functions also are involved in
+signing our so called recovery document. Hence an attacker should not
+be able to create a malicious recovery document with the same hash
+value as the original one.
+
+The definition of collision resistance slightly differs from the
+second pre-image resistance: For a given hash function $H$, it is
+computationally infeasible to find a pair $x, y$ such that $H(x) =
+H(y)$ \cite{SG2012}.
+%CG: the text below does NOT related to collision resistance!
+%As we are using HKDFs for deriving keys in
+%Anastasis, an attacker should not be able to find some other input
+%values also leading to the same keys we use.
+Anastasis does not rely upon collision resistance in its use of hash
+functions. % CG: at least no case comes to mind for me right now...
+
+A cryptographic hash function should also behave as a pseudo random
+function. This means that although a hash function is purely
+deterministic, the output must not be predictable.
+
+The avalanche effect describes the property of an algorithm that
+causes a significant change of the output value, usually a bit
+flipping of more than half the output is desired, if the input is
+changed slightly (for example, flipping a single bit).~\cite{RK2011}
+The more bits are flipping in the output value the higher the entropy
+of the randomness of the hash function.
+
+There are many applications for cryptographic hash functions. For
+example, you can store the hash value of a passphrase instead of the
+passphrase itself in a computer to protect the passphrase. Another
+important application is verification of message integrity: Before and
+after transmission of a message one can calculate the hash values of
+it and compare hashes later to determine if the message changed during
+transmission.
+
 In Anastasis we use SHA-512~\cite{GJW2011} for fast hash functions.
 
 \subsubsection{HMAC}
-When it comes to integrity of messages during communication of two parties 
over an insecure channel Keyed-Hash Message Authentication Codes (HMAC) are 
used as check values. An HMAC function is based on a hash function and takes 
two arguments, a key K and a message M:\\
-HMAC\textsubscript{K}(M) = H(K $\oplus$ opad,H(K $\oplus$ ipad, M)) with 
"ipad" and "opad" being constants which fill up the key K to the blocksize of 
the hash function \cite{BCK1996}. The blocksize of a modern hash function like 
SHA-512 is 64 Byte.\\
+
+When it comes to integrity of messages during communication of two
+parties over an insecure channel Keyed-Hash Message Authentication
+Codes (HMAC) are used as check values. An HMAC function is based on a
+hash function and takes two arguments, a key $K$ and a message $M$:
+
+$HMAC_{K}(M) = H(K \oplus opad,H(K \oplus ipad, M))$ with "ipad" and
+"opad" being constants which fill up the key $K$ to the blocksize of
+the hash function~\cite{BCK1996}. The blocksize of a modern hash
+function like SHA-512 is 64 bytes.
+
 In Anastasis we use HMACs to achieve verifiability.
+% CG: verifiability of WHAT?
+% CG: I don't recall seeing HMACs in Anastasis, except for:
 
 \subsubsection{HKDF}
-A HKDF is a key derivation function (KDF) based on HMAC. A KDF "is a basic and 
essential component of crypto-
-graphic systems: Its goal is to take a source of initial keying material, 
usually containing some good amount of randomness, but not distributed 
uniformly or for which an attacker has some partial knowledge, and derive from 
it one or more cryptographically strong secret keys" \cite{krawczyk2010}.\\
-Anastasis uses HKDFs based on SHA-512 to derive symmetric keys for encryption 
purposes.
+
+A HKDF is a key derivation function (KDF) based on HMAC. A KDF ``is a
+basic and essential component of cryptographic systems: Its goal is
+to take a source of initial keying material, usually containing some
+good amount of randomness, but not distributed uniformly or for which
+an attacker has some partial knowledge, and derive from it one or more
+cryptographically strong secret keys''~\cite{krawczyk2010}.
+
+Anastasis uses HKDFs based on SHA-512 to derive symmetric keys for
+encryption.
 
 \subsubsection{Argon2}
-Hash functions like SHA-512 are designed to be very fast. Therefor passwords 
being stored using this kind of hash are vulnerable to dictionary attacks with 
new hardware architectures like FPGAs \cite{trimberger2012} and dedicated ASIC 
\cite{madurawe2006} modules. But those architectures "experience difficulties 
when operating on large amount of memory" \cite{BDK2016}.\\
-In contrast to standard hash functions there are functions designed to be 
memory-hard. Argon2 is such a memory-hard function that won the Password 
Hashing Competition in 2015. It minimizes time-memory tradeoff \cite{stamp2003} 
and thus maximizes the costs to implement an ASIC for given CPU computing time 
\cite{BDK2016}. Aside from the fact that Argon2 makes dictionary attacks much 
harder, Argon2 can be used for another feature too: Memory-hard schemes like 
Argon2 are very useful for key  [...]
 
-Argon2 is used in Anastasis to derive an identifier for the user from some 
low-entropy material.
+Hash functions like SHA-512 are designed to be very fast. Therefor
+passwords being stored using this kind of hash are vulnerable to
+dictionary attacks with new hardware architectures like
+FPGAs~\cite{trimberger2012} and dedicated ASIC~\cite{madurawe2006}
+modules. But those architectures ``experience difficulties when
+operating on large amount of memory''~\cite{BDK2016}.
+
+In contrast to standard hash functions there are functions designed to
+be memory-hard. Argon2 is such a memory-hard function that won the
+Password Hashing Competition in 2015. It minimizes time-memory
+tradeoff~\cite{stamp2003} and thus maximizes the costs to implement an
+ASIC for given CPU computing time~\cite{BDK2016}. Aside from the fact
+that Argon2 makes dictionary attacks much harder, Argon2 can be used
+for another feature too: Memory-hard schemes like Argon2 are very
+useful for key derivation from low-entropy sources~\cite{BDK2016}.
+
+Argon2 is used in Anastasis to derive an identifier for the user from
+the user's attributes, which serve as low-entropy inputs.
 
 
 \subsection{Secret sharing}
-Secret splitting, also known as secret sharing, is a technique for 
distributing a secret amongst multiple recipients. This is achieved by 
assigning a share of the secret to each recipient. By combining a sufficient 
number of those shares, it is possible to reconstruct the secret.
-In a secret sharing theme the recipients of a share often are called 
\textit{players}. The figure who gives a share of the secret to the players is 
called \textit{dealer}.\\
-In Anastasis the user is the trusted dealer who splits the secret and also 
reconstructs it.
 
-\subsubsection{Shamir's Secret Sharing}
-The algorithm "Shamir's Secret Sharing" is one of the most well known secret 
sharing scheme. It „divide[s] data D into n pieces in such a way that D is 
easily reconstructible from any k pieces, but even complete knowledge of k - 1 
pieces reveals absolutely no information about D“ \cite{shamir_sharing}.\\
-Shamir’s simple secret sharing scheme has two key limitations. First, it 
requires a trusted dealer who initially generates the secret to be distributed, 
and second the shares are not verifiable during reconstruction. Therefore, 
malicious shareholders could submit corrupt shares to prevent the system from 
reconstructing the secret -- without these corrupt shareholders being 
detectable as malicious. Furthermore, the dealer distributing the shares could 
be corrupt and distribute some incons [...]
-Despite this, Shamir's Secret Sharing is inflexible because it is a (k, n) 
threshold scheme and also is very inefficient for big n. For Anastasis we need 
a more flexible solution allowing other cases, too. The user of Anastasis 
should be able to decide himself which combinations of \textit{players} shall 
be used.
+Secret splitting, also known as secret sharing, is a technique for
+distributing a secret amongst multiple recipients. This is achieved by
+assigning a share of the secret to each recipient. By combining a
+sufficient number of those shares, it is possible to reconstruct the
+secret.  In a secret sharing theme the recipients of a share often are
+called \textit{players}. The figure who gives a share of the secret to
+the players is called \textit{dealer}.
+
+In Anastasis the user is the trusted dealer who splits the secret and
+also reconstructs it.
+
+\subsubsection{Shamir's Secret Sharing} \label{sec:rel:shamir}
+
+The algorithm ``Shamir's Secret Sharing'' is probably the most well
+known secret sharing scheme. It ``divide[s] data D into n pieces in
+such a way that D is easily reconstructible from any k pieces, but
+even complete knowledge of $k - 1$ pieces reveals absolutely no
+information about D''~\cite{shamir_sharing}.
+
+Shamir’s simple secret sharing scheme has two key limitations. First,
+it requires a trusted dealer who initially generates the secret to be
+distributed, and second the shares are not verifiable during
+reconstruction. Therefore, malicious shareholders could submit corrupt
+shares to prevent the system from reconstructing the secret --- without
+these corrupt shareholders being detectable as malicious. Furthermore,
+the dealer distributing the shares could be corrupt and distribute
+some inconsistent shares to the others. Also, in some scenarios the
+dealer cannot be trusted with the knowledge of the original core
+secret.
+
+Additionally, Shamir's Secret Sharing is inflexible because it is a
+simple $k$-out-of-$n$ threshold scheme.  While this makes the scheme
+reasonably efficient even for big values of $n$, efficiency with
+respect to a large number of escrow providers and authorization
+procedures is not important for Anastasis: it is already difficult to
+conceive users providing more than a handful of authentication methods
+(Section~\ref{sec:rel:authentication} describes common choices.)
+
+For Anastasis, we thus decided to opt for more flexible approach that
+allows complex policies for recovery authorization, instead of only
+$k$-out-of-$n$. Each user of Anastasis is also able to decide which
+combinations of \textit{players} shall be permitted. % CG: players!?!?
 
 \subsubsection{Verifiable Secret Sharing}
-Verifiability can be achieved by using so called commitment schemes like the 
Pederson commitment. It allows „to distribute a secret to n persons such that 
each person can verify that he has received correct information about the 
secret without talking with other persons“ \cite{pedersen_sharing_0}. In his 
paper „A Practical Scheme for Non-interactive Verifiable Secret Sharing“ 
\cite{feldman_sharing}, Paul Feldman  combines the two schemes Shamir Secret 
Sharing and Pederson commitment. His [...]
-Because in Anastasis we have a trusted dealer, the shares must not be verified 
and therefor we don't need VSS.
+
+Verifiability can be achieved by using so called commitment schemes
+like the Pederson commitment. It allows ``to distribute a secret to n
+persons such that each person can verify that he has received correct
+information about the secret without talking with other
+persons''~\cite{pedersen_sharing_0}. In his paper ``A Practical Scheme
+for Non-interactive Verifiable Secret
+Sharing''~\cite{feldman_sharing}, Paul Feldman combines the two
+schemes Shamir Secret Sharing and Pederson commitment. His algorithm
+for verifiable secret sharing, short VSS, allows each recipient to
+verify the correctness of his share. But like in the Shamir Secret
+Sharing scheme, the dealer in the Verifiable Secret Sharing scheme
+also can't be trusted with the knowledge of the original core secret.
+
+Because in Anastasis each user can act as their own trusted dealer,
+the shares must not be verified and therefore Anastasis do not need
+any form of VSS.
 
 \subsubsection{Distributed Key Generation}
-Distributed key generation algorithms, short DKG, solve the problem of needing 
a trustworthy dealer by relying on a threshold of honest persons. Contrary to 
the above-mentioned schemes, in distributed key generation algorithms every 
participant is involved in key generation.\\
-The Pederson DKG is such „a secret sharing scheme without a mutually trusted 
authority“ \cite{pedersen_sharing_5.2}. Basically, this DKG works as follows: \\
-First, each involved party generates a pre-secret and distributes it to all 
parties using the verifiable secret sharing scheme of Feldman.\\ 
-Afterwards, each party recombines the received shares, including its own 
pre-secret, to a share of the main secret. The main secret can be reconstructed 
by summing up each recombination of the shared pre-secrets.\\
-For Anastasis we do not need a DKG because the dealer is the user himself and 
therefore, he is fully trustworthy.
 
-\subsection{Existing solutions}
-This section introduces some existing solutions for key recovery and why they 
are problematic.
+Distributed key generation (DKG) algorithms solve the problem of
+needing a trustworthy dealer by instead relying on a threshold of
+honest persons for key generation. Contrary to the above-mentioned
+schemes, in distributed key generation algorithms every participant is
+involved in key generation.  The Pederson DKG is such ``a secret
+sharing scheme without a mutually trusted
+authority''~\cite{pedersen_sharing_5.2}. Basically, this DKG works as
+follows: First, each involved party generates a pre-secret and
+distributes it to all parties using the verifiable secret sharing
+scheme of Feldman.  Afterwards, each party recombines the received
+shares, including its own pre-secret, to a share of the main
+secret. The main secret can be reconstructed by summing up each
+recombination of the shared pre-secrets.
 
-\subsubsection{Coinbase}
-Coinbase\footnote{\url{https://www.coinbase.com/}} is a global digital asset 
exchange company, providing a venue to buy and sell digital currencies. 
Coinbase also uses wallets secured with private keys. To recover this private 
key the user has to provide a 12 words recovery phrase. Coinbase now offers a 
solution to securely deposit this recovery phrase onto the users Google Drive 
or iCloud.~\cite{coinbase} The security here lies within the Google or iCloud 
Account and the password used t [...]
+Because in Anastasis each user can act as their own trusted dealer, we
+also do not worry about the dealer learning the user's key and hence
+Anastasis do not need any form of DKG.
 
-\subsubsection{MIDATA}
-MIDATA is a project that aims to give patients back control over their medical 
data and to enable them to share their data only with those they trust 
\footnote{\url{https://www.midata.coop/}}. In case the patient lost his device 
running the MIDATA-application and his MIDATA-password, MIDATA build in a key 
recovery system using the Shamir Secret Sharing Scheme mentioned above. In 
their case a few "persons working at MIDATA have generated a public-private key 
pair (Recovery key) on their o [...]
-The security of MIDATA as described in "Patient empowerment in IoT for eHealth 
- How to deal with lost keys?" \cite{midata} is broken in two ways:
-\begin{enumerate}
-       \item The password is reconstructed at the server, not at the patients 
device. An administrator of the server can theoretically access the recovered 
password at that time. A correct use of Shamir Secret Sharing scheme would 
reconstruct the password.
-       \item It is not clear which authentication methods the persons working 
for MIDATA use for their decisions and activities regarding the key recovery. 
The business process used here could be vulnerable. For example, an attacker 
could use social engineering to illegitimately trigger a recovery process via 
e-mail if it is the chosen authentication method.
-\end{enumerate}
+\subsection{Authentication} \label{sec:rel:authentication}
+
+To build a secure authentication procedure, today multi-factor
+authentication is the standard~\cite{multifactor_authentication}. A
+single authentication method by itself is usually vulnerable.
+Multi-factor authentication combines multiple authentication
+procedures to enhance the security of the system.
 
+Anastasis is designed to use a wide range of authentication methods to
+authenticate its users. Even though the user in Anastasis is free to
+specify only one authentication method, we strongly recommend the use
+of multi-factor authentication, typically using different
+authentication methods at different providers.
 
-\subsection{Authentication}
-To build a secure authentication procedure, today multi-factor authentication 
is the standard \cite{multifactor_authentication}. A single authentication 
method by itself is usually vulnerable. But multi-factor authentication 
combines multiple authentication procedures to enhance the security of the 
system. \\ 
-Anastasis is designed to use a wide range of authentication methods to 
authenticate its users. Even though the user in Anastasis is free to specify 
only one authentication method, we strongly recommend the use of multi-factor 
authentication. A short overview of the possible methods is presented here.
+A short overview of common authentication methods and issues with
+each of them is presented here.
 
 \subsubsection{Password authentication}
-Password authentication is the most widely used authentication procedure. But 
as studies show the procedure has its drawbacks 
\cite{authentication_methods_review}. For example the handling of the 
passwords, like storage or transmission, often is done poorly. Another problem 
is that the user must remember his password. Therefore the password is limited 
to the capabilities of the user to remember it. Thus people tend to use 
passwords with low entropy. Those passwords are vulnerable to brut [...]
-Because passwords can be forgotten, we do not recommend using this method in 
Anastasis, even though we want to offer the option to use it. If someone wants 
to use a password anyway, then he must make sure that the password cannot be 
forgotten, even if it means that the password has low entropy. Of course, this 
requires that additional factors are part of the authentication process.
+
+Password authentication is probably the most widely used
+authentication procedure. But as studies show the procedure has its
+drawbacks~\cite{authentication_methods_review}. For example the
+handling of the passwords, like storage or transmission, often is done
+poorly. Another problem is that the user must remember his
+password. Therefore the password is limited to the capabilities of the
+user to remember it. Thus people tend to use passwords with low
+entropy. Those passwords are vulnerable to brute force attacks or
+dictionary attacks. Another problem using passwords is the possibility
+of replay attacks: A password can be stolen by an eavesdropper during
+online transmission and used by the attacker.
+
+Because passwords can be forgotten, we do not recommend using this
+method for provider-authentication in Anastasis. Users could easily
+add a passwords into their set of ``invariant'' attributes used to
+derive the identity key, and then would automatically obtain all of
+the possible benefits (and drawbacks) from using a password.
+Specifically, they must make sure that the password cannot be
+forgotten, even if it means that the password has low entropy.
 
 \subsubsection{Secure question}
-Similar to password authentication the use of an authentication method based 
on a secure question requires the user to remember the correct answer to the 
specific question. The difference here is that the question provides a context 
that helps the user to remember the answer and the user does not need to 
memorize something new \cite{just2004}.\\
-There are several ways to implement authentication via a secure question:
+
+Similar to password authentication the use of an authentication method
+based on a secure question requires the user to remember the correct
+answer to a specific question. The difference here is that the
+question provides a context that helps the user to remember the answer
+and the user does not necessarily need to memorize something
+new~\cite{just2004}.
+
+There are several variations to implement authentication using a
+secure question:
+
 \begin{itemize}
-       \item The questions and answers are predefined.
-       \item Just the questions are predefined.
-       \item The user is free to create custom questions and answers.
+ \item The questions and answers are predefined.
+ \item Just the questions are predefined.
+ \item The user is free to create custom questions and answers.
 \end{itemize}
-The first option is the easiest one. But predefining the answers has the 
disadvantage being very impersonal and inflexible. The questions must 
inevitably be very general, which allows an attacker to answer the questions 
without even having to guess. Therefore the first option is not applicable.\\
-The second option is more applicable but has some drawbacks, too. For example 
there may be questions whose answers have multiple syntactic representations 
(for example, "St." versus "Street") \cite{just2004}. Another problem could be 
a question whose answer may change over time. Asking for the favourite actor 
for example could be problematic. In addition, there is a challenge to define 
questions for all kind of people. Some people for example could not answer to 
the question, what the na [...]
-In case of the third option we also have the problematic of the second one. 
Furthermore there is the difficulty for the user to ask creative questions. A 
good question should only be answerable by the user. Also, it would be perfect 
to have the attacker on the wrong track by using ambiguities he doesn't know.\\
-Authentication using a secure question needs personal information stored at 
the server which is critical in terms of privacy. That is why Anastasis doesn't 
store the answers of secure questions in clear text. Instead, we only store the 
hash value of an answer. Thus the user only has to provide the hash value of 
the answer and does not have to disclose any personal information.
+
+The first option is the easiest one. But predefining the answers has
+the disadvantage being impersonal and inflexible. The questions must
+inevitably be general, which may allow an attacker to obtain answers
+by collecting public information about the victim, or even simply
+solving the challenge by brute-forcing trying all possible choices.
+Therefore the first option is not ideal.
+
+The second option is more applicable but has some drawbacks, too. For
+example there may be questions whose answers have multiple syntactic
+representations (for example, ``St.'' versus
+``Street'')~\cite{just2004}. Another problem could be a question whose
+answer may change over time. Asking for the favourite actor for
+example could be problematic. In addition, there is a challenge to
+define questions for all kind of people. Some people for example could
+not answer to the question, what the name of their pet is, because
+they do not have one.
+
+In case of the third option, we have all of the issues of the second
+one, but additionally there is the difficulty for the user to ask
+creative questions. A good question should only be answerable by the
+user. Also, it would be perfect to have the attacker on the wrong
+track by using ambiguous questions with word plays the adversary
+cannot easily comprehend.
+
+Authentication using a secure question requires checking the validity
+of an answer that may include private personal information.
+Consequently, Anastasis does not store the answers of secure questions
+in cleartext. Instead, Anastasis only stores the hash value of a
+(salted) answer.  Thus the user only has to provide the hash value of
+the answer and not disclose the answer itself.
 
 \subsubsection{SMS authentication}
-Another way to authenticate is SMS authentication. The most popular use case 
is the so called Mobile TAN used to authorize online banking transactions. A 
Mobile TAN is an SMS based One-Time Password (OTP), short SMS OTP. SMS OTPs 
"were introduced to counter phishing and other attacks against authentication 
and authorization of Internet services" \cite{MBSS2013}.  But SMS is no longer 
considered secure. The SMS authentication relies on the security of the mobile 
network, which has differe [...]
-When it comes to privacy, storing a phone number is a problem. But the service 
authenticating the user needs the phone number enabling it to send a message to 
the user during authentication process.\\
-In Anastasis we also need to store the phone number to the server. But in our 
case the phone number is encrypted with a secret key only the user owns. The 
server only gets this secret key during an authentication process. Thus 
stealing the database of the server does not reveal the phone number to the 
attacker.
+
+Another way to authenticate users that have a mobile phone is to use
+SMS authentication. The most popular use case is the so called Mobile
+TAN used to authorize online banking transactions. A Mobile TAN is an
+SMS based One-Time Password (OTP), short SMS OTP. SMS OTPs ``were
+introduced to counter phishing and other attacks against
+authentication and authorization of Internet
+services''~\cite{MBSS2013}.
+
+However, SMS authentication is not very secure, as it relies on the
+security of the mobile network, which has various
+vulnerabilities~\cite{rieck_detection}. There are also specialized
+mobile trojans which are used to eavesdrop on these messages directly
+on the user's mobile device.
+
+While likely not as sensitive as answers to security questions, we
+still consider user's phone numbers as private information that
+deserves protection.  Naturally, a service authenticating the user
+needs the phone number to send a message to the user during SMS
+authentication.
+
+Hence, Anastasis providers have to learn the phone number during SMS
+authentication.  However, we can use cryptography to ensure that the
+provider only gets the keys to decrypt the phone number when the
+authentication process is started by the user as part of a recovery
+operation. Thus, a compromise of the provider's database would not
+directly reveal the phone numbers to the attacker.
+
 
 \subsubsection{E-mail authentication}
-Authentication by email is very similar to SMS authentication. Here, the user 
receives a token by email and has to provide it during the authentication 
process.
-The handling of this token needs some considerations. The token should have 
-a validity period, this means for example the token would only be valid for 
one hour. This is a security measure to prevent malicious actions if the user's 
email account was compromised. Also the token should be a randomly generated 
passphrase which has at least 8 characters.\\
-Another import part is that the email should never contain the requested 
information, in our case the keyshare. Because there is no guarantee that the 
email channel is encrypted. Also the email and the keyshare information would 
be stored for a indefinite period in the user's mailbox. Also the mailbox could 
be compromised of read by an IT department.\cite{emailauthowasp} \\
-As mentioned in the SMS authentication section we also store the email 
encrypted on the server. The user has to provide the corresponding key to the 
server during authentication process.
+
+Authentication by email is similar to SMS authentication. Here,
+the user receives a token by email and has to provide it during the
+authentication process.
+
+% CG: FIXME: (1) I don't buy the validity period, how does it help?
+% CG: FIXME: (2) This also applies to SMS, why have it here?
+The handling of this token needs some
+considerations. The token should have a validity period, this means
+for example the token would only be valid for one hour. This is a
+security measure to prevent malicious actions if the user's email
+account was compromised. Also the token should be a randomly generated
+passphrase which has at least 8 characters.
+
+Another import part is that the email should not already contain the
+requested information, so in the case of Anastasis the keyshare.  This
+is because the SMTP protocol used for email offers no hard security
+assurances. In particular, the email is likely to be stored for a
+indefinite period in the user's mailbox, which could be easily
+compromised and read by a mailbox provider.~\cite{emailauthowasp}
+
+Like with SMS authentication, Anastasis also encrypts the email
+addresses when they are stored at the provider.  The user has to
+provide the corresponding decryption key to the server during
+the authentication process.
+
 
 \subsubsection{VideoIdent}
-VideoIdent uses a video chat to verify the identity of a user. The user needs 
to show his face using a camera to an employee of the VideoIdent-service who 
verifies the correct user by a picture of the user \cite{pohlmann2017}.\\
-Prerequisites for error-free identification are a video camera with good video 
quality and a high-resolution image of the user on which the face can be seen 
very clearly. The user should also not change his outward appearance too much 
over time. A thick beard could also lead to the VideoIdent-service employee not 
being able to recognise the user correctly.\\
-For an attacker who looks very similar to the user, there is a high chance 
that the employee incorrectly confirms the identification. Therefor some 
interaction of the user is needed like for example telling the employee a short 
code which has been sent right before to the user by mail.\\
-In Anastasis the picture of the user is stored in an encrypted way. During 
authentication process the user has to provide the correct key for decryption 
to the server which provides the picture to the VideoIdent-service.
+
+VideoIdent uses a video chat to verify the identity of a user. The
+user needs to show their face using a camera to an employee of the
+VideoIdent service. The service then verifies the identity of the user
+by comparing the video stream to a picture of the
+user~\cite{pohlmann2017}.
+
+Prerequisites for error-free identification are a video camera with
+good video quality and a high-resolution image of the user on which
+the face can be clearly seen. The user should also not change their
+outward appearance too much over time. For example, growing or
+trimming a beard could lead to the VideoIdent-service employee not
+being able to recognise a user with sufficient confidence.
+
+For an attacker who looks similar to the user, there is a chance that
+the employee incorrectly confirms the identification.
+
+%CG: that's IMO then e-mail based verification, should not mix
+%    the two: this is basically multi-factor, so I'd leave it out here!
+%Therefore, some interaction of the user is needed like for example
+%telling the employee a short code which has been sent right before to
+%the user by mail.
+
+In Anastasis, pictures of users for VideoIdent authentication are
+considered private information stored encrypted at the providers.
+During the authentication process, the user has to provide the correct
+key for decryption to the service.
 
 \subsubsection{PostIdent}
-It is also possible to sent a verification code to the user by physical mail. 
Of course this authentication method takes some time and there is the 
possibility the physical mail gets intercepted or lost during transmission.\\
-Anastasis does not store the address of the user in clear text. Instead the 
address is encrypted before storing and the server gets to know the address 
only during authentication process of the user.
+
+It is also possible to sent a verification code to the user by
+physical mail. A major drawback of this authentication method is
+that it has high latency, and there is also the possibility that
+physical mail gets intercepted or lost during transmission.
+
+Anastasis providers using PostIndent would not store the address of
+their users in cleartext. Instead the address is encrypted by the user
+and the provider would receive the key to decrypt the address only
+during the authentication process.
 
 \subsubsection{Biometric authentication}
-Another way of authenticating is the biometric approach \cite{biometric_auth}. 
Biometric authentication is based on "something you are", like your iris or 
your fingerprint. There are also threats against biometric authentication. 
There are documented attacks against fingerprint and iris scan authentication. 
For example, a member of the German CCC e.V. was able to generate replicas from 
Angela Merkel's iris and Ursula von der Leyen's fingerprint \cite{ccc_merkel}.
 
+Another way of authenticating is the biometric
+approach~\cite{biometric_auth}. Biometric authentication is based on
+``something you are'', like your iris or your fingerprint.
+
+Biometric authentication is highly problematic because the attributes
+are invariant and frequently shared involuntarily.  Unlike passphrases
+or phone numbers, users cannot change their genome or fingerprint in
+case their private biometric information is exposed.  Furthermore,
+there are credible threats against biometric authentication, in
+paritcular there are documented inexpensive attacks against
+fingerprint and iris scan authentication. For example, a member of the
+German CCC e.V. was able to generate replicas from Angela Merkel's
+iris and Ursula von der Leyen's fingerprint~\cite{ccc_merkel}.
+
+
+
+\subsection{Existing solutions for key recovery}
+
+This section introduces some existing solutions for key recovery and
+why they are problematic.
+
+
+\subsubsection{Coinbase}
+
+Coinbase\footnote{\url{https://www.coinbase.com/}} is a global digital
+asset exchange company, providing a venue to buy and sell digital
+currencies. Coinbase also uses wallets secured with private keys. To
+recover this private key the user has to provide a 12 words recovery
+phrase.
+
+Coinbase offers a solution to securely deposit this recovery phrase
+onto the users Google Drive or iCloud.~\cite{coinbase} The security
+here lies within the Google or iCloud account and another password
+used to encrypt the security phrase. The problem here is that this
+approach undermines confidentiality, as encrypting a strong key with a
+weak key simply reduces the security to that of the weaker key.
+
+\subsubsection{MIDATA}
+
+MIDATA is a project that aims to give patients back control over their
+medical data and to enable them to share their data only with those
+they trust.\footnote{\url{https://www.midata.coop/}} In case a patient
+lost their device with the MIDATA-application and also forgot their
+MIDATA password, MIDATA provides a key recovery system using the
+Shamir Secret Sharing scheme (as described in
+Section~\ref{sec:rel:shamir}).
 
+In their case, a few ``persons working at MIDATA have generated a
+public-private key pair (Recovery key) on their own computer. They
+keep the private recovery key for themselves and never share it. The
+public keys are made public so that the apps can also access
+them''~\cite{midata}. Using Shamir's Secret Sharing the MIDATA
+application splits the user's app private key into 5 parts which are
+encrypted with one of the published recovery keys. The encrypted parts
+are then stored into the MIDATA server. During the recovery process at
+least two of the 5 parts need to be decrypted by the persons owning
+the private key part of the recovery key. ``The decrypted parts are
+sent to the server and {\em the server} may now reconstruct the app
+private key if enough parts of the key have been
+decrypted''~\cite{midata}. (Emphasis ours.)
+
+The security of MIDATA as described in ``Patient empowerment in IoT
+for eHealth - How to deal with lost keys?''~\cite{midata} is broken in
+two ways:
+
+\begin{enumerate}
+ \item The password is reconstructed at {\em the server}, not on the
+   patients device. An administrator of the server could thus
+   access the recovered password at that time.  It would be better
+   to reconstruct the password only on the patients device.
+ \item It is not clear which authentication methods the persons
+   working for MIDATA use for their decisions and activities regarding
+   the key recovery. The business process used here could be
+   vulnerable, and it is not clear whether multi-factor authentication
+   is used. As a result, we worry that it may be possible for an attacker
+   to successfully use social engineering via email (or other means)
+   to illegitimately trigger a recovery process.
+ \item The MIDATA system also does not offer any trust agility.
+   % FIXME: cite Moxie on trust agility!
+   The user is forced to accept the 2-out-of-5 rule with trustees
+   provided by MIDATA.
+\end{enumerate}

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.