From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPpUD-0006CA-9q for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 09:39:33 +0000 X-ACL-Warn: Received: from mail-pd0-f174.google.com ([209.85.192.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPpUB-00009O-GU for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 09:39:33 +0000 Received: by pdjg10 with SMTP id g10so24257899pdj.1 for ; Mon, 23 Feb 2015 01:39:25 -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=id8gpSFH4CUqLnsrNmX9cv7SXfu5HTYKBMVJQxKVFcM=; b=Zgq1GrkXwv6y7IsYWBR/zBlro6GLjhBseb9oLG5X4jou3avHx+Pxps96MY4sukHL9X L8+TPOeEi+dEhx+gubeAmaHr52RjO5OkFfeOPi+e8iRiOFTcKJWrIc/vtslwJnMbuvNO Lgd15IFpYXce2rgzjplDmWjJw/yk+h4XQwyPOfXYabyPPkW1Ij2YWhTDUneJpvpcwQio 3LEl4GA/u+m5QFCuSD5H2QCduORxrdri40I7auK9uJaUvJVR99S1DURRQpPRf/eTKVq9 YI6X1A2CkESYobyCNccnVukbuu1xhFgwqwrtv9V7Cfw1SLNiLiU2PT43h2QCMdbSvwLu pKOQ== X-Gm-Message-State: ALoCoQklHji4/1BNZKCMWCIAtA+NqEm//MoTkub1rmmLnwlWxSguPDcfNW2wymSQE02Z+t1cJ7Ci X-Received: by 10.68.203.136 with SMTP id kq8mr17639413pbc.103.1424684365582; Mon, 23 Feb 2015 01:39:25 -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 bt2sm24777250pad.12.2015.02.23.01.39.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 01:39:24 -0800 (PST) Message-ID: <54EAF570.2090602@voskuil.org> Date: Mon, 23 Feb 2015 01:40:00 -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> In-Reply-To: <54EAD884.8000205@AndySchroder.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g3WHx41rpdA8Wlo2PItRGF5BHqqURL1NS" 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: 1YPpUB-00009O-GU 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: Mon, 23 Feb 2015 09:39:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g3WHx41rpdA8Wlo2PItRGF5BHqqURL1NS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/22/2015 11:36 PM, Andy Schroder wrote: > I agree that NFC is the best we have as far as a trust anchor that you > are paying the right person. The thing I am worried about is the privac= y > loss that could happen if there is someone passively monitoring the > connection.=20 We have the same objective. Privacy loss is my primary concern with the existing proposal. > So, in response to some of your comments below and also in > response to some of Eric Voskuil's comments in another recent e-mail: >=20 > Consider some cases: >=20 > If NFC is assumed private, then sending the session key over the NFC > connection gives the payer and the payee assumed confidence that that a= > private bluetooth connection can be created. >=20 > If the NFC actually isn't private, then by sending the session key over= > it means the bluetooth connection is not private. An eavesdropper can > listen to all communication and possibly modify the communication, but > the payer and payee won't necessarily know if eavesdropping occurs > unless communication is also modified (which could be difficult to do > for a really low range communication). I realize you are postulating a situation where an interloper monitors but doesn't substitute the NFC communication. But clearly if you can do one you have the potential to do the other, so if one is going to rely on the assumption that the NFC tap can be monitored one must also accept that it can be modified. Once one accepts this premise there is no point in using NFC. > If we send a public key of the payee over the NFC connection (in place > of a session key) and the NFC connection is assumed trusted (and is > unmodified but actually monitored by an eavesdropper) and use that > public key received 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 the remaining communication, then the payee still > receives payment as expected and the payer sends the payment they > expected, and the eavesdropper doesn't see anything. You can send a public cert over a public channel but before it can be used it must be validated and verified to belong to the party that you intend to communicate with privately. Otherwise the interloper can substitute a public cert and subvert the payment process. The reduces to the system requiring PKI just to establish private communication. One might argue that BIP-70 already contemplates PKI. However the above approach is significantly different in that it would *require* all NFC/BT communication to use PKI just to be private. Furthermore, to establish a private channel between *both* intended parities, public certs must be exchanged in both directions. Otherwise, if the customer isn't validated by the merchant, a distant interloper can trivially use the merchant's public cert to obtain the payment request from the Bluetooth terminal. This is the privacy breach that we are trying to prevent in the first place. Any requirement for PKI, in either direction, itself creates privacy problems. But a requirement for customer certificates really gets hairy. The PKI requirement can be dropped by instead exchanging self-generated public keys, in the RedPhone model. However that requires out-of-band secure communication of a common derived value by the parties. This could be as simple as a number on each screen that one or both of the parties compares. But this requires no private communication, and therefore NFC is entirely unnecessary. This is in fact what I would recommend for the BT-only scenario. The value added by NFC is that proximity can be used to establish trust. If that does not meet one's threshold for privacy then the parties need to establish this trust through some presumably more private channel (such as visual or voice confirmation). Note that payment integrity can be reasonably ensured by relying on PKI as established by BIP-70 (which also offers the seller non-repudiation benefit). So this question is strictly about privacy. > If we send a public key of the payee over the NFC connection (in place > of a session key) and the NFC connection is assumed trusted (and is > actually modified by an eavesdropper) and use that public key received > via NFC to encrypt a session key and send it back via bluetooth, to the= n > initiate an encrypted bluetooth connection using that session key for > the remaining communication, then the payee receives no payment and the= > attack is quickly identified because the customer receives no product > for their payment and they notify the payee, and hopefully the problem > remedied and no further customers are affected.=20 In this case the attacker hijacks the subsequent BT connection, sends a payment request and gets paid. The only thing to prevent it would be BIP-70/PKI, as mentioned above. In a more complex attack the interloper can sit in the middle of all communications between payer and receiver. Since the payer is not validated by the receiver the interloper can impersonate the payer in all communication with the receiver. As such he can also impersonate the receiver in all communications with the payer. If the NFC communication is compromized there is no saving privacy without an alternate private channel. > The privacy loss will be > significantly reduced and the motive for such attacks will be reduced. The motive and privacy loss remain unchanged. > 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 guess= > 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 attack. 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 compromised.= The level of difficulty in the case where the interloper wants to taint transactions may appear lower, but it is not: With the session key tap the interloper must compromise the NFC location 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). 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. 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. 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. > Erick Voskuil mentioned this same problem would even occur if you had a= > hardwired connection to the payment terminal and those wires were > compromised. I guess I still think what I am saying would be better in > that case. There is also more obvious physical tampering required to > mess with wires. Attacks against wires do not require tampering with (as in damaging) wires. The distinction between a wired connection and a wireless connection is in many ways imaginary. > I'm not sure if there is any trust anchor required of the payer by the > payee, is there? Eric also mentioned a need for this. Why does the paye= r > care who they are as long as they get a payment received? Just to avoid= > a sophisticated modification" that I mention above? I can see how this > could be the case for a longer range communication (like over the > internet), but I'm not convinced it will be easy on really short ranges= ? I think I addressed this above but let me know if not. > It's almost like the attacker would be better off to just replace the > entire POS internals than mess with an attack like that, in which case > everything we could do locally (other than the payment request signing > using PKI), is useless. Yes, ultimately both endpoints must be secured. My point is that (when intended) NFC is practically the equivalent of a wired connection. Baseband attacks against buyers' phones or subversion of the entire POS terminal may be easier than interloping on a monitored NFC terminal. But that's the point, once the attack is easier at the endpoints that is where it will go. Further attempts to secure the gap between the devices will not help after that point. > I'm not a cryptography expert so I apologize if there is something > rudimentary that I am missing here. No need for apology, it's a good discussion, and there are precious few experts here. This discussion should make people very wary of any terminal system that doesn't use signed payment requests :). e > Andy Schroder >=20 > 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 communicati= on >>> private or not. I don't know that I think it can be. An eavesdropper = can >>> place a tiny snooping device near and read the communication. If it i= s >>> 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 eavesdroppe= d >> as well of course. --g3WHx41rpdA8Wlo2PItRGF5BHqqURL1NS 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 iQEcBAEBAgAGBQJU6vVwAAoJEDzYwH8LXOFOHywH/i6xE7kjKCPFhcpR3VS9BWkK +6e8okWKJ5LnDV35gnJWKQh5ubpnwpFj/nQO6Hna9542hxVZ+rgicOegsP/CZ19Q n09xXWUPgdl2/DzPCrHoBWE3B6gOKp6I5e0G2wJ1tezsBy9XJO3I8YeeLCUnV3cC YBqWDULu5mxebzEXAB9efZZUMa4f0AP4uT6oHDKx6DRMFFh2UsXpsDbNAu06URna u/YNmJhqIp7fpy8P9RrMsotPXLXlH0CTOVjlvKM+rd1D6UPBebrSi6pJWFVEfml6 A7fl++BZHodOf3sE7RNP8LyOwwCCy6ohI5NzXym2wngnsbU0W0D9LHxFhMVtoB8= =J7M5 -----END PGP SIGNATURE----- --g3WHx41rpdA8Wlo2PItRGF5BHqqURL1NS--