[taler-anastasis] branch master updated: new /truth text in design

[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 5ee91df  new /truth text in design
     new f36a46f  Merge branch 'master' of git+ssh://git.taler.net/anastasis
5ee91df is described below

commit 5ee91dffd2e31f6462d06d884d313b5ff87f69b0
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Jun 11 12:11:09 2020 +0200

    new /truth text in design
---
 doc/thesis/design.tex | 305 ++++++++++++++++++++++++++------------------------
 1 file changed, 159 insertions(+), 146 deletions(-)

diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index dfeb8a2..4487ca2 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -169,107 +169,112 @@ monitors the user’s network traffic or operates an 
escrow provider).
 
 \subsection{Identity-derived encryption}
 
-When a user needs to interact with Anastasis, the system first derives
-some key material, but not the master secret, from the user’s
-identifier using different HKDFs.  These HKDFs are salted using the
-respective escrow provider’s server salt, which ensures that the
-accounts for the same user cannot be easily correlated across the
-various Anastasis servers.
-
-At each Anastasis server, an EdDSA-based account key is used to
-identify the account of the user. The account private key is derived
-from the user’s identifier using Aargon2, a computationally expensive
-cryptographic hash function. Using an expensive hash algorithm is
-assumed to make it harder for a weak adversary to determine
-user attributes by brute force guessing.
-However, it is assumed that a strong adversary performing
-a targeted attack can compute the account key pair.
-
-The public account key is Crockford base32-encoded in the URI to
-identify the account, and used to sign requests. These signatures are
-also provided in base32-encoding and transmitted using the HTTP header
-\texttt{Anastasis-Account-Signature}.
-
-When confidential data is uploaded to an Anastasis server, the
-respective payload is encrypted using AES-GCM with the respective
-symmetric key and initialization vector derived as show in
-Figure~\ref{fig:keys_anastasis} and a high-entropy
-nonce. The nonce and the GCM tag are prepended to the ciphertext
-before being uploaded to the Anastasis server. This is done whenever
-confidential data is stored with the server, so both for
-encrypted authentication data and encrypted recovery documents.
-
-The core secret of the user is (AES) encrypted using a symmetric
-master key. The result becomes part of the encrypted recovery
-document, which is cryptographically signed and thus further
-integrity protections for the core secret are unnecessary.
-Recovering the master key requires the user to satisfy a
-policy. Policies specify a set of escrow methods, each of which leads
-the user to a key share. Combining those key shares (by hashing)
-allows the user to obtain a policy key, which can be used to decrypt
-the master key.
-There can be many policies, satisfying any of these
-will allow the user to recover the master key. A recovery document
-contains the encrypted core secret, a set of escrow methods and a set
-of policies, including one encryption of the master key per policy.
-
-\subsection{Key derivations}
-
-EdDSA public keys are always points on Curve25519 and
-represented using the standard 256-bit Ed25519 compact format. The
-binary representation is converted to Crockford Base32 when
-transmitted inside JSON or as part of URLs in the RESTful API of
-Anastasis (see Section~\ref{sec:serverarch}).
-
 To start, a user provides their private (alas not really secret),
 unique and unforgettable identifier as a seed to identify their
 account. For example, this could be a social security number together
 with their full name. Specifics may depend on the cultural context, in
 this document we will simply refer to this information as the
-identifier.
+{\em user attributes}.
+
+For each Anastasis provider, a {\em kdf id} key is derived from the
+user’s attributes and a provider salt using Aargon2~\cite{BDK2016}, a
+computationally expensive cryptographic hash function. Using an
+expensive hash algorithm is assumed to make it harder for a weak
+adversary to determine user attributes by brute force guessing.  The
+salt ensures that the keys for the same user cannot be easily
+correlated across the various Anastasis servers.  However, it is
+assumed that a strong adversary performing a targeted attack can
+compute the {\em kdf id}s.
 
