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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eric@voskuil.org>) id 1YPfJa-0001cN-3i
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 22:47:54 +0000
X-ACL-Warn:
Received: from mail-pa0-f50.google.com ([209.85.220.50])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPfJX-000123-Qa
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 22:47:54 +0000
Received: by padbj1 with SMTP id bj1so22734813pad.5
for <bitcoin-development@lists.sourceforge.net>;
Sun, 22 Feb 2015 14:47:45 -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
:subject:references:in-reply-to:content-type;
bh=KgckCaDNzTHeGSAlSGpzmsIeNg+mIlcGUppWZ+XlTsM=;
b=kYtlI2B9P9s1MTz5MUCEa0hsjypI0x+OO64cQVVHu0SU+iUGQKy4ZbS2Hllh2nUbYR
xhwXh40SaKlynjuhwbrV1wruWz0CW4j9+Q4lxWFuPNtTy71S/q6Fj6DEFEMFUTqqop+o
MrowlyUDNKkhx8i/K5pG5iMZOvpIYeeROhFs901MHVKSr/xZAwyfhlzYWLsimJFolAOt
0kq04Sq6IdQa4XBqIwZPNTY/3OoSD6vaFub0rlKiNR4oc2anN4m24wV6KFq0OvMD0+OH
2BgXFgkn/PcjNn0vkPQ0CVMmwMcwiTfPqP7t93VlAIa5IiHJ6bjP5/IiVP5+DkE6bjIo
HDGQ==
X-Gm-Message-State: ALoCoQkrtJHuOA7NFQauVmhzz87UI2jD6s5fzYwpe3MMaBqfPB3hmM766/NU7ZPlfoBW0qHfBiKr
X-Received: by 10.66.176.203 with SMTP id ck11mr14605901pac.54.1424645265506;
Sun, 22 Feb 2015 14:47:45 -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 f8sm30756497pdm.68.2015.02.22.14.47.44
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 22 Feb 2015 14:47:44 -0800 (PST)
Message-ID: <54EA5CB4.5030302@voskuil.org>
Date: Sun, 22 Feb 2015 14:48:20 -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: Jan Vornberger <jan@uos.de>,
bitcoin-development@lists.sourceforge.net
References: <20150222190839.GA18527@odo.localdomain>
<54EA5AAE.3040306@voskuil.org>
In-Reply-To: <54EA5AAE.3040306@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg"
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: 1YPfJX-000123-Qa
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
NFC and offline payments - implementer feedback
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: Sun, 22 Feb 2015 22:47:54 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
One correction inline below.
e
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
> Hi Jan,
>=20
> This is really nice work.
>=20
> WRT the Schroder and Schildbach proposal, the generalization of the "r"=
> and "payment_url" parameters makes sense, with only the potential
> backward compat issue on payment_url.
>=20
>> TBIP75 furthermore proposes to include an additional 'h' parameter
>> which would be a hash of the BIP70 payment request, preventing a MITM
>> attack on the Bluetooth channel even if the BIP70 payment request
>> isn't signed. This would have also been my suggestion, although I
>> know that Mike Hearn has raised concerns about this approach. One
>> being, that one needs to finalize the BIP70 payment request at the
>> time the QR code and NFC URI is generated.
>> ...
>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>=20
> Yes, this design is problematic from a privacy standpoint. Anyone withi=
n
> the rather significant range of the Bluetooth terminal is able to
> capture payment requests and correlate them to people. In other words i=
t
> can be used to automate tainting.
>=20
> The problem is easily resolved by recognizing that, in the envisioned
> face-to-face trade, proximity is the source of trust. Even in the above=
> proposal the "h" parameter is trusted because it was obtained by
> proximity to the NFC terminal. The presumption is that this proximity
> produces a private channel.
>=20
> As such the "tap" should transfer a session key used for symmetric bloc=
k
> cipher over the Bluetooth channel. This also resolves the issue of
> needing to formulate the payment request before the NFC.
>=20
> As an aside, in other scenarios, such as an automated dispenser, this
> presumption does not hold. The merchant is not present to guard against=
> device tampering. Those scenarios can be secured using BIP70, but canno=
t
> guarantee privacy.
>=20
> The other differences I have with the proposal pertain to efficiency,
> not privacy or integrity of the transaction:
>=20
> The proposed resource name is redundant with any unique identifier for
> the session. For example, the "h" parameter is sufficient. But with the=
> establishment of a session key both as I propose above, the parties can=
> derive a sufficiently unique public resource name from a hash of the
> key. An additional advantage is that the resource name can be
> fixed-length, simplifying the encoding/decoding.
>=20
> The MAC address (and resource name) should be encoded using base58. Thi=
s
The MAC address (and session key) should be encoded using base58. This
> is shorter than base16, is often shorter than base64, better
> standardized and does not require URI encoding, and is generally
> available to implementers.
>=20
> There is no need for the establishment of two Bluetooth services.
>=20
> I would change the payment_url recommendation so that the list order
> represents a recommended ordering provided by the terminal for the wall=
et.
>=20
> I wrote up my thoughts on these considerations last year and recently
> revised it by adding a section at the end to incorporate the "r" and
> "payment_url" generalizations from Andreas and Andy.
>=20
> https://github.com/evoskuil/bips/tree/master/docs
>=20
> e
>=20
>=20
> On 02/22/2015 11:08 AM, Jan Vornberger wrote:
>> Hi everyone,
>>
>> I am working on a Bitcoin point of sale terminal based on a Raspberry =
Pi, which
>> displays QR codes, but also provides payment requests via NFC. It can =
optionally
>> receive the sender's transaction via Bluetooth, so if the sender walle=
t
>> supports it, the sender can be completely offline. Only the terminal n=
eeds an
>> internet connection.
>>
>> Typical scenario envisioned: Customer taps their smartphone (or maybe =
smartwatch
>> in the future) on the NFC pad, confirms the transaction on their phone=
>> (or smartwatch) and the transaction completes via Bluetooth and/or the=
phone's
>> internet connection.
>>
>> You can see a prototype in action here:
>>
>> https://www.youtube.com/watch?v=3DP7vKHMoapr8
>>
>> The above demo uses a release version of Schildbach's Bitcoin Wallet, =
so it
>> works as shown today. However, some parts - especially the Bluetooth s=
tuff - are
>> custom extensions of Schildbach's wallet which are not yet standard.
>>
>> I'm writing this post to document my experience implementing NFC and o=
ffline
>> payments and hope to move the discussion forward around standardizing =
some of
>> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1=
,2]
>> follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4=
] are
>> relevant here as well.
>>
>>
>> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>>
>> Before I get into the implementation details, a few words for why I de=
cided to
>> go with the combination of NFC and Bluetooth:
>>
>> Doing everything via NFC is an interesting option to keep things simpl=
e, but the
>> issue is, that one usually can't maintain the connection while the use=
r confirms
>> the transaction (as they take the device back to press a button or may=
be enter a
>> PIN). So there are three options:
>>
>> 1. Do a "double tap": User taps, takes the device back, confirms, then=
taps
>> again to transmit the transaction. (I think Google Wallet does somethi=
ng like
>> this.)
>>
>> 2. Confirm beforehand: User confirms, then taps and everything can hap=
pen in one
>> go. The disadvantage is, that you confirm the transaction before you h=
ave seen
>> the details. (I believe Google Wallet can also work this way.)
>>
>> 3. Tap the phone, then establish a Bluetooth connection which allows y=
ou to do
>> all necessary communication even if the user takes the device back.
>>
>> I feel that option 3 is the nicest UX, so that is what I am focusing o=
n right
>> now, but there are pros and cons to all options. One disadvantage of o=
ption 3 in
>> practice is, that many users - in my experience - have Bluetooth turne=
d off, so
>> it can result in additional UI dialogs popping up, asking the user to =
turn on
>> Bluetooth.
>>
>> Regarding doing everything via Bluetooth or maybe BLE: I have been fol=
lowing the
>> work that Airbitz has done around that, but personally I prefer the NF=
C
>> interaction of "I touch what I want to pay" rather than "a payment req=
uest comes
>> to me through the air and I figure out whether it is meant for me/is l=
egitimate".
>>
>>
>> ## NFC data formats ##
>>
>> A bit of background for those who are not that familiar with NFC: Most=
Bitcoin
>> wallets with NFC support make use of NDEF (NFC Data Exchange Format) a=
s far as I
>> am aware (with CoinBlesk being an exception, which uses host-based car=
d
>> emulation, if I understand it correctly). NDEF defines a number of rec=
ord types,
>> among them 'URI' and 'Mime Type'.
>>
>> A common way of using NFC with Bitcoin is to create a URI record that =
contains a
>> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also =
support
>> the mime type record, which is then set to 'application/bitcoin-paymen=
trequest'
>> and the rest of the NFC data is a complete BIP70 payment request.
>>
>>
>> ## Implementation ##
>>
>> To structure the discussion a little bit, I have listed a number of sc=
enarios to
>> consider below. Not every possible combination is listed, but it shoul=
d cover a
>> bit of everything.
>>
>> Scenarios:
>>
>> 1) Scan QR code, transmit transaction via Bitcoin network
>> Example QR code: bitcoin:1asdf...?amount=3D42
>>
>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>> Example NFC URI: bitcoin:1asdf...?amount=3D42
>>
>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HT=
TP
>> Example QR code: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.o=
rg/bip70paymentrequest
>>
>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via H=
TTP
>> Example NFC URI: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.o=
rg/bip70paymentrequest
>>
>> 5) Touch NFC pad, receive BIP70 details directly, post transaction via=
HTTP
>> Example NFC MIME record: application/bitcoin-paymentrequest + BIP70=
payment request
>>
>> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction v=
ia Bluetooth
>> Example QR code: bitcoin:1asdf...?amount=3D42&bt=3D1234567890AB
>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>
>> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction =
via Bluetooth
>> Example NFC URI: bitcoin:1asdf...?amount=3D42&bt=3D1234567890AB
>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>
>> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I =
am just
>> listing them here for comparison. Scenario 3 is what is often in use n=
ow, for
>> example when using a checkout screen by BitPay or Coinbase.
>>
>> I played around with both scenarios 4 and 5, trying to decide whether =
I should
>> use an NFC URI record or already provide the complete BIP70 payment re=
quest via
>> NFC.
>>
>> My experience here has been, that the latter was fairly fragile in my =
setup
>> (Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy=
). I tried
>> with signed payment requests that were around 4k to 5k and the transfe=
r would
>> often not complete if I didn't hold the phone perfectly in place. So I=
quickly
>> switched to using the NFC URI record instead and have the phone fetch =
the BIP70
>> payment request via Bluetooth afterwards. Using this approach the amou=
nt of data
>> is small enough that it's usually 'all or nothing' and that seems more=
robust to
>> me.
>>
>> That said, I continue to have problems with the NFC stack that I'm usi=
ng, so it
>> might just be my NFC setup that is causing these problems. I will prob=
ably give
>> the NXP NFC library a try next (which I believe is also the stack that=
is used
>> by Android). Maybe I have more luck with that approach and could then =
switch to
>> scenario 5.
>>
>> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' pa=
rameter is
>> the non-standard extension of Andreas' wallet that I was mentioning. T=
BIP75
>> proposes to change 'bt' into 'r1' as part of a more generic approach o=
f
>> numbering different sources for the BIP70 payment request. I think tha=
t is a
>> good idea and would express my vote for this proposal. So the QR code =
or NFC URI
>> would then look something like this:
>>
>> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70&r1=3Dbt:1=
234567890AB/resource
>>
>> In addition the payment request would need to list additional 'payment=
_url's. My
>> proposal would be to do something like this:
>>
>> message PaymentDetails {
>> ...
>> optional string payment_url =3D 6;
>> optional bytes merchant_data =3D 7;
>> repeated string additional_payment_urls =3D 8;
>> // ^-- new; to hold things like 'bt:1234567890AB'
>> }
>>
>> TBIP75 proposes to just change 'optional string payment_url' into 'rep=
eated
>> string payment_url'. If this isn't causing any problems (and hopefully=
not too
>> much confusion?) I guess that would be fine too.
>>
>> In my opinion a wallet should then actually attempt all or multiple of=
the
>> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment r=
equest via
>> both HTTP and Bluetooth) and go with whatever completes first. But tha=
t is of
>> course up to each wallet to decide how to handle.
>>
>> TBIP75 furthermore proposes to include an additional 'h' parameter whi=
ch would
>> be a hash of the BIP70 payment request, preventing a MITM attack on th=
e
>> Bluetooth channel even if the BIP70 payment request isn't signed. This=
would
>> have also been my suggestion, although I know that Mike Hearn has rais=
ed
>> concerns about this approach. One being, that one needs to finalize th=
e BIP70
>> payment request at the time the QR code and NFC URI is generated.
>>
>>
>> ## Questions ##
>>
>> My questions to the list:
>>
>> 1) Do you prefer changing 'optional string payment_url' into 'repeated=
string
>> payment_url' or would you rather introduce a new field 'additional_pay=
ment_urls'?
>>
>> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin=
Wallet?
>>
>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>>
>> 4) General comments, advice, feedback?
>>
>> I appreciate your input! :-)
>>
>> Cheers,
>> Jan
>>
>> [1] http://andyschroder.com/BitcoinFluidDispenser/
>> [2] https://www.mail-archive.com/bitcoin-development%40lists.sourcefor=
ge.net/msg06354.html
>> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawi=
ki
>> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawi=
ki
>>
>> ----------------------------------------------------------------------=
--------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboar=
ds
>> with Interactivity, Sharing, Native Excel Exports, App Integration & m=
ore
>> Get technology previously reserved for billion-dollar corporations, FR=
EE
>> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/o=
stg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>=20
--EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg
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
iQEcBAEBAgAGBQJU6ly0AAoJEDzYwH8LXOFON9AIAJLAoyAShWYbZWl2WLxu7UsX
WflGHSOjmsMMDs6tVfG3uwN0DbFAEXtAYn8idWCfkiNu7jWieCLtk1ppJlE2n29p
cqJwlUFJA+SH8ASQHB7MgcJMDBZVX6fYCZMEs6g40aNbdxLVOR5iKpoZPRRsq+uu
DaqhPA/C+qOqbM+I4b/p3C2n1I9XwzpnK4SClHVG2Scpy1grUxiky8UfOJWxM9Zl
u+Yhiw2DQg7bbHpgOfk3zvDPF2RDue3xTLigDvzJMN5MtLZNRhEAiAUWG8KPnxGZ
WUjMo+DHZXqwcMHQs8q4Ubr26LH94KTxzZalD2yLQcACi5FomEuDod3YZT4ZrGg=
=trTk
-----END PGP SIGNATURE-----
--EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg--
|