Andy Schroder [ARCHIVE] on Nostr: š Original date posted:2015-02-23 š Original message:I agree that NFC is the ...
š
Original date posted:2015-02-23
š Original message: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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/90498cd6/attachment.sig>;
š Original message: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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/90498cd6/attachment.sig>;