-This identifier will be first hashed with Argon2, to provide a kdf\_id
-which will be used to derive other keys later. The hash must also be
-made over the respective provider's server\_salt. This ensures that
-the kdf\_id is different on each server. The use of Argon2 and the
-respective server\_salt are intended to make it difficult to
-brute-force kdf\_id values and help protect user’s privacy. Also this
-ensures that the kdf\_ids on every server differs. However, we do not
-assume that the identifier or the kdf\_id cannot be determined by an
-adversary performing a targeted attack, as a user’s identifier is
-likely to always be known to state actors and may likely also be
-available to other actors.
+The listing in Figure~\ref{fig:argon2} provides pseudo-code for
+the computation of the {\em kdf id}. The inputs are:
 
+\begin{description}
+       \item[attributes] {The personal attributes provided by the user.}
+       \item[server\_salt]{The salt from the Anastasis provider.}
+       \item[keysize]{The desired output size of the KDF, here 32 bytes.}
+\end{description}
+
+\begin{figure}
 \begin{lstlisting}
-user_identifier_derive(identifier, server_salt, keysize)
+user_identifier_derive(attributes, server_salt, keysize)
 {
-  kdf_id = Argon2(identifier, server_salt, keysize)
+  kdf_id = Argon2(attributes, server_salt, keysize)
   return kdf_id
 }
 \end{lstlisting}
+\caption{The user's attributes are hashed with Argon2, to provide a
+  kdf\_id which will be used to derive other keys later. The hash must
+  also be made over the respective provider's server\_salt. This
+  ensures that the kdf\_id is different on each server. The use of
+  Argon2 and the respective server\_salt are intended to make it
+  difficult to brute-force kdf\_id values and help protect user’s
+  privacy. Also this ensures that the kdf\_ids on every server
+  differs. However, we do not assume that the identifier or the
+  kdf\_id cannot be determined by an adversary performing a targeted
+  attack, as a user’s identifier is likely to always be known to state
+  actors and may likely also be available to other actors.}
+\label{fig:argon2}
+\end{figure}
 
-\begin{description}
-       \item[identifier] {The secret defined from the user beforehand.}
-       \item[server\_salt]{The salt from the Server.}
-       \item[keysize]{The desired output size of the KDF, here 32 bytes.}
-\end{description}
 
-\subsection{Verification}
+\subsection{The recovery document}
 
-For users to authorize “policy” operations we need an EdDSA key
-pair. As we cannot assure that the corresponding private key is truly
-secret, such policy operations must never be destructive: Should an
-adversary learn the private key, they could access (and with the
-kdf\_id decrypt) the user’s policy (but not the core secret), or
-upload a new version of the encrypted recovery document (but not
-delete an existing version).
+The {\em core secret} of the user is (AES) encrypted using a symmetric
+{\em master key}.  Recovering the master key requires the user to
+satisfy a {\em policy}. Policies specify a set of escrow methods, each
+of which leads the user to a {\em key share}. Combining those key
+shares (by hashing) allows the user to obtain a policy key, which can
+be used to decrypt the master key.  There can be many policies,
+satisfying any of these will allow the user to recover the master key.
+
+Which escrow methods are combined into which policies and which
+providers are involved can be different for each user. As users are
+unlikely to remember all the details, Anastasis needs a way to
+remember the specific configuration a user made.
+
+This process description is provided in a {\em recovery document}.  A
+recovery document includes a set of escrow methods and a set of
+policies, including one encryption of the master key per policy, and
+the encrypted core secret.  For each escrow method, the recovery
+document includes authentication method-specific details, a {\em truth
+  seed} and the URL of the escrow provider.
+
+% Figure~\ref{fig:recoverydoc} gives an example for a the contents of
+% a recovery document.
+% FIXME: actually include example!
+
+\subsection{Authenticity of recovery documents}
+
+At each Anastasis server, an EdDSA-based {\em account key} is used to
+identify the ``account'' of the user.  EdDSA public keys are always points
+on Curve25519 and represented using the standard 256-bit Ed25519
+compact format. The binary representation is converted to Crockford
+Base32 when transmitted inside JSON or as part of URLs in the RESTful
+API of Anastasis (see Section~\ref{sec:serverarch}).  EdDSA signatures
+are also provided in Crockford Base32-encoding and transmitted using
+the HTTP header \texttt{Anastasis-Account-Signature}.  Encrypted
+recovery documents are stored using the public account key as the
+identifier.
 
