{"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-24\n📝 Original message:I was saying provide a public key via NFC (or a public key fingerprint \nand then send the full public key over bluetooth). Instead of providing \na new public key on each tap, why can't the payee just stop accepting \nconnections from new parties on that \"resource\" after a session key has \nbeen received from the first person? If the person decides to have there \nfriend or family pay for them instead and cancel the payment, they could \njust hit cancel on the POS or something (on my fuel pump I have a switch \nthat needs to be turned, the purpose of this is to avoid wasting too \nmany addresses) and/or do another NFC tap (if you're providing QR codes \nyou'd still need a button of some kind though so it knows to refresh \nit), or the POS can just provide a completely new payment request to any \nnew connections on that same \"resource\" which use a different session key.\n\nI feel like the authentication of the payer to the payee in any future \nconnections after they receive the session key from them (which was \nencrypted with the payees public key), comes from the fact that they are \nsending responses back that are encrypted using the session key they \ngave to the payee. The way I am seeing it is that the NFC tap or QR code \nscan is acting in addition to the visual name check on the signature \nverification in the wallet. If the certificate used isn't signed by a CA \n(self signed), it may be fine as long as you heard about it via NFC or \nQR code. I don't think it will require PKI and should still work \nwallet-to-wallet.\n\nIt sounds like you are saying I'm proposing the customer is going to \nneed a certificate signed by CA? If so, why? I don't need this for any \nhttps website I visit. It's not like the payee is sending anything to \nthe payer that is private. The payment request only becomes private if \nsomething is actually received to it, otherwise, it is just discarded \nand it doesn't matter. Those bitcoin addresses are never used. It's just \nlike a shopping cart on a website where someone aborts payment and \ncancels the order.\n\nAt one point I was thinking we could do something similar to Mike \nHearn's suggestion in another recent e-mail where we re-use some \nexisting part of the bitcoin URI to bootstrap some trust in a public key \nthat the payee next sends via bluetooth after the NFC connection. Now \nthat I'm reviewing my notes though, I can't see how this will work with \na watching only wallet or if no backwards compatible (to BIP21) bitcoin \naddress is presented in the URI (as Mike said).\n\nWhat I was saying above about how you can stop accepting connections on \nthat \"resource\" after a session key has been received by the first \nperson could be problematic though. An evil person could just start \nmaking connections to every device they can, just to be mean, which \nwould not allow the POS operator to receive payments from their real \ncustomers. If you do the other option I proposed, which is to just keep \ngiving out new payment requests, you have other problems (on top of \nwasting addresses), which are that you can still have mean people giving \nyou a denial of service attach on your hardware, or you could have an \nunusual situation where two people pay (don't know why they would do \nthis though), so that is why I'm suggesting a manual tap or button press \nor switch turn being required.\n\nI guess as more of a abuse filter, a new \"resource\" could be given \ninstead with each tap, and the POS would just ignore all requests to an \ninactive resource. You may say, why not send a new public key (as you \nsuggested) instead of a new \"resource\" with each tap (or button press if \nusing QR codes), and then you can skip the sending of a static public \nkey (or public key fingerprint), and ignore any data that is not \nencrypted with that public key. Maybe that is a better idea because it \nwill shorten the bitcoin URI. However, I don't think its required from a \nprivacy standpoint, it primarily just aids in combining the public key \nfingerprint with the changing \"resource\" name used to filter abuse. Or, \nam I missing something?\n\n\nSo, after thinking through the abuse scenarios I mentioned above, I \nthink I am agreeing with you, but the reason I'm writing all this is to \nhopefully just get some feedback on my logic to learn something from \nthis discussion. I do think sending a unique public key over NFC has to \nbe better than a unique session key. It adds one more step, but seems to \nhelp. If we do this, can we then safely get rid of the h= parameter? \nThat should make Mike Hearn happy, and also may alleviate the base64url \ndebate?\n\n\nAndy Schroder\n\nOn 02/23/2015 09:55 PM, Eric Voskuil wrote:\n\u003e Andy, adding to my previous post below:\n\u003e\n\u003e On 02/23/2015 01:40 AM, Eric Voskuil wrote:\n\u003e\u003e On 02/22/2015 11:36 PM, Andy Schroder wrote:\n\u003e ...\n\u003e\u003e\u003e It's possible a really sophisticated modification could be done where\n\u003e\u003e\u003e the attacker encrypts and decrypts the communication and then relays to\n\u003e\u003e\u003e each party (without them knowing or any glitches detected), but I guess\n\u003e\u003e\u003e I'm not sure how easy that would be on such a close proximity device?\n\u003e\u003e If the NFC tap is sufficiently private, privacy is easy to achieve for\n\u003e\u003e the subsequent communication. If it is not, privacy can be completely\n\u003e\u003e compromised. The question is only how much more difficult is the attack.\n\u003e\u003e\n\u003e\u003e With the public cert tap, the level of difficulty is much lower for\n\u003e\u003e capturing selected payment requests. The interloper no longer needs to\n\u003e\u003e invade the space of the NFC terminal and can instead impersonate the\n\u003e\u003e payer from a safe distance. Nobody gets paid, but privacy is compromised.\n\u003e This problem in the preceding paragraph can be resolved by sending a\n\u003e unique public key on each NFC tap. In that case an attacker would need\n\u003e to monitor the NFC communication.\n\u003e\n\u003e The talk of wrapping the connection in SSL led me to believe you were\n\u003e talking about a static public certificate. However that's not a\n\u003e necessary assumption here and may not be what you intended.\n\u003e\n\u003e\u003e The level of difficulty in the case where the interloper wants to taint\n\u003e\u003e transactions may appear lower, but it is not:\n\u003e\u003e\n\u003e\u003e With the session key tap the interloper must compromise the NFC location\n\u003e\u003e and then monitor the BT traffic. Monitoring BT traffic without being\n\u003e\u003e party to the connection is presumably not rocket surgery, but not\n\u003e\u003e standard BT design either.\n\u003e\u003e\n\u003e\u003e With the public cert tap the interloper must also compromise the NFC\n\u003e\u003e location and communicate over BT. Therefore the hardware and physical\n\u003e\u003e attack requirements are similar. The only added difficulty is that the\n\u003e\u003e attack on the NFC terminal attack is active (modifying the MAC address\n\u003e\u003e directing the payer to the BT service).\n\u003e I believe your central claim was that the difference in the two\n\u003e bootstrapping approaches (public key vs. session key) is that by using a\n\u003e unique public key per tap, the attack requires an active vs. passive\n\u003e attack on the NFC terminal. I just wanted to make clear here that I\n\u003e agree with that assessment.\n\u003e\n\u003e The symmetric key approach is based on the idea that these attacks are\n\u003e comparable in difficulty and otherwise identical in privacy loss.\n\u003e\n\u003e However, the difference in implementation amounts to about +23\n\u003e additional encoded characters for the BT/LE URL, assuming use of the\n\u003e secp256k1 curve for DHE. This is really not a material issue in the case\n\u003e of the NFC tap. The entire URI+URL could be as small as:\n\u003e\n\u003e bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP\n\u003e\n\u003e In comparison to a symmetric key:\n\u003e\n\u003e bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E\n\u003e\n\u003e It also does not change the protocol design or complexity at all - it\n\u003e would just swap out an AES key for a secp256k1 public key.\n\u003e\n\u003e bitcoin:[address]?bt:\u003cmac\u003e/\u003ckey\u003e\n\u003e\n\u003e If that gets us aligned I'm all for it.\n\u003e\n\u003e\u003e However impersonating the payer is just a matter of software - no more\n\u003e\u003e difficult than the session key attack. In fact it may be much easier to\n\u003e\u003e implement, as the attack can use supported BT features because the\n\u003e\u003e attacker has directed the payer to connect to him and is connecting to\n\u003e\u003e the receiver as if he was a payer.\n\u003e\u003e\n\u003e\u003e But it gets worse for the public cert tap, since a more sophisticated\n\u003e\u003e attacker can set himself up in the same position without subverting the\n\u003e\u003e NFC terminal at all. By broadcasting a more powerful BT service on the\n\u003e\u003e same advertised MAC address, the attacker can capture traffic and relay\n\u003e\u003e it to the intended service.\n\u003e I'm retracting the last paragraph, since the interloper, without\n\u003e invading the NFC connection (by substituting the public cert), could not\n\u003e read the relayed traffic. It was getting late :/\n\u003e\n\u003e\u003e So in sum, reliance on a public cert makes the communication less\n\u003e\u003e private under the same physical set of constraints. The difference\n\u003e\u003e results from the receiver allowing non-proximate payers to impersonate\n\u003e\u003e proximate payers from a distance by generating their own session keys\n\u003e\u003e and submitting them over BT.\n\u003e e\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/20150224/79085253/attachment.sig\u003e"}