[taler-anastasis] branch master updated: bridge doc and design

[gnunet]

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

ds-meister pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new 470ec6c  bridge doc and design
470ec6c is described below

commit 470ec6cd7706cf66a3006153ad90bf9ac3d40d62
Author: Dominik Meister <address@hidden>
AuthorDate: Wed Feb 26 23:46:19 2020 +0100

    bridge doc and design
---
 doc/bridge/bridge.doc | Bin 99242 -> 115931 bytes
 doc/thesis/design.tex | 143 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 143 insertions(+)

diff --git a/doc/bridge/bridge.doc b/doc/bridge/bridge.doc
index ec1cf0b..7e3383a 100644
Binary files a/doc/bridge/bridge.doc and b/doc/bridge/bridge.doc differ
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
new file mode 100644
index 0000000..8bd3e54
--- /dev/null
+++ b/doc/thesis/design.tex
@@ -0,0 +1,143 @@
+\section{Design}
+Anastasis is a service that allows the user to securely deposit a core secret 
with an open set of escrow providers and recover it if the secret is lost. The 
core secret itself is protected from the escrow providers by encrypting it with 
a master key. The main objective of Anastasis is to ensure that the user can 
reliably recover the core secret, while making this difficult for everyone 
else. Furthermore, it is assumed that the user is unable to reliably remember 
any secret with sufficien [...]
+
+To uniquely identify users, an “unforgettable” identifier is used. This 
identifier should be difficult to guess for anybody but the user. However, the 
identifier is not expected to have sufficient entropy or secrecy to be 
cryptographically secure. Examples for such identifier would be a concatenation 
of the full name of the user and their social security or passport number(s). 
For Swiss citizens, the AHV number could also be used.
+
+The adversary model of Anastasis has two types of adversaries: weak 
adversaries which do not know the user’s identifier, and strong adversaries 
which somehow do know a user’s identifier. For weak adversaries the system 
guarantees full confidentiality. For strong adversaries, breaking 
confidentiality additionally requires that Anastasis escrow providers must have 
colluded. The user is able to specify a set of policies which determine which 
Anastasis escrow providers would need to collude  [...]
+
+A recovery document includes all of the information a user needs to recover 
access to their core secret. It specifies a set of escrow methods, which 
specify how the user should convince the Anastasis server that they are “real”. 
Escrow methods can for example include SMS-based verification, 
Video-identfication or a security question. For each escrow method, the 
Anastasis server is provided with truth, that is data the Anastasis operator 
may learn during the recovery process to authentica [...]
+
+\subsection{Cryptography}
+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.
+
+Each Anastasis server uses an EdDSA account key to identify the account of the 
user. The account private key is derived from the user’s identifier using a 
computationally expensive cryptographic hash function. Using an expensive hash 
algorithm is assumed to make it infeasible for a weak adversary to determine 
account keys by brute force (without knowing the user’s identifier). 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 
“Anastasis-Account-Signature”.
+
+When confidential data is uploaded to an Anastasis server, the respective 
payload is encrypted using AES-GCM with a symmetric key and initialization 
vector derived from the identifier 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.
+
+The core secret of the user is (AES) encrypted using a symmetric master key. 
Recovering this master key requires the user to satisfy a particular 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 contain [...]
+
+\subsection{Key Derivations}
+EdDSA and ECDHE 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.
+
+To start, a user provides their private, 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.
+
+This identifier will be first hashed with SCrypt, to provide a kdf\_id which 
will be used to derive other keys later. The Hash must also include the 
respective server\_salt. This also ensures that the kdf\_id is different on 
each server. The use of SCrypt and the respective server\_salt is 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 o [...]
+\begin{lstlisting}
+kdf_id := SCrypt( identifier, server_salt, keysize )
+\end{lstlisting}
+
+\textbf{identifier}: The secret defined from the user beforehand. \\
+
+\textbf{server\_salt}: The salt from the Server \\
+
+\textbf{keysize}: The desired output size of the KDF, here 32 bytes. \\
+
+\subsection{Verification}
+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).
+
+For the generation of the private key we use the 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, “ver” is used as a salt for the HKDF to 
ensure that the result differs from other cases where we hash kdf\_id.
+\begin{lstlisting}
+ver_secret:= HKDF(kdf_id, "ver", keysize) 
+eddsa_priv := eddsa_d_to_a(ver_secret) 
+eddsa_pub := get_EdDSA_Pub(eddsa_priv) 
+\end{lstlisting}
+
+\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512 
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
+
+\textbf{kdf\_id}: Hashed identifier. \\
+
+\textbf{key\_size}: Size of the output, here 32 bytes. \\
+
+\textbf{ver\_secret}: Derived key from the kdf\_id, serves as intermediate 
step for the generation of the private key. \\
+
+\textbf{eddsa\_d\_to\_a()}: Function which converts the ver\_key to a valid 
EdDSA private key. Specifically, assuming the value eddsa\_priv is in a 32-byte 
array “digest”, the function clears and sets certain bits as follows: \\
+
+\begin{lstlisting}
+digest[0] = (digest[0] & 0x7f) | 0x40; 
+digest[31] &= 0xf8;
+\end{lstlisting}
+
+\textbf{eddsa\_priv}: The generated EdDSA private key. \\
+
+\textbf{eddsa\_pub}: The generated EdDSA public key. \\
+
+\subsection{Encryption}
+
+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.
+
+\begin{lstlisting}
+(iv,key) := HKDF(kdf_id, nonce, keysize + ivsize)
+\end{lstlisting}
+
+\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512 
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
+
+\textbf{kdf\_id}: Hashed identifier \\
+
+\textbf{keysize}: Size of the AES symmetric key, here 32 bytes \\
+
+\textbf{ivsize}: Size of the AES GCM IV, here 12 bytes \\
+
+\textbf{prekey}: Original key material. \\
+
+\textbf{nonce}: 32-byte nonce, must never match “ver” (which it cannot as the 
length is different). Of course, we must avoid key reuse. So, we have to use 
different nonces to get different keys and ivs (see below). \\
+
+\textbf{key}: Symmetric key which is later used to encrypt the documents with 
AES256-GCM. \\
+
+\textbf{iv}: IV which will be used for AES-GCM \\
+
+\subsection{Key usage}
+
+The keys we have generated are then used to encrypt the \textbf{recovery 
document} and the \textbf{key\_share} of the user.
+
+\subsubsection{Encryption}
+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. 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}
+(iv0, key0) = HKDF(key_id, nonce0, "erd", keysize + ivsize)
+(encrypted_recovery_document, aes_gcm_tag) = AES256_GCM(recovery_document, 
key0, iv0) 
+(iv_i, key_i) = HKDF(key_id, nonce_i, "eks", [optional data], keysize + 
ivsize) 
+(encrypted_key_share_i, aes_gcm_tag_i) = AES256_GCM(key_share_i, key_i, iv_i) 
+\end{lstlisting}
+
+\textbf{encrypted\_recovery\_document}: The encrypted recovery document which 
contains the escrow methods, policies and the encrypted core secret. \\
+
+\textbf{nonce0}: Nonce which is used to generate key0 and iv0 which are used 
for the encryption of the recovery document. Nonce must contain the string 
“ERD”. \\
+
+\textbf{optional data}: Key material that optionally is contributed from the 
authentication method to further obfuscate the key share from the escrow 
provider. \\
+
+\textbf{encrypted\_key\_share\_i}: The encrypted key\_share which the escrow 
provider must release upon successful authentication. Here, i must be a 
positive number used to iterate over the various key shares used for the 
various escrow methods at the various providers. \\
+nonce\_i
+\textbf{nonce\_i}: Nonce which is used to generate key\_i and iv\_i which are 
used for the encryption of the key share. i must be the same number as 
specified above for encrypted\_key\_share\_i. Nonce must contain the string 
“EKS” plus the according i. \\
+
+\subsubsection{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. The following algorithm is 
equivalent for Anastasis-Policy-Signature.
+
+\begin{lstlisting}
+(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv) 
+ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub
+\end{lstlisting}
+
+\textbf{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) \\
+
+\textbf{h\_body}: The hashed body. \\
+
+\textbf{ver\_res}: A boolean value. True: Signature verification passed, 
False: Signature verification failed. \\
+\\
+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}
+
+\textbf{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) \\
+
+\textbf{version}: The version requested as a 64-bit integer, for the “latest 
version”. \\
+
+\textbf{ver\_res}: A boolean value. True: Signature verification passed, 
False: Signature verification failed. \\
+
+\subsection{Availability Considerations}
+Anastasis considers two main threats against availability. First, the 
Anastasis server operators must be protected against denial-of-service attacks 
where an adversary attempts to exhaust operator’s resources. The API protects 
against these attacks by allowing operators to set fees for all operations. 
Furthermore, all data stored comes with an expiration logic, so an attacker 
cannot force servers to store data indefinitively.
+
+A second availability issue arises from strong adversaries that may be able to 
compute the account keys of some user. While we assume that such an adversary 
cannot successfully authenticate against the truth, the account key does 
inherently enable these adversaries to upload a new policy for the account. 
This cannot be prevented, as the legitimate user must be able to set or change 
a policy using only the account key. To ensure that an adversary cannot exploit 
this, policy uploads first  [...]

-- 
To stop receiving notification emails like this one, please contact
address@hidden.