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 1YPgVr-0004Uc-QR for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 00:04:39 +0000 X-ACL-Warn: Received: from mail-pd0-f180.google.com ([209.85.192.180]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPgVp-0007oH-Kn for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 00:04:39 +0000 Received: by pdjz10 with SMTP id z10so21332075pdj.0 for ; Sun, 22 Feb 2015 16:04:31 -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=hyYIbyJg6AIoJVJXdotyJbWPmpb4HRfq7jwlDYfymQs=; b=D2ifGA/SEO22vrRHjR1S4kZ8zlR0MjEtNH9ctffaHaL5QSlEugyze2O+14+Bg0hefG elnS6EYPTfi++vi3BrTCZc1T3LXE4PRfEx34zS2xvoSiqk7pPFwIWzORHkBmij67eu3N Re3d0bxFx4KT2arGJ4TTgFeeeUHujtHnf7CGYlXGbuSdspqxh4aqSMEyrf43QJNtL8qz DvA3biqYFfPpdbNxxfbxOrkb9gWXmn/UASagbGKlXC4bJFxLfXomxK/b78E2YhpRpFbv 4xd+30OfUIIoBzUlYbC1spbSKuFVGNahlzQkuBVhHhRWkczQaO1Se7NMx9xZuxy2liEi xPfw== X-Gm-Message-State: ALoCoQldfbN7ZkNRGLveuJO1NUAsnU2o58NgVSYcJzlSSk3KNgZdVHBrl6HzaU+E+k12gi+BlCi8 X-Received: by 10.68.125.164 with SMTP id mr4mr14326801pbb.27.1424649871639; Sun, 22 Feb 2015 16:04:31 -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 kp1sm33509742pbd.54.2015.02.22.16.04.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 16:04:31 -0800 (PST) Message-ID: <54EA6EB2.1070108@voskuil.org> Date: Sun, 22 Feb 2015 16:05:06 -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: Andy Schroder , Jan Vornberger , bitcoin-development@lists.sourceforge.net References: <20150222190839.GA18527@odo.localdomain> <54EA5A1C.2020701@AndySchroder.com> <54EA60D9.8000001@voskuil.org> <54EA66F5.2000302@AndySchroder.com> In-Reply-To: <54EA66F5.2000302@AndySchroder.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Eju8GAv9VlNAfIUeoplae8PUm4DPk4CHf" 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: 1YPgVp-0007oH-Kn 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: Mon, 23 Feb 2015 00:04:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Eju8GAv9VlNAfIUeoplae8PUm4DPk4CHf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/22/2015 03:32 PM, Andy Schroder wrote: > 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 t= he >>> 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= =2E >> Once we rely on the channel being *private*, the entire SSL process is= >> unnecessary. >=20 >=20 > I guess we need to decide whether we want to consider NFC communication= > private or not. I don't know that I think it can be. If the NFC communication is not private then there is no reason to use it= =2E > An eavesdropper can > place a tiny snooping device near and read the communication. If it is > just passive, then the merchant/operator won't realize it's there. See my comments on an unmonitored terminal. > So, I > don't know if I like your idea (mentioned in your other reply) of > putting the session key in the URL is a good idea? My point is that you are not solving that problem by creating a more complex system. Either you establish trust via proximity or you don't. If you don't, it's a public network. If you do, then keep it simple. There's nothing holy about a session key in this scenario. It's not derived from long-lived keys and is itself used only once. There is nothing wrong with the URL carrying the secret. If you want to secure this channel without manual intervention, there is ultimately no other option. >> 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 require= d, >> since the private session can be established over the public (Bluetoot= h) >> 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. = We >>> 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 Raspberr= y >>>> Pi, which >>>> displays QR codes, but also provides payment requests via NFC. It ca= n >>>> optionally >>>> receive the sender's transaction via Bluetooth, so if the sender wal= let >>>> supports it, the sender can be completely offline. Only the terminal= >>>> needs an >>>> internet connection. >>>> >>>> Typical scenario envisioned: Customer taps their smartphone (or mayb= e >>>> smartwatch >>>> in the future) on the NFC pad, confirms the transaction on their pho= ne >>>> (or smartwatch) and the transaction completes via Bluetooth and/or t= he >>>> 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 standardizin= g >>>> 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, th= en >>>> 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 t= o >>>> 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 = NFC >>>> 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: Mo= st >>>> 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 c= ard >>>> 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 tha= t >>>> contains a >>>> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) als= o >>>> 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 >>>> HTTP >>>> Example QR code: >>>> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentreq= uest >>>> >>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via= >>>> HTTP >>>> Example NFC URI: >>>> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentreq= uest >>>> >>>> 5) Touch NFC pad, receive BIP70 details directly, post transaction v= ia >>>> 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 transactio= n >>>> 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 whethe= r >>>> 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 m= y >>>> 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 fetc= h >>>> 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 mo= re >>>> 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 th= at >>>> is used >>>> by Android). Maybe I have more luck with that approach and could the= n >>>> 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 cod= e >>>> or NFC URI >>>> would then look something like this: >>>> >>>> =20 >>>> 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 >>>> 'repeated >>>> string payment_url'. If this isn't causing any problems (and hopeful= ly >>>> 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= >>>> 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 = the >>>> Bluetooth channel even if the BIP70 payment request isn't signed. Th= is >>>> 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. >>>> >>>> >>>> ## Questions ## >>>> >>>> My questions to the list: >>>> >>>> 1) Do you prefer changing 'optional string payment_url' into 'repeat= ed >>>> 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 Bitco= in >>>> 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= =2Enet/msg06354.html >>>> >>>> >>>> [3] >>>> https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki= >>>> [4] >>>> https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki= >>>> >>>> --------------------------------------------------------------------= ---------- >>>> >>>> >>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>> from Actuate! Instantly Supercharge Your Business Reports and >>>> Dashboards >>>> with Interactivity, Sharing, Native Excel Exports, App Integration &= >>>> more >>>> Get technology previously reserved for billion-dollar corporations, >>>> FREE >>>> 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 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 >>> >=20 >=20 --Eju8GAv9VlNAfIUeoplae8PUm4DPk4CHf 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 iQEcBAEBAgAGBQJU6m6yAAoJEDzYwH8LXOFOcbgH/Rer2gq/qcPqNRkgWfR21wlL U0SOzUOhwF0hiohwmx2LPgMkoPIdjID036xSnkvUa/k8YccVPiTDATZCdbYgliEk 5QuFrRHQQtVwjO7/jcOcny4LcMJIkfTwXOhrX5qOdIhTXp5UY0EDt4RTlzGGIA6T R7e0DaXkUWoDU0V/9tPJVX7k3VQtBSLh6MxTnETLdMNbbThSJuWC+bFFhrQifv3T vDqq1u4T+H4yQnX0K00SP0Vbq5gCJXHrQuriLq+Zq+fMBt14FKTtvMFH/G8Ta+Jd qdlbdxmEycKCwJqaySnMfoGF7NMA4EkdRBsmaXkEsENfkJl60HrGy0P+o8P573Y= =WeBE -----END PGP SIGNATURE----- --Eju8GAv9VlNAfIUeoplae8PUm4DPk4CHf--