From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 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 , bitcoin-development@lists.sourceforge.net References: <20150222190839.GA18527@odo.localdomain> <54EA5A1C.2020701@AndySchroder.com> <54EA60D9.8000001@voskuil.org> <54EA66F5.2000302@AndySchroder.com> <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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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:/ 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--