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

[Torsten Grote]

On 2020-05-22 15:58, Christian Grothoff wrote:
> Yes, I understand this is an issue, and we _may_ want to add some 'lock'
> screen to block access, or have a check box on that screen to "never
> show this again" to disable the ability to quickly show the access code.

Requiring user presence to display this screen (e.g. by requesting phone
lock screen secret if set up) would alleviate this particular issue. A
checkbox wouldn't help, because it would only protect users who check it
and also change the UX when checked.

> However, I also see this 'show the secret again' as an easy/convenient
> way to (deliberately) add another device to the sync group. Here, asking
> the user to type it in (or scan a copy of the printed QR code) seems not
> very user-friendly.

Maybe a good way to ensure that the user has a physical copy and can
actually use it to restore from backup ;)

> And at the time when I setup the backup, I may not
> have a printer (or 2nd device to sync) readily available, so an option
> to show the code again later seems important.

If you want to support device sync with the current scheme, I agree that
there should be an option that doesn't require you to get a piece of
paper from your safe.

> Furthermore, showing the code again may also be a good entry point for
> setting up Anastasis: exporting the secret via Anastasis may take more
> time to do, but other than speed the threat is the same -- if I can
> share your sync secret via Anastasis with myself, I end up with access
> to your data.

I would have expected that the wallet can give Anastasis access to our
backup (e.g. by sharing the secret) on its own without the user manually
having to export/share a secret.

> So yes, I do see your concern, but I think having an option to disable
> it (i.e. if a user is pretty sure that they have a sound backup), or to
> set a lock (pin, pattern, default screen-lock, etc.) to prevent "fast"
> access, is likely better than not supporting it at all.

There's also the issue that removing devices or Anastasis setups
requires removing and manually re-doing backup/sync setups on all
devices, because there's a single static master key.

I don't know all your requirements for backup/sync and Anastasis, but
here's a naive idea I wonder would fit those requirements and was
considered: If each device is already identified by its unique public
key, why not encrypt each backup blob with a fresh symmetric key which
itself is encrypted to all device's public keys?

In this scheme, Anastasis could just be like another device. The
anastasis service gets its own fresh keypair and you escrow the private
key. If you want to remove that particular Anastasis service or another
device later, it is just a matter of removing it in the UI (of a master
device?) and all future backups will be encrypted in a way that the
removed device or Anastasis service can not access it anymore. The
backup service itself could continue to work without a need to re-do it.

Each secret could stay on the device and would not need to be exposed on
a continues basis in the UI. The offline recovery key *could* also be a
dedicated keypair to encrypt to and its private key only shown once and
then stay in the devices HSM and never again leave.

Arguably this setup makes adding new devices a bit more difficult,
because just scanning a single code is probably not enough as you need
to exchange more information in both directions. E.g. the devices public
key in one direction and the service parameters in the other, or the
service parameters along with all public keys in the current device set.

Normally, I like to reduce complexity as much as possible, but when it
comes uploading an encrypted wallet backup, the simplicity of using a
single static key (per service or global) seems to call for trouble.

> I think each service should have its own secret, but we can and should
> be able to simply derive all of them from some immuatable master secret.
> 
> However, there is a possibly HUGE issue here, in that I may start with
> two independent devices, two wallets, and thus two independent master
> secrets. I may even setup Anastasis for _both_. Now what happens if I
> then start to sync those devices? Now I have two master secrets.

I think independent of the question of one global master secret or per
service or per device, we should think about whether there should be one
single master device that can add/remove devices/anastasis setup or
whether all devices should be equal and can do these things.

>> So there needs to be some extra screen that shows the currently active
>> services and makes the secrets available there thus making them a lot
>> harder to discover.
> I think for the display of the master secret (QR code, Anastasis, etc.),
> that should not change if the backup services change.

But if that secret should be used to restore from backup and add new
devices to the sync group, then a different backup service would also
change the QR code, right? There's also the account key that identifies
out backup blobs at the service, or is that simply deterministically
derived from the master secret thus only change of service provider
would change the displayed secret?

>> This could maybe be integrated into the choose backup service screen
>> that already has a list of services. So it could show the active
>> services at the top along with an option to show their secret.
> I'd only show the (invariant) master secret, not the individual sync
> server's secrets.

But then how can this be used to restore or add devices? They need to
now where to download the encrypted blob from, right?

> If we have as an operation to "set sync server" (instead of "add sync
> server"), I don't think a CRDT is possible on a (destructive) "set"
> operation because depending on the order of two "set" steps the final
> result would have to be different.

Yeah that wouldn't work, but does the sync server(s) need to be part of
the synced state? I guess you might want to add a new backup server on
one device and then have that automatically added on all others? But is
that strictly necessary? You need to add all devices manually to the
first server anyway. Those who use two services can use the same flow there.

>> Can Anastasis handle multiple backup services?
> Anastasis stores a "core secret" for you, which, except for some
> semi-arbitrary protocol limitations is just a byte buffer for Anastasis.
> So if your "core secret" isn't just 256 bits but maybe 1024 bits of key
> material and a few kilobytes of URLs for the backup services, that
> should be no problem.

Sounds like the storage format of that "core secret" isn't completely
defined, yet.

>> I can already add an option somewhere in the wallet to enter URIs by
>> hand. I am just worried that users might not realize that they just scan
>> their backup code like they scan payment codes. It might be too easy ;)
>> So it is possible that users look for a dedicated restore from backup
>> option.
> Well, I would expect this to be in the FAQ and other places. Also, I
> hope we can "teach" users that "scan QR code" works for "everything":
> add exchange, add auditor, withdraw, pay, tip, refund -- and restore
> from backup.

We can start like this and if users complain that they don't find the
restore from backup option, we add a dedicated place for that which is
essentially the same QR code scanner (and URI input).

> I think the answer is to auto-renew (or remind) the user not 5 minutes
> before the backup expires, but like 3+ months in advance. IIRC the
> subscription(s) are always (per protocol) for a full year, so a 3+
> months notice should in most cases be sufficient for recovery.

I hope it is. However, it might be a bit nicer to just block new uploads
after the paid year is over and keep the backup for (a few?) download(s)
for an additional grace period.

> Deleted is deleted (modulo the trash bin discussion we had). For privacy
> reasons, I think this really has to be the case. We can't have someone's
> phone seized at the border, and some random security guard find
> compromising purchases in ancient backups despite them having been
> deleted.

If that's a design goal, then isn't a trash bin that keeps deleted
transactions in conflict with that goal?

Kind Regards,
Torsten