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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YPqiQ-00042o-Mt
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 10:58:18 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.170 as permitted sender)
client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f170.google.com;
Received: from mail-wi0-f170.google.com ([209.85.212.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPqiP-0001Vj-8i
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 10:58:18 +0000
Received: by mail-wi0-f170.google.com with SMTP id hi2so18387597wib.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 23 Feb 2015 02:58:11 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.78.4 with SMTP id x4mr19668978wiw.86.1424689091245; Mon,
23 Feb 2015 02:58:11 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Mon, 23 Feb 2015 02:58:11 -0800 (PST)
In-Reply-To: <54EAFC1C.9080502@voskuil.org>
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> <mcet2t$qav$1@ger.gmane.org>
<54EAFC1C.9080502@voskuil.org>
Date: Mon, 23 Feb 2015 11:58:11 +0100
X-Google-Sender-Auth: k2C94zixLzQD_eFoRE83pYni-ak
Message-ID: <CANEZrP0XYfnarvN5H_NeOGyO8RLBSGyGxv7M63MSrAd_HXj1OQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=f46d043bdf5e32ff28050fbf474c
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YPqiP-0001Vj-8i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
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: Mon, 23 Feb 2015 10:58:18 -0000
--f46d043bdf5e32ff28050fbf474c
Content-Type: text/plain; charset=UTF-8
>
> DHKE will not improve the situation. Either we use a simple method to
> transfer a session key or a complex method.
>
You're right that just sending the session key is simpler. I originally
suggested doing ECDHE to set up an encrypted channel for the following
reasons:
1. URIs are put in QR codes more often than NFC tags. QR codes have
limited space. The more stuff you pack into them, the slower and flakier
the scanning process becomes.
For normal wallets, doing ECDH over secp256k1 to derive a session key
means we can reuse the address that was put in the URI already for
pre-BIP70 wallets, thus we don't have to expand the URI at all except
perhaps to flag that crypted Bluetooth connections are supported. Win!
2. If the wallet is a watching wallet, this won't work and in that case
you would need to put a separate key into the URI. However, this key is
ephemeral and does not need to be very strong. So we can generate a regular
secp256k1 key and then put say 5-8 prefix bytes into the URI as a new
parameter. The public key can then be provided in full in the clear over
the Bluetooth connection and the session key derived. If we put the session
key into the URI in full, then we could not use this trick. Win!
3. It's quite common in low tech scenarios like little coffee shops to
just print a QR code and put it in the menu, or sticky tape it to the back
wall of the shop.
In these cases, it's possible that the device is actually hanging around
in the shop somewhere but having the QR code somewhere larger and more
accessible than the shop devices screen is highly convenient. However it
means the data is entirely static.
Putting/reusing an identity key from the URI means the session keys are
always unique and known only to both devices, even though the bootstrap
data is public.
4. Doing ECDHE to derive the keys means we can derive a MAC key as well
as an AES key. Otherwise you have the issue of exchanging both, which again
uses up valuable bootstrap space.
So for a small increase in session setup complexity we potentially avoid
troubling problems down the line where people the same functionality from
NFC and QR code based bootstrap, but we can't provide it.
These discussions keep coming up. I think the next step is for someone to
upgrade Andreas' wallet to support encrypted connections and the TBIPs, to
see what happens.
Re: the h= parameter. I only objected to requiring this when the payment
request is also signed. It adds complexity, uses space, and the rationale
was "the PKI can't be trusted" even though it's been used to protect credit
card payments for 20 years without any issues. In the case of unsigned
payment requests, sure ... but with a proper implementation of an encrypted
Bluetooth channel it'd be unnecessary as the channel establishment process
would guarantee authenticity anyway.
But don't let me hold you guys back! I'd rather see something that works
than an endless debate about the perfect arrangement of hashes and URI
parameters :)
--f46d043bdf5e32ff28050fbf474c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">DHKE will not improve the situation. Either we u=
se a simple method to<br>
transfer a session key or a complex method.<br></blockquote><div><br></div>=
<div>You're right that just sending the session key is simpler. I origi=
nally suggested doing ECDHE to set up an encrypted channel for the followin=
g reasons:</div><div><ol><li>URIs are put in QR codes more often than NFC t=
ags. QR codes have limited space. The more stuff you pack into them, the sl=
ower and flakier the scanning process becomes.<br><br>For normal wallets, d=
oing ECDH over secp256k1 to derive a session key means we can reuse the add=
ress that was put in the URI already for pre-BIP70 wallets, thus we don'=
;t have to expand the URI at all except perhaps to flag that crypted Blueto=
oth connections are supported. Win!<br><br></li><li>If the wallet is a watc=
hing wallet, this won't work and in that case you would need to put a s=
eparate key into the URI. However, this key is ephemeral and does not need =
to be very strong. So we can generate a regular secp256k1 key and then put =
say 5-8 prefix bytes into the URI as a new parameter. The public key can th=
en be provided in full in the clear over the Bluetooth connection and the s=
ession key derived. If we put the session key into the URI in full, then we=
could not use this trick. Win!<br><br></li><li>It's quite common in lo=
w tech scenarios like little coffee shops to just print a QR code and put i=
t in the menu, or sticky tape it to the back wall of the shop.<br><br>In th=
ese cases, it's possible that the device is actually hanging around in =
the shop somewhere but having the QR code somewhere larger and more accessi=
ble than the shop devices screen is highly convenient. However it means the=
data is entirely static.<br><br>Putting/reusing an identity key from the U=
RI means the session keys are always unique and known only to both devices,=
even though the bootstrap data is public.<br><br></li><li>Doing ECDHE to d=
erive the keys means we can derive a MAC key as well as an AES key. Otherwi=
se you have the issue of exchanging both, which again uses up valuable boot=
strap space.</li></ol><div>So for a small increase in session setup complex=
ity we potentially avoid troubling problems down the line where people the =
same functionality from NFC and QR code based bootstrap, but we can't p=
rovide it.</div></div><div><br></div><div>These discussions keep coming up.=
I think the next step is for someone to upgrade Andreas' wallet to sup=
port encrypted connections and the TBIPs, to see what happens.</div><div><b=
r></div><div>Re: the h=3D parameter. I only objected to requiring this when=
the payment request is also signed. It adds complexity, uses space, and th=
e rationale was "the PKI can't be trusted" even though it'=
;s been used to protect credit card payments for 20 years without any issue=
s. In the case of unsigned payment requests, sure ... but with a proper imp=
lementation of an encrypted Bluetooth channel it'd be unnecessary as th=
e channel establishment process would guarantee authenticity anyway.</div><=
div><br></div><div>But don't let me hold you guys back! I'd rather =
see something that works than an endless debate about the perfect arrangeme=
nt of hashes and URI parameters :)</div><div><br></div></div></div></div>
--f46d043bdf5e32ff28050fbf474c--
|
