summaryrefslogtreecommitdiff
path: root/anastasis.rst
blob: 967467b95458de6bb522aa48bf4e92945f9d088f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
..
  This file is part of GNU TALER.
  Copyright (C) 2019 Taler Systems SA

  TALER is free software; you can redistribute it and/or modify it under the
  terms of the GNU General Public License as published by the Free Software
  Foundation; either version 2.1, or (at your option) any later version.

  TALER is distributed in the hope that it will be useful, but WITHOUT ANY
  WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
  A PARTICULAR PURPOSE.  See the GNU Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public License along with
  TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>

  @author Christian Grothoff
  @author Dominik Meister
  @author Dennis Neufeld

=========
Anastasis
=========

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 sufficiently high entropy, so we
cannot simply encrypt using some other key material in possession of the user.

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 to break confidentiality. These policies also set the bar for the user
to recover their core secret.

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-identification 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 authenticate the
user.  Examples for truth would be a phone number (for SMS), a picture of the
user (for video identification), or the (hash of) a security answer.  A strong
adversary is assumed to be able to learn the truth, while weak adversaries
must not.  In addition to a set of escrow methods and associated Anastasis
server operators, the **recovery document** also specifies **policies**, which
describe the combination(s) of the escrow methods that suffice to obtain
access to the core secret.  For example, a **policy** could say that the
escrow methods (A and B) suffice, and a second policy may permit (A and C).  A
different user may choose to use the policy that (A and B and C) are all
required.  Anastasis imposes no limit on the number of policies in a
**recovery document**, or the set of providers or escrow methods involved in
guarding a user's secret.  Weak adversaries must not be able to deduce
information about a user's **recovery document** (except for its length, which
may be exposed to an adversary which monitors the user's network traffic).

-------------------
Anastasis DB-Schema
-------------------
.. image:: anastasis-db.png



----------------------
Anastasis 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** contains the
encrypted **core secret**, a set of escrow methods and a set of policies.




---------------
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.


::

    kdf_id := Argon2( identifier, server_salt, keysize )

**identifier**: The secret defined from the user beforehand.

**server_salt**: The salt from the Server

**keysize**: The desired output size of the KDF, here 32 bytes.


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**.

::

    ver_secret:= HKDF(kdf_id, "ver", keysize)
    eddsa_priv := eddsa_d_to_a(ver_secret)
    eddsa_pub := get_EdDSA_Pub(eddsa_priv)


**HKDF()**: The HKDF-function uses to phases: First we use HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion phase.

**kdf_id**: Hashed identifier.

**key_size**: Size of the output, here 32 bytes.

**ver_secret**: Derived key from the kdf_id, serves as intermediate step for the generation of the private key

**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:

::

   digest[0] = (digest[0] & 0x7f) | 0x40;
   digest[31] &= 0xf8;

**eddsa_priv**: The generated EdDSA private key.

**eddsa_pub**: The generated EdDSA public key.


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.

::

    (iv,key) := HKDF(kdf_id, nonce, keysize + ivsize)

**HKDF()**: The HKDF-function uses to phases: First we use HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion phase.

**kdf_id**: Hashed identifier

**keysize**: Size of the AES symmetric key, here 32 bytes

**ivsize**: Size of the AES GCM IV, here 12 bytes

**prekey**: Original key material.

**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).

**key**: Symmetric key which is later used to encrypt the documents with AES256-GCM.

**iv**: IV which will be used for AES-GCM


---------
Key Usage
---------

The keys we have generated are then used to encrypt the **recovery document** and
the **key_share** of the user.


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).

::

    (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)

**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*.
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**
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
the same number as specified above for *encrypted_key_share_i*. Nonce must contain the string "EKS" plus the according *i*.

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**.

::

    (anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
    ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub)

**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)

**h_body**: The hashed body.

**ver_res**: A boolean value. True: Signature verification passed, False: Signature verification failed.


When requesting policy downloads, the client must also provide a signature:

::

    (anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
    ver_res = eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)

**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)

**version**: The version requested as a 64-bit integer, 2^64-1 for the "latest version".

**ver_res**: A boolean value. True: Signature verification passed, False: Signature verification failed.


---------------------------
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 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 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.



------------------
Anastasis REST API
------------------

