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"
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
Precedence: list

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--