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