{"type":"rich","version":"1.0","author_name":"npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7","author_url":"https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-23\n📝 Original message:I think at this point I'd like to bring back my original suggestion of\nusing DHKE (Diffie-Hellman) or simlar. I know we'd still need to\ntransmit some secret that could be eavesdropped, but at least the\nsession could not be decrypted from recordings.\n\nAnyway, establishing a \"mostly secure\" session is clearly an improvement\nto no protection at all. If we can't find a solution to the dilemma of\nhow to exchange the secret, I suggest going ahead with what we have and\nmake the best from it.\n\n\nOn 02/23/2015 08:36 AM, Andy Schroder wrote:\n\u003e I agree that NFC is the best we have as far as a trust anchor that you\n\u003e are paying the right person. The thing I am worried about is the privacy\n\u003e loss that could happen if there is someone passively monitoring the\n\u003e connection. So, in response to some of your comments below and also in\n\u003e response to some of Eric Voskuil's comments in another recent e-mail:\n\u003e \n\u003e Consider some cases:\n\u003e \n\u003e If NFC is assumed private, then sending the session key over the NFC\n\u003e connection gives the payer and the payee assumed confidence that that a\n\u003e private bluetooth connection can be created.\n\u003e \n\u003e If the NFC actually isn't private, then by sending the session key over\n\u003e it means the bluetooth connection is not private. An eavesdropper can\n\u003e listen to all communication and possibly modify the communication, but\n\u003e the payer and payee won't necessarily know if eavesdropping occurs\n\u003e unless communication is also modified (which could be difficult to do\n\u003e for a really low range communication).\n\u003e \n\u003e If we send a public key of the payee over the NFC connection (in place\n\u003e of a session key) and the NFC connection is assumed trusted (and is\n\u003e unmodified but actually monitored by an eavesdropper) and use that\n\u003e public key received via NFC to encrypt a session key and send it back\n\u003e via bluetooth, to then initiate an encrypted bluetooth connection using\n\u003e that session key for the remaining communication, then the payee still\n\u003e receives payment as expected and the payer sends the payment they\n\u003e expected, and the eavesdropper doesn't see anything.\n\u003e \n\u003e If we send a public key of the payee over the NFC connection (in place\n\u003e of a session key) and the NFC connection is assumed trusted (and is\n\u003e actually modified by an eavesdropper) and use that public key received\n\u003e via NFC to encrypt a session key and send it back via bluetooth, to then\n\u003e initiate an encrypted bluetooth connection using that session key for\n\u003e the remaining communication, then the payee receives no payment and the\n\u003e attack is quickly identified because the customer receives no product\n\u003e for their payment and they notify the payee, and hopefully the problem\n\u003e remedied and no further customers are affected. The privacy loss will be\n\u003e significantly reduced and the motive for such attacks will be reduced.\n\u003e It's possible a really sophisticated modification could be done where\n\u003e the attacker encrypts and decrypts the communication and then relays to\n\u003e each party (without them knowing or any glitches detected), but I guess\n\u003e I'm not sure how easy that would be on such a close proximity device?\n\u003e \n\u003e Erick Voskuil mentioned this same problem would even occur if you had a\n\u003e hardwired connection to the payment terminal and those wires were\n\u003e compromised. I guess I still think what I am saying would be better in\n\u003e that case. There is also more obvious physical tampering required to\n\u003e mess with wires.\n\u003e \n\u003e I'm not sure if there is any trust anchor required of the payer by the\n\u003e payee, is there? Eric also mentioned a need for this. Why does the payer\n\u003e care who they are as long as they get a payment received? Just to avoid\n\u003e a sophisticated modification\" that I mention above? I can see how this\n\u003e could be the case for a longer range communication (like over the\n\u003e internet), but I'm not convinced it will be easy on really short ranges?\n\u003e It's almost like the attacker would be better off to just replace the\n\u003e entire POS internals than mess with an attack like that, in which case\n\u003e everything we could do locally (other than the payment request signing\n\u003e using PKI), is useless.\n\u003e \n\u003e I'm not a cryptography expert so I apologize if there is something\n\u003e rudimentary that I am missing here.\n\u003e \n\u003e Andy Schroder\n\u003e \n\u003e On 02/22/2015 08:02 PM, Andreas Schildbach wrote:\n\u003e\u003e On 02/23/2015 12:32 AM, Andy Schroder wrote:\n\u003e\u003e\u003e I guess we need to decide whether we want to consider NFC communication\n\u003e\u003e\u003e private or not. I don't know that I think it can be. An eavesdropper can\n\u003e\u003e\u003e place a tiny snooping device near and read the communication. If it is\n\u003e\u003e\u003e just passive, then the merchant/operator won't realize it's there. So, I\n\u003e\u003e\u003e don't know if I like your idea (mentioned in your other reply) of\n\u003e\u003e\u003e putting the session key in the URL is a good idea?\n\u003e\u003e I think the \"trust by proximity\" is the best we've got. If we don't\n\u003e\u003e trust the NFC link (or the QR code scan), what other options have we\n\u003e\u003e got? Speaking the session key by voice? Bad UX, and can be eavesdropped\n\u003e\u003e as well of course.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server\n\u003e\u003e from Actuate! Instantly Supercharge Your Business Reports and Dashboards\n\u003e\u003e with Interactivity, Sharing, Native Excel Exports, App Integration \u0026 more\n\u003e\u003e Get technology previously reserved for billion-dollar corporations, FREE\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=190641631\u0026iu=/4140/ostg.clktrk\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server\n\u003e from Actuate! Instantly Supercharge Your Business Reports and Dashboards\n\u003e with Interactivity, Sharing, Native Excel Exports, App Integration \u0026 more\n\u003e Get technology previously reserved for billion-dollar corporations, FREE\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=190641631\u0026iu=/4140/ostg.clktrk\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e"}