Message-ID: <54EAD884.8000205@AndySchroder.com>
Date: Mon, 23 Feb 2015 02:36:36 -0500
From: Andy Schroder <info@AndySchroder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: 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>
In-Reply-To: <mcdu6b$j11$1@ger.gmane.org>
OpenPGP: id=2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ"
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

I agree that NFC is the best we have as far as a trust anchor that you=20
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=20
connection. So, in response to some of your comments below and also in=20
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=20
connection gives the payer and the payee assumed confidence that that a=20
private bluetooth connection can be created.

If the NFC actually isn't private, then by sending the session key over=20
it means the bluetooth connection is not private. An eavesdropper can=20
listen to all communication and possibly modify the communication, but=20
the payer and payee won't necessarily know if eavesdropping occurs=20
unless communication is also modified (which could be difficult to do=20
for a really low range communication).

If we send a public key of the payee over the NFC connection (in place=20
of a session key) and the NFC connection is assumed trusted (and is=20
unmodified but actually monitored by an eavesdropper) and use that=20
public key received via NFC to encrypt a session key and send it back=20
via bluetooth, to then initiate an encrypted bluetooth connection using=20
that session key for the remaining communication, then the payee still=20
receives payment as expected and the payer sends the payment they=20
expected, and the eavesdropper doesn't see anything.

If we send a public key of the payee over the NFC connection (in place=20
of a session key) and the NFC connection is assumed trusted (and is=20
actually modified by an eavesdropper) and use that public key received=20
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=20
the remaining communication, then the payee receives no payment and the=20
attack is quickly identified because the customer receives no product=20
for their payment and they notify the payee, and hopefully the problem=20
remedied and no further customers are affected. The privacy loss will be =

significantly reduced and the motive for such attacks will be reduced.=20
It's possible a really sophisticated modification could be done where=20
the attacker encrypts and decrypts the communication and then relays to=20
each party (without them knowing or any glitches detected), but I guess=20
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=20
hardwired connection to the payment terminal and those wires were=20
compromised. I guess I still think what I am saying would be better in=20
that case. There is also more obvious physical tampering required to=20
mess with wires.

I'm not sure if there is any trust anchor required of the payer by the=20
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=20
a sophisticated modification" that I mention above? I can see how this=20
could be the case for a longer range communication (like over the=20
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=20
entire POS internals than mess with an attack like that, in which case=20
everything we could do locally (other than the payment request signing=20
using PKI), is useless.

I'm not a cryptography expert so I apologize if there is something=20
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 communicatio=
n
>> private or not. I don't know that I think it can be. An eavesdropper c=
an
>> 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 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
>
>
>


--GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ
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.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJU6tiEAAoJEDT679stRBhrvG0H/iGlWo+0vVi8d2vX54mEediu
hwzUhDEPx6+RGHwmQQz9Yf/lSd9Uhk2zTq1SHRIPB48yh4a8zFITRP+7z9q/mNLZ
bSijhxMWo/OfK4+fUPdXXp2ay/bBHgy6JMoCtmIvVgtWNphZhPiCuWUDSbC9IEdb
/JbRSObTN0aXAoR/4UNBiUDATnbb40Ywa5GElPo9c4iCoWuLiZAcd8bbH4eBt3S2
XLeg3bAmnufvzLKA/FF9HDOXDIlXEOxjtC1A3GmT6HjuHq133SvIF8840yV1AF/p
+NtyWnArb7xGAas3nSqq/sS6EAGcAlfU3P7WguYvNHVz8cOcwRNaM7q7s+DUcFA=
=0XX4
-----END PGP SIGNATURE-----

--GLECcdveXMPFKqTlO8pBabaTgW4ln4EQQ--