From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJVkw-0001YM-87 for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 23:22:42 +0000 X-ACL-Warn: Received: from mail-pd0-f170.google.com ([209.85.192.170]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJVku-0008U4-R2 for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 23:22:42 +0000 Received: by pdjg10 with SMTP id g10so4533234pdj.1 for ; Thu, 05 Feb 2015 15:22:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=GVcgi9r03poTcXggqHu0VqoDygQNdjUTDF/OMYt5pP4=; b=ULFBl1EjcLsGfEWaa26s1jNW8XKHXI/RC52eeACkGy5A0Kh+WKje3o10CM585lzmwY qemPCMa7JfMjWePn9wG3rSD6MGwy42lX7cO44xkRHRb7CVd6vBkrbU4U2mUzS553F7RJ NFAbxi5+vQvLF/3JvBubnQga5E7K6xE0WNPoBFPFuTMVWBxVYJk0f8TjlPkf1osT9yZN mXSTErUymdfnD+iXsgXN5qm2b46IxNPnmzupfHasc/31CUEYaXCKLRC9covcWloeMaKg DSS4/e1BvYkg1bbqXEsSJvw/mbdIMD5w9K+/4V94afBGFCb1/sIwAl5tgE76s2/Mymet +aTw== X-Gm-Message-State: ALoCoQncthW69odWGjhmPVzvx7gsHCR25fhEn5BEId/QD+RLu1FRVpBniCI5VhB6y5nTJ0szd5qz X-Received: by 10.70.48.33 with SMTP id i1mr895412pdn.153.1423178555048; Thu, 05 Feb 2015 15:22:35 -0800 (PST) Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net. [50.135.46.157]) by mx.google.com with ESMTPSA id hd4sm6059902pbc.86.2015.02.05.15.22.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 15:22:34 -0800 (PST) Message-ID: <54D3FB4A.9010105@voskuil.org> Date: Thu, 05 Feb 2015 15:22:50 -0800 From: Eric Voskuil 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 References: <54D3D636.1030308@voskuil.org> <279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com> <6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HuOlUXqDxXq0bLIBrR8NMCxkFcLNvLbGu" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YJVku-0008U4-R2 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 23:22:42 -0000 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 > 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 > > 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 > > 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--