1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
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 <eric@voskuil.org>) 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 <bitcoin-development@lists.sourceforge.net>;
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 <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"
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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--
|
