path: root/83/4e33bfe054681b3c205d66012561fac68f48f7

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <eric@voskuil.org>) id 1YPpvl-00020f-V0
	for bitcoin-development@lists.sourceforge.net;
	Mon, 23 Feb 2015 10:08:01 +0000
X-ACL-Warn: 
Received: from mail-pd0-f173.google.com ([209.85.192.173])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YPpvj-00009Q-Lw
	for bitcoin-development@lists.sourceforge.net;
	Mon, 23 Feb 2015 10:08:01 +0000
Received: by pdjy10 with SMTP id y10so24339302pdj.6
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 23 Feb 2015 02:07:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type;
	bh=ENmWhcwxTRUZeq45e3rhyR8CQyVWxxpSmX/S1Ssy1Ek=;
	b=c1erdG706VCYNuqkFeR+d6cl5cQxRzuEGPwR+PGSD0TJM1z31sY+apPYx0PBF3f9RV
	4i3OObtYfz33lYNhTsuIyV73yQqNKTOzL4rU8cpKLMjHlSYs+ZJVOrQ0K4ItTFOC6hp3
	ESUAvSiyR9lvQP45mmbf8+EEPc+joQ/TqgPQiJs+EqyPoPhS2m7m7lGa/i6f2z4TToZy
	eV8qmlLEnnO5VL323wotzB9aXQreldIWBrnPb1m5Jj6gg3Md2W83oLRkSV/kNvA8ZNCo
	1ktfwmAo1bZk5P4xcfaRSOLME55dLPpWxoRG8taIQeFwJUHO0x+QLfUQesgTxhEtH3Xp
	dRRg==
X-Gm-Message-State: ALoCoQl5Bhp3jSAuADx9YdcR+t4OelwTrzczUoStmh/4SlW0X15erZu7dTfAJ/7a+UcjSatToiwT
X-Received: by 10.69.26.166 with SMTP id iz6mr17944902pbd.9.1424686073799;
	Mon, 23 Feb 2015 02:07:53 -0800 (PST)
Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net.
	[50.135.46.157]) by mx.google.com with ESMTPSA id
	ut3sm35021151pbc.25.2015.02.23.02.07.52
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 23 Feb 2015 02:07:53 -0800 (PST)
Message-ID: <54EAFC1C.9080502@voskuil.org>
Date: Mon, 23 Feb 2015 02:08:28 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andreas Schildbach <andreas@schildbach.de>, 
	bitcoin-development@lists.sourceforge.net
References: <20150222190839.GA18527@odo.localdomain>	<54EA5A1C.2020701@AndySchroder.com>	<54EA60D9.8000001@voskuil.org>	<54EA66F5.2000302@AndySchroder.com>	<mcdu6b$j11$1@ger.gmane.org>
	<54EAD884.8000205@AndySchroder.com> <mcet2t$qav$1@ger.gmane.org>
In-Reply-To: <mcet2t$qav$1@ger.gmane.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YPpvj-00009Q-Lw
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2015 10:08:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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,=20

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 improvemen=
t
> 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 priva=
cy
>> 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 ove=
r
>> 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 usin=
g
>> 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 th=
en
>> initiate an encrypted bluetooth connection using that session key for
>> the remaining communication, then the payee receives no payment and th=
e
>> 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 t=
o
>> each party (without them knowing or any glitches detected), but I gues=
s
>> 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 pay=
er
>> care who they are as long as they get a payment received? Just to avoi=
d
>> 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 range=
s?
>> 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 communicat=
ion
>>>> 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. S=
o, 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 eavesdropp=
ed
>>> as well of course.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------=
---------
>>>
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboa=
rds
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & =
more
>>> Get technology previously reserved for billion-dollar corporations, F=
REE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/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 Dashboar=
ds
>> with Interactivity, Sharing, Native Excel Exports, App Integration & m=
ore
>> Get technology previously reserved for billion-dollar corporations, FR=
EE
>> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/o=
stg.clktrk
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboard=
s
> with Interactivity, Sharing, Native Excel Exports, App Integration & mo=
re
> Get technology previously reserved for billion-dollar corporations, FRE=
E
> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/os=
tg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20


--CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU6vwcAAoJEDzYwH8LXOFOt2YIAIIfalOKxPefjVRq4TO0ASNM
eZQ1WEV4VvOgP1Rt9nBfi/J7I/91hhbBRHrhiziQCcF305/OV9jRj7F1bD1PINb5
bBor8kHiazscjPhJry2EVqBheNg8cTjHCGSVuzCpxzjpG2AFYMRWM1tRFTzYdMl3
4zLOb0qW2uVZYqDEQM4NZt9J9KkagE4FyApP2FMcqtLjkoyB5j06EBL1aPb//YRz
y26VrqC+CLfCvr6wMk2PhgvyN0+VElnRVZbLpjgVtQonrpjrd/WvbUjqanA0h95X
XLzyyDZLJu6havSacmtz7FvTIDeMjbJR74Cz9v4rtWJf8K7Ad1PuQG8SP9yGNPs=
=HMqj
-----END PGP SIGNATURE-----

--CFgDxDalBs3kEN0cmBACJvTWgrDU5wfdi--