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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <info@AndySchroder.com>) id 1YPnZP-0003kk-3f
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 07:36:47 +0000
X-ACL-Warn:
Received: from uschroder.com ([74.142.93.202])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YPnZM-0000qB-VD for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 07:36:47 +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 A99E722BD81DA
for <bitcoin-development@lists.sourceforge.net>;
Mon, 23 Feb 2015 02:36:38 -0500 (EST)
Message-ID: <54EAD884.8000205@AndySchroder.com>
Date: Mon, 23 Feb 2015 02:36:36 -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: 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>
In-Reply-To: <mcdu6b$j11$1@ger.gmane.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="GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ"
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: 1YPnZM-0000qB-VD
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 07:36:47 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
I agree that NFC is the best we have as far as a trust anchor that you=20
are paying the right person. The thing I am worried about is the privacy =
loss that could happen if there is someone passively monitoring the=20
connection. So, in response to some of your comments below and also in=20
response to some of Eric Voskuil's comments in another recent e-mail:
Consider some cases:
If NFC is assumed private, then sending the session key over the NFC=20
connection gives the payer and the payee assumed confidence that that a=20
private bluetooth connection can be created.
If the NFC actually isn't private, then by sending the session key over=20
it means the bluetooth connection is not private. An eavesdropper can=20
listen to all communication and possibly modify the communication, but=20
the payer and payee won't necessarily know if eavesdropping occurs=20
unless communication is also modified (which could be difficult to do=20
for a really low range communication).
If we send a public key of the payee over the NFC connection (in place=20
of a session key) and the NFC connection is assumed trusted (and is=20
unmodified but actually monitored by an eavesdropper) and use that=20
public key received via NFC to encrypt a session key and send it back=20
via bluetooth, to then initiate an encrypted bluetooth connection using=20
that session key for the remaining communication, then the payee still=20
receives payment as expected and the payer sends the payment they=20
expected, and the eavesdropper doesn't see anything.
If we send a public key of the payee over the NFC connection (in place=20
of a session key) and the NFC connection is assumed trusted (and is=20
actually modified by an eavesdropper) and use that public key received=20
via NFC to encrypt a session key and send it back via bluetooth, to then =
initiate an encrypted bluetooth connection using that session key for=20
the remaining communication, then the payee receives no payment and the=20
attack is quickly identified because the customer receives no product=20
for their payment and they notify the payee, and hopefully the problem=20
remedied and no further customers are affected. The privacy loss will be =
significantly reduced and the motive for such attacks will be reduced.=20
It's possible a really sophisticated modification could be done where=20
the attacker encrypts and decrypts the communication and then relays to=20
each party (without them knowing or any glitches detected), but I guess=20
I'm not sure how easy that would be on such a close proximity device?
Erick Voskuil mentioned this same problem would even occur if you had a=20
hardwired connection to the payment terminal and those wires were=20
compromised. I guess I still think what I am saying would be better in=20
that case. There is also more obvious physical tampering required to=20
mess with wires.
I'm not sure if there is any trust anchor required of the payer by the=20
payee, is there? Eric also mentioned a need for this. Why does the payer =
care who they are as long as they get a payment received? Just to avoid=20
a sophisticated modification" that I mention above? I can see how this=20
could be the case for a longer range communication (like over the=20
internet), but I'm not convinced it will be easy on really short ranges? =
It's almost like the attacker would be better off to just replace the=20
entire POS internals than mess with an attack like that, in which case=20
everything we could do locally (other than the payment request signing=20
using PKI), is useless.
I'm not a cryptography expert so I apologize if there is something=20
rudimentary that I am missing here.
Andy Schroder
On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>> I guess we need to decide whether we want to consider NFC communicatio=
n
>> private or not. I don't know that I think it can be. An eavesdropper c=
an
>> place a tiny snooping device near and read the communication. If it is=
>> just passive, then the merchant/operator won't realize it's there. So,=
I
>> don't know if I like your idea (mentioned in your other reply) of
>> putting the session key in the URL is a good idea?
> I think the "trust by proximity" is the best we've got. If we don't
> trust the NFC link (or the QR code scan), what other options have we
> got? Speaking the session key by voice? Bad UX, and can be eavesdropped=
> as well of course.
>
>
>
> -----------------------------------------------------------------------=
-------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboard=
s
> with Interactivity, Sharing, Native Excel Exports, App Integration & mo=
re
> Get technology previously reserved for billion-dollar corporations, FRE=
E
> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/os=
tg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
--GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ
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/
iQEcBAEBAgAGBQJU6tiEAAoJEDT679stRBhrvG0H/iGlWo+0vVi8d2vX54mEediu
hwzUhDEPx6+RGHwmQQz9Yf/lSd9Uhk2zTq1SHRIPB48yh4a8zFITRP+7z9q/mNLZ
bSijhxMWo/OfK4+fUPdXXp2ay/bBHgy6JMoCtmIvVgtWNphZhPiCuWUDSbC9IEdb
/JbRSObTN0aXAoR/4UNBiUDATnbb40Ywa5GElPo9c4iCoWuLiZAcd8bbH4eBt3S2
XLeg3bAmnufvzLKA/FF9HDOXDIlXEOxjtC1A3GmT6HjuHq133SvIF8840yV1AF/p
+NtyWnArb7xGAas3nSqq/sS6EAGcAlfU3P7WguYvNHVz8cOcwRNaM7q7s+DUcFA=
=0XX4
-----END PGP SIGNATURE-----
--GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ--
|
