[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated: restructure design vs implement
|
From: |
gnunet |
|
Subject: |
[taler-anastasis] branch master updated: restructure design vs implementation |
|
Date: |
Sun, 07 Jun 2020 13:34:17 +0200 |
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 7691157 restructure design vs implementation
7691157 is described below
commit 7691157a20c98579c09a6ae0c19af05ffa5b259e
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Jun 7 13:34:15 2020 +0200
restructure design vs implementation
---
doc/thesis/design.tex | 450 ++++++++++++++++++++++------------------
doc/thesis/implementation.tex | 465 +++++++++++++++++++-----------------------
2 files changed, 461 insertions(+), 454 deletions(-)
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 59ac7ea..97ee756 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -62,205 +62,267 @@ approximate creation time, which may be exposed to an
adversary which
monitors the user’s network traffic or operates an escrow provider).
-\subsection{System architecture}
-
-This graphic shows the basic architecture of the Anastasis
-application. It shows a simplified flow of the application. The
-details of each component are explained later.
-
-\begin{figure}[H]
- % FIXME: _handle => handler (!)
- \centering
- \includegraphics[scale=0.4]{images/system_design.png}
- \caption{System design overview}
- \label{fig:system_design}
-\end{figure}
-
-\begin{enumerate}
-\item The Anastasis CLI interacts with the Anastasis API. The
- Anastasis API is responsible for triggering interactions with the
- user, and also manages the interactions between the
- various client-side components.
-\item After the user provided their unforgettable secret, the
- Crypto API derives the needed key material for the further
- communication. This is simplified, in reality the client would first
- need to download the server salt to generate the user keys. The
- crypto API is later also responsible for the decryption and
- encryption of the data, sent or received from the server.
-\item The Service API is responsible for the communication with the
- Anastasis server. The Anastasis API sends the previously generated
- data and the user selected request to the service.
- The Service API is also responsible to handle
- the server's response to the request.
-\item The central webserver logic handles HTTP requests sent to it by the
- clients. It will dispatch requests to the corresponding handler. The
- webserver's core logic also returns the response and the status code
- of the operation to the client application.
-\item Each REST endpoint of the Anastasis server is implemented by
- a specific handler. The handler prcesses the requests, typically
- by storing or looking up the requested
- data with the database. When the request is finished, the handler will
- send back the data or the status code to the webserver's core logic.
-\end{enumerate}
-
-
-\input{server_architecture}
-
-\input{client_architecture}
-
-
-
-\subsection{Client Application Command Line Interface (CLI)}
-
-There are two client applications which interact with the user. First
-the Anastasis {\em splitter} and second the Anastasis {\em
- assembler}. The splitter application is responsible for the backup
-of the core secret. The assembler is then responsible for the recovery
-of the core secret.
-
-Both commands are started with a configuration option ``--me=FILE''
-that gives the name of a file with the user's identity attributes.
-
-\subsubsection{Anastasis splitter}
-
-The user starts the assembler by passing a JSON document with their
-unforgetable identity attributes (name, social security number, ...).
-
-The following commands are available:
-
-\begin{itemize}
-\item server add \$URL: this command lets the user add escrow
- providers. The command will check if a supported escrow service is
- available under the provided URL. Afterwards it will download its
- terms and salt. The server needs to be added before the user can do
- any uploads on it.
-\item truth add \$server \$method \$truth: with this command the user
- can upload a truth on a previously added server. The user needs to
- specify the authorization method used and the truth for the
- authorization process, for example the phone number for SMS
- authentication. The programm will check if the server supports the
- provided method before uploading.
-\item policy add \$truth1 \$truth2...: after a user has added all the
- truths, per can start to create policies. Per can combine the truths
- in any way they wish. It is also possible to just store one truth in
- a policy, but this is not recommended since it defies the design of
- the application.
-\item policy: shows all created policies.
-\item truth: shows all created truths.
-\item server: shows all added servers.
-\item publish \$secret: if the user is finished per can publish the
- configuration. The application will then generate the recovery
- document with the provided information and secret. Afterwards, it
- will upload the recovery document on every server that was used. For
- recovery, the user only needs to remember any one of the servers.
-\end{itemize}
-
-Below is an example transcript of an interaction with the splitter:
+
+
+\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
+\texttt{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
+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.
+
+\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 Argon2, 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 Argon2 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 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.
+
+\begin{lstlisting}
+user_identifier_create(identifier, server_salt, keysize)
+{
+ kdf_id = Argon2(identifier, server_salt, keysize)
+ return kdf_id
+}
+\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}
+eddsa_keys_create (kdf_id, salt, keysize)
+{
+ver_secret = HKDF(kdf_id, salt, keysize)
+eddsa_priv = eddsa_d_to_a(ver_secret)
+eddsa_pub = get_eddsa_pub(eddsa_priv)
+return eddsa_priv, eddsa_pub
+}
+\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{salt}: used that different keys are generated, the salt here is "ver".
\\
+
+\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. Additionally,
+a salt is added so the different encryption keys differ
+fundamentally. For example for the recovery document key the salt
+"erd" is added.
+
+\begin{lstlisting}
+encryption_key_create(kdf_id, salt, nonce)
+{
+iv, key = HKDF (kdf_id, nonce, salt, keysize + ivsize)
+return iv,key
+}
+\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{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 must 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}
+encrypt(kdf_id, data, salt)
+{
+ nonce = generate_random_bytes(32)
+ iv, key = encryption_key_create(kdf_id, salt, nonce)
+ encrypted_data, aes_gcm_tag = AES256_GCM(data, iv, key)
+ encrypted_data = nonce + aes_gcm_tag + encrypted_data
+ return encrypted_data
+}
+
+key_share_encrypt(kdf_id, key_share)
+{
+ encrypted_key_share = encrypt(kdf_id, key_share, "eks")
+ return encrypted_key_share
+}
+recovery_document_encrypt(kdf_id, recovery_document)
+{
+ encrypted_recovery_document = encrypt(kdf_id, recovery_document, "erd")
+ return encrypted_recovery_document
+}
+
+\end{lstlisting}
+
+\textbf{encrypted\_recovery\_document}: The encrypted recovery document which
contains the escrow methods, policies and the encrypted core secret. \\
+
+\textbf{encrypted\_key\_share}: The encrypted key\_share which the escrow
provider must release upon successful authentication.\\
+
+\textbf{nonce}: Nonce which is used to generate keys and ivs which are used
for the encryption. The nonce must contain either eks or erd.
+
+\textbf{encrypted\_data}: The encrypted data contains the either a recovery
document or a key share which was encrypted and the nonce and the
aes\_gcm\_tag. To be able to decrypt it the first 32Bytes are the nonce and the
next 12 Bytes are the
+aes\_gcm\_tag.
+
+\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-splitter --me=identity.json
-anastasis-splitter> server add $URL1
-version: 1.0
-annual fee: EUR:4.99,
-available policy methods: sms
-Server #1 available
-anastasis-splitter> server add $URL2
-version: 1.0
-annual fee: EUR:3.99,
-available policy methods: sms, question
-Server #2 available
-anastasis-splitter> truth add server#1 sms +492452526
-Truth #1 added for server #1
-anastasis-splitter> truth add server#2 mail "hoehenweg 80, Biel"
-Sorry, server #2 does not support 'mail'
-anastasis-splitter> truth add question "favorite color" "red"
-Truth #2 added
-anastasis-splitter> policy add truth#1 truth#2
-Policy #1 defined
-anastasis-splitter> policy
-Policy#1: #truth#1 #truth2
-anastasis-splitter> truth
-truth#1: server#1 sms +492452526
-truth#2: server#2 question "favorite color" <OMITTED>
-anastasis-splitter> truth --secrets
-truth#1: sms +492452526
-truth#2: question "favorite color" "red"
-anastasis-splitter> server
-server#1: http://anastasis.example.com/ methods: sms,
-insured up to: 420 KUDOS, cost: 0.4 KUDOS
-anastasis-splitter> publish
-Server#1 failure: 402 payment required:
-payto://pay/ABALSASDFA KUDOS:0.3
-Server#2 failure: 402 payment required:
-payto://pay/ABALSAADAS KUDOS:0.5
-Total: 0.8 KUDOS
-# Here: taler-wallet-cli payto://pay/ABALASDFA used to pay!
-anastasis-splitter> publish
-Server#2 failure: 402 payment required
-# Here: taler-wallet-cli payto://pay/ABASDFASDF used to pay!
-anastasis-splitter> publish "my super secret"
-Thank you for using Anastasis.
-$
+(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) \\
-\subsubsection{Anastasis assembler}
-
-The user starts the assembler by passing a JSON document with their
-unforgetable identity attributes (name, social security number, ...).
-They also must pass the URL of an escrow provider which stores their
-recovery document, as well as the requested version of the recovery
-document. The assembler will then download and decrypt the recovery
-document and begin the recovery process.
-
-
-The following commands are available:
-\begin{itemize}
-\item truth: shows all available authorization challenges
- from the recovery document and their status (``(-)'' not solved, ``(+)''
solved)
-\item policies: shows all available policies in the recovery document and
- the respective status of the truths used in each policy.
-\item try \$truth: this command starts an authorization process which
- needs interaction with external services like SMS or email. It shows
- the instructions to follow to authorize release of the share.
-\item answer \$truth \$answer: this command tries to answer the
- selected challenge with the provided answer. The application will
- check the answer and give a feedback to the user. Everytime a
- challenge is solved, the client API will check if as a result any of
- the policies is completely satisfied. If any policy was completely
- satisfied, the assembler will print out the recovered core secret
- and exit.
-\end{itemize}
-
-Below is an example transcript of an interaction with the assembler:
+\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-assembler --import https://anastasis.example.com/
---policy-version=42 --me=identity.json
-anastasis-assembler> truth
-truth#1(-): KUDOS 0.0 question "favorite color"
-truth#2(-): KUDOS 0.4 sms
-truth#3(-): KUDOS 2.6 post
-anastasis-assembler> policies
-policy#1: KUDOS 0.4 truth#1 truth#2 missing
-policy#2: KUDOS 3.0 truth#1 truth#2 truth#3 missing
-anastasis-assembler> try truth#2
-payto://pay/BASDFASD
-# SMS arrives asynchronously
-anastasis-assembler> answer truth#2 1234
-Success truth#2
-anastasis-assembler> answer truth#1 "blue"
-Failed truth#1
-anastasis-assembler> truth
-truth#1(-): KUDOS 0.0 question "favorite color"
-truth#2(+): KUDOS 0.4 sms
-truth#3(-): KUDOS 2.6 post
-anastasis-assembler> policies
-policy#1: KUDOS 0.0 truth#1 missing
-policy#2: KUDOS 2.6 truth#1 truth#3 missing
-anastasis-assembler> answer truth#2 "red"
-Success truth#2
-//One of the policies was solved successfully and the secret is recovered.
-Secret was: "my super secret"
-$
+(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 indefinitely.
+
+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 successfuly 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 of all never delete existing policies, but merely create
+another version. This way, even if an adversary uploads a malicious
+policy, a user can still retrieve an older version of the policy to
+recover access to their data. This append-only storage for policies
+still leaves a strong adversary with the option of uploading many
+policies to exhaust the Anastasis server’s capacity. We limit this
+attack by requiring a policy upload to include a reference to a
+payment identifier from a payment made by the user. Thus, a policy
+upload requires both knowledge of the identity and making a
+payment. This effectively prevents and adversary from using the
+append-only policy storage from exhausting Anastasis server capacity.
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 7012449..2fb65a5 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -29,6 +29,54 @@ At the bottom section are the external libraries used for
the project.
These libraries are presented in Section~\ref{sec:libraries}.
+
+\subsection{System architecture}
+
+This graphic shows the basic architecture of the Anastasis
+application. It shows a simplified flow of the application. The
+details of each component are explained later.
+
+\begin{figure}[H]
+ % FIXME: _handle => handler (!)
+ \centering
+ \includegraphics[scale=0.4]{images/system_design.png}
+ \caption{System design overview}
+ \label{fig:system_design}
+\end{figure}
+
+\begin{enumerate}
+\item The Anastasis CLI interacts with the Anastasis API. The
+ Anastasis API is responsible for triggering interactions with the
+ user, and also manages the interactions between the
+ various client-side components.
+\item After the user provided their unforgettable secret, the
+ Crypto API derives the needed key material for the further
+ communication. This is simplified, in reality the client would first
+ need to download the server salt to generate the user keys. The
+ crypto API is later also responsible for the decryption and
+ encryption of the data, sent or received from the server.
+\item The Service API is responsible for the communication with the
+ Anastasis server. The Anastasis API sends the previously generated
+ data and the user selected request to the service.
+ The Service API is also responsible to handle
+ the server's response to the request.
+\item The central webserver logic handles HTTP requests sent to it by the
+ clients. It will dispatch requests to the corresponding handler. The
+ webserver's core logic also returns the response and the status code
+ of the operation to the client application.
+\item Each REST endpoint of the Anastasis server is implemented by
+ a specific handler. The handler prcesses the requests, typically
+ by storing or looking up the requested
+ data with the database. When the request is finished, the handler will
+ send back the data or the status code to the webserver's core logic.
+\end{enumerate}
+
+
+\input{server_architecture}
+
+\input{client_architecture}
+
+
\subsection{Application flow}
This section describes a happy flow of the two protocols of Anastasis,
@@ -130,6 +178,163 @@ provide for example the PIN sent to them via SMS with the
same request
as before (GET /truth/\$UUID?resonse=\$RESPONSE).
+\subsection{Client Application Command Line Interface (CLI)}
+
+There are two client applications which interact with the user. First
+the Anastasis {\em splitter} and second the Anastasis {\em
+ assembler}. The splitter application is responsible for the backup
+of the core secret. The assembler is then responsible for the recovery
+of the core secret.
+
+Both commands are started with a configuration option ``--me=FILE''
+that gives the name of a file with the user's identity attributes.
+
+\subsubsection{Anastasis splitter}
+
+The user starts the assembler by passing a JSON document with their
+unforgetable identity attributes (name, social security number, ...).
+
+The following commands are available:
+
+\begin{itemize}
+\item server add \$URL: this command lets the user add escrow
+ providers. The command will check if a supported escrow service is
+ available under the provided URL. Afterwards it will download its
+ terms and salt. The server needs to be added before the user can do
+ any uploads on it.
+\item truth add \$server \$method \$truth: with this command the user
+ can upload a truth on a previously added server. The user needs to
+ specify the authorization method used and the truth for the
+ authorization process, for example the phone number for SMS
+ authentication. The programm will check if the server supports the
+ provided method before uploading.
+\item policy add \$truth1 \$truth2...: after a user has added all the
+ truths, per can start to create policies. Per can combine the truths
+ in any way they wish. It is also possible to just store one truth in
+ a policy, but this is not recommended since it defies the design of
+ the application.
+\item policy: shows all created policies.
+\item truth: shows all created truths.
+\item server: shows all added servers.
+\item publish \$secret: if the user is finished per can publish the
+ configuration. The application will then generate the recovery
+ document with the provided information and secret. Afterwards, it
+ will upload the recovery document on every server that was used. For
+ recovery, the user only needs to remember any one of the servers.
+\end{itemize}
+
+Below is an example transcript of an interaction with the splitter:
+
+\begin{lstlisting}
+$ anastasis-splitter --me=identity.json
+anastasis-splitter> server add $URL1
+version: 1.0
+annual fee: EUR:4.99,
+available policy methods: sms
+Server #1 available
+anastasis-splitter> server add $URL2
+version: 1.0
+annual fee: EUR:3.99,
+available policy methods: sms, question
+Server #2 available
+anastasis-splitter> truth add server#1 sms +492452526
+Truth #1 added for server #1
+anastasis-splitter> truth add server#2 mail "hoehenweg 80, Biel"
+Sorry, server #2 does not support 'mail'
+anastasis-splitter> truth add question "favorite color" "red"
+Truth #2 added
+anastasis-splitter> policy add truth#1 truth#2
+Policy #1 defined
+anastasis-splitter> policy
+Policy#1: #truth#1 #truth2
+anastasis-splitter> truth
+truth#1: server#1 sms +492452526
+truth#2: server#2 question "favorite color" <OMITTED>
+anastasis-splitter> truth --secrets
+truth#1: sms +492452526
+truth#2: question "favorite color" "red"
+anastasis-splitter> server
+server#1: http://anastasis.example.com/ methods: sms,
+insured up to: 420 KUDOS, cost: 0.4 KUDOS
+anastasis-splitter> publish
+Server#1 failure: 402 payment required:
+payto://pay/ABALSASDFA KUDOS:0.3
+Server#2 failure: 402 payment required:
+payto://pay/ABALSAADAS KUDOS:0.5
+Total: 0.8 KUDOS
+# Here: taler-wallet-cli payto://pay/ABALASDFA used to pay!
+anastasis-splitter> publish
+Server#2 failure: 402 payment required
+# Here: taler-wallet-cli payto://pay/ABASDFASDF used to pay!
+anastasis-splitter> publish "my super secret"
+Thank you for using Anastasis.
+$
+\end{lstlisting}
+
+
+\subsubsection{Anastasis assembler}
+
+The user starts the assembler by passing a JSON document with their
+unforgetable identity attributes (name, social security number, ...).
+They also must pass the URL of an escrow provider which stores their
+recovery document, as well as the requested version of the recovery
+document. The assembler will then download and decrypt the recovery
+document and begin the recovery process.
+
+
+The following commands are available:
+\begin{itemize}
+\item truth: shows all available authorization challenges
+ from the recovery document and their status (``(-)'' not solved, ``(+)''
solved)
+\item policies: shows all available policies in the recovery document and
+ the respective status of the truths used in each policy.
+\item try \$truth: this command starts an authorization process which
+ needs interaction with external services like SMS or email. It shows
+ the instructions to follow to authorize release of the share.
+\item answer \$truth \$answer: this command tries to answer the
+ selected challenge with the provided answer. The application will
+ check the answer and give a feedback to the user. Everytime a
+ challenge is solved, the client API will check if as a result any of
+ the policies is completely satisfied. If any policy was completely
+ satisfied, the assembler will print out the recovered core secret
+ and exit.
+\end{itemize}
+
+Below is an example transcript of an interaction with the assembler:
+
+\begin{lstlisting}
+$ anastasis-assembler --import https://anastasis.example.com/
+--policy-version=42 --me=identity.json
+anastasis-assembler> truth
+truth#1(-): KUDOS 0.0 question "favorite color"
+truth#2(-): KUDOS 0.4 sms
+truth#3(-): KUDOS 2.6 post
+anastasis-assembler> policies
+policy#1: KUDOS 0.4 truth#1 truth#2 missing
+policy#2: KUDOS 3.0 truth#1 truth#2 truth#3 missing
+anastasis-assembler> try truth#2
+payto://pay/BASDFASD
+# SMS arrives asynchronously
+anastasis-assembler> answer truth#2 1234
+Success truth#2
+anastasis-assembler> answer truth#1 "blue"
+Failed truth#1
+anastasis-assembler> truth
+truth#1(-): KUDOS 0.0 question "favorite color"
+truth#2(+): KUDOS 0.4 sms
+truth#3(-): KUDOS 2.6 post
+anastasis-assembler> policies
+policy#1: KUDOS 0.0 truth#1 missing
+policy#2: KUDOS 2.6 truth#1 truth#3 missing
+anastasis-assembler> answer truth#2 "red"
+Success truth#2
+//One of the policies was solved successfully and the secret is recovered.
+Secret was: "my super secret"
+$
+\end{lstlisting}
+
+
+
\subsection{Libraries} \label{sec:libraries}
In this section the libraries used by Anastasis are presented.
@@ -221,263 +426,3 @@ simplified test flow would be the following:
% unit tests for crypto and simple HTTP REST
% tests do not necessarily preceede the
% integration tests done with the testing library!
-
-\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
-\texttt{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
-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.
-
-\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 Argon2, 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 Argon2 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 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.
-
-\begin{lstlisting}
-user_identifier_create(identifier, server_salt, keysize)
-{
- kdf_id = Argon2(identifier, server_salt, keysize)
- return kdf_id
-}
-\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}
-eddsa_keys_create (kdf_id, salt, keysize)
-{
-ver_secret = HKDF(kdf_id, salt, keysize)
-eddsa_priv = eddsa_d_to_a(ver_secret)
-eddsa_pub = get_eddsa_pub(eddsa_priv)
-return eddsa_priv, eddsa_pub
-}
-\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{salt}: used that different keys are generated, the salt here is "ver".
\\
-
-\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. Additionally,
-a salt is added so the different encryption keys differ
-fundamentally. For example for the recovery document key the salt
-"erd" is added.
-
-\begin{lstlisting}
-encryption_key_create(kdf_id, salt, nonce)
-{
-iv, key = HKDF (kdf_id, nonce, salt, keysize + ivsize)
-return iv,key
-}
-\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{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 must 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}
-encrypt(kdf_id, data, salt)
-{
- nonce = generate_random_bytes(32)
- iv, key = encryption_key_create(kdf_id, salt, nonce)
- encrypted_data, aes_gcm_tag = AES256_GCM(data, iv, key)
- encrypted_data = nonce + aes_gcm_tag + encrypted_data
- return encrypted_data
-}
-
-key_share_encrypt(kdf_id, key_share)
-{
- encrypted_key_share = encrypt(kdf_id, key_share, "eks")
- return encrypted_key_share
-}
-recovery_document_encrypt(kdf_id, recovery_document)
-{
- encrypted_recovery_document = encrypt(kdf_id, recovery_document, "erd")
- return encrypted_recovery_document
-}
-
-\end{lstlisting}
-
-\textbf{encrypted\_recovery\_document}: The encrypted recovery document which
contains the escrow methods, policies and the encrypted core secret. \\
-
-\textbf{encrypted\_key\_share}: The encrypted key\_share which the escrow
provider must release upon successful authentication.\\
-
-\textbf{nonce}: Nonce which is used to generate keys and ivs which are used
for the encryption. The nonce must contain either eks or erd.
-
-\textbf{encrypted\_data}: The encrypted data contains the either a recovery
document or a key share which was encrypted and the nonce and the
aes\_gcm\_tag. To be able to decrypt it the first 32Bytes are the nonce and the
next 12 Bytes are the
-aes\_gcm\_tag.
-
-\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 indefinitely. 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 successfuly
-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 of all never delete existing
-policies, but merely create another version. This way, even if an
-adversary uploads a malicious policy, a user can still retrieve an
-older version of the policy to recover access to their data. This
-append-only storage for policies still leaves a strong adversary with
-the option of uploading many policies to exhaust the Anastasis
-server’s capacity. We limit this attack by requiring a policy upload
-to include a reference to a payment identifier from a payment made by
-the user. Thus, a policy upload requires both knowledge of the
-identity and making a payment. This effectively prevents and adversary
-from using the append-only policy storage from exhausting Anastasis
-server capacity.
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-anastasis] branch master updated: restructure design vs implementation,
gnunet <=