From: Eric Voskuil <eric@voskuil.org>
To: Paul Puey <paul@airbitz.co>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Date: Thu, 05 Feb 2015 15:22:50 -0800 [thread overview]
Message-ID: <54D3FB4A.9010105@voskuil.org> (raw)
In-Reply-To: <C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 5423 bytes --]
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.
>
> e
>
> On Feb 5, 2015, at 2:07 PM, Paul Puey <paul@airbitz.co
> <mailto:paul@airbitz.co>> wrote:
>
>> 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.
>>
>> 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.
>>>
>>>
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-02-05 23:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 20:06 [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI Paul Puey
2015-02-05 20:28 ` Mike Hearn
2015-02-05 20:37 ` Paul Puey
2015-02-05 20:43 ` Mike Hearn
2015-02-05 20:44 ` Eric Voskuil
2015-02-05 20:50 ` Mike Hearn
2015-02-05 20:59 ` Eric Voskuil
2015-02-05 21:19 ` Brian Hoffman
2015-02-05 21:23 ` Eric Voskuil
2015-02-05 21:36 ` Mike Hearn
2015-02-05 21:46 ` Eric Voskuil
2015-02-05 22:07 ` Paul Puey
2015-02-05 22:10 ` Eric Voskuil
2015-02-05 22:49 ` Roy Badami
2015-02-05 23:22 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:02 ` William Swanson
2015-02-05 23:34 ` Roy Badami
2015-02-05 23:59 ` Eric Voskuil
2015-02-06 8:59 ` Roy Badami
2015-02-06 9:13 ` Eric Voskuil
2015-02-06 0:58 ` Paul Puey
2015-02-05 23:22 ` Eric Voskuil [this message]
2015-02-05 23:36 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:46 ` Eric Voskuil
2015-02-06 0:04 ` MⒶrtin HⒶboⓋštiak
2015-02-06 0:22 ` Eric Voskuil
2015-02-06 0:36 ` Martin Habovštiak
2015-02-06 1:29 ` Eric Voskuil
2015-02-06 9:07 ` MⒶrtin HⒶboⓋštiak
2015-02-10 16:55 ` Eric Voskuil
2015-02-10 17:16 ` MⒶrtin HⒶboⓋštiak
2015-02-10 17:56 ` Eric Voskuil
2015-02-06 0:49 ` Paul Puey
2015-02-06 0:50 ` Martin Habovštiak
2015-02-06 1:05 ` Eric Voskuil
2015-02-06 2:09 ` Paul Puey
2015-02-05 22:02 ` Paul Puey
2015-02-05 22:01 ` Paul Puey
2015-02-05 22:05 ` Eric Voskuil
2015-02-05 22:08 ` Paul Puey
-- strict thread matches above, loose matches on Subject: below --
2015-02-05 8:01 Paul Puey
2015-02-05 13:46 ` Andreas Schildbach
2015-02-05 13:57 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D3FB4A.9010105@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=paul@airbitz.co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox