📅 Original date posted:2015-02-23
📝 Original message: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, but at least the
session could not be decrypted from recordings.
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.
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
>
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 15:31:04
in reply to nevent1q…w789
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 15:31:04Event JSON
{
"id": "f1f9adf11523d0e65f78daaa2dd9ca7fc699b816903b43eda8561add3f5a15c1",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686151864,
"kind": 1,
"tags": [
[
"e",
"dfefe04b212481eb3fe073238ab7d32774988526d8b8bf7f8fff0d7249ebe09f",
"",
"root"
],
[
"e",
"cf38469b90ca1806dcfa96fcdc66c3c657fbfa7231aaa10c8f1795bc0721206d",
"",
"reply"
],
[
"p",
"1c7d4637a4686939cc8b4a759caace11bb63bafb75b73b6f57d7ba81f9bd6a6c"
]
],
"content": "📅 Original date posted:2015-02-23\n📝 Original message:I think at this point I'd like to bring back my original suggestion of\nusing DHKE (Diffie-Hellman) or simlar. I know we'd still need to\ntransmit some secret that could be eavesdropped, but at least the\nsession could not be decrypted from recordings.\n\nAnyway, establishing a \"mostly secure\" session is clearly an improvement\nto no protection at all. If we can't find a solution to the dilemma of\nhow to exchange the secret, I suggest going ahead with what we have and\nmake the best from it.\n\n\nOn 02/23/2015 08:36 AM, 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. 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\u003e \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\u003e \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. The privacy loss will be\n\u003e significantly reduced and the motive for such attacks will be reduced.\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\u003e \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\u003e \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\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\u003e \n\u003e I'm not a cryptography expert so I apologize if there is something\n\u003e rudimentary that I am missing here.\n\u003e \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\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server\n\u003e\u003e from Actuate! Instantly Supercharge Your Business Reports and Dashboards\n\u003e\u003e with Interactivity, Sharing, Native Excel Exports, App Integration \u0026 more\n\u003e\u003e Get technology previously reserved for billion-dollar corporations, FREE\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=190641631\u0026iu=/4140/ostg.clktrk\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e \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 \n\u003e \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",
"sig": "0c9bf38432347b1f24becf6275b145e7c4914c9de9cf0940d34254d2fed6b6b7c53797e85ed34fd20978cfddc9240eb1dbf5462855b8dbff15552d7972b1619a"
}