summaryrefslogtreecommitdiff
path: root/anastasis.rst
diff options
context:
space:
mode:
Diffstat (limited to 'anastasis.rst')
-rw-r--r--anastasis.rst59
1 files changed, 34 insertions, 25 deletions
diff --git a/anastasis.rst b/anastasis.rst
index e451c93f..bb206db3 100644
--- a/anastasis.rst
+++ b/anastasis.rst
@@ -133,10 +133,10 @@ 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**
+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 SCrypt and the respective server_salt is intended
+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
@@ -147,7 +147,7 @@ likely also be available to other actors.
::
- kdf_id := SCrypt( identifier, server_salt, keysize )
+ kdf_id := Argon2( identifier, server_salt, keysize )
**identifier**: The secret defined from the user beforehand.
@@ -255,16 +255,16 @@ individual **key share**, we use different salts ("erd" and "eks" respectively).
(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)
-**encrypted_recovery_document**: The encrypted **recovery document** which contains the escrow methods, policies
+**encrypted_recovery_document**: The encrypted **recovery document** which contains the escrow methods, policies
and the encrypted **core secret**.
-**nonce0**: Nonce which is used to generate *key0* and *iv0* which are used for the encryption of the *recovery document*.
+**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".
**optional data**: Key material that optionally is contributed from the authentication method to further obfuscate the key share from the escrow provider.
-**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**
+**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**: Nonce which is used to generate *key_i* and *iv_i* which are used for the encryption of the *key share*. **i** must be
@@ -356,7 +356,7 @@ Obtain salt
**Response:**
Returns a `SaltResponse`_.
-
+
.. _SaltResponse:
.. ts:def:: SaltResponse
@@ -509,7 +509,7 @@ In the following, UUID is always defined and used according to `RFC 4122`_.
Upload a new version of the customer's encrypted recovery document.
While the document's structure is described in JSON below, the upload
should just be the bytestream of the raw data (i.e. 32 bytes nonce followed
- by 16 bytes tag followed by the encrypted document).
+ by 16 bytes tag followed by the encrypted document).
If request has been seen before, the server should do nothing, and otherwise store the new version.
The body must begin with a nonce, an AES-GCM tag and continue with the ciphertext. The format
is the same as specified for the response of the GET method. The
@@ -635,7 +635,7 @@ In the following, UUID is always defined and used according to `RFC 4122`_.
policy_salt: [32]; //bytearray
// Master key, AES-encrypted with key derived from
- // salt and secrets revealed by the following list of
+ // salt and keyshares revealed by the following list of
// escrow methods identified by UUID.
encrypted_master_key: [32]; //bytearray
@@ -644,8 +644,7 @@ In the following, UUID is always defined and used according to `RFC 4122`_.
}
-.. _manage-truth:
-
+.. _Truth:
Managing truth
^^^^^^^^^^^^^^
@@ -691,8 +690,8 @@ charge per truth operation using GNU Taler.
interface TruthUploadRequest {
// Contains the information of an interface `EncryptedKeyShare`, but simply
// as one binary block (in Crockford Base32 encoding for JSON).
- key_share_data: []; //bytearray of undefined length
-
+ key_share_data: []; //bytearray
+
// Key share method, i.e. "security question", "SMS", "e-mail", ...
method: string;
@@ -710,7 +709,7 @@ charge per truth operation using GNU Taler.
//
// The nonce of the HKDF for this encryption must include the
// string "ECT".
- encrypted_truth: []; //bytearray of undefined length
+ encrypted_truth: [80]; //bytearray
// mime type of truth, i.e. text/ascii, image/jpeg, etc.
truth_mime: string;
@@ -720,7 +719,7 @@ charge per truth operation using GNU Taler.
.. http:get:: /truth/$UUID[?response=$RESPONSE]
Get the stored encrypted key share. If $RESPONSE is specified by the client, the server checks
- if $RESPONSE matches the expected response specified before within the TruthUploadRequest_ (see encrypted_truth).
+ if $RESPONSE matches the expected response specified before within the TruthUploadRequest_ (see encrypted_truth).
Also, the user has to provide the correct *truth_encryption_key* with every get request (see below).
When $RESPONSE is correct, the server responses with the encrypted key share.
The encrypted key share is returned simply as a byte array and not in JSON format.
@@ -768,11 +767,11 @@ charge per truth operation using GNU Taler.
//
// HKDF for the key generation must include the
// string "eks" as salt.
- // Depending on the method,
+ // Depending on the method,
// the HKDF may additionally include
// bits from the response (i.e. some hash over the
// answer to the security question)
- encrypted_key_share_i: []; //bytearray of undefined length
+ encrypted_key_share_i: [32]; //bytearray
}
@@ -790,6 +789,7 @@ charge per truth operation using GNU Taler.
}
+.. _anastasis-auth-methods:
----------------------
Authentication Methods
@@ -803,17 +803,26 @@ SMS (sms)
^^^^^^^^^
Sends an SMS with a code to the users phone.
-The must send this code back with his request (see $RESPONSE under 'Managing truth').
+The user must send this code back with his request (see $RESPONSE under 'Managing truth').
If the transmitted code is correct, the server responses with the requested encrypted key share.
FIXME: details!
+
+Email verification (email)
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+Sends an email with a code to the users mail address.
+The user must send this code back with his request (see $RESPONSE under 'Managing truth').
+If the transmitted code is correct, the server responses with the requested encrypted key share.
+FIXME: details!
+
+
Video identification (vid)
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Requires the user to identify via video-call. The user is expected to delete all metadata revealing
-information about him/her from the images before uploading them. Since the respective images must
-be passed on to the video identification service in the event of password recovery, it must be
-ensured that no further information about the user can be derived from them.
+Requires the user to identify via video-call. The user is expected to delete all metadata revealing
+information about him/her from the images before uploading them. Since the respective images must
+be passed on to the video identification service in the event of password recovery, it must be
+ensured that no further information about the user can be derived from them.
FIXME: details!
@@ -827,8 +836,8 @@ function over the same security answer is used to provide **optional data**
for the decryption of the (encrypted) **key share**.
-Post-Indent (post)
-^^^^^^^^^^^^^^^^^^
+Snail mail verification (post)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Physical address verification via snail mail.
FIXME: details!