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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPg0U-0000Cg-7c for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 23:32:14 +0000 X-ACL-Warn: Received: from uschroder.com ([74.142.93.202]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YPg0S-0005yJ-8t for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 23:32:14 +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 A044822BD6965; Sun, 22 Feb 2015 18:32:06 -0500 (EST) Message-ID: <54EA66F5.2000302@AndySchroder.com> Date: Sun, 22 Feb 2015 18:32:05 -0500 From: Andy Schroder 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 , Jan Vornberger , bitcoin-development@lists.sourceforge.net References: <20150222190839.GA18527@odo.localdomain> <54EA5A1C.2020701@AndySchroder.com> <54EA60D9.8000001@voskuil.org> In-Reply-To: <54EA60D9.8000001@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="DMPKBc3RKdOwsIJAmP5qFsV7LmVnOMFfM" 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: 1YPg0S-0005yJ-8t 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 23:32:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DMPKBc3RKdOwsIJAmP5qFsV7LmVnOMFfM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andy Schroder On 02/22/2015 06:06 PM, Eric Voskuil wrote: > On 02/22/2015 02:37 PM, Andy Schroder wrote: >> I'd like to see some discussion too about securing the bluetooth >> connection. Right now it is possible for an eavesdropper to monitor th= e >> data transferred. > Yes, this should be a prerequisite issue to all others. > >> I'd personally like to see if wrapping the current >> connection with SSL works or if we can run https over a bluetooth >> socket. > There is no reason to add this significant complexity. The purpose of > SSL/TLS is to establish privacy over a *public* channel. But to do so > requires verification by the user of the merchant's public certificate.= > Once we rely on the channel being *private*, the entire SSL process is > unnecessary. I guess we need to decide whether we want to consider NFC communication=20 private or not. I don't know that I think it can be. An eavesdropper can = place a tiny snooping device near and read the communication. If it is=20 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=20 putting the session key in the URL is a good idea? > > Presumably we would not want to require PKI for privacy, since that's a= > bit of a contradiction. But if one wants to do this NFC is not required= , > since the private session can be established over the public (Bluetooth= ) > network. > >> There was some criticism of this, but I don't think it has been >> tested to know if it is really a problem or not. If we just run https >> over bluetooth, then a lot of my concerns about the message header >> inconsistencies will go away and the connection will also be secure. W= e >> don't have to reinvent anything. >> >> >> >> Andy Schroder >> >> On 02/22/2015 02:08 PM, 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 wall= et >>> supports it, the sender can be completely offline. Only the terminal >>> needs 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 phon= e >>> (or smartwatch) and the transaction completes via Bluetooth and/or th= e >>> 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 >>> stuff - are >>> custom extensions of Schildbach's wallet which are not yet standard. >>> >>> I'm writing this post to document my experience implementing NFC and >>> offline >>> 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 >>> decided to >>> go with the combination of NFC and Bluetooth: >>> >>> Doing everything via NFC is an interesting option to keep things >>> simple, but the >>> issue is, that one usually can't maintain the connection while the >>> user confirms >>> the transaction (as they take the device back to press a button or >>> maybe enter a >>> PIN). So there are three options: >>> >>> 1. Do a "double tap": User taps, takes the device back, confirms, the= n >>> taps >>> again to transmit the transaction. (I think Google Wallet does >>> something like >>> this.) >>> >>> 2. Confirm beforehand: User confirms, then taps and everything can >>> happen in one >>> go. The disadvantage is, that you confirm the transaction before you >>> have seen >>> the details. (I believe Google Wallet can also work this way.) >>> >>> 3. Tap the phone, then establish a Bluetooth connection which allows >>> you 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 >>> on right >>> now, but there are pros and cons to all options. One disadvantage of >>> option 3 in >>> practice is, that many users - in my experience - have Bluetooth >>> turned 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 >>> following the >>> work that Airbitz has done around that, but personally I prefer the N= FC >>> interaction of "I touch what I want to pay" rather than "a payment >>> request comes >>> to me through the air and I figure out whether it is meant for me/is >>> legitimate". >>> >>> >>> ## NFC data formats ## >>> >>> A bit of background for those who are not that familiar with NFC: Mos= t >>> Bitcoin >>> wallets with NFC support make use of NDEF (NFC Data Exchange Format) >>> as far as I >>> am aware (with CoinBlesk being an exception, which uses host-based ca= rd >>> emulation, if I understand it correctly). NDEF defines a number of >>> record 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-paymentrequest' >>> 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 >>> scenarios to >>> consider below. Not every possible combination is listed, but it >>> should 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 H= TTP >>> Example QR code: >>> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentrequ= est >>> >>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via = HTTP >>> Example NFC URI: >>> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentrequ= est >>> >>> 5) Touch NFC pad, receive BIP70 details directly, post transaction vi= a >>> HTTP >>> Example NFC MIME record: application/bitcoin-paymentrequest + >>> BIP70 payment request >>> >>> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction >>> via 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 >>> now, 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 >>> request 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 >>> transfer 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 >>> amount of data >>> is small enough that it's usually 'all or nothing' and that seems mor= e >>> robust to >>> me. >>> >>> That said, I continue to have problems with the NFC stack that I'm >>> using, so it >>> might just be my NFC setup that is causing these problems. I will >>> probably give >>> the NXP NFC library a try next (which I believe is also the stack tha= t >>> 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' >>> parameter is >>> the non-standard extension of Andreas' wallet that I was mentioning. >>> TBIP75 >>> proposes to change 'bt' into 'r1' as part of a more generic approach = of >>> numbering different sources for the BIP70 payment request. I think >>> that 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: >>> >>> =20 >>> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70&r1=3Dbt:12= 34567890AB/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 >>> 'repeated >>> string payment_url'. If this isn't causing any problems (and hopefull= y >>> not too >>> much confusion?) I guess that would be fine too. >>> >>> In my opinion a wallet should then actually attempt all or multiple o= f >>> the >>> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment >>> request via >>> both HTTP and Bluetooth) and go with whatever completes first. But >>> that is of >>> course up to each wallet to decide how to handle. >>> >>> TBIP75 furthermore proposes to include an additional 'h' parameter >>> which would >>> be a hash of the BIP70 payment request, preventing a MITM attack on t= he >>> Bluetooth channel even if the BIP70 payment request isn't signed. Thi= s >>> would >>> have also been my suggestion, although I know that Mike Hearn has rai= sed >>> 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. >>> >>> >>> ## Questions ## >>> >>> My questions to the list: >>> >>> 1) Do you prefer changing 'optional string payment_url' into 'repeate= d >>> string >>> payment_url' or would you rather introduce a new field >>> 'additional_payment_urls'? >>> >>> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoi= n >>> 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.sourceforge.= net/msg06354.html >>> >>> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediaw= iki >>> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediaw= iki >>> >>> ---------------------------------------------------------------------= --------- >>> >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboa= rds >>> with Interactivity, Sharing, Native Excel Exports, App Integration & = more >>> Get technology previously reserved for billion-dollar corporations, F= REE >>> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/= ostg.clktrk >>> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >>> >> >> >> ----------------------------------------------------------------------= -------- >> 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 >> --DMPKBc3RKdOwsIJAmP5qFsV7LmVnOMFfM 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/ iQEcBAEBAgAGBQJU6mb1AAoJEDT679stRBhr7fMH/AoR21mu/kmNvfC2qaoXTPFg 9SzdUKjYMaDY6fuaTe6dpQV8XyqRCBzKb25+KViF63RKYIcyPKfB18uPRulINLmC +j4L8+mqLnrjwH4G69VAzobLg/enTsvxoEfgrYAhNCvGWQvPcsc3p8kcMhvwTSij iI12SsoGpgLYL92eJxLYqZt6IRxUO2dgmNWZeg0NelJg96ISE74K7DBUwwET0sHM EdO0bZz5rz/IbH6wZEnpFLuPzeZeT0UPHgqQh7LLG3yZZ5WBxA5Kh0PH9JzCQGB3 RpmRiiedcqXH1RKosUY5LaPtBFRCgtHNFuJIHIlXUu+KD3uImLhdCMwSRubLkII= =j3G+ -----END PGP SIGNATURE----- --DMPKBc3RKdOwsIJAmP5qFsV7LmVnOMFfM--