[Taler] backups with fast sync via notification servers and link passwords

[Jeff Burdges]

I think Florian and I reached a interesting point on sync backup
proposals today, with these two realizations:
 (1) We need stronger security between linked wallets for many users.
 (2) Anything fast requires notifications servers anyways. 
We envision coin are owned by specific wallets, and the displayed
balance is associated to the current wallet, but another balance of
linked wallets can be displayed too.

In essence, we're adopting for (1) the perspective that users cannot
choose between feature vs security, but they can choose between using a
feature with or without obvious but annoying security measures.  In this
case, those security enhancements are link passwords that limit linked
wallets ability to take coins from one another, but may be left empty
for convenience.  These link passwords save users from messy single
wallet backup procedures and help determine wallet privacy behavior.


We proceed roughly as follows when a user spends past their balance but
not past the linked wallet balance:

First, ask the user if we can take from their linked wallets, possibly
displaying their linked wallet list to permit them to reorder (drag) or
exclude (swip) wallets.  Assuming they approve, send their linked
wallets, in order, request for enough coins, using those wallets'
notification servers.  If any linked wallets are password protected then
we might ask for a password if the value is too large.

Any wallets that receive requests approve automatically and send coins,
assuming the value is not too large.  We must assess quickly if our
requests are arriving or not.  Assuming not, then one of two things
happens:

Case 1.  If links are *not* password protected, then we take any needed
coins, probably in the same order we think the linked wallet would give
them, and spend them at the merchant. 

We now send the user a device notification that warns them that we spent
coins in a way that might break their privacy or cause confusion because
they did not password protect their links, and provide a button to set
up a password.

We notify the linked wallets too, which caused them to prompt to
deauthorize our wallet or require a password.

Case 2. If links are password protected, then we warn the user about
about taking coins form other wallets and let them enter their password
to do so. 


In this scheme, we do not access backup servers in a predictable way
either before or after a spend or refresh operation, so anonymity sets
are not necessarily reduced by network traffic, although we must think
more about the database's own privacy properties.

Instead, we contact request coins from linked wallets directly through
notification servers, and possibly their backup servers, but only during
the rare event that spends exceed the device balance.  If we must take
coins, then we only warn the users afterwards that they should not take
coins like this.  We might provide a "fine print" privacy warning on the
linked wallet list screen, but overall this sounds minimally dangerous
because it's rare and wallets may chatter over notifications servers
anyways.  It does suck to use google or apple's notification server, so
maybe we should use our own.


We do not store the linked wallets' coins locally.  Instead, we control
access to the linked wallets' backups through a coin reading credential
consisting of a public key R = r G with private key
  r = H(r0 || read_secret) where
  r0 = mask_i xor Argon2(read_secret_i || password_i) for various i.
In this way, we could use the same cryptography to make password_i the
same for all linked wallets or for all wallets linking to us.

In the database, we encrypt coin records using encrypt-then-mac with
key 
  k = H( E || read_secret || DH(E,R) ) where E = e G is ephemeral.

In this way, our records maintain post-quantum anonymity so long as
read_secret is never compromised and large enough.  If read_secret and
read_secret_i are compromised then the adversary still needs password_i,
but normally this password shall be short.  

If a device has no read_secret_i but only R then it can only append to
the database, meaning it can only send coins.  We can revoke a device by
changing all mask_i, which avoids changing any password_i or
read_secret_i, but one could imaging changing read_secret in extreme
cases.  If password_i is empty then reading and taking coins does not
require any password for device i.  Also password_0 is always empty as
i=0 owns the backup. 

In QR code setup, we transfer read_secret and use messaging to set up
read_secret_i and mask_i.  In particular, we might change our minds
which device defines read_secret_i and mask_i based on which device
picks the link password.  In this, passwords are directional, but we'll
keep this simpler in practice, like perhaps even one password for all
linked devices that gets set on only one device. 

We could encrypt our balance information similarly but omitting the
password_i, so R_balance = r_balance G where 
  r_balance = H(mask_balance_i xor H(read_secret_i) || read_secret)
It might however be simpler to append it to all linked wallets.


We also need a master secret determined by both a public seed stored
unencrypted with the database and an autogenerated 10 word diceware
password (128 bits).
  master_secret = Argon2(master_password || master_seed)
We use master_secret to derive other secrets and to authenticate to
deletions from our backup database for cleanup purposes, so presumably
through another key pair M = m G where
  m = H(master_secret || master_seed) or whatever.

In this way, an unlinked lone wallets can be backed up and recovered
merely by writing down and reentering this password, while still
achieving post-quantum anonymity vs Shor's algorithm.  We do not achieve
post-quantum anonymity vs Grover's algorithm per se.  Yet, we only ever
run this Argon2 once per wallet, so we may configure Argon2 to consume
enough memory for long enough that no foreseeable quantum computer has
any advantage.  


We technically require the device protects master_secret and read_secret
using application separation of course, so Android and iOS do this, but
afaik among GNU Linux variants, only Subgraph OS or Qubes OS really do
this, but maybe keychain software helps with others. 


I've ignored anything around forward security, aka ratcheting, efforts
here because they sound complex.

signature.asc
Description: This is a digitally signed message part