taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Grothoff
Subject: Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)
Date: Mon, 25 May 2020 15:47:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 5/25/20 2:34 PM, Torsten Grote wrote:
>> 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.

Exactly. I think the screen lock is a good compromise here.

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

My point was that this is an equivalent threat vector, so we'll have to
protect the Anastasis setup with an equivalent security measure.

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

I only want to put (at most!) the 256-bits for one key into the QR code
that the user would have to print. Excessively big QR codes don't scan
easily, and if the user has to write down the sync-URI, even 256 bit
keys are already nasty to copy down flawlessly.

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

Yes, albeit we expect the trash bin to be emptied automatically. And
without it, an attacker getting hold of your sync/backup data could be
extra nasty. So a moderate recovery window seems like a good trade-off.
And we could allow users to configure the trash bin with a lifetime of
zero to get the best privacy.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]