{"type":"rich","version":"1.0","author_name":"npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","author_url":"https://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-23\n📝 Original message:I agree that NFC is the best we have as far as a trust anchor that you \nare paying the right person. The thing I am worried about is the privacy \nloss that could happen if there is someone passively monitoring the \nconnection. So, in response to some of your comments below and also in \nresponse to some of Eric Voskuil's comments in another recent e-mail:\n\nConsider some cases:\n\nIf NFC is assumed private, then sending the session key over the NFC \nconnection gives the payer and the payee assumed confidence that that a \nprivate bluetooth connection can be created.\n\nIf the NFC actually isn't private, then by sending the session key over \nit means the bluetooth connection is not private. An eavesdropper can \nlisten to all communication and possibly modify the communication, but \nthe payer and payee won't necessarily know if eavesdropping occurs \nunless communication is also modified (which could be difficult to do \nfor a really low range communication).\n\nIf we send a public key of the payee over the NFC connection (in place \nof a session key) and the NFC connection is assumed trusted (and is \nunmodified but actually monitored by an eavesdropper) and use that \npublic key received via NFC to encrypt a session key and send it back \nvia bluetooth, to then initiate an encrypted bluetooth connection using \nthat session key for the remaining communication, then the payee still \nreceives payment as expected and the payer sends the payment they \nexpected, and the eavesdropper doesn't see anything.\n\nIf we send a public key of the payee over the NFC connection (in place \nof a session key) and the NFC connection is assumed trusted (and is \nactually modified by an eavesdropper) and use that public key received \nvia NFC to encrypt a session key and send it back via bluetooth, to then \ninitiate an encrypted bluetooth connection using that session key for \nthe remaining communication, then the payee receives no payment and the \nattack is quickly identified because the customer receives no product \nfor their payment and they notify the payee, and hopefully the problem \nremedied and no further customers are affected. The privacy loss will be \nsignificantly reduced and the motive for such attacks will be reduced. \nIt's possible a really sophisticated modification could be done where \nthe attacker encrypts and decrypts the communication and then relays to \neach party (without them knowing or any glitches detected), but I guess \nI'm not sure how easy that would be on such a close proximity device?\n\nErick Voskuil mentioned this same problem would even occur if you had a \nhardwired connection to the payment terminal and those wires were \ncompromised. I guess I still think what I am saying would be better in \nthat case. There is also more obvious physical tampering required to \nmess with wires.\n\nI'm not sure if there is any trust anchor required of the payer by the \npayee, is there? Eric also mentioned a need for this. Why does the payer \ncare who they are as long as they get a payment received? Just to avoid \na sophisticated modification\" that I mention above? I can see how this \ncould be the case for a longer range communication (like over the \ninternet), but I'm not convinced it will be easy on really short ranges? \nIt's almost like the attacker would be better off to just replace the \nentire POS internals than mess with an attack like that, in which case \neverything we could do locally (other than the payment request signing \nusing PKI), is useless.\n\nI'm not a cryptography expert so I apologize if there is something \nrudimentary that I am missing here.\n\nAndy Schroder\n\nOn 02/22/2015 08:02 PM, Andreas Schildbach wrote:\n\u003e On 02/23/2015 12:32 AM, Andy Schroder wrote:\n\u003e\u003e I guess we need to decide whether we want to consider NFC communication\n\u003e\u003e private or not. I don't know that I think it can be. An eavesdropper can\n\u003e\u003e place a tiny snooping device near and read the communication. If it is\n\u003e\u003e just passive, then the merchant/operator won't realize it's there. So, I\n\u003e\u003e don't know if I like your idea (mentioned in your other reply) of\n\u003e\u003e putting the session key in the URL is a good idea?\n\u003e I think the \"trust by proximity\" is the best we've got. If we don't\n\u003e trust the NFC link (or the QR code scan), what other options have we\n\u003e got? Speaking the session key by voice? Bad UX, and can be eavesdropped\n\u003e as well of course.\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 Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 555 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/90498cd6/attachment.sig\u003e"}