path: root/1b/ec73c1d9ddc1ebb138735ebf69de4bf4e5f2ac

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 <info@AndySchroder.com>) 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 <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>, Jan Vornberger <jan@uos.de>, 
	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: <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: 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--