-For the generation of the private key we use the kdf\_id as the
+\texttt{/policy/} requests are used to upload new encrypted recovery
+documents. For users to authorize \texttt{/policy} operations, we need an
+account key pair.  The account keys are derived from the {\em kdf id}
+(see Figure~\ref{fig:keys_anastasis}).  Hence, we cannot assure that
+the corresponding private account key is truly secret. Thus, policy
+operations must never be destructive: A strong adversary can derive
+the private key and access (and with the {\em kdf id} also decrypt)
+the user’s recovery document (but not the core secret!), and also
+upload a new version of the encrypted recovery document. However,
+because uploads are not destructive, even a strong adversary cannot
+delete an existing version and thus cannot break availability.
+
+For the generation of the private key we use the {\em kdf id} as the
 entropy source, hash it to derive a base secret which will then be
 processed to fit the requirements for EdDSA private keys. From the
 private key we can then generate the corresponding public key. Here,
 the string “ver” is used for the salt value for the HKDF to ensure
-that the result differs from other cases where we hash kdf\_id.
+that the result differs from other cases where we hash {\em kdf id}:
 
 \begin{lstlisting}
 eddsa_keys_create (kdf_id, salt, keysize)
@@ -301,16 +306,80 @@ digest[31] &= 0xf8;
 \end{description}
 
 
