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
|
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 <eric@voskuil.org>) id 1YQ5eT-0006VK-Uh
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Feb 2015 02:55:14 +0000
X-ACL-Warn:
Received: from mail-pd0-f178.google.com ([209.85.192.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YQ5eS-0003Cq-RZ
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Feb 2015 02:55:13 +0000
Received: by pdjz10 with SMTP id z10so29924005pdj.12
for <bitcoin-development@lists.sourceforge.net>;
Mon, 23 Feb 2015 18:55:07 -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=nDkeaqy0xybRjkkfIxG7zyeqfSW8neZb538J7hWQNAI=;
b=Yw16yjeSUpwSGQhXI3EFEZoSMZ1jEKtrShvgmZJ2D61wcFTzfJsgo5jG1dmNsm88Wd
T8BQKdSF/dCQl7f/x04UXM351g20n5CB4VqNykcGkOVDja5wvZQ2ElZKbqW+MpHtiT9B
7mR8uPAUjWGWJF9mwCJsA4bzOrJolrd7La+DTcYb46O1x3L8TDYoMkFpp8N+ZynZwULD
UwTVvaB+nyEuksCV+J+fNvvbOMFtc7u8LT8yQT+8mtdWINzb2no+pCqwiUv0sqWkzLE2
pc/a+LBqOl3RHZKDqC88hXmeoNlspIkPDzB7EVK1D+ZCaChdpF5Jd4XJSiYrdwpqhmGq
VHlA==
X-Gm-Message-State: ALoCoQlADgwp39FCfZOPbiYWavAmD1EDqtHzRhlfPF26sudlfeNWPkzil6kgGlb8w53dZVKe90fc
X-Received: by 10.70.64.163 with SMTP id p3mr19752863pds.118.1424746507140;
Mon, 23 Feb 2015 18:55:07 -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
ge7sm36468624pbc.16.2015.02.23.18.55.05
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 23 Feb 2015 18:55:06 -0800 (PST)
Message-ID: <54EBE809.70801@voskuil.org>
Date: Mon, 23 Feb 2015 18:55:05 -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: Andy Schroder <info@AndySchroder.com>,
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>
In-Reply-To: <54EAF570.2090602@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="gJWwJDlEHs3UTkQ0ToTqpHXm04E1XWNo5"
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: 1YQ5eS-0003Cq-RZ
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 02:55:14 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gJWwJDlEHs3UTkQ0ToTqpHXm04E1XWNo5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Andy, adding to my previous post below:
On 02/23/2015 01:40 AM, Eric Voskuil wrote:
> On 02/22/2015 11:36 PM, Andy Schroder wrote:
=2E..
>> It's possible a really sophisticated modification could be done where
>> the attacker encrypts and decrypts the communication and then relays t=
o
>> each party (without them knowing or any glitches detected), but I gues=
s
>> I'm not sure how easy that would be on such a close proximity device?
>=20
> If the NFC tap is sufficiently private, privacy is easy to achieve for
> the subsequent communication. If it is not, privacy can be completely
> compromised. The question is only how much more difficult is the attack=
=2E
>=20
> With the public cert tap, the level of difficulty is much lower for
> capturing selected payment requests. The interloper no longer needs to
> invade the space of the NFC terminal and can instead impersonate the
> payer from a safe distance. Nobody gets paid, but privacy is compromise=
d.
This problem in the preceding paragraph can be resolved by sending a
unique public key on each NFC tap. In that case an attacker would need
to monitor the NFC communication.
The talk of wrapping the connection in SSL led me to believe you were
talking about a static public certificate. However that's not a
necessary assumption here and may not be what you intended.
> The level of difficulty in the case where the interloper wants to taint=
> transactions may appear lower, but it is not:
>=20
> With the session key tap the interloper must compromise the NFC locatio=
n
> and then monitor the BT traffic. Monitoring BT traffic without being
> party to the connection is presumably not rocket surgery, but not
> standard BT design either.
>=20
> With the public cert tap the interloper must also compromise the NFC
> location and communicate over BT. Therefore the hardware and physical
> attack requirements are similar. The only added difficulty is that the
> attack on the NFC terminal attack is active (modifying the MAC address
> directing the payer to the BT service).
I believe your central claim was that the difference in the two
bootstrapping approaches (public key vs. session key) is that by using a
unique public key per tap, the attack requires an active vs. passive
attack on the NFC terminal. I just wanted to make clear here that I
agree with that assessment.
The symmetric key approach is based on the idea that these attacks are
comparable in difficulty and otherwise identical in privacy loss.
However, the difference in implementation amounts to about +23
additional encoded characters for the BT/LE URL, assuming use of the
secp256k1 curve for DHE. This is really not a material issue in the case
of the NFC tap. The entire URI+URL could be as small as:
bitcoin:?r=3Dbt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
In comparison to a symmetric key:
bitcoin:?r=3Dbt:12rAs9mM/12drXXUifSrRnXLGbXg8E
It also does not change the protocol design or complexity at all - it
would just swap out an AES key for a secp256k1 public key.
bitcoin:[address]?bt:<mac>/<key>
If that gets us aligned I'm all for it.
> However impersonating the payer is just a matter of software - no more
> difficult than the session key attack. In fact it may be much easier to=
> implement, as the attack can use supported BT features because the
> attacker has directed the payer to connect to him and is connecting to
> the receiver as if he was a payer.
>=20
> But it gets worse for the public cert tap, since a more sophisticated
> attacker can set himself up in the same position without subverting the=
> NFC terminal at all. By broadcasting a more powerful BT service on the
> same advertised MAC address, the attacker can capture traffic and relay=
> it to the intended service.
I'm retracting the last paragraph, since the interloper, without
invading the NFC connection (by substituting the public cert), could not
read the relayed traffic. It was getting late :/
> So in sum, reliance on a public cert makes the communication less
> private under the same physical set of constraints. The difference
> results from the receiver allowing non-proximate payers to impersonate
> proximate payers from a distance by generating their own session keys
> and submitting them over BT.
e
--gJWwJDlEHs3UTkQ0ToTqpHXm04E1XWNo5
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
iQEcBAEBAgAGBQJU6+gJAAoJEDzYwH8LXOFO2R8H/RJ3e4crhls8c49mvPq8aypC
iNR8qbjZJKFg9bT1my/9dF+ywESqnf9X0xOVaDrxM561gO+rGMORwRK4rCa3s2gd
eM3s5WRzur8BlY+J+gAhk7SKJJ5aEUNtFors7N8idXAO6yVeMeDClc5vzmv1ADiw
ZK6SUcUWgN6SzMYgxyccnAKYB5v+1Lj31a+6/jd/PwGpkxYx6MJnKSAIAtFx08z6
/A/7MygNflIKrkUCZ3y5JBPZpKwzqj2upqt47x0NN2E0dlU6P5Lw6qBL2W30OxlO
AxTHVDHpZPEaxLhx7f0qSGHtIGQjgsed0uLlcH+IO1UXa1c/bMUwAbMHhvs4yCE=
=6o1k
-----END PGP SIGNATURE-----
--gJWwJDlEHs3UTkQ0ToTqpHXm04E1XWNo5--
|
