Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)

[Florian Dold]

On 4/27/20 8:16 PM, Torsten Grote wrote:
> Hi all,
> 
> I am trying to split out the technical discussion of backup and sync
> from the UI discussion.
> 
> On 2020-04-21 15:25, Christian Grothoff wrote:
>> We basically do 'sync' by restoring from backup. So indeed it is both
>> the same mechanism.
> 
> That is interesting.
> 
> Normally, syncing data and backing it up are two different use-cases and
> processes:
> 
> Backup is for storing a copy of data so you can restore it it when
> needed, so you never lose that data.
> Syncing is for having the same data and state available in different
> devices.

There are some products that do both at the same time.  I'd say many
people use Dropbox or Google Drive for both backup and synchronization!

We ourselves even use git for that to some degree ;-)

> Doing both separately is already hard, but doing both within the same
> process seems even harder. I am curious how you solved that.

We've recently discussed some of the more technical details, I guess I
should write this up in a design doc!

> For example, when doing a payment on device A, a user expects that this
> payment will show up on the synchronized device B instantaneous or at
> least very soon. Similarly, when there's only a small balance available
> and it is spend on device A, the user should not be able to spend it
> again on device B, because device B picks up the reduction in balance
> before the user even attempts the payment and warns about the
> insufficient balance.

Our plan is to assign a "primary device" to each coin we withdraw.  Each
device first spends the coins that belong to it, which should reduce
these conflicts!

Of corse it's possible that a device runs out of primary coins (even if
we periodically re-distribute them).  In that case, we have to "steal"
from a synced wallet, and it's possible that we accidentally
double-spend when the other synced wallet spends the same coin at the
same time.  We can recover from that though using the exchange's error
report.

The error report from the exchange ("you already spent this coin") can
be cryptographically verified by the wallet.

As a consequence, the wallet that received this error creates a "ghost"
for a spending event.  Later when the devices are able to sync again,
this ghost event can be augmented with the real data from the other wallet.

> I imagine that it is rather difficult to back up the complete data and
> state on device A and upload it as a single (potentially quite big)
> archive in a timely fashion and then download this on device B and
> reconcile the potentially changed state with what is found in the backup
> of device A. Is Taler using CRDTs for the latter?

Yes, we will indeed use CRDTs.

>>> To sync their wallet with another device, the user is shown a secret (we
>>> should probably *not* expose the private key here)
>> I doubt we can avoid that. Besides, whatever we do expose will basically
>> allow anyone who gets hold of it access to the full wallet (including
>> all the private keys in it). That's after all the point.
> 
> Wouldn't it be safer if each device had its own backup key? The docs
> don't say how additional devices are added or removed, only that backups
> are uploaded to the account key, encrypted with the private key. So if
> all devices share the same private key, how can you reasonably revoke a
> (potentially compromised) device?

I think we decided to only have one key for simplicity.  If a sync
account is compromised (say somebody stole my old phone), it should be
cheap enough to migrate my devices to a new sync account with a
different key and to stop using the old one.

(Christian:  Here we need to be careful with syncing sync enrollments,
otherwise the old sync group that has a compromised member might obtain
access to the new sync group.)

>>> Further feature that were desired in the documentation is a way to
>>> export the backup config (key + url) and to disable sync and backup
>>> entirely. I am not sure it is a good idea to expose the key material in
>>> a second time as it becomes available to physical attackers this way and
>>> can't be stored in a secure element (available on most modern mobile
>>> devices).
>> I doubt the secure element solution will work anyway, because you're not
>> yet having Anastasis in your scopes (which is fine, that's after all the
>> _next_ step after Sync/Backup).
> 
> Right. I haven't looked at that yet, but I would have expected the
> Anastasis core secret to be different from the backup private key.

It is the same key!  As with Anastasis creating a key backup is much
easier than restoring one, rolling over to a new backup account should
not be that expensive.

> Is the idea here that Anastasis requires backup and that it recovers
> your private backup key, so you can restore from backup, even if the key
> is lost?

Exactly.

- Florian