{"type":"rich","version":"1.0","author_name":"npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","author_url":"https://nostr.ae/npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-23\n📝 Original message:On 02/22/2015 11:36 PM, 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. \n\nWe have the same objective. Privacy loss is my primary concern with the\nexisting proposal.\n\n\u003e 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\nI realize you are postulating a situation where an interloper monitors\nbut doesn't substitute the NFC communication. But clearly if you can do\none you have the potential to do the other, so if one is going to rely\non the assumption that the NFC tap can be monitored one must also accept\nthat it can be modified. Once one accepts this premise there is no point\nin using NFC.\n\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\nYou can send a public cert over a public channel but before it can be\nused it must be validated and verified to belong to the party that you\nintend to communicate with privately. Otherwise the interloper can\nsubstitute a public cert and subvert the payment process.\n\nThe reduces to the system requiring PKI just to establish private\ncommunication. One might argue that BIP-70 already contemplates PKI.\nHowever the above approach is significantly different in that it would\n*require* all NFC/BT communication to use PKI just to be private.\n\nFurthermore, to establish a private channel between *both* intended\nparities, public certs must be exchanged in both directions. Otherwise,\nif the customer isn't validated by the merchant, a distant interloper\ncan trivially use the merchant's public cert to obtain the payment\nrequest from the Bluetooth terminal. This is the privacy breach that we\nare trying to prevent in the first place.\n\nAny requirement for PKI, in either direction, itself creates privacy\nproblems. But a requirement for customer certificates really gets hairy.\n\nThe PKI requirement can be dropped by instead exchanging self-generated\npublic keys, in the RedPhone model. However that requires out-of-band\nsecure communication of a common derived value by the parties. This\ncould be as simple as a number on each screen that one or both of the\nparties compares. But this requires no private communication, and\ntherefore NFC is entirely unnecessary. This is in fact what I would\nrecommend for the BT-only scenario.\n\nThe value added by NFC is that proximity can be used to establish trust.\nIf that does not meet one's threshold for privacy then the parties need\nto establish this trust through some presumably more private channel\n(such as visual or voice confirmation).\n\nNote that payment integrity can be reasonably ensured by relying on PKI\nas established by BIP-70 (which also offers the seller non-repudiation\nbenefit). So this question is strictly about privacy.\n\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. \n\nIn this case the attacker hijacks the subsequent BT connection, sends a\npayment request and gets paid. The only thing to prevent it would be\nBIP-70/PKI, as mentioned above.\n\nIn a more complex attack the interloper can sit in the middle of all\ncommunications between payer and receiver. Since the payer is not\nvalidated by the receiver the interloper can impersonate the payer in\nall communication with the receiver. As such he can also impersonate the\nreceiver in all communications with the payer. If the NFC communication\nis compromized there is no saving privacy without an alternate private\nchannel.\n\n\u003e The privacy loss will be\n\u003e significantly reduced and the motive for such attacks will be reduced.\n\nThe motive and privacy loss remain unchanged.\n\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\nIf the NFC tap is sufficiently private, privacy is easy to achieve for\nthe subsequent communication. If it is not, privacy can be completely\ncompromised. The question is only how much more difficult is the attack.\n\nWith the public cert tap, the level of difficulty is much lower for\ncapturing selected payment requests. The interloper no longer needs to\ninvade the space of the NFC terminal and can instead impersonate the\npayer from a safe distance. Nobody gets paid, but privacy is compromised.\n\nThe level of difficulty in the case where the interloper wants to taint\ntransactions may appear lower, but it is not:\n\nWith the session key tap the interloper must compromise the NFC location\nand then monitor the BT traffic. Monitoring BT traffic without being\nparty to the connection is presumably not rocket surgery, but not\nstandard BT design either.\n\nWith the public cert tap the interloper must also compromise the NFC\nlocation and communicate over BT. Therefore the hardware and physical\nattack requirements are similar. The only added difficulty is that the\nattack on the NFC terminal attack is active (modifying the MAC address\ndirecting the payer to the BT service).\n\nHowever impersonating the payer is just a matter of software - no more\ndifficult than the session key attack. In fact it may be much easier to\nimplement, as the attack can use supported BT features because the\nattacker has directed the payer to connect to him and is connecting to\nthe receiver as if he was a payer.\n\nBut it gets worse for the public cert tap, since a more sophisticated\nattacker can set himself up in the same position without subverting the\nNFC terminal at all. By broadcasting a more powerful BT service on the\nsame advertised MAC address, the attacker can capture traffic and relay\nit to the intended service.\n\nSo in sum, reliance on a public cert makes the communication less\nprivate under the same physical set of constraints. The difference\nresults from the receiver allowing non-proximate payers to impersonate\nproximate payers from a distance by generating their own session keys\nand submitting them over BT.\n\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\nAttacks against wires do not require tampering with (as in damaging)\nwires. The distinction between a wired connection and a wireless\nconnection is in many ways imaginary.\n\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\nI think I addressed this above but let me know if not.\n\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\nYes, ultimately both endpoints must be secured. My point is that (when\nintended) NFC is practically the equivalent of a wired connection.\nBaseband attacks against buyers' phones or subversion of the entire POS\nterminal may be easier than interloping on a monitored NFC terminal. But\nthat's the point, once the attack is easier at the endpoints that is\nwhere it will go. Further attempts to secure the gap between the devices\nwill not help after that point.\n\n\u003e I'm not a cryptography expert so I apologize if there is something\n\u003e rudimentary that I am missing here.\n\nNo need for apology, it's a good discussion, and there are precious few\nexperts here.\n\nThis discussion should make people very wary of any terminal system that\ndoesn't use signed payment requests :).\n\ne\n\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\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/e131bcbc/attachment.sig\u003e"}