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
|
Design Doc 009: Wallet Backup
#############################
Summary
=======
This document describes the backup system used by Taler wallets.
This is the second, simplified iteration of the proposal, which leaves
out multi-device synchronization.
Requirements
============
* Backup must work both with and without Anastasis
* When not using Anastasis, the user is responsible for keeping
their wallet's root secret safe.
* Arbitrary number of backup providers must be supported
* Minimize information leaks / timing side channels **if** requested by the user
* Minimize potential to lose money or important information
* Since real-time sync is not supported yet, wallets should have a feature
where their whole content is "emptied" to another wallet, and the wallet is
reset.
* Even without real-time sync, the backup data must support merging with old, existing wallet
state, as the device that the wallet runs on may be restored from backup or be offline
for a long time.
Solution Overview
=================
Each wallet has a 64 byte wallet root secret, which is used to derive all other secrets
used during backup, which are currently:
1. The sync account key for a sync provider, derived via the sync provider's base URL.
2. The symmetric key used to encrypt the backup blob
If the user chooses to use Anastasis, the following information is backed up in Anastasis:
* list of used backup providers
* wallet root secret
Supported Operations
--------------------
* **restore-from-anastasis**: Start Anastasis recovery process. This requires
the wallet backup state to be "uninitialized".
* **restore-from-recovery-secret**: This requires the wallet backup state to be uninitialized.
* **add-provider** / **remove-provider**: Add/remove a sync provider from the
list of providers. Adding a provider will cause payment(s) to the provider
to be scheduled according to the provider's terms. If the wallet backup
state is "uninitialized", adding a provider will set the backup state to
"initialized" with a fresh wallet root key. Changing the provider list will
also update the backup provider URL list in the anastasis core secret.
* **abandon** / **takeover**: When the user wants to stop using a wallet on a particular
device, another wallet can "take over" by reading the recovery secret of the abandoned wallet.
The abandoned wallet marks explicitly in its backup blob that it is abandoned.
Abandoning a wallet will set the backup state to "uninitialized".
* **backup**: Do a backup cycle.
Backup Format
-------------
TBD. Considerations from :doc:`005-wallet-backup-sync` still apply,
especially regarding the CRDT.
Initial User Experience
-----------------------
The user will be asked to set up backup&sync (by selecting a provider)
after the first withdrawal operation has been confirmed. After selecting
the backup&sync providers, the user will be presented with a "checklist" that
contains an option to (1) show/print the recovery secret and (2) set up Anastasis.
The wallet will initially only withdraw enough money to pay the
backup&sync/anastasis providers. Only after successful backup of the wallet's
signed planchets, the full withdrawal will be completed.
Open Questions
==============
* Should the wallet root secret and wallet database be locally encrypted
and protected via a passphrase?
* What happens if the same Anastasis user has multiple wallets? Can Anastasis somehow
support multiple "instances" per application?
Future Work
===========
* Incremental backups?
* Instead of one big blob that always needs to be read/written, we could have (1) a
limited length append-only journal and (2) a merkle tree so that the backup blob can
be updated incrementally once the journal is full.
* Leaks more information and is more complex.
* Real-time synchronization, either over some signaling server
or P2P connectivity (WebRTC, etc.)
|
