From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YQ8R9-0005t8-Rv for bitcoin-development@lists.sourceforge.net; Tue, 24 Feb 2015 05:53:39 +0000 X-ACL-Warn: Received: from uschroder.com ([74.142.93.202]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YQ8R7-0005fB-DA for bitcoin-development@lists.sourceforge.net; Tue, 24 Feb 2015 05:53:39 +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 A2DD922BDCD9C; Tue, 24 Feb 2015 00:53:31 -0500 (EST) Message-ID: <54EC11DA.2010000@AndySchroder.com> Date: Tue, 24 Feb 2015 00:53:30 -0500 From: Andy Schroder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Voskuil , 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> <54EBE809.70801@voskuil.org> In-Reply-To: <54EBE809.70801@voskuil.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="9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6" 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: 1YQ8R7-0005fB-DA 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 05:53:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I was saying provide a public key via NFC (or a public key fingerprint=20 and then send the full public key over bluetooth). Instead of providing=20 a new public key on each tap, why can't the payee just stop accepting=20 connections from new parties on that "resource" after a session key has=20 been received from the first person? If the person decides to have there = friend or family pay for them instead and cancel the payment, they could = just hit cancel on the POS or something (on my fuel pump I have a switch = that needs to be turned, the purpose of this is to avoid wasting too=20 many addresses) and/or do another NFC tap (if you're providing QR codes=20 you'd still need a button of some kind though so it knows to refresh=20 it), or the POS can just provide a completely new payment request to any = new connections on that same "resource" which use a different session key= =2E I feel like the authentication of the payer to the payee in any future=20 connections after they receive the session key from them (which was=20 encrypted with the payees public key), comes from the fact that they are = sending responses back that are encrypted using the session key they=20 gave to the payee. The way I am seeing it is that the NFC tap or QR code = scan is acting in addition to the visual name check on the signature=20 verification in the wallet. If the certificate used isn't signed by a CA = (self signed), it may be fine as long as you heard about it via NFC or=20 QR code. I don't think it will require PKI and should still work=20 wallet-to-wallet. It sounds like you are saying I'm proposing the customer is going to=20 need a certificate signed by CA? If so, why? I don't need this for any=20 https website I visit. It's not like the payee is sending anything to=20 the payer that is private. The payment request only becomes private if=20 something is actually received to it, otherwise, it is just discarded=20 and it doesn't matter. Those bitcoin addresses are never used. It's just = like a shopping cart on a website where someone aborts payment and=20 cancels the order. At one point I was thinking we could do something similar to Mike=20 Hearn's suggestion in another recent e-mail where we re-use some=20 existing part of the bitcoin URI to bootstrap some trust in a public key = that the payee next sends via bluetooth after the NFC connection. Now=20 that I'm reviewing my notes though, I can't see how this will work with=20 a watching only wallet or if no backwards compatible (to BIP21) bitcoin=20 address is presented in the URI (as Mike said). What I was saying above about how you can stop accepting connections on=20 that "resource" after a session key has been received by the first=20 person could be problematic though. An evil person could just start=20 making connections to every device they can, just to be mean, which=20 would not allow the POS operator to receive payments from their real=20 customers. If you do the other option I proposed, which is to just keep=20 giving out new payment requests, you have other problems (on top of=20 wasting addresses), which are that you can still have mean people giving = you a denial of service attach on your hardware, or you could have an=20 unusual situation where two people pay (don't know why they would do=20 this though), so that is why I'm suggesting a manual tap or button press = or switch turn being required. I guess as more of a abuse filter, a new "resource" could be given=20 instead with each tap, and the POS would just ignore all requests to an=20 inactive resource. You may say, why not send a new public key (as you=20 suggested) instead of a new "resource" with each tap (or button press if = using QR codes), and then you can skip the sending of a static public=20 key (or public key fingerprint), and ignore any data that is not=20 encrypted with that public key. Maybe that is a better idea because it=20 will shorten the bitcoin URI. However, I don't think its required from a = privacy standpoint, it primarily just aids in combining the public key=20 fingerprint with the changing "resource" name used to filter abuse. Or,=20 am I missing something? So, after thinking through the abuse scenarios I mentioned above, I=20 think I am agreeing with you, but the reason I'm writing all this is to=20 hopefully just get some feedback on my logic to learn something from=20 this discussion. I do think sending a unique public key over NFC has to=20 be better than a unique session key. It adds one more step, but seems to = help. If we do this, can we then safely get rid of the h=3D parameter?=20 That should make Mike Hearn happy, and also may alleviate the base64url=20 debate? Andy Schroder On 02/23/2015 09:55 PM, Eric Voskuil wrote: > 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: > ... >>> It's possible a really sophisticated modification could be done where= >>> the attacker encrypts and decrypts the communication and then relays = to >>> each party (without them knowing or any glitches detected), but I gue= ss >>> I'm not sure how easy that would be on such a close proximity device?= >> 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 attac= k. >> >> 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 compromis= ed. > 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 tain= t >> transactions may appear lower, but it is not: >> >> With the session key tap the interloper must compromise the NFC locati= on >> 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. >> >> 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 cas= e > 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 t= o >> 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. >> >> But it gets worse for the public cert tap, since a more sophisticated >> attacker can set himself up in the same position without subverting th= e >> NFC terminal at all. By broadcasting a more powerful BT service on the= >> same advertised MAC address, the attacker can capture traffic and rela= y >> 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 no= t > 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 > --9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6 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/ iQEcBAEBAgAGBQJU7BHaAAoJEDT679stRBhrjQQH/2yzv4HRI2MWe+jy3uBpGPwr 1mSPHW+2P0bVdKBTa3e65IOwK/+luk2Y4uwTExSL58HdqK3gDy9cGAz7dXU05Bgi NWd84R43aZ0GwEeM9VA8ep7tnJlioFmVRoSPfC7+ShG8I45o7kV1IacnKstdUaHs NvPug7TB8uV8o1EL5WYGmRk5NP4rbryIKIGc1sKGXgDPsdNOnabBz10dFeY3HMly 2ZumdFROl2xXsjGh4BLBZVGOMqw0msntfO6UKez2sg9nwDfFDpDL6SWbS8lOj3NU mvM0/q43H7dCURLYx99PSIvRr88bUXBuxmy9IAvfT+8kSvANzzi0hXxoHwXRK60= =YU9g -----END PGP SIGNATURE----- --9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6--