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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <info@AndySchroder.com>) id 1YQOJb-0001j7-DN
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Feb 2015 22:50:55 +0000
X-ACL-Warn:
Received: from uschroder.com ([74.142.93.202])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YQOJZ-0003NC-S0 for bitcoin-development@lists.sourceforge.net;
Tue, 24 Feb 2015 22:50:55 +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 2171B22BE0B7B;
Tue, 24 Feb 2015 17:50:48 -0500 (EST)
Message-ID: <54ED0046.3030906@AndySchroder.com>
Date: Tue, 24 Feb 2015 17:50:46 -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>
<54EC11DA.2010000@AndySchroder.com> <54EC605B.8080005@voskuil.org>
<54ECD5BA.7040109@AndySchroder.com> <54ECF7DB.3060607@voskuil.org>
In-Reply-To: <54ECF7DB.3060607@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="XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj"
X-Spam-Score: 0.2 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YQOJZ-0003NC-S0
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 22:50:55 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
We can change "resource" to "Session ID" if you want.
I think the URL scheme should be:
bitcoin:[address]?r=3Dbt:<mac>&s=3D<PublicKey>
But when connecting to the mac, the client indicates the SessionID in=20
the header, and as you say, SessionID is derived in some way from PublicK=
ey.
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=20
message. The other thing is it can be used with more protocols without=20
taking up more space in the URL.
However, by loosing the h=3D parameter, I think we are now loosing some=20
benefit it brought to https based connections if the customer doesn't=20
want to use bluetooth. Right?
Also, you talk about a new public key (and session ID) for each tap. I=20
guess I'm wondering about this though. If the public key is compromised=20
on the first tap, isn't their payment request already compromised?
Since we are securing everything, can we change the message header=20
format from what Schildbach's bitcoin wallet implements to something=20
more consistent? Maybe we can create a new UUID for this secure service=20
so Schildbach's bitcoin wallet can still maintain backwards compatibility=
=2E
Andy Schroder
On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>> * Add a "s=3D" parameter that uses a unique public key for each ses=
sion.
>> This public key identifies the payee to the payer and payer to th=
e
>> payee.
> This would be the simple model, which just tacks on another parameter t=
o
> 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 the=
> 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) b=
e
> deterministically derived from the session key. Given the design change=
> to pass an EC public key it would need to be derived from that key (not=
> 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 tha=
t
> 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 public=
> 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 customers=
> 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 if=
> any call for parallelism.
>
> e
--XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj
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/
iQEcBAEBAgAGBQJU7QBGAAoJEDT679stRBhrsKsH/RnRYGT12JFqSiIwatN6QLuA
6p5jBvFlY10ttivr64ITF4muirmYFcjW8VQc/IFTX2RgLZImaT0p9cBwtARSNXrT
yW0ekjo/3Ap4m6iGeuuK4YOtECEoTMlxG0G5fkXbelLWnstMsZ67AzjRVXc45p7K
Z3cq82WljeXfGTCVKa1xsN2xA+UQn5yMpt5KGZrw9DCzRHeYl2uUW9VKylqj6rW6
xc9M1xmKDWtung0Tjx1tNQCn09s5sI7y9TP5B1w/tf9VpQoLhtM1efbknOnSnCpb
IW9aqAwyCjE8ou6WxvH9jj0g+TsD9M+P6dTAmDQv4Fw9Iq9QQpNWfkEl7szvqQo=
=upi4
-----END PGP SIGNATURE-----
--XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj--
|
