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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eric@voskuil.org>) id 1YQRQ6-0000MY-UV
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Feb 2015 02:09:50 +0000
X-ACL-Warn:
Received: from mail-pa0-f45.google.com ([209.85.220.45])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YQRQ5-0007wT-Al
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Feb 2015 02:09:50 +0000
Received: by padhz1 with SMTP id hz1so1272548pad.9
for <bitcoin-development@lists.sourceforge.net>;
Tue, 24 Feb 2015 18:09:43 -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=p4xn/KFRRc3kk/FLVz4q3d8tGMBvkd/hbZwyIRbcrUs=;
b=lfxJRqSfiD/jP4q3+OC6BLdf/H1LbsN0eCiPpcbDHeq366QAOT9sa9F/RBWj2mlOPI
b7HLEnJBsvvD/uLyer9oDbxU+xHP3/PCdy1jzK0fvGlFk/sq1ISztTPkWFtjaePCzkiw
xqMMke4LdxuuhKT5fiHWpekgbi7vytTEDLhtor4BUGJw1jf4GIpTeqsq+OyPJtdjnKo+
uoNPaW14AHSuLWvs6T+1jPRwzQofK9tmzXNVR19FYLygK4Lup2ZEVPEBucYYRxyR0bUJ
+iyH5irO04ZvYhTyHfDHvEWmiLKZ/S7zxFeCebBlx0HZ4ZP4v7Pj6B3lKrrPBKqFEGO3
pQOA==
X-Gm-Message-State: ALoCoQkXxZeqR7GGc/JjrXnApN5iCOh08jrTCY4iAtlNAO0VQBFcdPs20wIK61oVmhzb5oXO53SO
X-Received: by 10.68.65.12 with SMTP id t12mr1461546pbs.42.1424830183462;
Tue, 24 Feb 2015 18:09:43 -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 ff6sm8485228pdb.80.2015.02.24.18.09.42
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 24 Feb 2015 18:09:42 -0800 (PST)
Message-ID: <54ED2EE6.6020903@voskuil.org>
Date: Tue, 24 Feb 2015 18:09:42 -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: 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>
<54EC11DA.2010000@AndySchroder.com> <54EC605B.8080005@voskuil.org>
<54ECD5BA.7040109@AndySchroder.com> <54ECF7DB.3060607@voskuil.org>
<54ED0046.3030906@AndySchroder.com>
In-Reply-To: <54ED0046.3030906@AndySchroder.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="CNUDtE04k6spssOhc5jbt85HihWoQO4A1"
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: 1YQRQ5-0007wT-Al
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: Wed, 25 Feb 2015 02:09:51 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CNUDtE04k6spssOhc5jbt85HihWoQO4A1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 02/24/2015 02:50 PM, Andy Schroder wrote:
> We can change "resource" to "Session ID" if you want.
>=20
> I think the URL scheme should be:
>=20
> bitcoin:[address]?r=3Dbt:<mac>&s=3D<PublicKey>
This is a question of proper URL semantics, as applied to the "bt" scheme=
=2E
=46rom rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]:
"The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any)."
=2E..
"The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a resource
within the scope of the URI's scheme and naming authority (if any). The
query component is indicated by the first question mark ("?") character
and terminated by a number sign ("#") character or by the end of the URI.=
"
https://tools.ietf.org/html/rfc3986#section-3.3
The question therefore is whether <key> is (1) relative to the path
(hierarchical) or (2) independent of the path and instead relative to
the scheme and naming authority.
The "bt" scheme does not include a naming authority, and as such the
question is simply whether <key> is relative to "bt" or relative to the
path, which is <mac>. Quite clearly <key> is valid only in the context
of <mac>, not relevant to all <mac>s.
As such one must conclude that the proper form is:
bt:<mac>/<key>
> But when connecting to the mac, the client indicates the SessionID in
> the header, and as you say, SessionID is derived in some way from
> PublicKey.
Yes.
> This is a slightly different format than both of your suggestions below=
,
> but seems to make more sense based on what you said in your entire
> message. The other thing is it can be used with more protocols without
> taking up more space in the URL.
>=20
> However, by loosing the h=3D parameter, I think we are now loosing some=
> benefit it brought to https based connections if the customer doesn't
> want to use bluetooth. Right?
I don't believe that the BIP-70 protocol over https has any need for the
parameter. It was only useful because the NFC/BT session wasn't secured.
So I don't think anything is lost.
> Also, you talk about a new public key (and session ID) for each tap. I
> guess I'm wondering about this though. If the public key is compromised=
> on the first tap, isn't their payment request already compromised?
Yes, but that is not the problem that non-reuse is designed to resolve.
Reuse of the public key creates a forward secrecy problem. If 1000
sessions are recorded, and later the private key associated with the
reused public key is compromized, all of the sessions are retroactively
compromised.
Another problem is persistent impersonation. If the one associated
private key is compromised, and nobody knows it, the attacker can not
only monitor all transactions but can selectively steal payments (if
they aren't signed and verified). This is BTW also a good reason to not
use HD generation of these session keys.
Another problem is that any payer can use the well-known public key to
obtain payment requests.
Another problem is that without a unique public key there is no unique
session id, so that would need to be added explicitly on the URI.
> Since we are securing everything, can we change the message header
> format from what Schildbach's bitcoin wallet implements to something
> more consistent?
Could you spell this out, I'm not familiar with the implementation, just
the proposals.
> Maybe we can create a new UUID for this secure service
> so Schildbach's bitcoin wallet can still maintain backwards compatibili=
ty.
That may be necessary depending on the implementation of existing
terminals, but I'm not familiar enough to speculate.
e
> On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>>> * Add a "s=3D" parameter that uses a unique public key for each
>>> session.
>>> This public key identifies the payee to the payer and payer to t=
he
>>> payee.
>> This would be the simple model, which just tacks on another parameter =
to
>> the bitcoin URL:
>>
>> bitcoin:[address]?bt=3D<mac>&s=3D<key>
>>
>> But we should also look at the more flexible "r#" approach from your
>> existing TBIPs, which would yield:
>>
>> bitcoin:[address]?r=3Dbt:<mac>/<key>
>>
>> and incorporate the "payment_url" list.
>>
>>> * Use a base58 encoding to save space and reduce the character set=
>>> slightly.
>> :)
>>
>>> * Get rid of the resource? If a terminal is accepting payment from=
>>> multiple customers simultaneously, it should be smart enough to
>>> distinguish between customers based on the public key they are
>>> encrypting the data with. Is this approach feasible?
>> Yes, it is not necessary on the URL. But an id is useful in helping th=
e
>> BT terminal identify the session without having to try all of its
>> outstanding keys until it finds one that works.
>>
>> I proposed that the resource name ("session id" may be a better name) =
be
>> deterministically derived from the session key. Given the design chang=
e
>> to pass an EC public key it would need to be derived from that key (no=
t
>> from the session key because the receiver would not have a copy before=
>> decrypting the first BT message). So any function on the public key th=
at
>> reduces it to a smaller length, fixed width should be fine. Hashing it=
>> first may be better as is prevents disclosure of any bits of the publi=
c
>> key, which should be treated as a secret during the session.
>>
>>> * When you said a new public key for each tap, do you see that as
>>> every single tap, or do you consider multiple taps from the same=
>>> customer the same tap?
>> Yes, since there would be no other way to distinguish between customer=
s
>> in some scenarios and this is the safest approach. We certainly won't
>> run out of numbers, and unused sessions can be discarded based on any
>> number of criteria, including discarding all but the most recent. That=
>> may may be sufficient for your vending machines given there's little i=
f
>> any call for parallelism.
>>
>> e
>=20
--CNUDtE04k6spssOhc5jbt85HihWoQO4A1
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
iQEcBAEBAgAGBQJU7S7mAAoJEDzYwH8LXOFODAMH/0i4ZJxXyQ58mM07IoAJMezi
FgBVzcEbR+CKzieKriFUCbvcUlYJ9CEZK8DWXzBMR+V4fQ9rlINUWpv5ySrMu/Ou
0vby/rV3joZlAIFBB6zWkS+sNxBeVGxtd56wAHSDj57LNVSEmrZMB1fKtsSawVB/
b0qjxLuG3E+Q5+wmnbrk+/DgufeJKQ6LFA8sOBe47KtfT4YaC7lV4al7aZgZJU6y
QGBozC8e+ecQh/NekStYYYFlAx1uMiVhSPUVbXD6diIB0X3x4SXFK2uujOLM8mjh
uKuimDgg9t2KVBYydiEe/b3ruF4ac9CpW2vzFVwDjfoHlFz7B0cDqV8aoxdVw6g=
=uveJ
-----END PGP SIGNATURE-----
--CNUDtE04k6spssOhc5jbt85HihWoQO4A1--
|