.. _salt:


Obtain salt
^^^^^^^^^^^

.. http:get:: /salt

  Obtain the salt used by the escrow provider.  Different providers
  will use different high-entropy salt values. The resulting
  **provider salt** is then used in various operations to ensure
  cryptographic operations differ by provider.  A provider must
  never change its salt value.


  **Response:**

  Returns a `SaltResponse`_.

  .. _SaltResponse:
  .. ts:def:: SaltResponse

    interface SaltResponse {
      // salt value, at least 128 bits of entropy
      server_salt: string;
    }

.. _terms:


Receiving Terms of Service
^^^^^^^^^^^^^^^^^^^^^^^^^^

.. http:get:: /terms

  Obtain the terms of service provided by the escrow provider.

  **Response:**

  Returns an `EscrowTermsOfServiceResponse`_.

  .. _EscrowTermsOfServiceResponse:
  .. ts:def:: EscrowTermsOfServiceResponse

    interface EscrowTermsOfServiceResponse {

      // minimum supported protocol version
      min_version: number;

      // maximum supported protocol version
      max_version: number;

      // supported authentication methods
      auth_methods: AuthenticationMethod[];

      // Payment required to maintain an account to store policy documents for a month.
      // Users can pay more, in which case the storage time will go up proportionally.
      monthly_account_fee: Amount;

      // Amount required per policy upload. Note that the amount is NOT charged additionally
      // to the monthly_storage_fee. Instead, when a payment is made, the amount is
      // divided by the policy_upload_fee (and rounded down) to determine how many
      // uploads can be made under the associated **payment identifier**.
      policy_upload_ratio: Amount;

      // maximum policy upload size supported
      policy_size_limit_in_bytes: number;

      // maximum truth upload size supported
      truth_size_limit_in_bytes: number;

      // how long until the service expires deposited truth
      // (unless refreshed via another POST)?
      truth_expiration: RelativeTime;

      // Payment required to upload truth.  To be paid per upload.
      truth_upload_fee: Amount;

      // Limit on the liability that the provider is offering with
      // respect to the services provided.
      liability_limit: Amount;

      // HTML text describing the terms of service in legalese.
      // May include placeholders like "${truth_upload_fee}" to
      // reference entries in this response.
      tos: string;

    }

  .. _AuthenticationMethod:
  .. ts:def:: AuthenticationMethod

    interface AuthenticationMethod {
      // name of the authentication method
      name: string;

      // Fee for accessing truth using this method
      usage_fee: Amount;

    }

.. _manage-policy:


Manage policy
^^^^^^^^^^^^^

This API is used by the Anastasis client to deposit or request encrypted
recovery documents with the escrow provider.  Generally, a client will deposit
the same encrypted recovery document with each escrow provider, but provide
different truth to each escrow provider.

Operations by the client are identified and authorized by $ACCOUNT_PUB, which
should be kept secret from third parties. $ACCOUNT_PUB should be an account
public key using the Crockford base32-encoding.

In the following, UUID is always defined and used according to `RFC 4122`_.

.. _`RFC 4122`: https://tools.ietf.org/html/rfc4122

