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
|
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 <alexy.kot.all@gmail.com>) id 1WQi3H-0004ym-GV
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 18:50:51 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.128.169 as permitted sender)
client-ip=209.85.128.169; envelope-from=alexy.kot.all@gmail.com;
helo=mail-ve0-f169.google.com;
Received: from mail-ve0-f169.google.com ([209.85.128.169])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WQi3E-0002M2-98
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 18:50:51 +0000
Received: by mail-ve0-f169.google.com with SMTP id pa12so1440755veb.14
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Mar 2014 11:50:42 -0700 (PDT)
X-Received: by 10.220.81.194 with SMTP id y2mr5653608vck.29.1395341442693;
Thu, 20 Mar 2014 11:50:42 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.59.0.38 with HTTP; Thu, 20 Mar 2014 11:50:02 -0700 (PDT)
In-Reply-To: <CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com>
References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org>
<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>
<lge7nk$3mf$2@ger.gmane.org>
<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
<CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com>
<CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com>
From: Alex Kotenko <alexykot@gmail.com>
Date: Thu, 20 Mar 2014 18:50:02 +0000
X-Google-Sender-Auth: WS8mNhEO1B7isNQP2WpS_bdlp8A
Message-ID: <CALDj+BYAJ=vJcrW4gthTdcrhVux-XBeh3r-SSxzxd0FAdnk4cw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c2d8600852da04f50e3f98
X-Spam-Score: -0.6 (/)
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
(alexy.kot.all[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WQi3E-0002M2-98
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
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: Thu, 20 Mar 2014 18:50:51 -0000
--001a11c2d8600852da04f50e3f98
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
We'll see how it will go, maybe I will get to implement this somewhere soon=
.
Yes, I'm thinking exactly about radio MitM attacks possible with bluetooth.
I'll also look into using PKI inside the PoS for the merchant. It would be
great user experience if we would be able to provide a signed payment
request with human recognizable merchant identity name in the way you
described much earlier in Bitcoin 0.9 FAQ. =E2=80=8B
2014-03-20 18:31 GMT+00:00 Mike Hearn <mike@plan99.net>:
> With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket,
> address, 1234, true) to wrap a bluetooth socket in SSL. However I have no=
t
> tried it.
>
> For now, just prototype and build your product without the security. We
> can find someone to experiment with this, if you don't want to .
>
> Bluetooth needs encryption and MACs as well as signing to be secure,
> because there could be radio MITM. Yes, this overlaps somewhat with the P=
KI
> signing in BIP70, but not entirely - you might want to serve unsigned
> payment requests, but still have confidentiality and authenticity for a
> local face to face transaction. The signing and encryption does different
> things.
>
>
> On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko <alexykot@gmail.com> wrote:
>
>> Hmm, is there any other way to do it? Can we provide a signed payment
>> request and verify the sign on receiving side and this way protect from
>> bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn=
't
>> a very well developed area, and my own skills are not enough to quickly
>> implement a reliable secure solution here.
>>
>>
>> 2014-03-20 10:36 GMT+00:00 Mike Hearn <mike@plan99.net>:
>>
>>> Encoding entire payment requests into qrcodes is definitely not the way
>>> to go. They can already be large when signed and we're just at the star=
t of
>>> adding features.
>>>
>>> Finishing off and standardising the bluetooth support is the way to go
>>> (r=3Dbt:mac). Andreas' app already has some support for this I believe,=
so
>>> Alex you could prototype with that, but we need to:
>>>
>>> 1) Add an encryption/auth layer on top, because it runs over RFCOMM
>>> sockets. The authentication would require proof of owning the Bitcoin k=
ey
>>> that's in the address part of the URI (which is needed for backwards co=
mpat
>>> anyway).
>>>
>>> 2) Write a BIP for it and make sure it's interoperable
>>>
>>> For the auth layer we could either use SSL and then just ignore the
>>> server certificate and require signing of the session public key with t=
he
>>> Bitcoin key, which should be easy to code up but is rather heavy on the
>>> air, or roll a custom lightweight thing where we just do a basic ECDH, =
with
>>> the servers key being the same as the address key. But rolling such
>>> protocols is subtle and I guess it'd need to be reviewed by people fami=
liar
>>> with such things.
>>>
>>> This feels like a good opportunity to grow the community - perhaps we
>>> can find a volunteer in the forums who enjoys crypto.
>>>
>>>
>>> -----------------------------------------------------------------------=
-------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>
--001a11c2d8600852da04f50e3f98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier =
new,monospace;color:#003300">We'll see how it will go, maybe I will get=
to implement this somewhere soon.</div><div class=3D"gmail_default" style=
=3D"font-family:courier new,monospace;color:#003300">
<br></div><div class=3D"gmail_default" style=3D"font-family:courier new,mon=
ospace;color:#003300">Yes, I'm thinking exactly about radio MitM attack=
s possible with bluetooth. I'll also look into using PKI inside the PoS=
for the merchant. It would be great user experience if we would be able to=
provide a signed payment request with human recognizable merchant identity=
name in the way you described much earlier in Bitcoin 0.9 FAQ. =E2=80=8B</=
div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">2014-03-20 18:31 GMT+00:00 Mike Hearn <span dir=3D"ltr"=
><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</=
a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">With Java, in theory, you c=
an use SSLSocketFactory.createSocket(btsocket, address, 1234, true) to wrap=
a bluetooth socket in SSL. However I have not tried it.<div>
<br></div><div>For now, just prototype and build your product without the s=
ecurity. We can find someone to experiment with this, if you don't want=
to .</div>
<div><br></div><div>Bluetooth needs encryption and MACs as well as signing =
to be secure, because there could be radio MITM. Yes, this overlaps somewha=
t with the PKI signing in BIP70, but not entirely - you might want to serve=
unsigned payment requests, but still have confidentiality and authenticity=
for a local face to face transaction. The signing and encryption does diff=
erent things.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 7:20 PM, Alex Kote=
nko <span dir=3D"ltr"><<a href=3D"mailto:alexykot@gmail.com" target=3D"_=
blank">alexykot@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:c=
ourier new,monospace;color:#003300">Hmm, is there any other way to do it? C=
an we provide a signed payment request and verify the sign on receiving sid=
e and this way protect from bluetooth MitM attack? Quick googling showed th=
at SSL over bluetooth isn't a very well developed area, and my own skil=
ls are not enough to quickly implement a reliable secure solution here.</di=
v>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><div class=3D"gmail_quote">2014-03-20 10:36 GMT+0=
0:00 Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" ta=
rget=3D"_blank">mike@plan99.net</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div class=3D"gma=
il_extra">Encoding entire payment requests into qrcodes is definitely not t=
he way to go. They can already be large when signed and we're just at t=
he start of adding features.</div>
<div class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">Finishing off and standardising the bl=
uetooth support is the way to go (r=3Dbt:mac). Andreas' app already has=
some support for this I believe, so Alex you could prototype with that, bu=
t we need to:</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1) Add an e=
ncryption/auth layer on top, because it runs over RFCOMM sockets. The authe=
ntication would require proof of owning the Bitcoin key that's in the a=
ddress part of the URI (which is needed for backwards compat anyway).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) Write a =
BIP for it and make sure it's interoperable</div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">For the auth layer we could eithe=
r use SSL and then just ignore the server certificate and require signing o=
f the session public key with the Bitcoin key, which should be easy to code=
up but is rather heavy on the air, or roll a custom lightweight thing wher=
e we just do a basic ECDH, with the servers key being the same as the addre=
ss key. But rolling such protocols is subtle and I guess it'd need to b=
e reviewed by people familiar with such things.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This feels =
like a good opportunity to grow the community - perhaps we can find a volun=
teer in the forums who enjoys crypto.</div></div>
<br></div></div><div>------------------------------------------------------=
------------------------<br>
Learn Graph Databases - Download FREE O'Reilly Book<br>
"Graph Databases" is the definitive new guide to graph databases =
and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href=3D"http://p.sf.net/sfu/13534_NeoTech" target=3D"_blank">http://p.sf=
.net/sfu/13534_NeoTech</a><br>_____________________________________________=
__<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></div></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
--001a11c2d8600852da04f50e3f98--
|
