diff options
| author | Andy Schroder <info@AndySchroder.com> | 2015-02-24 17:50:46 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-02-24 22:50:55 +0000 |
| commit | 467bebd61c55a0bba031e6e68a53e8a7400d7c2a (patch) | |
| tree | 7150550a83894357daa8789becdb8710fdef7a11 | |
| parent | e98e75346fa6a97ec201d1e85c3e69a9cdeaf5c7 (diff) | |
| download | pi-bitcoindev-467bebd61c55a0bba031e6e68a53e8a7400d7c2a.tar.gz pi-bitcoindev-467bebd61c55a0bba031e6e68a53e8a7400d7c2a.zip | |
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
| -rw-r--r-- | f0/b29eeb15db7f2c4473378a66c13e9298cb0091 | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/f0/b29eeb15db7f2c4473378a66c13e9298cb0091 b/f0/b29eeb15db7f2c4473378a66c13e9298cb0091 new file mode 100644 index 000000000..861e48df3 --- /dev/null +++ b/f0/b29eeb15db7f2c4473378a66c13e9298cb0091 @@ -0,0 +1,179 @@ +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-- + + |