Message-ID: <54D3FB4A.9010105@voskuil.org>
Date: Thu, 05 Feb 2015 15:22:50 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Paul Puey <paul@airbitz.co>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
	<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
	<54D3D636.1030308@voskuil.org>
	<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>
	<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>
	<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>
	<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>
	<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>
	<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
In-Reply-To: <C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="HuOlUXqDxXq0bLIBrR8NMCxkFcLNvLbGu"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
 transfer of Payment URI
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HuOlUXqDxXq0bLIBrR8NMCxkFcLNvLbGu
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/05/2015 02:08 PM, Paul Puey wrote:
> Although not perfect, and it may require visual/verbal verification,
> I don't see what the trust issue is.

I agree that with manual verification between the parties the worst
problem becomes DOS, which is certainly not catastrophic.

But the objective is to the extent possible improve upon the cumbersome
process of QR code, NFC signal, or textual address scanning. Given that
there would be no way to know you are under attack, with the exception
of manual confirmation, it would seem unwise to ever rely on the
automation. If the automation cannot be relied upon, it may actually
make matters worse. People would either take their chances by relying on
it or go through a more complex process.

In terms of the difficulty of an attack, it's important to recognize
that all attacks (DOS, privacy, integrity) in this scenario can be
fully-automated and executed over the air by a black box at some distance=
:

* DOS is possible by rebroadcasting a similar request.

* Privacy is compromised by monitoring for payment requests and
correlating them to location and potentially images of parties.

* Integrity is compromised by either:
(1) Rebroadcasting a similar transaction with a bogus address but with
the same leading characters; can't be spent but you lose your money.
(2) Rebroadcasting with a valid address that doesn't match the leading
characters, in the expectation that the user doesn't check manually.

Regarding possible mitigation via BIP-70:

A BIP-70 signed payment request in the initial broadcast can resolve the
integrity issues, but because of the public nature of the broadcast
coupled with strong public identity, the privacy compromise is much
worse. Now transactions are cryptographically tainted.

This is also the problem with BIP-70 over the web. TLS and other
security precautions aside, an interloper on the communication, desktop,
datacenter, etc., can capture payment requests and strongly correlate
transactions to identities in an automated manner. The payment request
must be kept private between the parties, and that's hard to do.

So the initial broadcast needs privacy, but then of course it cannot be
a broadcast - it need to be a narrow cast. That brings us back to
proximity-based establishment.

I think that you could get away with this for a while, simply because of
the narrow fields we are working in presently. But in a bitcoin world it
would be very problematic. For this reason I wouldn't want to encourage
standardization on this approach.

e

On 02/05/2015 02:10 PM, Eric Voskuil wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming
> the original. You then only see one.
>=20
> e
>=20
> On Feb 5, 2015, at 2:07 PM, Paul Puey <paul@airbitz.co
> <mailto:paul@airbitz.co>> wrote:
>=20
>> So if you picked up the BLE broadcast request. All you know is that
>> *someone* within 100m is requesting bitcoin at a certain address. Not
>> necessarily who. The *name* is both optional, and possibly just a
>> *handle* of the user. If I'm sitting 5 ft away from someone at dinner
>> and wanted to pay them via BLE, I might see "Monkey Dude" on my list
>> and simply ask him "is that you?" If so, I send it. If there are two
>> "Monkey Dude's" Then I have to bother with the address prefix, but not=

>> otherwise.
>>
>> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric@voskuil.org
>> <mailto:eric@voskuil.org>> wrote:
>>
>>     BLE has an advertised range of over 100m.=20
>>
>>     http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>>
>>     In the case of mass surveillance that range could most likely be
>>     extended dramatically by the reviewer. I've seen  WiFi ranges of
>>     over a mile with a strong (not FCC approved) receiver.
>>
>>     WiFi hotspots don't have strong identity or a guaranteed position,=

>>     so they can't be trusted for location.
>>
>>     e
>>
>>     On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99.net
>>     <mailto:mike@plan99.net>> wrote:
>>
>>>         This sounds horrible. You could basically monitor anyone with=

>>>         a wallet in a highly populated area and track them super
>>>         easily by doing facial recognition.
>>>
>>>
>>>     We're talking about BLE, still? The radio tech that runs in the
>>>     so called "junk bands" because propagation is so poor?
>>>
>>>     My watch loses its connection to my phone if I just put it down
>>>     and walk around my apartment. I'm all for reasonable paranoia,
>>>     but Bluetooth isn't going to be enabling mass surveillance any
>>>     time soon. It barely goes through air, let alone walls.
>>>
>>>     Anyway, whatever. I'm just bouncing around ideas for faster user
>>>     interfaces. You could always switch it off or set it to be
>>>     triggered by the presence of particular wifi hotspots, if you
>>>     don't mind an initial bit of setup.
>>>
>>>     Back on topic - the debate is interesting, but I think to get
>>>     this to the stage of being a BIP we'd need at least another
>>>     wallet to implement it? Then I guess a BIP would be useful
>>>     regardless of the design issues. The prefix matching still feels
>>>     flaky to me but it's hard to know if you could really swipe
>>>     payments out of the air in practice, without actually trying it.
>>>
>>>
>>


--HuOlUXqDxXq0bLIBrR8NMCxkFcLNvLbGu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU0/tKAAoJEDzYwH8LXOFOmGUH/01GjCWI1VLhMZNW1B3SgCVM
TEZGPirq89xC44YIEGrkqpZXjhqwbZujClSjeh7LH1Lf+tRkg453JuVU9rB0tiPN
/4NSpSgsMK2glaHdsI/EFSZjdm3QNSasWyaOR9YTfDkDtW/qM8eupbF4xblquufP
vybhcXUvQ/LTGNpDvFHu8CHgswZUWbQyIU6jK3aoWjuzGpUxjLBJV4livWyaTklA
b52+hEWRI8boVAb3//c5zqm0M3tIvqy2qJAR8CFSyaDkbbCky5qVf0pi1ISV3V7B
ZvBUu0XZN5lTWwgD58SXAYJb/nRtU0HwUjLbmqKKiyORZOqFNqQQhgH7BglVi70=
=Rq1G
-----END PGP SIGNATURE-----

--HuOlUXqDxXq0bLIBrR8NMCxkFcLNvLbGu--