[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Taler] sync vs financial security
Re: [Taler] sync vs financial security
Sat, 24 Feb 2018 00:50:50 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
Being able to manage the devices that are allowed to sync is (or should
be!) a standard feature of a reasonable sync system, even many websites
allow to revoke sessions from other browsers nowadays.
So certainly a feature that we should implement, agreed! This should
probably be added to Christian's API draft.
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. 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.
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.
On 02/23/2018 09:35 AM, Jeff Burdges wrote:
> I'll split off a separate thread to discuss "theft by sync", which I
> also felt got lost in the big synchronization thread.
> A "theft by sync" occurs whenever an attacker enables synchronization so
> that they can spends coins without the actual owners permission, usually
> by gaining temporary physical access and/or tricking the owner. It's
> oddly counter intuitive to normal users, which makes it problematic.
> Again we have balance sync vs only backup and payment sync.
> I pointed out previously that "theft by balance sync" is catastrophic to
> real world wallet financial security, due to balance sync making it
> If we abandon balance sync, then "theft by backup sync" can still occur.
> We can however do device notifications on both double spending and on
> coins being taken via balance override, including a prompt to "revoke"
> the offending device. In principle this prevents the "slow drain"
> attack of "theft by balance sync", which limits total damages.
> An attacker may wait for the victim to hold a large balance to then make
> a large purchase themselves of course, but police are more likely to
> become involved as purchase value increases.
> We might also help prevent "theft by sync" by requiring additional
> authentication to link wallets:
> Right now, there is no wallet password but almost all platforms offer a
> keychain tied to reentering login credentials. There is nothing we can
> do if the wallet runs in a context accessible by applications the
> adversary might install, like on Linux. If otoh platforms provide
> applications with some security then accessing the wallet's sync
> configuration could require reentering the device password. I'm okay
> assuming no zero-days here. This may require App Store signatures and
> maybe violate GPL assurances.
> We could achieve stronger assurances less tied to device contexts by
> using a public key backup scheme in which the backing up device cannot
> reread its own backups after submitting them. It does not protect
> existing sync users unless we add a novel parallel forward secure
> ratcheting scheme too.
> At the extreme, if backup servers have a trust relationship with
> exchanges, then we might augment this by backup servers requiring an
> exchange's signature on a withdrawal records showing similar SEPA origin
> details for both devices, so users could not link devices until they had
> funded both devices from the same bank account. An adversary could
> circumvent this by paying into the victims device, but leaves a trail
> via SEPA.
> tl;dr Authentication schemes to prevent "theft by sync" on "GNU Linux"
> distributions require a fancy public key ratcheting scheme, but maybe
> application separation suffices on devices like Android. And balance
> sync makes "theft by sync" really nasty.
> p.s. In this vein, we should check if laws regulate opening joint bank
> accounts, as linking Taler wallets may qualify.