taler
[Top][All Lists]
Advanced

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

Re: [Taler] sync vs financial security


From: Jeff Burdges
Subject: Re: [Taler] sync vs financial security
Date: Sat, 24 Feb 2018 13:01:14 +0100

On Sat, 2018-02-24 at 00:50 +0100, Florian Dold wrote:
> You say that "theft by sync" happens by "by gaining temporary physical
> access and/or tricking the owner".  But if that's your threat, you've
> already lost: there are *way* nastier things that an attacker could
> easily do in this scenario.  

There are always nastier attacks, but maybe not more likely attacks,
especially if balance sync gives every two-bit pickpocket the idea.

> Gaining access via sync is one of the nicer things that could happen,
> because it's relatively easy to detect and easy to get rid of.

Average users cannot detect access via balance sync unless they notice
their balance decline.  We cannot rely upon this happening quickly so
the total financial damages become larger. 

Access via only backup and contract sync can be detected assuming the
device gives notifications when coins gets double spent or otherwise
taken.  I think this mostly agrees with our claim that Taler acts like
cash, even though technically a thief can wait until they observe a
large wallet balance.

> So we should first be clear under what threat model "theft by sync" is
> a problem, but your device can't be completely pwned in worse ways
> anyway.

I think the threat model is casual thieves with only limited technical
knowhow.  

Aside from balance sync, I see two questions here:

(1)  Can/when/do we require user authentication to enable sync?

(2)  Should we use fancy public key cryptography, possibly with forward
secure ratcheting, that limits a device's access to its own backups? 

I think (1) provides the considerable benefit for moderate but device
centric effort, as it covers for non-rooted Android and iOS devices.  I
do think (2) sounds cool, and not device centric, but rather complex.
Also there might be enough applications that'd benefit from (2) that it
should be left to another library or even another application.  

Jeff


Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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