.. http:get:: /policy/$ACCOUNT_PUB[?version=$NUMBER]

  Get the customer's encrypted recovery document.  If "version"
  is not specified, the server returns the latest available version.  If
  "version" is specified, returns the policy with the respective
  "version".  The response must begin with the nonce and
  an AES-GCM tag and continue with the ciphertext.  Once decrypted, the
  plaintext is expected to contain:

  * the escrow policy
  * the separately encrypted master public key

  Note that the key shares required to decrypt the master public key are
  not included, as for this the client needs to obtain authorization.
  The policy does provide sufficient information for the client to determine
  how to authorize requests for **truth**.

  The client MAY provide an "If-None-Match" header with an Etag.
  In that case, the server MUST additionally respond with an "304" status
  code in case the resource matches the provided Etag.

  **Response**:

  :http:statuscode:`200 OK`:
    The escrow provider responds with an EncryptedRecoveryDocument_ object.
  :http:statuscode:`304 Not modified`:
    The client requested the same resource it already knows.
  :http:statuscode:`400 Bad request`:
    The $ACCOUNT_PUB is not an EdDSA public key.
  :http:statuscode:`402 Payment Required`:
    The account's balance is too low for the specified operation.
    See the Taler payment protocol specification for how to pay.
  :http:statuscode:`403 Forbidden`:
    The required account signature was invalid.
  :http:statuscode:`404 Not found`:
    The requested resource was not found.

  *Anastasis-Version*: $NUMBER --- The server must return actual version of the encrypted recovery document via this header.
  If the client specified a version number in the header of the request, the server must return that version. If the client
  did not specify a version in the request, the server returns latest version of the EncryptedRecoveryDocument_.

  *Etag*: Set by the server to the Base32-encoded SHA512 hash of the body. Used for caching and to prevent redundancies. The server MUST send the Etag if the status code is 200 OK.

  *If-None-Match*: If this is not the very first request of the client, this contains the Etag-value which the client has reveived before from the server.
  The client SHOULD send this header with every request (except for the first request) to avoid unnecessary downloads.

  *Anastasis-Account-Signature*: The client must provide Base-32 encoded EdDSA signature over hash of body with $ACCOUNT_PRIV, affirming desire to download the requested encrypted recovery document.  The purpose used MUST be TALER_SIGNATURE_ANASTASIS_POLICY_DOWNLOAD (1401).

