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 > ------------------------------------------------------------------------------ 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
