summaryrefslogtreecommitdiff
path: root/77/bdf8066ec6e93abeccbb686bbc88f1b8e1051f
blob: d5dd356616602194162991da7dd7dff3394ffbbe (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <info@AndySchroder.com>) id 1YQ8R9-0005t8-Rv
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 05:53:39 +0000
X-ACL-Warn: 
Received: from uschroder.com ([74.142.93.202])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1YQ8R7-0005fB-DA for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 05:53:39 +0000
Received: from [192.168.253.4] (cpe-74-137-24-201.swo.res.rr.com
	[74.137.24.201])
	by uschroder.com (Postfix) with ESMTPSA id A2DD922BDCD9C;
	Tue, 24 Feb 2015 00:53:31 -0500 (EST)
Message-ID: <54EC11DA.2010000@AndySchroder.com>
Date: Tue, 24 Feb 2015 00:53:30 -0500
From: Andy Schroder <info@AndySchroder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Eric Voskuil <eric@voskuil.org>, bitcoin-development@lists.sourceforge.net
References: <20150222190839.GA18527@odo.localdomain>	<54EA5A1C.2020701@AndySchroder.com>	<54EA60D9.8000001@voskuil.org>	<54EA66F5.2000302@AndySchroder.com>
	<mcdu6b$j11$1@ger.gmane.org> <54EAD884.8000205@AndySchroder.com>
	<54EAF570.2090602@voskuil.org> <54EBE809.70801@voskuil.org>
In-Reply-To: <54EBE809.70801@voskuil.org>
X-Enigmail-Version: 1.6
OpenPGP: id=2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6"
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: 1YQ8R7-0005fB-DA
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: Tue, 24 Feb 2015 05:53:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


I was saying provide a public key via NFC (or a public key fingerprint=20
and then send the full public key over bluetooth). Instead of providing=20
a new public key on each tap, why can't the payee just stop accepting=20
connections from new parties on that "resource" after a session key has=20
been received from the first person? If the person decides to have there =

friend or family pay for them instead and cancel the payment, they could =

just hit cancel on the POS or something (on my fuel pump I have a switch =

that needs to be turned, the purpose of this is to avoid wasting too=20
many addresses) and/or do another NFC tap (if you're providing QR codes=20
you'd still need a button of some kind though so it knows to refresh=20
it), or the POS can just provide a completely new payment request to any =

new connections on that same "resource" which use a different session key=
=2E

I feel like the authentication of the payer to the payee in any future=20
connections after they receive the session key from them (which was=20
encrypted with the payees public key), comes from the fact that they are =

sending responses back that are encrypted using the session key they=20
gave to the payee. The way I am seeing it is that the NFC tap or QR code =

scan is acting in addition to the visual name check on the signature=20
verification in the wallet. If the certificate used isn't signed by a CA =

(self signed), it may be fine as long as you heard about it via NFC or=20
QR code. I don't think it will require PKI and should still work=20
wallet-to-wallet.

It sounds like you are saying I'm proposing the customer is going to=20
need a certificate signed by CA? If so, why? I don't need this for any=20
https website I visit. It's not like the payee is sending anything to=20
the payer that is private. The payment request only becomes private if=20
something is actually received to it, otherwise, it is just discarded=20
and it doesn't matter. Those bitcoin addresses are never used. It's just =

like a shopping cart on a website where someone aborts payment and=20
cancels the order.

At one point I was thinking we could do something similar to Mike=20
Hearn's suggestion in another recent e-mail where we re-use some=20
existing part of the bitcoin URI to bootstrap some trust in a public key =

that the payee next sends via bluetooth after the NFC connection. Now=20
that I'm reviewing my notes though, I can't see how this will work with=20
a watching only wallet or if no backwards compatible (to BIP21) bitcoin=20
address is presented in the URI (as Mike said).

What I was saying above about how you can stop accepting connections on=20
that "resource" after a session key has been received by the first=20
person could be problematic though. An evil person could just start=20
making connections to every device they can, just to be mean, which=20
would not allow the POS operator to receive payments from their real=20
customers. If you do the other option I proposed, which is to just keep=20
giving out new payment requests, you have other problems (on top of=20
wasting addresses), which are that you can still have mean people giving =

you a denial of service attach on your hardware, or you could have an=20
unusual situation where two people pay (don't know why they would do=20
this though), so that is why I'm suggesting a manual tap or button press =

or switch turn being required.

I guess as more of a abuse filter, a new "resource" could be given=20
instead with each tap, and the POS would just ignore all requests to an=20
inactive resource. You may say, why not send a new public key (as you=20
suggested) instead of a new "resource" with each tap (or button press if =

using QR codes), and then you can skip the sending of a static public=20
key (or public key fingerprint), and ignore any data that is not=20
encrypted with that public key. Maybe that is a better idea because it=20
will shorten the bitcoin URI. However, I don't think its required from a =

privacy standpoint, it primarily just aids in combining the public key=20
fingerprint with the changing "resource" name used to filter abuse. Or,=20
am I missing something?


So, after thinking through the abuse scenarios I mentioned above, I=20
think I am agreeing with you, but the reason I'm writing all this is to=20
hopefully just get some feedback on my logic to learn something from=20
this discussion. I do think sending a unique public key over NFC has to=20
be better than a unique session key. It adds one more step, but seems to =

help. If we do this, can we then safely get rid of the h=3D parameter?=20
That should make Mike Hearn happy, and also may alleviate the base64url=20
debate?


Andy Schroder

On 02/23/2015 09:55 PM, Eric Voskuil wrote:
> Andy, adding to my previous post below:
>
> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
> ...
>>> It's possible a really sophisticated modification could be done where=

>>> the attacker encrypts and decrypts the communication and then relays =
to
>>> each party (without them knowing or any glitches detected), but I gue=
ss
>>> I'm not sure how easy that would be on such a close proximity device?=

>> If the NFC tap is sufficiently private, privacy is easy to achieve for=

>> the subsequent communication. If it is not, privacy can be completely
>> compromised. The question is only how much more difficult is the attac=
k.
>>
>> With the public cert tap, the level of difficulty is much lower for
>> capturing selected payment requests. The interloper no longer needs to=

>> invade the space of the NFC terminal and can instead impersonate the
>> payer from a safe distance. Nobody gets paid, but privacy is compromis=
ed.
> This problem in the preceding paragraph can be resolved by sending a
> unique public key on each NFC tap. In that case an attacker would need
> to monitor the NFC communication.
>
> The talk of wrapping the connection in SSL led me to believe you were
> talking about a static public certificate. However that's not a
> necessary assumption here and may not be what you intended.
>
>> The level of difficulty in the case where the interloper wants to tain=
t
>> transactions may appear lower, but it is not:
>>
>> With the session key tap the interloper must compromise the NFC locati=
on
>> and then monitor the BT traffic. Monitoring BT traffic without being
>> party to the connection is presumably not rocket surgery, but not
>> standard BT design either.
>>
>> With the public cert tap the interloper must also compromise the NFC
>> location and communicate over BT. Therefore the hardware and physical
>> attack requirements are similar. The only added difficulty is that the=

>> attack on the NFC terminal attack is active (modifying the MAC address=

>> directing the payer to the BT service).
> I believe your central claim was that the difference in the two
> bootstrapping approaches (public key vs. session key) is that by using =
a
> unique public key per tap, the attack requires an active vs. passive
> attack on the NFC terminal. I just wanted to make clear here that I
> agree with that assessment.
>
> The symmetric key approach is based on the idea that these attacks are
> comparable in difficulty and otherwise identical in privacy loss.
>
> However, the difference in implementation amounts to about +23
> additional encoded characters for the BT/LE URL, assuming use of the
> secp256k1 curve for DHE. This is really not a material issue in the cas=
e
> of the NFC tap. The entire URI+URL could be as small as:
>
> bitcoin:?r=3Dbt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>
> In comparison to a symmetric key:
>
> bitcoin:?r=3Dbt:12rAs9mM/12drXXUifSrRnXLGbXg8E
>
> It also does not change the protocol design or complexity at all - it
> would just swap out an AES key for a secp256k1 public key.
>
> bitcoin:[address]?bt:<mac>/<key>
>
> If that gets us aligned I'm all for it.
>
>> However impersonating the payer is just a matter of software - no more=

>> difficult than the session key attack. In fact it may be much easier t=
o
>> implement, as the attack can use supported BT features because the
>> attacker has directed the payer to connect to him and is connecting to=

>> the receiver as if he was a payer.
>>
>> But it gets worse for the public cert tap, since a more sophisticated
>> attacker can set himself up in the same position without subverting th=
e
>> NFC terminal at all. By broadcasting a more powerful BT service on the=

>> same advertised MAC address, the attacker can capture traffic and rela=
y
>> it to the intended service.
> I'm retracting the last paragraph, since the interloper, without
> invading the NFC connection (by substituting the public cert), could no=
t
> read the relayed traffic. It was getting late :/
>
>> So in sum, reliance on a public cert makes the communication less
>> private under the same physical set of constraints. The difference
>> results from the receiver allowing non-proximate payers to impersonate=

>> proximate payers from a distance by generating their own session keys
>> and submitting them over BT.
> e
>



--9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6
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.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJU7BHaAAoJEDT679stRBhrjQQH/2yzv4HRI2MWe+jy3uBpGPwr
1mSPHW+2P0bVdKBTa3e65IOwK/+luk2Y4uwTExSL58HdqK3gDy9cGAz7dXU05Bgi
NWd84R43aZ0GwEeM9VA8ep7tnJlioFmVRoSPfC7+ShG8I45o7kV1IacnKstdUaHs
NvPug7TB8uV8o1EL5WYGmRk5NP4rbryIKIGc1sKGXgDPsdNOnabBz10dFeY3HMly
2ZumdFROl2xXsjGh4BLBZVGOMqw0msntfO6UKez2sg9nwDfFDpDL6SWbS8lOj3NU
mvM0/q43H7dCURLYx99PSIvRr88bUXBuxmy9IAvfT+8kSvANzzi0hXxoHwXRK60=
=YU9g
-----END PGP SIGNATURE-----

--9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6--