-\subsection{Symmetric encryption}
+\subsection{Account signatures}
+
+The EdDSA account keys are used to sign the encrypted recovery
+document sent from the client to the server.
+
+% FIXME: "everything"? I don't think we can sign the encrypted truth
+% with the eddsa_priv, as that would link the truth to the ERD.
+% We need ANOTHER acocunt key here, one per truth + provider?
+
+\begin{lstlisting}
+(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
+ver_res =
+  eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub)
+\end{lstlisting}
+
+\begin{description}
+       \item[anastasis-account-signature] {Signature over the SHA-512 hash of 
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_UPLOAD 
(1400) (see GNUnet EdDSA signature API for the use of purpose).}
+       \item[h\_body] {The hashed body.}
+       \item[ver\_res] {A Boolean value. True: Signature verification passed, 
False: Signature verification failed.}
+\end{description}
+
+\noindent
+When requesting \texttt{/policy} downloads, the client must also provide a 
signature:
+\begin{lstlisting}
+(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
+ver_res =
+  eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
+\end{lstlisting}
+
+\begin{description}
+       \item[anastasis-account-signature] {Signature over the SHA-512 hash of 
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD  
\\
+       (1401) (see GNUnet EdDSA signature API for the use of purpose).}
+       \item[version] {The version requested as a 64-bit integer, for the 
“latest version”.}
+       \item[ver\_res] {A Boolean value. True: Signature verification passed, 
False: Signature verification failed.}
+\end{description}
+
+
+\subsection{Authenticity of truth}
+
+\texttt{/truth/} requests are used to upload encrypted authentication data
+and encrypted key shares to an Anastasis escrow service.  As an additional
+layer of protection, an Anastasis escrow service cannot link truth data to
+policy data, except maybe by observing the timing of the requests.
+
+Anastasis uses EdDSA-based {\em truth key}s to identify truth
+objects. For those, the truth keys are derived from a {\em truth
+  seed}, as show in Figure~\ref{fig:truth_keys}.  The private truth
+key is used to authorize the truth upload. The signatures also
+authenticate the encrypted key shares returned from the Anastasis
+provider during recovery.  The signature process for truth is
+analogous to that for accounts.
+
 
-For symmetric encryption of data, we use AES256-GCM. For this we need
-a symmetric key and an initialization vector (IV). To ensure that the
-symmetric key changes for each encryption operation, we compute the
-key material using an HKDF over a nonce and the kdf\_id. Additionally,
-a salt is added so the encryption keys differ
-fundamentally for different types of operations.
-For example, for the recovery document key the string "erd" is used
-for the salt.
+\subsection{Symmetric key derivations}
+
+In addition to the account private key, Anastasis derives symmetric
+key material --- but not the master secret --- from the {\em kdf id}
+using different HKDFs~\cite{krawczyk2010}.
+
+When confidential data --- such as the recovery document or the truth
+--- is uploaded to an Anastasis server, the respective payload is
+encrypted using AES-GCM with the respective symmetric key and
+initialization vector derived key material as shown in
+Figure~\ref{fig:keys_anastasis} and a high-entropy nonce.  The nonce
+and the GCM tag are prepended to the ciphertext before being uploaded
+to the Anastasis server. This is done whenever confidential data is
+stored with the server, so both for encrypted authentication data
+(\texttt{/truth} uploads) and encrypted recovery documents
+(\texttt{/policy} uploads).
+
+To ensure that the key derivation for the encryption of the recovery
+document differs fundamentally from that of an individual key share,
+we use different salts for different types of operations (“erd” and
+“eks” respectively):
 
 \begin{lstlisting}
 encryption_key_create(kdf_id, salt, nonce)
@@ -330,25 +399,6 @@ encryption_key_create(kdf_id, salt, nonce)
        \item[iv] {IV which will be used for AES-GCM.}
 \end{description}
 
-The keys we have generated are then used to encrypt the \textbf{recovery 
document} and the \textbf{key\_share} of the user.
-
-% FIXME: key_share??? I thought the truth!
-
-
-Before every encryption a 32-byte nonce is generated. From this the
-symmetric key is computed as described above. We use AES256-GCM for
-the encryption of the recovery document and the key\_share.
-% Why the key share??? That we SHOULD AES-encrypt and then EdDSA-sign
-% so that we can check that the server returned the right truth,
-% but for AES-GCM I'd expect us to use that for the encryption of the
-% truth (and the AES-k2-encrypted key share).
-%
-% FIXME: we should discuss how to protect against Anastasis providers
-% that return a bogus EKS.
-To ensure
-that the key derivation for the encryption of the recovery document
-differs fundamentally from that of an individual key share, we use
-different salts (“erd” and “eks” respectively).
 
 \begin{lstlisting}
 encrypt(kdf_id, data, salt)
@@ -383,43 +433,6 @@ recovery_document_encrypt(kdf_id, recovery_document)
 \end{description}
 
 
-\subsection{Signatures}
-
-The EdDSA keys are used to sign the data sent from the client to the
-server. Everything the client sends to server is signed. An equivalent
-algorithm is also used to generate the
-\texttt{Anastasis-Policy-Signature}.
-
-% FIXME: "everything"? I don't think we can sign the encrypted truth
-% with the eddsa_priv, as that would link the truth to the ERD.
-% We need ANOTHER acocunt key here, one per truth + provider?
-
-\begin{lstlisting}
-(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
-ver_res =
-  eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub)
-\end{lstlisting}
-
-\begin{description}
-       \item[anastasis-account-signature] {Signature over the SHA-512 hash of 
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_UPLOAD 
(1400) (see GNUnet EdDSA signature API for the use of purpose).}
-       \item[h\_body] {The hashed body.}
-       \item[ver\_res] {A Boolean value. True: Signature verification passed, 
False: Signature verification failed.}
-\end{description}
-
-\noindent
-When requesting policy downloads, the client must also provide a signature:
-\begin{lstlisting}
-(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
-ver_res =
-  eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
-\end{lstlisting}
-
-\begin{description}
-       \item[anastasis-account-signature] {Signature over the SHA-512 hash of 
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD  
\\
-       (1401) (see GNUnet EdDSA signature API for the use of purpose).}
-       \item[version] {The version requested as a 64-bit integer, for the 
“latest version”.}
-       \item[ver\_res] {A Boolean value. True: Signature verification passed, 
False: Signature verification failed.}
-\end{description}
 
 
 \subsection{Availability considerations}

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