path: root/77/bdf8066ec6e93abeccbb686bbc88f1b8e1051f

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <info@AndySchroder.com>) id 1YQ8R9-0005t8-Rv
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 05:53:39 +0000
X-ACL-Warn: 
Received: from uschroder.com ([74.142.93.202])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1YQ8R7-0005fB-DA for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 05:53:39 +0000
Received: from [192.168.253.4] (cpe-74-137-24-201.swo.res.rr.com
	[74.137.24.201])
	by uschroder.com (Postfix) with ESMTPSA id A2DD922BDCD9C;
	Tue, 24 Feb 2015 00:53:31 -0500 (EST)
Message-ID: <54EC11DA.2010000@AndySchroder.com>
Date: Tue, 24 Feb 2015 00:53:30 -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: Eric Voskuil <eric@voskuil.org>, 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>
	<54EAF570.2090602@voskuil.org> <54EBE809.70801@voskuil.org>
In-Reply-To: <54EBE809.70801@voskuil.org>
X-Enigmail-Version: 1.6
OpenPGP: id=2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6"
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: 1YQ8R7-0005fB-DA
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: Tue, 24 Feb 2015 05:53:40 -0000

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


I was saying provide a public key via NFC (or a public key fingerprint=20
and then send the full public key over bluetooth). Instead of providing=20
a new public key on each tap, why can't the payee just stop accepting=20
connections from new parties on that "resource" after a session key has=20
been received from the first person? If the person decides to have there =

friend or family pay for them instead and cancel the payment, they could =

just hit cancel on the POS or something (on my fuel pump I have a switch =

that needs to be turned, the purpose of this is to avoid wasting too=20
many addresses) and/or do another NFC tap (if you're providing QR codes=20
you'd still need a button of some kind though so it knows to refresh=20
it), or the POS can just provide a completely new payment request to any =

new connections on that same "resource" which use a different session key=
=2E

I feel like the authentication of the payer to the payee in any future=20
connections after they receive the session key from them (which was=20
encrypted with the payees public key), comes from the fact that they are =

sending responses back that are encrypted using the session key they=20
gave to the payee. The way I am seeing it is that the NFC tap or QR code =

scan is acting in addition to the visual name check on the signature=20
verification in the wallet. If the certificate used isn't signed by a CA =

(self signed), it may be fine as long as you heard about it via NFC or=20
QR code. I don't think it will require PKI and should still work=20
wallet-to-wallet.

It sounds like you are saying I'm proposing the customer is going to=20
need a certificate signed by CA? If so, why? I don't need this for any=20
https website I visit. It's not like the payee is sending anything to=20
the payer that is private. The payment request only becomes private if=20
something is actually received to it, otherwise, it is just discarded=20
and it doesn't matter. Those bitcoin addresses are never used. It's just =

like a shopping cart on a website where someone aborts payment and=20
cancels the order.

At one point I was thinking we could do something similar to Mike=20
Hearn's suggestion in another recent e-mail where we re-use some=20
existing part of the bitcoin URI to bootstrap some trust in a public key =

that the payee next sends via bluetooth after the NFC connection. Now=20
that I'm reviewing my notes though, I can't see how this will work with=20
a watching only wallet or if no backwards compatible (to BIP21) bitcoin=20
address is presented in the URI (as Mike said).

What I was saying above about how you can stop accepting connections on=20
that "resource" after a session key has been received by the first=20
person could be problematic though. An evil person could just start=20
making connections to every device they can, just to be mean, which=20
would not allow the POS operator to receive payments from their real=20
customers. If you do the other option I proposed, which is to just keep=20
giving out new payment requests, you have other problems (on top of=20
wasting addresses), which are that you can still have mean people giving =

you a denial of service attach on your hardware, or you could have an=20
unusual situation where two people pay (don't know why they would do=20
this though), so that is why I'm suggesting a manual tap or button press =

or switch turn being required.

I guess as more of a abuse filter, a new "resource" could be given=20
instead with each tap, and the POS would just ignore all requests to an=20
inactive resource. You may say, why not send a new public key (as you=20
suggested) instead of a new "resource" with each tap (or button press if =

using QR codes), and then you can skip the sending of a static public=20
key (or public key fingerprint), and ignore any data that is not=20
encrypted with that public key. Maybe that is a better idea because it=20
will shorten the bitcoin URI. However, I don't think its required from a =

privacy standpoint, it primarily just aids in combining the public key=20
fingerprint with the changing "resource" name used to filter abuse. Or,=20
am I missing something?


So, after thinking through the abuse scenarios I mentioned above, I=20
think I am agreeing with you, but the reason I'm writing all this is to=20
hopefully just get some feedback on my logic to learn something from=20
this discussion. I do think sending a unique public key over NFC has to=20
be better than a unique session key. It adds one more step, but seems to =

help. If we do this, can we then safely get rid of the h=3D parameter?=20
That should make Mike Hearn happy, and also may alleviate the base64url=20
debate?


Andy Schroder

On 02/23/2015 09:55 PM, Eric Voskuil wrote:
> Andy, adding to my previous post below:
>
> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
> ...
>>> 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 gue=
ss
>>> I'm not sure how easy that would be on such a close proximity device?=

>> If the NFC tap is sufficiently private, privacy is easy to achieve for=

>> the subsequent communication. If it is not, privacy can be completely
>> compromised. The question is only how much more difficult is the attac=
k.
>>
>> With the public cert tap, the level of difficulty is much lower for
>> capturing selected payment requests. The interloper no longer needs to=

>> invade the space of the NFC terminal and can instead impersonate the
>> payer from a safe distance. Nobody gets paid, but privacy is compromis=
ed.
> This problem in the preceding paragraph can be resolved by sending a
> unique public key on each NFC tap. In that case an attacker would need
> to monitor the NFC communication.
>
> The talk of wrapping the connection in SSL led me to believe you were
> talking about a static public certificate. However that's not a
> necessary assumption here and may not be what you intended.
>
>> The level of difficulty in the case where the interloper wants to tain=
t
>> transactions may appear lower, but it is not:
>>
>> With the session key tap the interloper must compromise the NFC locati=
on
>> and then monitor the BT traffic. Monitoring BT traffic without being
>> party to the connection is presumably not rocket surgery, but not
>> standard BT design either.
>>
>> With the public cert tap the interloper must also compromise the NFC
>> location and communicate over BT. Therefore the hardware and physical
>> attack requirements are similar. The only added difficulty is that the=

>> attack on the NFC terminal attack is active (modifying the MAC address=

>> directing the payer to the BT service).
> I believe your central claim was that the difference in the two
> bootstrapping approaches (public key vs. session key) is that by using =
a
> unique public key per tap, the attack requires an active vs. passive
> attack on the NFC terminal. I just wanted to make clear here that I
> agree with that assessment.
>
> The symmetric key approach is based on the idea that these attacks are
> comparable in difficulty and otherwise identical in privacy loss.
>
> However, the difference in implementation amounts to about +23
> additional encoded characters for the BT/LE URL, assuming use of the
> secp256k1 curve for DHE. This is really not a material issue in the cas=
e
> of the NFC tap. The entire URI+URL could be as small as:
>
> bitcoin:?r=3Dbt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>
> In comparison to a symmetric key:
>
> bitcoin:?r=3Dbt:12rAs9mM/12drXXUifSrRnXLGbXg8E
>
> It also does not change the protocol design or complexity at all - it
> would just swap out an AES key for a secp256k1 public key.
>
> bitcoin:[address]?bt:<mac>/<key>
>
> If that gets us aligned I'm all for it.
>
>> However impersonating the payer is just a matter of software - no more=

>> difficult than the session key attack. In fact it may be much easier t=
o
>> implement, as the attack can use supported BT features because the
>> attacker has directed the payer to connect to him and is connecting to=

>> the receiver as if he was a payer.
>>
>> But it gets worse for the public cert tap, since a more sophisticated
>> attacker can set himself up in the same position without subverting th=
e
>> NFC terminal at all. By broadcasting a more powerful BT service on the=

>> same advertised MAC address, the attacker can capture traffic and rela=
y
>> it to the intended service.
> I'm retracting the last paragraph, since the interloper, without
> invading the NFC connection (by substituting the public cert), could no=
t
> read the relayed traffic. It was getting late :/
>
>> So in sum, reliance on a public cert makes the communication less
>> private under the same physical set of constraints. The difference
>> results from the receiver allowing non-proximate payers to impersonate=

>> proximate payers from a distance by generating their own session keys
>> and submitting them over BT.
> e
>



--9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6
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/

iQEcBAEBAgAGBQJU7BHaAAoJEDT679stRBhrjQQH/2yzv4HRI2MWe+jy3uBpGPwr
1mSPHW+2P0bVdKBTa3e65IOwK/+luk2Y4uwTExSL58HdqK3gDy9cGAz7dXU05Bgi
NWd84R43aZ0GwEeM9VA8ep7tnJlioFmVRoSPfC7+ShG8I45o7kV1IacnKstdUaHs
NvPug7TB8uV8o1EL5WYGmRk5NP4rbryIKIGc1sKGXgDPsdNOnabBz10dFeY3HMly
2ZumdFROl2xXsjGh4BLBZVGOMqw0msntfO6UKez2sg9nwDfFDpDL6SWbS8lOj3NU
mvM0/q43H7dCURLYx99PSIvRr88bUXBuxmy9IAvfT+8kSvANzzi0hXxoHwXRK60=
=YU9g
-----END PGP SIGNATURE-----

--9nmS3U79w7p2jfiei9n6VOjoM4RbpbPG6--