.. http:post:: /policy/$ACCOUNT_PUB

  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).
  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
  Anastasis server cannot fully validate the format, but MAY impose
  minimum and maximum size limits.

  **Request**:

  :query pay:
     Optional argument, any non-empty value will do,
     suggested is ``y`` for ``yes``.
     The client insists on making a payment for the respective
     account, even if this is not yet required. The server
     will respond with a ``402 Payment required``, but only
     if the rest of the request is well-formed (account
     signature must match).  Clients that do not actually
     intend to make a new upload but that only want to pay
     may attempt to upload the latest backup again, as this
     option will be checked before the ``304 Not modified``
     case.

  *If-Match*: Unless the client expects to upload the first encrypted recovery document to this account, the client
    SHOULD provide an Etag matching the latest version already known to the server.  If this
    header is present, the server MUST refuse the upload if the latest known version prior to
    this upload does not match the given Etag.

  *If-None-Match*: This header MUST be present and set to the SHA512 hash (Etag) of the body by the client.
    The client SHOULD also set the "Expect: 100-Continue" header and wait for "100 continue"
    before uploading the body.  The server MUST
    use the Etag to check whether it already knows the encrypted recovery document that is about to be uploaded.
    The server MUST refuse the upload with a "304" status code if the Etag matches
    the latest version already known to the server.

  *Anastasis-Policy-Signature*: The client must provide Base-32 encoded EdDSA signature over hash of body with $ACCOUNT_PRIV, affirming desire to upload an encrypted recovery document.

  *Payment-Identifier*: Base-32 encoded 32-byte payment identifier that was included in a previous payment (see 402 status code). Used to allow the server to check that the client paid for the upload (to protect the server against DoS attacks) and that the client knows a real secret of financial value (as the **kdf_id** might be known to an attacker). If this header is missing in the client's request (or the associated payment has exceeded the upload limit), the server must return a 402 response.  When making payments, the server must include a fresh, randomly-generated payment-identifier in the payment request.

  **Response**:

  :http:statuscode:`204 No content`:
    The encrypted recovery document was accepted and stored.  "Anastasis-Version" and "Anastasis-UUID" headers
    incidate what version and UUID was assigned to this encrypted recovery document upload by the server.
  :http:statuscode:`304 Not modified`:
    The same encrypted recovery document was previously accepted and stored.  "Anastasis-Version" header
    incidates what version was previously assigned to this encrypted recovery document.
  :http:statuscode:`400 Bad request`:
    The $ACCOUNT_PUB is not an EdDSA public key or mandatory headers are missing.
    The response body MUST elaborate on the error using a Taler error code in the typical JSON encoding.
  :http:statuscode:`402 Payment required`:
    The account's balance is too low for the specified operation.
    See the Taler payment protocol specification for how to pay.
    The response body MAY provide alternative means for payment.
  :http:statuscode:`403 Forbidden`:
    The required account signature was invalid.  The response body may elaborate on the error.
  :http:statuscode:`409 Conflict`:
    The *If-Match* Etag does not match the latest prior version known to the server.
  :http:statuscode:`413 Request entity too large`:
    The upload is too large *or* too small. The response body may elaborate on the error.

  **Details:**

  .. _EncryptedRecoveryDocument:
  .. ts:def:: EncryptedRecoveryDocument

    interface EncryptedRecoveryDocument {
      // Nonce used to compute the (iv,key) pair for encryption of the
      // encrypted_compressed_recovery_document.
      nonce: [32]; //bytearray

      // Authentication tag
      aes_gcm_tag: [16]; //bytearray

      // Variable-size encrypted recovery document. After decryption,
      // this contains a gzip compressed JSON-encoded `RecoveryDocument`.
      // The nonce of the HKDF for this encryption must include the
      // string "ERD".
      encrypted_compressed_recovery_document: []; //bytearray of undefined length

    }

  .. _RecoveryDocument:
  .. ts:def:: RecoveryDocument

    interface RecoveryDocument {
      // Account identifier at backup provider, AES-encrypted with
      // the (symmetric) master_key, i.e. an URL
      // https://sync.taler.net/$BACKUP_ID and
      // a private key to decrypt the backup.  Anastasis is oblivious
      // to the details of how this is ultimately encoded.
      backup_account: []; //bytearray of undefined length

      // List of escrow providers and selected authentication method
      methods: EscrowMethod[];

      // List of possible decryption policies
      policy: DecryptionPolicy[];

    }

  .. _EscrowMethod:
  .. ts:def:: EscrowMethod

    interface EscrowMethod {
      // URL of the escrow provider (including possibly this Anastasis server)
      provider_url : string;

      // Name of the escrow method (e.g. security question, SMS etc.)
      escrow_method: string;

      // UUID of the escrow method (see /truth/ API below).
      uuid: string;

      // Key used to encrypt the `Truth` this `EscrowMethod` is related to.
      // Client has to provide this key to the server when using /truth/
      truth_encryption_key: [32]; //bytearray

      // Salt used to encrypt the truth on the Anastasis server.
      truth_salt: [32]; //bytearray

      // The challenge to give to the user (i.e. the security question
      // if this is challenge-response).
      // (Q: as string in base32 encoding?)
      // (Q: what is the mime-type of this value?)
      //
      // For some methods, this value may be absent.
      //
      // The plaintext challenge is not revealed to the
      // Anastasis server.
      challenge: []; //bytearray of undefined length

    }

  .. _DecryptionPolicy:
  .. ts:def:: DecryptionPolicy

    interface DecryptionPolicy {
      // Salt included to encrypt master key share when
      // using this decryption policy.
      policy_salt: [32]; //bytearray

      // Master key, AES-encrypted with key derived from
      // salt and keyshares revealed by the following list of
      // escrow methods identified by UUID.
      encrypted_master_key: [32]; //bytearray

      // List of escrow methods identified by their uuid.
      uuid: string[];

    }

.. _Truth:

Managing truth
^^^^^^^^^^^^^^

This API is used by the Anastasis client to deposit **truth** or request a (encrypted) **key share** with
the escrow provider.

An **escrow method** specifies an Anastasis provider and how the user should
authorize themself.  The **truth** API allows the user to provide the
(encrypted) key share to the respective escrow provider, as well as auxiliary
data required for such an respective escrow method.

An Anastasis-server may store truth for free for a certain time period, or
charge per truth operation using GNU Taler.

.. http:post:: /truth/$UUID

  Upload a TruthUploadRequest_-Object according to the policy the client created before (see RecoveryDocument_).
  If request has been seen before, the server should do nothing, and otherwise store the new object.

  :http:statuscode:`204 No content`:
    Truth stored successfully.
  :http:statuscode:`304 Not modified`:
    The same truth was previously accepted and stored under this UUID.  The
    Anastasis server must still update the expiration time for the truth when returning
    this response code.
  :http:statuscode:`402 Payment required`:
    This server requires payment to store truth per item.
    See the Taler payment protocol specification for how to pay.
    The response body MAY provide alternative means for payment.
  :http:statuscode:`409 Conflict`:
    The server already has some truth stored under this UUID. The client should check that it
    is generating UUIDs with enough entropy.
  :http:statuscode:`412 Precondition failed`:
    The selected authentication method is not supported on this provider.


  **Details:**

  .. _TruthUploadRequest:
  .. ts:def:: TruthUploadRequest

    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

      // Key share method, i.e. "security question", "SMS", "e-mail", ...
      method: string;

      // Nonce used to compute the (iv,key) pair for encryption of the
      // encrypted_truth.
      nonce: [32]; //bytearray

      // Authentication tag of encrypted_truth
      aes_gcm_tag: [16]; //bytearray

      // Variable-size truth. After decryption,
      // this contains the ground truth, i.e. H(challenge answer),
      // phone number, e-mail address, picture, fingerprint, ...
      // **base32 encoded**.
      //
      // The nonce of the HKDF for this encryption must include the
      // string "ECT".
      encrypted_truth: [80]; //bytearray

      // mime type of truth, i.e. text/ascii, image/jpeg, etc.
      truth_mime: string;

    }

.. 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).
  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.

  **Response**:

  :http:statuscode:`200 OK`:
    EncryptedKeyShare_ is returned in body (in binary).
  :http:statuscode:`202 Accepted`:
    The escrow provider will respond out-of-band (i.e. SMS).
    The body may contain human-readable instructions on next steps.
  :http:statuscode:`303 See other`:
    The provider redirects for authentication (i.e. video identification/WebRTC).
    If the client is not a browser, it should launch a browser at the URL
    given in the "Location" header and allow the user to re-try the operation
    after successful authorization.
  :http:statuscode:`402 Payment required`:
    The service requires payment for access to truth.
    See the Taler payment protocol specification for how to pay.
    The response body MAY provide alternative means for payment.
  :http:statuscode:`403 Forbidden`:
    The server requires a valid "response" to the challenge associated with the UUID.
  :http:statuscode:`404 Not found`:
    The server does not know any truth under the given UUID.
  :http:statuscode:`503 Service Unavailable`:
    Server is out of Service.

  *Truth-Decryption-Key*: Key used to encrypt the **truth** (see encrypted_truth within TruthUploadRequest_) and which has to provided by the user. The key is stored with
  the according EscrowMethod_. The server needs this key to get the info out of TruthUploadRequest_ needed to verify the $RESPONSE.

  **Details:**

  .. _EncryptedKeyShare:
  .. ts:def:: EncryptedKeyShare

    interface EncryptedKeyShare {
      // Nonce used to compute the decryption (iv,key) pair.
      nonce_i: [32]; //bytearray

      // Authentication tag
      aes_gcm_tag_i: [16]; //bytearray

      // Encrypted key-share in base32 encoding.
      // After decryption, this yields a `KeyShare`.  Note that
      // the `KeyShare` MUST be encoded as a fixed-size binary
      // block (instead of in JSON encoding).
      //
      // HKDF for the key generation must include the
      // string "eks" as salt.
      // 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: [32]; //bytearray

    }

  .. _KeyShare:
  .. ts:def:: KeyShare

    interface KeyShare {
      // Key material to concatenate with policy_salt and KDF to derive
      // the key to decrypt the master key.
      key_share: [32]; //bytearray

      // Signature over method, uuid, and key_share.
      account_sig: EddsaSignature;

    }


---------------------
Anastasis Reducer API
---------------------

This section describes the Anastasis Reducer API which is used by client applications
to store or load the different states the client application can have.
The reducer takes a state_ in JSON syntax and returns the new state in JSON syntax.

For example a **state** may take the following structure:
::

    {
      "backup_state": "CONTINENT_SELECTING",
      "continents": [
        "Europe",
        "North_America"
      ]
    }

The new state depends on the previous one and on the transition action_ with its
arguments given to the reducer. A **transition argument** also is a statement in JSON syntax:
::

    {
      "continent": "Europe"
    }

