From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPfJa-0001cN-3i for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 22:47:54 +0000 X-ACL-Warn: Received: from mail-pa0-f50.google.com ([209.85.220.50]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPfJX-000123-Qa for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 22:47:54 +0000 Received: by padbj1 with SMTP id bj1so22734813pad.5 for ; Sun, 22 Feb 2015 14:47:45 -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=KgckCaDNzTHeGSAlSGpzmsIeNg+mIlcGUppWZ+XlTsM=; b=kYtlI2B9P9s1MTz5MUCEa0hsjypI0x+OO64cQVVHu0SU+iUGQKy4ZbS2Hllh2nUbYR xhwXh40SaKlynjuhwbrV1wruWz0CW4j9+Q4lxWFuPNtTy71S/q6Fj6DEFEMFUTqqop+o MrowlyUDNKkhx8i/K5pG5iMZOvpIYeeROhFs901MHVKSr/xZAwyfhlzYWLsimJFolAOt 0kq04Sq6IdQa4XBqIwZPNTY/3OoSD6vaFub0rlKiNR4oc2anN4m24wV6KFq0OvMD0+OH 2BgXFgkn/PcjNn0vkPQ0CVMmwMcwiTfPqP7t93VlAIa5IiHJ6bjP5/IiVP5+DkE6bjIo HDGQ== X-Gm-Message-State: ALoCoQkrtJHuOA7NFQauVmhzz87UI2jD6s5fzYwpe3MMaBqfPB3hmM766/NU7ZPlfoBW0qHfBiKr X-Received: by 10.66.176.203 with SMTP id ck11mr14605901pac.54.1424645265506; Sun, 22 Feb 2015 14:47:45 -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 f8sm30756497pdm.68.2015.02.22.14.47.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 14:47:44 -0800 (PST) Message-ID: <54EA5CB4.5030302@voskuil.org> Date: Sun, 22 Feb 2015 14:48:20 -0800 From: Eric Voskuil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jan Vornberger , bitcoin-development@lists.sourceforge.net References: <20150222190839.GA18527@odo.localdomain> <54EA5AAE.3040306@voskuil.org> In-Reply-To: <54EA5AAE.3040306@voskuil.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg" 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: 1YPfJX-000123-Qa 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 22:47:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One correction inline below. e On 02/22/2015 02:39 PM, Eric Voskuil wrote: > Hi Jan, >=20 > This is really nice work. >=20 > WRT the Schroder and Schildbach proposal, the generalization of the "r"= > and "payment_url" parameters makes sense, with only the potential > backward compat issue on payment_url. >=20 >> TBIP75 furthermore proposes to include an additional 'h' parameter >> which would be a hash of the BIP70 payment request, preventing a MITM >> attack on the Bluetooth channel even if the BIP70 payment request >> isn't signed. This would have also been my suggestion, although I >> know that Mike Hearn has raised concerns about this approach. One >> being, that one needs to finalize the BIP70 payment request at the >> time the QR code and NFC URI is generated. >> ... >> 3) Are there other comments regarding 'h' parameter as per TBIP75? >=20 > Yes, this design is problematic from a privacy standpoint. Anyone withi= n > the rather significant range of the Bluetooth terminal is able to > capture payment requests and correlate them to people. In other words i= t > can be used to automate tainting. >=20 > The problem is easily resolved by recognizing that, in the envisioned > face-to-face trade, proximity is the source of trust. Even in the above= > proposal the "h" parameter is trusted because it was obtained by > proximity to the NFC terminal. The presumption is that this proximity > produces a private channel. >=20 > As such the "tap" should transfer a session key used for symmetric bloc= k > cipher over the Bluetooth channel. This also resolves the issue of > needing to formulate the payment request before the NFC. >=20 > As an aside, in other scenarios, such as an automated dispenser, this > presumption does not hold. The merchant is not present to guard against= > device tampering. Those scenarios can be secured using BIP70, but canno= t > guarantee privacy. >=20 > The other differences I have with the proposal pertain to efficiency, > not privacy or integrity of the transaction: >=20 > The proposed resource name is redundant with any unique identifier for > the session. For example, the "h" parameter is sufficient. But with the= > establishment of a session key both as I propose above, the parties can= > derive a sufficiently unique public resource name from a hash of the > key. An additional advantage is that the resource name can be > fixed-length, simplifying the encoding/decoding. >=20 > The MAC address (and resource name) should be encoded using base58. Thi= s The MAC address (and session key) should be encoded using base58. This > is shorter than base16, is often shorter than base64, better > standardized and does not require URI encoding, and is generally > available to implementers. >=20 > There is no need for the establishment of two Bluetooth services. >=20 > I would change the payment_url recommendation so that the list order > represents a recommended ordering provided by the terminal for the wall= et. >=20 > I wrote up my thoughts on these considerations last year and recently > revised it by adding a section at the end to incorporate the "r" and > "payment_url" generalizations from Andreas and Andy. >=20 > https://github.com/evoskuil/bips/tree/master/docs >=20 > e >=20 >=20 > On 02/22/2015 11:08 AM, Jan Vornberger wrote: >> Hi everyone, >> >> I am working on a Bitcoin point of sale terminal based on a Raspberry = Pi, which >> displays QR codes, but also provides payment requests via NFC. It can = optionally >> receive the sender's transaction via Bluetooth, so if the sender walle= t >> supports it, the sender can be completely offline. Only the terminal n= eeds an >> internet connection. >> >> Typical scenario envisioned: Customer taps their smartphone (or maybe = smartwatch >> in the future) on the NFC pad, confirms the transaction on their phone= >> (or smartwatch) and the transaction completes via Bluetooth and/or the= phone's >> internet connection. >> >> You can see a prototype in action here: >> >> https://www.youtube.com/watch?v=3DP7vKHMoapr8 >> >> The above demo uses a release version of Schildbach's Bitcoin Wallet, = so it >> works as shown today. However, some parts - especially the Bluetooth s= tuff - are >> custom extensions of Schildbach's wallet which are not yet standard. >> >> I'm writing this post to document my experience implementing NFC and o= ffline >> payments and hope to move the discussion forward around standardizing = some of >> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1= ,2] >> follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4= ] are >> relevant here as well. >> >> >> ## NFC vs Bluetooth vs NFC+Bluetooth ## >> >> Before I get into the implementation details, a few words for why I de= cided to >> go with the combination of NFC and Bluetooth: >> >> Doing everything via NFC is an interesting option to keep things simpl= e, but the >> issue is, that one usually can't maintain the connection while the use= r confirms >> the transaction (as they take the device back to press a button or may= be enter a >> PIN). So there are three options: >> >> 1. Do a "double tap": User taps, takes the device back, confirms, then= taps >> again to transmit the transaction. (I think Google Wallet does somethi= ng like >> this.) >> >> 2. Confirm beforehand: User confirms, then taps and everything can hap= pen in one >> go. The disadvantage is, that you confirm the transaction before you h= ave seen >> the details. (I believe Google Wallet can also work this way.) >> >> 3. Tap the phone, then establish a Bluetooth connection which allows y= ou to do >> all necessary communication even if the user takes the device back. >> >> I feel that option 3 is the nicest UX, so that is what I am focusing o= n right >> now, but there are pros and cons to all options. One disadvantage of o= ption 3 in >> practice is, that many users - in my experience - have Bluetooth turne= d off, so >> it can result in additional UI dialogs popping up, asking the user to = turn on >> Bluetooth. >> >> Regarding doing everything via Bluetooth or maybe BLE: I have been fol= lowing the >> work that Airbitz has done around that, but personally I prefer the NF= C >> interaction of "I touch what I want to pay" rather than "a payment req= uest comes >> to me through the air and I figure out whether it is meant for me/is l= egitimate". >> >> >> ## NFC data formats ## >> >> A bit of background for those who are not that familiar with NFC: Most= Bitcoin >> wallets with NFC support make use of NDEF (NFC Data Exchange Format) a= s far as I >> am aware (with CoinBlesk being an exception, which uses host-based car= d >> emulation, if I understand it correctly). NDEF defines a number of rec= ord types, >> among them 'URI' and 'Mime Type'. >> >> A common way of using NFC with Bitcoin is to create a URI record that = contains a >> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also = support >> the mime type record, which is then set to 'application/bitcoin-paymen= trequest' >> and the rest of the NFC data is a complete BIP70 payment request. >> >> >> ## Implementation ## >> >> To structure the discussion a little bit, I have listed a number of sc= enarios to >> consider below. Not every possible combination is listed, but it shoul= d cover a >> bit of everything. >> >> Scenarios: >> >> 1) Scan QR code, transmit transaction via Bitcoin network >> Example QR code: bitcoin:1asdf...?amount=3D42 >> >> 2) Touch NFC pad, transmit transaction via Bitcoin network >> Example NFC URI: bitcoin:1asdf...?amount=3D42 >> >> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HT= TP >> Example QR code: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.o= rg/bip70paymentrequest >> >> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via H= TTP >> Example NFC URI: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.o= rg/bip70paymentrequest >> >> 5) Touch NFC pad, receive BIP70 details directly, post transaction via= HTTP >> Example NFC MIME record: application/bitcoin-paymentrequest + BIP70= payment request >> >> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction v= ia Bluetooth >> Example QR code: bitcoin:1asdf...?amount=3D42&bt=3D1234567890AB >> Payment request has 'payment_url' set to 'bt:1234567890AB' >> >> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction = via Bluetooth >> Example NFC URI: bitcoin:1asdf...?amount=3D42&bt=3D1234567890AB >> Payment request has 'payment_url' set to 'bt:1234567890AB' >> >> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I = am just >> listing them here for comparison. Scenario 3 is what is often in use n= ow, for >> example when using a checkout screen by BitPay or Coinbase. >> >> I played around with both scenarios 4 and 5, trying to decide whether = I should >> use an NFC URI record or already provide the complete BIP70 payment re= quest via >> NFC. >> >> My experience here has been, that the latter was fairly fragile in my = setup >> (Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy= ). I tried >> with signed payment requests that were around 4k to 5k and the transfe= r would >> often not complete if I didn't hold the phone perfectly in place. So I= quickly >> switched to using the NFC URI record instead and have the phone fetch = the BIP70 >> payment request via Bluetooth afterwards. Using this approach the amou= nt of data >> is small enough that it's usually 'all or nothing' and that seems more= robust to >> me. >> >> That said, I continue to have problems with the NFC stack that I'm usi= ng, so it >> might just be my NFC setup that is causing these problems. I will prob= ably give >> the NXP NFC library a try next (which I believe is also the stack that= is used >> by Android). Maybe I have more luck with that approach and could then = switch to >> scenario 5. >> >> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' pa= rameter is >> the non-standard extension of Andreas' wallet that I was mentioning. T= BIP75 >> proposes to change 'bt' into 'r1' as part of a more generic approach o= f >> numbering different sources for the BIP70 payment request. I think tha= t is a >> good idea and would express my vote for this proposal. So the QR code = or NFC URI >> would then look something like this: >> >> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70&r1=3Dbt:1= 234567890AB/resource >> >> In addition the payment request would need to list additional 'payment= _url's. My >> proposal would be to do something like this: >> >> message PaymentDetails { >> ... >> optional string payment_url =3D 6; >> optional bytes merchant_data =3D 7; >> repeated string additional_payment_urls =3D 8; >> // ^-- new; to hold things like 'bt:1234567890AB' >> } >> >> TBIP75 proposes to just change 'optional string payment_url' into 'rep= eated >> string payment_url'. If this isn't causing any problems (and hopefully= not too >> much confusion?) I guess that would be fine too. >> >> In my opinion a wallet should then actually attempt all or multiple of= the >> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment r= equest via >> both HTTP and Bluetooth) and go with whatever completes first. But tha= t is of >> course up to each wallet to decide how to handle. >> >> TBIP75 furthermore proposes to include an additional 'h' parameter whi= ch would >> be a hash of the BIP70 payment request, preventing a MITM attack on th= e >> Bluetooth channel even if the BIP70 payment request isn't signed. This= would >> have also been my suggestion, although I know that Mike Hearn has rais= ed >> concerns about this approach. One being, that one needs to finalize th= e BIP70 >> payment request at the time the QR code and NFC URI is generated. >> >> >> ## Questions ## >> >> My questions to the list: >> >> 1) Do you prefer changing 'optional string payment_url' into 'repeated= string >> payment_url' or would you rather introduce a new field 'additional_pay= ment_urls'? >> >> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin= Wallet? >> >> 3) Are there other comments regarding 'h' parameter as per TBIP75? >> >> 4) General comments, advice, feedback? >> >> I appreciate your input! :-) >> >> Cheers, >> Jan >> >> [1] http://andyschroder.com/BitcoinFluidDispenser/ >> [2] https://www.mail-archive.com/bitcoin-development%40lists.sourcefor= ge.net/msg06354.html >> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawi= ki >> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawi= ki >> >> ----------------------------------------------------------------------= -------- >> 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 --EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg 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 iQEcBAEBAgAGBQJU6ly0AAoJEDzYwH8LXOFON9AIAJLAoyAShWYbZWl2WLxu7UsX WflGHSOjmsMMDs6tVfG3uwN0DbFAEXtAYn8idWCfkiNu7jWieCLtk1ppJlE2n29p cqJwlUFJA+SH8ASQHB7MgcJMDBZVX6fYCZMEs6g40aNbdxLVOR5iKpoZPRRsq+uu DaqhPA/C+qOqbM+I4b/p3C2n1I9XwzpnK4SClHVG2Scpy1grUxiky8UfOJWxM9Zl u+Yhiw2DQg7bbHpgOfk3zvDPF2RDue3xTLigDvzJMN5MtLZNRhEAiAUWG8KPnxGZ WUjMo+DHZXqwcMHQs8q4Ubr26LH94KTxzZalD2yLQcACi5FomEuDod3YZT4ZrGg= =trTk -----END PGP SIGNATURE----- --EsaN5hiOSjCUxLOTbQukLSanNjdL70lIg--