public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andreas Schildbach <andreas@schildbach.de>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Date: Mon, 23 Feb 2015 10:49:17 +0100	[thread overview]
Message-ID: <mcet2t$qav$1@ger.gmane.org> (raw)
In-Reply-To: <54EAD884.8000205@AndySchroder.com>

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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 





  parent reply	other threads:[~2015-02-23  9:49 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-22 19:08 [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback Jan Vornberger
2015-02-22 22:37 ` Andy Schroder
2015-02-22 23:06   ` Eric Voskuil
2015-02-22 23:32     ` Andy Schroder
2015-02-23  0:05       ` Eric Voskuil
2015-02-23  1:02       ` Andreas Schildbach
2015-02-23  7:36         ` Andy Schroder
2015-02-23  9:13           ` Natanael
2015-02-23  9:40           ` Eric Voskuil
2015-02-24  2:55             ` Eric Voskuil
2015-02-24  5:53               ` Andy Schroder
2015-02-24 11:28                 ` Eric Voskuil
2015-02-24 19:49                   ` Andy Schroder
2015-02-24 22:14                     ` Eric Voskuil
2015-02-24 22:50                       ` Andy Schroder
2015-02-25  2:09                         ` Eric Voskuil
2015-02-28  9:46                           ` Andy Schroder
2015-02-23  9:49           ` Andreas Schildbach [this message]
2015-02-23 10:08             ` Eric Voskuil
2015-02-23 10:58               ` Mike Hearn
2015-02-23 11:58                 ` Andreas Schildbach
2015-02-23 12:18                   ` Mike Hearn
2015-02-23 12:30                     ` Andreas Schildbach
2015-02-23 23:00                 ` Eric Voskuil
2015-02-23 23:11                   ` Mike Hearn
2015-02-24  0:10                     ` Eric Voskuil
2015-02-24 10:41                       ` Mike Hearn
2015-02-26 12:30                         ` Andreas Schildbach
2015-03-03  0:54                           ` Eric Voskuil
2015-02-23  0:58   ` Andreas Schildbach
2015-02-23 15:09   ` Jan Vornberger
2015-02-23 16:59     ` Mike Hearn
2015-02-23 19:56       ` Jan Vornberger
2015-02-23 20:31         ` Mike Hearn
2015-02-24  6:14     ` Andy Schroder
2015-02-24 15:41       ` Jan Vornberger
2015-02-26 12:37     ` Andreas Schildbach
2015-02-22 22:39 ` Eric Voskuil
2015-02-22 22:48   ` Eric Voskuil
2015-02-22 23:35     ` Andy Schroder
2015-02-23  0:46       ` Eric Voskuil
2015-02-23  1:05   ` Andreas Schildbach
2015-02-23  1:55     ` Aaron Voisine
2015-02-23  0:48 ` Andreas Schildbach
     [not found] <54ED2F34.8090704@voskuil.org>
     [not found] ` <54ED3150.4020800@AndySchroder.com>
     [not found]   ` <54ED7D8B.5070903@schildbach.de>
2015-02-25  9:20     ` Eric Voskuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='mcet2t$qav$1@ger.gmane.org' \
    --to=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox