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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPpvl-00020f-V0 for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 10:08:01 +0000 X-ACL-Warn: Received: from mail-pd0-f173.google.com ([209.85.192.173]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPpvj-00009Q-Lw for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 10:08:01 +0000 Received: by pdjy10 with SMTP id y10so24339302pdj.6 for ; Mon, 23 Feb 2015 02:07:53 -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=ENmWhcwxTRUZeq45e3rhyR8CQyVWxxpSmX/S1Ssy1Ek=; b=c1erdG706VCYNuqkFeR+d6cl5cQxRzuEGPwR+PGSD0TJM1z31sY+apPYx0PBF3f9RV 4i3OObtYfz33lYNhTsuIyV73yQqNKTOzL4rU8cpKLMjHlSYs+ZJVOrQ0K4ItTFOC6hp3 ESUAvSiyR9lvQP45mmbf8+EEPc+joQ/TqgPQiJs+EqyPoPhS2m7m7lGa/i6f2z4TToZy eV8qmlLEnnO5VL323wotzB9aXQreldIWBrnPb1m5Jj6gg3Md2W83oLRkSV/kNvA8ZNCo 1ktfwmAo1bZk5P4xcfaRSOLME55dLPpWxoRG8taIQeFwJUHO0x+QLfUQesgTxhEtH3Xp dRRg== X-Gm-Message-State: ALoCoQl5Bhp3jSAuADx9YdcR+t4OelwTrzczUoStmh/4SlW0X15erZu7dTfAJ/7a+UcjSatToiwT X-Received: by 10.69.26.166 with SMTP id iz6mr17944902pbd.9.1424686073799; Mon, 23 Feb 2015 02:07:53 -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 ut3sm35021151pbc.25.2015.02.23.02.07.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 02:07:53 -0800 (PST) Message-ID: <54EAFC1C.9080502@voskuil.org> Date: Mon, 23 Feb 2015 02:08:28 -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: Andreas Schildbach , 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: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi" 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: 1YPpvj-00009Q-Lw 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 10:08:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/23/2015 01:49 AM, Andreas Schildbach wrote: > 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,=20 Hi Andreas, DHKE will not improve the situation. Either we use a simple method to transfer a session key or a complex method. > but at least the session could not be decrypted from recordings. DHKE doesn't offer greater forward secrecy than private transfer of a session key, in fact it's lesser. > Anyway, establishing a "mostly secure" session is clearly an improvemen= t > 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. I don't see that there is a dilemma. The current proposal has a significant privacy problem that can be easily resolved, and the resolution actually makes the implementation simpler. e > 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 priva= cy >> 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 ove= r >> 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 usin= g >> 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 th= en >> initiate an encrypted bluetooth connection using that session key for >> the remaining communication, then the payee receives no payment and th= e >> 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 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? >> >> 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 pay= er >> care who they are as long as they get a payment received? Just to avoi= d >> 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 range= s? >> 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 communicat= ion >>>> 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. S= o, 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 eavesdropp= ed >>> as well of course. >>> >>> >>> >>> ---------------------------------------------------------------------= --------- >>> >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboa= rds >>> with Interactivity, Sharing, Native Excel Exports, App Integration & = more >>> Get technology previously reserved for billion-dollar corporations, F= REE >>> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/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 Dashboar= ds >> with Interactivity, Sharing, Native Excel Exports, App Integration & m= ore >> Get technology previously reserved for billion-dollar corporations, FR= EE >> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/o= stg.clktrk >> >> >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >=20 >=20 >=20 > -----------------------------------------------------------------------= ------- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboard= s > with Interactivity, Sharing, Native Excel Exports, App Integration & mo= re > Get technology previously reserved for billion-dollar corporations, FRE= E > http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/os= tg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi 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 iQEcBAEBAgAGBQJU6vwcAAoJEDzYwH8LXOFOt2YIAIIfalOKxPefjVRq4TO0ASNM eZQ1WEV4VvOgP1Rt9nBfi/J7I/91hhbBRHrhiziQCcF305/OV9jRj7F1bD1PINb5 bBor8kHiazscjPhJry2EVqBheNg8cTjHCGSVuzCpxzjpG2AFYMRWM1tRFTzYdMl3 4zLOb0qW2uVZYqDEQM4NZt9J9KkagE4FyApP2FMcqtLjkoyB5j06EBL1aPb//YRz y26VrqC+CLfCvr6wMk2PhgvyN0+VElnRVZbLpjgVtQonrpjrd/WvbUjqanA0h95X XLzyyDZLJu6havSacmtz7FvTIDeMjbJR74Cz9v4rtWJf8K7Ad1PuQG8SP9yGNPs= =HMqj -----END PGP SIGNATURE----- --CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi--