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

[Florian Dold]

Sounds great!  It's similar to the idea that I was trying to explain
earlier, but your approach handles the Anastasis integration much better
by treating it as basically just another wallet device.

- Florian

On 5/26/20 1:58 AM, Christian Grothoff wrote:
> On 5/25/20 9:09 PM, Torsten Grote wrote:
>> On 2020-05-25 14:36, Florian Dold wrote:
>>> Regarding Torsten's scenario:  At least that requires a physical
>>> interaction, *and* it will be "tamper-evident", as the user will see an
>>> additional public key.
>>
>> Yep, I just feel better with a crypto solution where I can at least see
>> that there's an unknown device getting regular access to my wallet state.
>>
>> Having a static secret exposed in various places and not being able to
>> easily change it, not knowing if it is compromised or not would leave me
>> personally with an uneasy feeling using a Taler wallet for anything serious.
> 
> I think we can have both: a single master key and the crypto-visibility:
> Let the master key be M (symmetric!), and each device "x \in X" has a
> device key Dx.  M is shared across all devices. M is used to derive an
> account key "A := f(M)" for the sync process (asymmetric, for
> signatures). But, when we sync, we take the actual wallet state S
> (plaintext) -- which of course includes the master key M, the set of
> devices X and the device keys Dx. Now we roughly what GnuPG would do:
> pick a symmetric fresh secret (and IV) "K". Let DH(Ex,Dx,K) be use of
> Diffie Hellman over the public keys Ex and Dx to AEAD-encrypt K, where
> Ex is an ephemeral. Then store at the sync service:
> 
>   S_A(  E_M(X, { Ex, DH(Ex,Dx,K) }_{x\inX} || E_K(S) (|| J)+) )
> 
> (Note that S_A is required by the Sync protocol, to detect an authorized
> party making a change.)  The Anastasis backup would include M and ONE x
> \in X for Anastasis (so basically the Anastasis service counts as an
> extra device). I'll get to J below.
> 
> With this, we know:
> - only devices in the device group (incl. Anastasis) can do the
>   DH to find the current K
> - the Sync service still learns nothing, not even the set of
>   devices, only 'A' is exposed as it must be
> - to add a device via QR code, we now need an additional
>   interaction: basically we teach the new device 'M' first
>   (via QR code), and then we need another interaction where
>   an existing device adds Dx to the device list.
> 
> To manage the joining without having to scan another QR code or
> requiring a bi-directional channel, I propose the new device begins by
> downloading the 'sync' data. It then keeps most of the data everything
> unchanged (except for the Sync-mandated fresh IV for E_M), as it cannot
> "open" E_K yet. But the new device appends "J", which includes Dn for
> the new device 'n' and some name of the new device (basically saying
> "Your F-Droid phone" would like to join with key "Dn").
> 
> Naturally, we'll need some kind of encoding to allow us to tell the
> length of the E_K part so we can find the J+ blobs.
> 
> Devices that are already in the group see the 'J', prompt the user to
> approve the new device. If the user rejects, they remove J (kicking the
> new device out). If the user approves, they add Dn to the X set, upload
> the result and now the new device can download the state S for the first
> time.
> 
> WDYT?
> 
> -Christian
>