[Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

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>