The new state returned by the reducer with the state and transition argument defined
above would look like following for the transition action_ "select_continent":
::

  {
    "backup_state": "COUNTRY_SELECTING",
    "continents": [
      "Europe",
      "North_America"
    ],
    "selected_continent": "Europe",
    "countries": [
      {
        "code": "ch",
        "name": "Switzerland",
        "continent": "Europe",
        "name_i18n": {
          "de_DE": "Schweiz",
          "de_CH": "Schwiiz",
          "fr": "Suisse",
          "en": "Swiss"
        },
        "currency": "CHF"
      },
      {
        "code": "de",
        "name": "Germany",
        "continent": "Europe",
        "continent_i18n": {
          "de": "Europa"
        },
        "name_i18n": {
          "de_DE": "Deutschland",
          "de_CH": "Deutschland",
          "fr": "Allemagne",
          "en": "Germany"
        },
        "currency": "EUR"
      }
    ]
  }

**State**:
  - In SELECTING-States the user has to choose one value out of a predefined set of values (for example a continent out of a set of continents).
  - In COLLECTING-States the user has to give certain values.
  - In EDITING-States the user is free to choose which values he wants to give.


Backup Reducer
^^^^^^^^^^^^^^
.. _state:
.. _action:
.. figure:: anastasis_reducer_backup.png
    :name: fig-anastasis_reducer_backup
    :alt: fig-anastasis_reducer_backup
    :scale: 35 %
    :align: center

    Backup states and their transitions.


The illustration above shows the different states the reducer can have during a backup
process.
In the following, the individual transitions in the backup process will be specified in more detail.

**select_continent:**

Arguments (example):
::

    {
      "continent": "Europe"
    }


**select_country:**

Arguments (example):
::

    {
      "country": "Germany",
      "country_code": "de",
      "currency": "EUR"
    }


**enter_user_attributes:**

Arguments (example):
::

    {
      "identity_attributes": {
        "full_name": "Max Musterman",
        "social_security_number": "123456789",
        "birth_year": "2000",
        "birth_month": "01",
        "birth_day": "01"
      }
    }


**add_policy:**

Arguments (example):
::

    {
      "policy": [
        {
          "auth_method_index": 1,
          "provider": "anastasis_01"
        },
        {
          "auth_method_index": 3,
          "provider": "anastasis_02"
        }
      ]
    }


**del_policy:**

Arguments (example):
::

  {
    "policy_index": 3
  }


**enter_secret:**

Arguments (example):
::

    {
      "secret": "someverysecretsecret",
      "type": "password"
    }

- type: *password* (secret is a password or passphrase)
- type: *data* (secret must be a Crockford-Base32 encoded string of some data, e.g. a private key)


**next**, **back**, **pay:**

No Arguments needed.


Recovery Reducer
^^^^^^^^^^^^^^^^
.. figure:: anastasis_reducer_recovery.png
    :name: fig-anastasis_reducer_recovery
    :alt: fig-anastasis_reducer_recovery
    :scale: 35 %
    :align: center

    Recovery states and their transitions.


The illustration above shows the different states the reducer can have during a recovery
process.
In the following, the individual transitions in the backup process will be specified in more detail.

**select_continent:**

Arguments (example):
::

    {
      "continent": "Europe"
    }


**select_country:**

Arguments (example):
::

    {
      "country": "Germany",
      "country_code": "de",
      "currency": "EUR"
    }


**enter_user_attributes:**

Arguments (example):
::

    {
      "identity_attributes": {
        "full_name": "Max Musterman",
        "social_security_number": "123456789",
        "birth_year": "2000",
        "birth_month": "01",
        "birth_day": "01"
      }
    }


**select_challenge:**

Arguments (example):
::

    {
        "challenge_index": 1
    }


**solve_challenge:**

Arguments (example):
::

    {
        "challenge_index": 1,
        "solution": "answer to secure question"
    }


**back**, **pay:**

No Arguments needed.


.. _anastasis-auth-methods:

----------------------
Authentication Methods
----------------------

This section describes the supported authentication methods in
detail.


SMS (sms)
^^^^^^^^^

Sends an SMS with a code to the users phone.
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.
FIXME: details!


Security question (qa)
^^^^^^^^^^^^^^^^^^^^^^

Asks the user a security question.  The user sends back a hash over the
answer.  If the hash value matches with the one the server is expecting, the
server answers with the requested encrypted key share.  A different hash
function over the same security answer is used to provide **optional data**
for the decryption of the (encrypted) **key share**.


Snail mail verification (post)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Physical address verification via snail mail.
FIXME: details!