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 22:28:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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