public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Andreas Schildbach <andreas@schildbach.de>,
	 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 02:08:28 -0800	[thread overview]
Message-ID: <54EAFC1C.9080502@voskuil.org> (raw)
In-Reply-To: <mcet2t$qav$1@ger.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 7762 bytes --]

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@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
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-02-23 10:08 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
2015-02-23 10:08             ` Eric Voskuil [this message]
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=54EAFC1C.9080502@voskuil.org \
    --to=eric@voskuil.org \
    --cc=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