Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <info@AndySchroder.com>) id 1YQOJb-0001j7-DN
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 22:50:55 +0000
X-ACL-Warn: 
Received: from uschroder.com ([74.142.93.202])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1YQOJZ-0003NC-S0 for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 22:50:55 +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 2171B22BE0B7B;
	Tue, 24 Feb 2015 17:50:48 -0500 (EST)
Message-ID: <54ED0046.3030906@AndySchroder.com>
Date: Tue, 24 Feb 2015 17:50:46 -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>
	<54EC11DA.2010000@AndySchroder.com> <54EC605B.8080005@voskuil.org>
	<54ECD5BA.7040109@AndySchroder.com> <54ECF7DB.3060607@voskuil.org>
In-Reply-To: <54ECF7DB.3060607@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="XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj"
X-Spam-Score: 0.2 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YQOJZ-0003NC-S0
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 22:50:55 -0000

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

We can change "resource" to "Session ID" if you want.

I think the URL scheme should be:

bitcoin:[address]?r=3Dbt:<mac>&s=3D<PublicKey>

But when connecting to the mac, the client indicates the SessionID in=20
the header, and as you say, SessionID is derived in some way from PublicK=
ey.

This is a slightly different format than both of your suggestions below, =

but seems to make more sense based on what you said in your entire=20
message. The other thing is it can be used with more protocols without=20
taking up more space in the URL.

However, by loosing the h=3D parameter, I think we are now loosing some=20
benefit it brought to https based connections if the customer doesn't=20
want to use bluetooth. Right?

Also, you talk about a new public key (and session ID) for each tap. I=20
guess I'm wondering about this though. If the public key is compromised=20
on the first tap, isn't their payment request already compromised?




Since we are securing everything, can we change the message header=20
format from what Schildbach's bitcoin wallet implements to something=20
more consistent? Maybe we can create a new UUID for this secure service=20
so Schildbach's bitcoin wallet can still maintain backwards compatibility=
=2E




Andy Schroder

On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>>    * Add a "s=3D" parameter that uses a unique public key for each ses=
sion.
>>      This public key identifies the payee to the payer and payer to th=
e
>>      payee.
> This would be the simple model, which just tacks on another parameter t=
o
> the bitcoin URL:
>
> bitcoin:[address]?bt=3D<mac>&s=3D<key>
>
> But we should also look at the more flexible "r#" approach from your
> existing TBIPs, which would yield:
>
> bitcoin:[address]?r=3Dbt:<mac>/<key>
>
> and incorporate the "payment_url" list.
>
>>    * Use a base58 encoding to save space and reduce the character set
>>      slightly.
> :)
>
>>    * Get rid of the resource? If a terminal is accepting payment from
>>      multiple customers simultaneously, it should be smart enough to
>>      distinguish between customers based on the public key they are
>>      encrypting the data with. Is this approach feasible?
> Yes, it is not necessary on the URL. But an id is useful in helping the=

> BT terminal identify the session without having to try all of its
> outstanding keys until it finds one that works.
>
> I proposed that the resource name ("session id" may be a better name) b=
e
> deterministically derived from the session key. Given the design change=

> to pass an EC public key it would need to be derived from that key (not=

> from the session key because the receiver would not have a copy before
> decrypting the first BT message). So any function on the public key tha=
t
> reduces it to a smaller length, fixed width should be fine. Hashing it
> first may be better as is prevents disclosure of any bits of the public=

> key, which should be treated as a secret during the session.
>
>>    * When you said a new public key for each tap, do you see that as
>>      every single tap, or do you consider multiple taps from the same
>>      customer the same tap?
> Yes, since there would be no other way to distinguish between customers=

> in some scenarios and this is the safest approach. We certainly won't
> run out of numbers, and unused sessions can be discarded based on any
> number of criteria, including discarding all but the most recent. That
> may may be sufficient for your vending machines given there's little if=

> any call for parallelism.
>
> e


--XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj
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/

iQEcBAEBAgAGBQJU7QBGAAoJEDT679stRBhrsKsH/RnRYGT12JFqSiIwatN6QLuA
6p5jBvFlY10ttivr64ITF4muirmYFcjW8VQc/IFTX2RgLZImaT0p9cBwtARSNXrT
yW0ekjo/3Ap4m6iGeuuK4YOtECEoTMlxG0G5fkXbelLWnstMsZ67AzjRVXc45p7K
Z3cq82WljeXfGTCVKa1xsN2xA+UQn5yMpt5KGZrw9DCzRHeYl2uUW9VKylqj6rW6
xc9M1xmKDWtung0Tjx1tNQCn09s5sI7y9TP5B1w/tf9VpQoLhtM1efbknOnSnCpb
IW9aqAwyCjE8ou6WxvH9jj0g+TsD9M+P6dTAmDQv4Fw9Iq9QQpNWfkEl7szvqQo=
=upi4
-----END PGP SIGNATURE-----

--XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj--