{"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-24\n📝 Original message:Andy, adding to my previous post below:\n\nOn 02/23/2015 01:40 AM, Eric Voskuil wrote:\n\u003e On 02/22/2015 11:36 PM, Andy Schroder wrote:\n...\n\u003e\u003e It's possible a really sophisticated modification could be done where\n\u003e\u003e the attacker encrypts and decrypts the communication and then relays to\n\u003e\u003e each party (without them knowing or any glitches detected), but I guess\n\u003e\u003e I'm not sure how easy that would be on such a close proximity device?\n\u003e \n\u003e If the NFC tap is sufficiently private, privacy is easy to achieve for\n\u003e the subsequent communication. If it is not, privacy can be completely\n\u003e compromised. The question is only how much more difficult is the attack.\n\u003e \n\u003e With the public cert tap, the level of difficulty is much lower for\n\u003e capturing selected payment requests. The interloper no longer needs to\n\u003e invade the space of the NFC terminal and can instead impersonate the\n\u003e payer from a safe distance. Nobody gets paid, but privacy is compromised.\n\nThis problem in the preceding paragraph can be resolved by sending a\nunique public key on each NFC tap. In that case an attacker would need\nto monitor the NFC communication.\n\nThe talk of wrapping the connection in SSL led me to believe you were\ntalking about a static public certificate. However that's not a\nnecessary assumption here and may not be what you intended.\n\n\u003e The level of difficulty in the case where the interloper wants to taint\n\u003e transactions may appear lower, but it is not:\n\u003e \n\u003e With the session key tap the interloper must compromise the NFC location\n\u003e and then monitor the BT traffic. Monitoring BT traffic without being\n\u003e party to the connection is presumably not rocket surgery, but not\n\u003e standard BT design either.\n\u003e \n\u003e With the public cert tap the interloper must also compromise the NFC\n\u003e location and communicate over BT. Therefore the hardware and physical\n\u003e attack requirements are similar. The only added difficulty is that the\n\u003e attack on the NFC terminal attack is active (modifying the MAC address\n\u003e directing the payer to the BT service).\n\nI believe your central claim was that the difference in the two\nbootstrapping approaches (public key vs. session key) is that by using a\nunique public key per tap, the attack requires an active vs. passive\nattack on the NFC terminal. I just wanted to make clear here that I\nagree with that assessment.\n\nThe symmetric key approach is based on the idea that these attacks are\ncomparable in difficulty and otherwise identical in privacy loss.\n\nHowever, the difference in implementation amounts to about +23\nadditional encoded characters for the BT/LE URL, assuming use of the\nsecp256k1 curve for DHE. This is really not a material issue in the case\nof the NFC tap. The entire URI+URL could be as small as:\n\nbitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP\n\nIn comparison to a symmetric key:\n\nbitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E\n\nIt also does not change the protocol design or complexity at all - it\nwould just swap out an AES key for a secp256k1 public key.\n\nbitcoin:[address]?bt:\u003cmac\u003e/\u003ckey\u003e\n\nIf that gets us aligned I'm all for it.\n\n\u003e However impersonating the payer is just a matter of software - no more\n\u003e difficult than the session key attack. In fact it may be much easier to\n\u003e implement, as the attack can use supported BT features because the\n\u003e attacker has directed the payer to connect to him and is connecting to\n\u003e the receiver as if he was a payer.\n\u003e \n\u003e But it gets worse for the public cert tap, since a more sophisticated\n\u003e attacker can set himself up in the same position without subverting the\n\u003e NFC terminal at all. By broadcasting a more powerful BT service on the\n\u003e same advertised MAC address, the attacker can capture traffic and relay\n\u003e it to the intended service.\n\nI'm retracting the last paragraph, since the interloper, without\ninvading the NFC connection (by substituting the public cert), could not\nread the relayed traffic. It was getting late :/\n\n\u003e So in sum, reliance on a public cert makes the communication less\n\u003e private under the same physical set of constraints. The difference\n\u003e results from the receiver allowing non-proximate payers to impersonate\n\u003e proximate payers from a distance by generating their own session keys\n\u003e and submitting them over BT.\n\ne\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/5ac01515/attachment.sig\u003e"}