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 1YPpdw-0003LI-U3 for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 09:49:36 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YPpdv-0007vV-4p for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 09:49:36 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YPpdo-0002lF-1w for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 10:49:28 +0100 Received: from f052084239.adsl.alicedsl.de ([78.52.84.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2015 10:49:28 +0100 Received: from andreas by f052084239.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2015 10:49:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Mon, 23 Feb 2015 10:49:17 +0100 Message-ID: References: <20150222190839.GA18527@odo.localdomain> <54EA5A1C.2020701@AndySchroder.com> <54EA60D9.8000001@voskuil.org> <54EA66F5.2000302@AndySchroder.com> <54EAD884.8000205@AndySchroder.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: f052084239.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <54EAD884.8000205@AndySchroder.com> X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YPpdv-0007vV-4p 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:49:37 -0000 I think at this point I'd like to bring back my original suggestion of using DHKE (Diffie-Hellman) or simlar. I know we'd still need to transmit some secret that could be eavesdropped, but at least the session could not be decrypted from recordings. Anyway, establishing a "mostly secure" session is clearly an improvement to no protection at all. If we can't find a solution to the dilemma of how to exchange the secret, I suggest going ahead with what we have and make the best from it. On 02/23/2015 08:36 AM, 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 privacy > loss that could happen if there is someone passively monitoring the > connection. 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: > > Consider some cases: > > 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. > > 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). > > 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. > > 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 then > 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. The privacy loss will be > significantly reduced and the motive for such attacks will be reduced. > 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? > > 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. > > 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 payer > 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? > 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. > > I'm not a cryptography expert so I apologize if there is something > rudimentary that I am missing here. > > Andy Schroder > > 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 communication >>> 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 is >>> 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 eavesdropped >> as well of course. >> >> >> >> ------------------------------------------------------------------------------ >> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> > > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >