[Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Jan Vornberger]

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 wallet
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 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=P7vKHMoapr8

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, then 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 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: Most 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 card
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=42

2) Touch NFC pad, transmit transaction via Bitcoin network
   Example NFC URI: bitcoin:1asdf...?amount=42

3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
   Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest

4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
   Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/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 via Bluetooth
   Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
   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=42&bt=1234567890AB
   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 more 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 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' 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:

  bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
        optional bytes merchant_data = 7;
        repeated string additional_payment_urls = 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 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 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. 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.


## 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_payment_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.sourceforge.net/msg06354.html
[3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
[4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 15030 bytes --]

Hello Jan,

Regarding a few of your questions:

Andreas and I had a number of private discussions regarding the 
payment_url parameter. I had suggested a "additional_payment_urls" 
repeated parameter, but he didn't seem to like that idea and I 
personally am indifferent, so that is why we decided to just change 
payment_url to a repeated field. The spec is simpler without the 
"additional_payment_urls", but the wallets have to be a little bit 
smarter finding the right url they want to use in the list. It's maybe 
not a bad idea for the wallet to try all payment_url mechanisms in 
parallel. Should we add this as a recommendation to wallets in TBIP75?

I had heard from Andreas a few weeks ago that the multiple r parameters 
was not yet implemented. Maybe your interest can motivate him to do so!

I actually also happen to be using nfcpy. I am having some reliability 
issues as well with it. What exactly are your problems?

I have seen your video before. I guess I'm wondering how your prototype 
works with bitpay and bluetooth. Doesn't bitpay sign the payment request 
for you with an https based payment_url? If so, how do you add the 
bluetooth payment_url while keeping their signature valid? In your video 
it looks like the phone still has cellular and wifi reception (it is not 
offline).

You mention workflow options 1,2,3. You forgot to mention that options 
1,2 are not backwards compatible with older wallets.

Regarding the NFC data formats. I would like to clarify that the wallets 
are having those events dispatched by the android OS. The "URI" and 
"mime type" events are sent to the application in the same way as from 
other sources such as a web browser, e-mail, stand alone QR code scanner 
app, etc.. So, I don't think the wallet actually knows it is receiving 
the event from NFC. That is one reason why so many existing wallets 
happen to support BIP21 payment request via NFC. Andreas can correct me 
if I am wrong on these statements. I'm a little weary sending the "mime 
type" based format over NFC because of backwards compatibility and 
because of the long certificate chain that needs to be transferred. You 
want that tap to be as robust and fast as possible. A bluetooth 
connection can have a retry without any user interaction.

I don't really understand why Mike Hearn has the objections to the h 
parameter. It seems like you should already be ready to produce the 
BIP70 payment request at the time when the URI is generated. I'd also 
like to clarify that the h parameter is for more than just unsigned 
payment requests. You can have a signed payment request with the wrong 
signer. There is way to much brainpower required to verify that the 
signer is actually the merchant you are doing business with. Just think 
how many times you shop at a store that you don't even know the name of. 
Also, the store may contract their payment processing out to another 
party, or they may have multiple store names but use the same payment 
processing system for all their stores, and the parent company has a 
different name. It's good to have both the h parameter AND the signed 
payment request.

I don't really like the Airbitz proposal. Figuring out if your selecting 
is the right one is a real nuisance. The idea is neat in a few 
applications, but I just don't think it is going to work for people as 
the most efficient and trouble free option day to day. I realize they 
are probably doing it to work with Apple's limited functionality phones 
(and BLE is a new buzz word). However, I don't think we should base 
bitcoin around what Apple wants us to do. They've already had their war 
on bitcoin. They are going to do whatever they can to protect their NFC 
based payment system. We need to make their platform the the less 
desirable one if they are going to play the game that way. If that means 
an Airbitz like proposal is implemented as a fallback, maybe that is 
fine and POS systems need to support both, but I just don't think we 
should limit what we can do because of Apple's products capabilities.

There is also the "ack" memo that I mentioned in reference [2]. I think 
we can improve upon this really. Can we make a new status field or 
different bluetooth message header? I know Andreas didn't want to change 
it because that is how his app already works, but I don't think the way 
it is is ideal.

I'd like to see some discussion too about securing the bluetooth 
connection. Right now it is possible for an eavesdropper to monitor the 
data transferred. 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 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 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 wallet
> 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 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=P7vKHMoapr8
>
> 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, then 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 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: Most 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 card
> 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=42
>
> 2) Touch NFC pad, transmit transaction via Bitcoin network
>     Example NFC URI: bitcoin:1asdf...?amount=42
>
> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>     Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>
> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>     Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/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 via Bluetooth
>     Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>     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=42&bt=1234567890AB
>     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 more 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 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' 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:
>
>    bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>          optional bytes merchant_data = 7;
>          repeated string additional_payment_urls = 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 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 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. 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.
>
>
> ## 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_payment_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.sourceforge.net/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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>


[-- Attachment #1.2: 0x2D44186B.asc --]
[-- Type: application/pgp-keys, Size: 1769 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 12987 bytes --]

Hi Jan,

This is really nice work.

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.

> 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?

Yes, this design is problematic from a privacy standpoint. Anyone within
the rather significant range of the Bluetooth terminal is able to
capture payment requests and correlate them to people. In other words it
can be used to automate tainting.

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.

As such the "tap" should transfer a session key used for symmetric block
cipher over the Bluetooth channel. This also resolves the issue of
needing to formulate the payment request before the NFC.

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 cannot
guarantee privacy.

The other differences I have with the proposal pertain to efficiency,
not privacy or integrity of the transaction:

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.

The MAC address (and resource name) 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.

There is no need for the establishment of two Bluetooth services.

I would change the payment_url recommendation so that the list order
represents a recommended ordering provided by the terminal for the wallet.

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.

https://github.com/evoskuil/bips/tree/master/docs

e


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 wallet
> 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 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=P7vKHMoapr8
> 
> 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, then 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 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: Most 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 card
> 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=42
> 
> 2) Touch NFC pad, transmit transaction via Bitcoin network
>    Example NFC URI: bitcoin:1asdf...?amount=42
> 
> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>    Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
> 
> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>    Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/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 via Bluetooth
>    Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>    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=42&bt=1234567890AB
>    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 more 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 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' 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:
> 
>   bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>         optional bytes merchant_data = 7;
>         repeated string additional_payment_urls = 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 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 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. 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.
> 
> 
> ## 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_payment_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.sourceforge.net/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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 13423 bytes --]

One correction inline below.

e

On 02/22/2015 02:39 PM, Eric Voskuil wrote:
> Hi Jan,
> 
> This is really nice work.
> 
> 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.
> 
>> 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?
> 
> Yes, this design is problematic from a privacy standpoint. Anyone within
> the rather significant range of the Bluetooth terminal is able to
> capture payment requests and correlate them to people. In other words it
> can be used to automate tainting.
> 
> 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.
> 
> As such the "tap" should transfer a session key used for symmetric block
> cipher over the Bluetooth channel. This also resolves the issue of
> needing to formulate the payment request before the NFC.
> 
> 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 cannot
> guarantee privacy.
> 
> The other differences I have with the proposal pertain to efficiency,
> not privacy or integrity of the transaction:
> 
> 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.
> 
> The MAC address (and resource name) should be encoded using base58. This

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.
> 
> There is no need for the establishment of two Bluetooth services.
> 
> I would change the payment_url recommendation so that the list order
> represents a recommended ordering provided by the terminal for the wallet.
> 
> 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.
> 
> https://github.com/evoskuil/bips/tree/master/docs
> 
> e
> 
> 
> 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 wallet
>> 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 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=P7vKHMoapr8
>>
>> 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, then 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 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: Most 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 card
>> 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=42
>>
>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>    Example NFC URI: bitcoin:1asdf...?amount=42
>>
>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>>    Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>
>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>>    Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/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 via Bluetooth
>>    Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>    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=42&bt=1234567890AB
>>    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 more 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 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' 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:
>>
>>   bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>>         optional bytes merchant_data = 7;
>>         repeated string additional_payment_urls = 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 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 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. 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.
>>
>>
>> ## 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_payment_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.sourceforge.net/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=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 12457 bytes --]

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 the
> 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.

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. 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 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 wallet
>> 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 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=P7vKHMoapr8
>>
>> 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, then
>> 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 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: Most
>> 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 card
>> 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=42
>>
>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>     Example NFC URI: bitcoin:1asdf...?amount=42
>>
>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>>     Example QR code:
>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>
>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>>     Example NFC URI:
>> bitcoin:1asdf...?amount=42&r=https://example.org/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
>> via Bluetooth
>>     Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>     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=42&bt=1234567890AB
>>     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 more
>> 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 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'
>> 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:
>>
>>   
>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>>          optional bytes merchant_data = 7;
>>          repeated string additional_payment_urls = 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 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
>> 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. 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.
>>
>>
>> ## 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_payment_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.sourceforge.net/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=190641631&iu=/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 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=190641631&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1: Type: text/plain, Size: 13283 bytes --]


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 the
>> 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 
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 
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 
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. 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 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 wallet
>>> 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 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=P7vKHMoapr8
>>>
>>> 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, then
>>> 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 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: Most
>>> 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 card
>>> 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=42
>>>
>>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>>      Example NFC URI: bitcoin:1asdf...?amount=42
>>>
>>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>>>      Example QR code:
>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>
>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>>>      Example NFC URI:
>>> bitcoin:1asdf...?amount=42&r=https://example.org/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
>>> via Bluetooth
>>>      Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>>      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=42&bt=1234567890AB
>>>      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 more
>>> 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 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'
>>> 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:
>>>
>>>    
>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>>>           optional bytes merchant_data = 7;
>>>           repeated string additional_payment_urls = 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 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
>>> 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. 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.
>>>
>>>
>>> ## 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_payment_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.sourceforge.net/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=190641631&iu=/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 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=190641631&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 14897 bytes --]


Andy Schroder

On 02/22/2015 05:48 PM, Eric Voskuil wrote:
> One correction inline below.
>
> e
>
> On 02/22/2015 02:39 PM, Eric Voskuil wrote:
>> Hi Jan,
>>
>> This is really nice work.
>>
>> 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.
>>
>>> 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?
>> Yes, this design is problematic from a privacy standpoint. Anyone within
>> the rather significant range of the Bluetooth terminal is able to
>> capture payment requests and correlate them to people. In other words it
>> can be used to automate tainting.
>>
>> 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.
>>
>> As such the "tap" should transfer a session key used for symmetric block
>> cipher over the Bluetooth channel. This also resolves the issue of
>> needing to formulate the payment request before the NFC.
>>
>> 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 cannot
>> guarantee privacy.
>>
>> The other differences I have with the proposal pertain to efficiency,
>> not privacy or integrity of the transaction:
>>
>> 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.
>>
>> The MAC address (and resource name) should be encoded using base58. This
> The MAC address (and session key) should be encoded using base58. This


As I mentioned in my other e-mail, I don't know that we can consider 
this NFC a private channel, so I don't think a session key should be 
transmitted over it.


>
>> is shorter than base16, is often shorter than base64, better
>> standardized and does not require URI encoding, and is generally
>> available to implementers.
>>
>> There is no need for the establishment of two Bluetooth services.
>>
>> I would change the payment_url recommendation so that the list order
>> represents a recommended ordering provided by the terminal for the wallet.
>>
>> 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.


The order is set so that it maintains backwards compatibility by 
providing the https request first. As mentioned in the proposal, the 
order of the r parameters has the recommended (but not required) 
priority. The wallet is encouraged to use the same protocol (but not 
required).


>>
>> https://github.com/evoskuil/bips/tree/master/docs
>>
>> e
>>
>>
>> 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 wallet
>>> 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 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=P7vKHMoapr8
>>>
>>> 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, then 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 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: Most 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 card
>>> 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=42
>>>
>>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>>     Example NFC URI: bitcoin:1asdf...?amount=42
>>>
>>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>>>     Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>
>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>>>     Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/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 via Bluetooth
>>>     Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>>     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=42&bt=1234567890AB
>>>     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 more 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 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' 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:
>>>
>>>    bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>>>          optional bytes merchant_data = 7;
>>>          repeated string additional_payment_urls = 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 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 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. 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.
>>>
>>>
>>> ## 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_payment_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.sourceforge.net/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=190641631&iu=/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 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=190641631&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #1.2: Type: text/html, Size: 17386 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 14382 bytes --]

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 the
>>> 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
> 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.

> 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 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. 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 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 wallet
>>>> 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 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=P7vKHMoapr8
>>>>
>>>> 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, then
>>>> 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 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: Most
>>>> 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 card
>>>> 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=42
>>>>
>>>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>>>      Example NFC URI: bitcoin:1asdf...?amount=42
>>>>
>>>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via
>>>> HTTP
>>>>      Example QR code:
>>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>>
>>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via
>>>> HTTP
>>>>      Example NFC URI:
>>>> bitcoin:1asdf...?amount=42&r=https://example.org/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
>>>> via Bluetooth
>>>>      Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>>>      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=42&bt=1234567890AB
>>>>      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 more
>>>> 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 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'
>>>> 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:
>>>>
>>>>   
>>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>>>>           optional bytes merchant_data = 7;
>>>>           repeated string additional_payment_urls = 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 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
>>>> 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. 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.
>>>>
>>>>
>>>> ## 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_payment_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.sourceforge.net/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=190641631&iu=/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 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=190641631&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 17254 bytes --]

On 02/22/2015 03:35 PM, Andy Schroder wrote:
>> On 02/22/2015 02:39 PM, Eric Voskuil wrote:
>>> Hi Jan,
>>>
>>> This is really nice work.
>>>
>>> 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.
>>>
>>>> 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?
>>> Yes, this design is problematic from a privacy standpoint. Anyone within
>>> the rather significant range of the Bluetooth terminal is able to
>>> capture payment requests and correlate them to people. In other words it
>>> can be used to automate tainting.
>>>
>>> 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.
>>>
>>> As such the "tap" should transfer a session key used for symmetric block
>>> cipher over the Bluetooth channel. This also resolves the issue of
>>> needing to formulate the payment request before the NFC.
>>>
>>> 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 cannot
>>> guarantee privacy.
>>>
>>> The other differences I have with the proposal pertain to efficiency,
>>> not privacy or integrity of the transaction:
>>>
>>> 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.
>>>
>>> The MAC address (and resource name) should be encoded using base58. This
>> The MAC address (and session key) should be encoded using base58. This
> 
> 
> As I mentioned in my other e-mail, I don't know that we can consider
> this NFC a private channel, so I don't think a session key should be
> transmitted over it.

I don't think there is another option. The point of the NFC terminal is
to establish trust based on proximity.

I don't agree that it's insufficiently private. It's no less private
than if the customer pulled out an R2-D2 interface arm and plugged into
the merchant's terminal. The terminal connection can still be compromised.

IOW the merchant trusts that the person who just tapped on the NFC
terminal is the one who he/she is going to hand the product to, and both
parties trust that because of this handshake, no non-proximate
interlopers can monitor the content of the transaction. In the absence
of BIP70 (quite real in some scenarios) the payer also relies on
proximity to establish the identity of the receiver.

Otherwise, without proximity establishment, an *independent* secure
channel is required (see the Airbitz/RedPhone discussion). You end up
with an infinite regression problem. RedPhone terminates this regression
by relying on each party's ability to recognize the other's voice, and
in the difficulty of spoofing a voice. PKI deals with it by trusting
root CAs on presumed-trusted platforms (and a troublesome revocation
process). WoT establishes this by unspecified means (e.g. Peter Todd has
produced a nice video of him reading out his PGP key fingerprint).

If interlopers are so close to the NFC terminal that they can join the
session, they have effectively compromised an endpoint, so the privacy
problem becomes moot. Both endpoints must secure their devices to
achieve privacy in any design.

>>> is shorter than base16, is often shorter than base64, better
>>> standardized and does not require URI encoding, and is generally
>>> available to implementers.
>>>
>>> There is no need for the establishment of two Bluetooth services.
>>>
>>> I would change the payment_url recommendation so that the list order
>>> represents a recommended ordering provided by the terminal for the wallet.
>>>
>>> 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.
> 
> 
> The order is set so that it maintains backwards compatibility by
> providing the https request first.

Understood, it just isn't entirely clear to me that the backward compat
in this case doesn't depend on implementation choices of existing
systems. In any case it may be worth the small potential risk to achieve
the more elegant design.

> As mentioned in the proposal, the
> order of the r parameters has the recommended (but not required)
> priority. The wallet is encouraged to use the same protocol (but not
> required).

Understood, but it is more flexible to provide the recommendation that
the payment_url set be priority-ordered as well. This allows the seller
to deviate from the protocol (URL scheme) coupling, while also allowing
it to be established, as desired. Presumably it's the merchant's
priority that we want the wallet to honor where possible.

>>> https://github.com/evoskuil/bips/tree/master/docs
>>>
>>> e
>>>
>>>
>>> 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 wallet
>>>> 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 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=P7vKHMoapr8
>>>>
>>>> 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, then 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 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: Most 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 card
>>>> 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=42
>>>>
>>>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>>>    Example NFC URI: bitcoin:1asdf...?amount=42
>>>>
>>>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>>>>    Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>>
>>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>>>>    Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/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 via Bluetooth
>>>>    Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>>>    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=42&bt=1234567890AB
>>>>    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 more 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 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' 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:
>>>>
>>>>   bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/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 = 6;
>>>>         optional bytes merchant_data = 7;
>>>>         repeated string additional_payment_urls = 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 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 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. 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.
>>>>
>>>>
>>>> ## 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_payment_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.sourceforge.net/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=190641631&iu=/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 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=190641631&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

Jan, this is great stuff! Thanks for sharing your experiences.

I think the 4k payments requests issue must be solvable somehow. I had
no trouble transmitting that amount via NFC, although yes a bit of delay
was noticable.

About payment_url: Protobuf allows changing optional to repeated and yes
it's backwards compatible. Which is why I'm personally against parsing
two fields rather than just one.

> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?

No it isn't. It's implemented in bitcoinj though.

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

On 02/22/2015 11:37 PM, Andy Schroder wrote:

> Andreas and I had a number of private discussions regarding the
> payment_url parameter. I had suggested a "additional_payment_urls"
> repeated parameter, but he didn't seem to like that idea and I
> personally am indifferent, so that is why we decided to just change
> payment_url to a repeated field. The spec is simpler without the
> "additional_payment_urls", but the wallets have to be a little bit
> smarter finding the right url they want to use in the list. It's maybe
> not a bad idea for the wallet to try all payment_url mechanisms in
> parallel. Should we add this as a recommendation to wallets in TBIP75?

I think it will cause too much chaos. My recommendation for the
payment_url field is prefer the same mechanism that was used for
fetching the payment request. Only if the recommendation fails use the
alternatives in order (or in reverse order, I'm not sure at the moment).

> Regarding the NFC data formats. I would like to clarify that the wallets
> are having those events dispatched by the android OS. The "URI" and
> "mime type" events are sent to the application in the same way as from
> other sources such as a web browser, e-mail, stand alone QR code scanner
> app, etc.. So, I don't think the wallet actually knows it is receiving
> the event from NFC.

I think it can know. The method for catching these intents is very
similar and you can reuse almost all code, but in fact you need to add
an additional line to your AndroidManifest.xml.

> That is one reason why so many existing wallets
> happen to support BIP21 payment request via NFC.

Many? Bitcoin Wallet and its forks were the only ones for about a year.
Only recently Mycelium caught up and the others still do not care I guess.

> I'm a little weary sending the "mime
> type" based format over NFC because of backwards compatibility and
> because of the long certificate chain that needs to be transferred. You
> want that tap to be as robust and fast as possible. A bluetooth
> connection can have a retry without any user interaction.

I agree whatever we do must be robust. However I see no reason why NFC
can't be robust, see my previous post.

> I don't really like the Airbitz proposal. Figuring out if your selecting
> is the right one is a real nuisance. The idea is neat in a few
> applications, but I just don't think it is going to work for people as
> the most efficient and trouble free option day to day. I realize they
> are probably doing it to work with Apple's limited functionality phones
> (and BLE is a new buzz word). However, I don't think we should base
> bitcoin around what Apple wants us to do. They've already had their war
> on bitcoin. They are going to do whatever they can to protect their NFC
> based payment system. We need to make their platform the the less
> desirable one if they are going to play the game that way. If that means
> an Airbitz like proposal is implemented as a fallback, maybe that is
> fine and POS systems need to support both, but I just don't think we
> should limit what we can do because of Apple's products capabilities.

Ack on Airbitz, and ack on our relationship to Apple (-:

> There is also the "ack" memo that I mentioned in reference [2]. I think
> we can improve upon this really. Can we make a new status field or
> different bluetooth message header? I know Andreas didn't want to change
> it because that is how his app already works, but I don't think the way
> it is is ideal.

I'm not against improving this point, but I felt the BT enhancements and
the r,r1,r2 proposals are already getting complex enough. I would like
to simplify the proposal by moving unrelated things to somewhere else.

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

On 02/23/2015 12:32 AM, Andy Schroder wrote:
> 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. 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. 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?

I think the "trust by proximity" is the best we've got. If we don't
trust the NFC link (or the QR code scan), what other options have we
got? Speaking the session key by voice? Bad UX, and can be eavesdropped
as well of course.

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

On 02/22/2015 11:39 PM, Eric Voskuil wrote:

> The MAC address (and resource name) 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.

Of course this is just a minor detail, but Base64Url is well defined,
almost always more efficient than Base58 and never less efficient, and
implemented in way more libraries and OSes than Base58. Base58 was
designed for copy-typing by humans.

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

>> However, I don't think we should base
>> bitcoin around what Apple wants us to do. They've already had their war
>> on bitcoin. They are going to do whatever they can to protect their NFC
>> based payment system. We need to make their platform the the less
>> desirable one if they are going to play the game that way. If that means
>> an Airbitz like proposal is implemented as a fallback, maybe that is
>> fine and POS systems need to support both, but I just don't think we
>> should limit what we can do because of Apple's products capabilities.
>
> Ack on Airbitz, and ack on our relationship to Apple (-:

I also agree we shouldn't limit specs to Apple product capabilities. If
history is any indication, NFC will be opened up to developers in iOS 9,
just like touch id in was in iOS 8, and bluetooth LE in iOS 5, one major OS
revision after the hardware capability is first introduced.

Also, I'm pretty sure that Apple doesn't care about bitcoin at all. When
they banned wallets from the app store, it was prior to the 2013 FinCEN
guidance. At the time many of us, myself included, assumed USG would take
the same stance with bitcoin as they did against e-gold. It wasn't clear at
all that bitcoin didn't violate legal tender laws or who knows what. When
Apple allowed wallets back in, it was just weeks before Apple pay launched.
It's seems clear that bitcoin is too small for them to be concerned about
in the slightest.

Aaron Voisine
co-founder and CEO
breadwallet.com

[-- Attachment #2: Type: text/html, Size: 2146 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1: Type: text/plain, Size: 5126 bytes --]

I agree that NFC is the best we have as far as a trust anchor that you 
are paying the right person. The thing I am worried about is the privacy 
loss that could happen if there is someone passively monitoring the 
connection. So, in response to some of your comments below and also in 
response to some of Eric Voskuil's comments in another recent e-mail:

Consider some cases:

If NFC is assumed private, then sending the session key over the NFC 
connection gives the payer and the payee assumed confidence that that a 
private bluetooth connection can be created.

If the NFC actually isn't private, then by sending the session key over 
it means the bluetooth connection is not private. An eavesdropper can 
listen to all communication and possibly modify the communication, but 
the payer and payee won't necessarily know if eavesdropping occurs 
unless communication is also modified (which could be difficult to do 
for a really low range communication).

If we send a public key of the payee over the NFC connection (in place 
of a session key) and the NFC connection is assumed trusted (and is 
unmodified but actually monitored by an eavesdropper) and use that 
public key received via NFC to encrypt a session key and send it back 
via bluetooth, to then initiate an encrypted bluetooth connection using 
that session key for the remaining communication, then the payee still 
receives payment as expected and the payer sends the payment they 
expected, and the eavesdropper doesn't see anything.

If we send a public key of the payee over the NFC connection (in place 
of a session key) and the NFC connection is assumed trusted (and is 
actually modified by an eavesdropper) and use that public key received 
via NFC to encrypt a session key and send it back via bluetooth, to then 
initiate an encrypted bluetooth connection using that session key for 
the remaining communication, then the payee receives no payment and the 
attack is quickly identified because the customer receives no product 
for their payment and they notify the payee, and hopefully the problem 
remedied and no further customers are affected. The privacy loss will be 
significantly reduced and the motive for such attacks will be reduced. 
It's possible a really sophisticated modification could be done where 
the attacker encrypts and decrypts the communication and then relays to 
each party (without them knowing or any glitches detected), but I guess 
I'm not sure how easy that would be on such a close proximity device?

Erick Voskuil mentioned this same problem would even occur if you had a 
hardwired connection to the payment terminal and those wires were 
compromised. I guess I still think what I am saying would be better in 
that case. There is also more obvious physical tampering required to 
mess with wires.

I'm not sure if there is any trust anchor required of the payer by the 
payee, is there? Eric also mentioned a need for this. Why does the payer 
care who they are as long as they get a payment received? Just to avoid 
a sophisticated modification" that I mention above? I can see how this 
could be the case for a longer range communication (like over the 
internet), but I'm not convinced it will be easy on really short ranges? 
It's almost like the attacker would be better off to just replace the 
entire POS internals than mess with an attack like that, in which case 
everything we could do locally (other than the payment request signing 
using PKI), is useless.

I'm not a cryptography expert so I apologize if there is something 
rudimentary that I am missing here.

Andy Schroder

On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>> 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. 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. 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?
> I think the "trust by proximity" is the best we've got. If we don't
> trust the NFC link (or the QR code scan), what other options have we
> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
> as well of course.
>
>
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Den 23 feb 2015 08:38 skrev "Andy Schroder" <info@andyschroder.com>:
>
> I agree that NFC is the best we have as far as a trust anchor that you
are paying the right person. The thing I am worried about is the privacy
loss that could happen if there is someone passively monitoring the
connection. So, in response to some of your comments below and also in
response to some of Eric Voskuil's comments in another recent e-mail:

From the sources I can find NFC don't provide full privacy, but some
modulations are MITM resistant to varying degrees, some aren't at all, and
they are all susceptible to denial of service via jammers.

If the merchant system monitors the signal strength and similar metrics, a
MITM that alters data (or attempts to) should be detectable, allowing it to
shut down the connection.

Using NFC for key exchange to establish an encrypted link should IMHO be
secure enough.

http://resources.infosecinstitute.com/near-field-communication-nfc-technology-vulnerabilities-and-principal-attack-schema/

[-- Attachment #2: Type: text/html, Size: 1346 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 10817 bytes --]

On 02/22/2015 11:36 PM, Andy Schroder wrote:
> I agree that NFC is the best we have as far as a trust anchor that you
> are paying the right person. The thing I am worried about is the privacy
> loss that could happen if there is someone passively monitoring the
> connection. 

We have the same objective. Privacy loss is my primary concern with the
existing proposal.

> So, in response to some of your comments below and also in
> response to some of Eric Voskuil's comments in another recent e-mail:
> 
> Consider some cases:
> 
> If NFC is assumed private, then sending the session key over the NFC
> connection gives the payer and the payee assumed confidence that that a
> private bluetooth connection can be created.
> 
> If the NFC actually isn't private, then by sending the session key over
> it means the bluetooth connection is not private. An eavesdropper can
> listen to all communication and possibly modify the communication, but
> the payer and payee won't necessarily know if eavesdropping occurs
> unless communication is also modified (which could be difficult to do
> for a really low range communication).

I realize you are postulating a situation where an interloper monitors
but doesn't substitute the NFC communication. But clearly if you can do
one you have the potential to do the other, so if one is going to rely
on the assumption that the NFC tap can be monitored one must also accept
that it can be modified. Once one accepts this premise there is no point
in using NFC.

> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> unmodified but actually monitored by an eavesdropper) and use that
> public key received via NFC to encrypt a session key and send it back
> via bluetooth, to then initiate an encrypted bluetooth connection using
> that session key for the remaining communication, then the payee still
> receives payment as expected and the payer sends the payment they
> expected, and the eavesdropper doesn't see anything.

You can send a public cert over a public channel but before it can be
used it must be validated and verified to belong to the party that you
intend to communicate with privately. Otherwise the interloper can
substitute a public cert and subvert the payment process.

The reduces to the system requiring PKI just to establish private
communication. One might argue that BIP-70 already contemplates PKI.
However the above approach is significantly different in that it would
*require* all NFC/BT communication to use PKI just to be private.

Furthermore, to establish a private channel between *both* intended
parities, public certs must be exchanged in both directions. Otherwise,
if the customer isn't validated by the merchant, a distant interloper
can trivially use the merchant's public cert to obtain the payment
request from the Bluetooth terminal. This is the privacy breach that we
are trying to prevent in the first place.

Any requirement for PKI, in either direction, itself creates privacy
problems. But a requirement for customer certificates really gets hairy.

The PKI requirement can be dropped by instead exchanging self-generated
public keys, in the RedPhone model. However that requires out-of-band
secure communication of a common derived value by the parties. This
could be as simple as a number on each screen that one or both of the
parties compares. But this requires no private communication, and
therefore NFC is entirely unnecessary. This is in fact what I would
recommend for the BT-only scenario.

The value added by NFC is that proximity can be used to establish trust.
If that does not meet one's threshold for privacy then the parties need
to establish this trust through some presumably more private channel
(such as visual or voice confirmation).

Note that payment integrity can be reasonably ensured by relying on PKI
as established by BIP-70 (which also offers the seller non-repudiation
benefit). So this question is strictly about privacy.

> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> actually modified by an eavesdropper) and use that public key received
> via NFC to encrypt a session key and send it back via bluetooth, to then
> initiate an encrypted bluetooth connection using that session key for
> the remaining communication, then the payee receives no payment and the
> attack is quickly identified because the customer receives no product
> for their payment and they notify the payee, and hopefully the problem
> remedied and no further customers are affected. 

In this case the attacker hijacks the subsequent BT connection, sends a
payment request and gets paid. The only thing to prevent it would be
BIP-70/PKI, as mentioned above.

In a more complex attack the interloper can sit in the middle of all
communications between payer and receiver. Since the payer is not
validated by the receiver the interloper can impersonate the payer in
all communication with the receiver. As such he can also impersonate the
receiver in all communications with the payer. If the NFC communication
is compromized there is no saving privacy without an alternate private
channel.

> The privacy loss will be
> significantly reduced and the motive for such attacks will be reduced.

The motive and privacy loss remain unchanged.

> It's possible a really sophisticated modification could be done where
> the attacker encrypts and decrypts the communication and then relays to
> each party (without them knowing or any glitches detected), but I guess
> I'm not sure how easy that would be on such a close proximity device?

If the NFC tap is sufficiently private, privacy is easy to achieve for
the subsequent communication. If it is not, privacy can be completely
compromised. The question is only how much more difficult is the attack.

With the public cert tap, the level of difficulty is much lower for
capturing selected payment requests. The interloper no longer needs to
invade the space of the NFC terminal and can instead impersonate the
payer from a safe distance. Nobody gets paid, but privacy is compromised.

The level of difficulty in the case where the interloper wants to taint
transactions may appear lower, but it is not:

With the session key tap the interloper must compromise the NFC location
and then monitor the BT traffic. Monitoring BT traffic without being
party to the connection is presumably not rocket surgery, but not
standard BT design either.

With the public cert tap the interloper must also compromise the NFC
location and communicate over BT. Therefore the hardware and physical
attack requirements are similar. The only added difficulty is that the
attack on the NFC terminal attack is active (modifying the MAC address
directing the payer to the BT service).

However impersonating the payer is just a matter of software - no more
difficult than the session key attack. In fact it may be much easier to
implement, as the attack can use supported BT features because the
attacker has directed the payer to connect to him and is connecting to
the receiver as if he was a payer.

But it gets worse for the public cert tap, since a more sophisticated
attacker can set himself up in the same position without subverting the
NFC terminal at all. By broadcasting a more powerful BT service on the
same advertised MAC address, the attacker can capture traffic and relay
it to the intended service.

So in sum, reliance on a public cert makes the communication less
private under the same physical set of constraints. The difference
results from the receiver allowing non-proximate payers to impersonate
proximate payers from a distance by generating their own session keys
and submitting them over BT.

> Erick Voskuil mentioned this same problem would even occur if you had a
> hardwired connection to the payment terminal and those wires were
> compromised. I guess I still think what I am saying would be better in
> that case. There is also more obvious physical tampering required to
> mess with wires.

Attacks against wires do not require tampering with (as in damaging)
wires. The distinction between a wired connection and a wireless
connection is in many ways imaginary.

> I'm not sure if there is any trust anchor required of the payer by the
> payee, is there? Eric also mentioned a need for this. Why does the payer
> care who they are as long as they get a payment received? Just to avoid
> a sophisticated modification" that I mention above? I can see how this
> could be the case for a longer range communication (like over the
> internet), but I'm not convinced it will be easy on really short ranges?

I think I addressed this above but let me know if not.

> It's almost like the attacker would be better off to just replace the
> entire POS internals than mess with an attack like that, in which case
> everything we could do locally (other than the payment request signing
> using PKI), is useless.

Yes, ultimately both endpoints must be secured. My point is that (when
intended) NFC is practically the equivalent of a wired connection.
Baseband attacks against buyers' phones or subversion of the entire POS
terminal may be easier than interloping on a monitored NFC terminal. But
that's the point, once the attack is easier at the endpoints that is
where it will go. Further attempts to secure the gap between the devices
will not help after that point.

> I'm not a cryptography expert so I apologize if there is something
> rudimentary that I am missing here.

No need for apology, it's a good discussion, and there are precious few
experts here.

This discussion should make people very wary of any terminal system that
doesn't use signed payment requests :).

e

> Andy Schroder
> 
> On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
>> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>>> 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. 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. 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?
>> I think the "trust by proximity" is the best we've got. If we don't
>> trust the NFC link (or the QR code scan), what other options have we
>> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
>> as well of course.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

I think at this point I'd like to bring back my original suggestion of
using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
transmit some secret that could be eavesdropped, but at least the
session could not be decrypted from recordings.

Anyway, establishing a "mostly secure" session is clearly an improvement
to no protection at all. If we can't find a solution to the dilemma of
how to exchange the secret, I suggest going ahead with what we have and
make the best from it.


On 02/23/2015 08:36 AM, Andy Schroder wrote:
> I agree that NFC is the best we have as far as a trust anchor that you
> are paying the right person. The thing I am worried about is the privacy
> loss that could happen if there is someone passively monitoring the
> connection. So, in response to some of your comments below and also in
> response to some of Eric Voskuil's comments in another recent e-mail:
> 
> Consider some cases:
> 
> If NFC is assumed private, then sending the session key over the NFC
> connection gives the payer and the payee assumed confidence that that a
> private bluetooth connection can be created.
> 
> If the NFC actually isn't private, then by sending the session key over
> it means the bluetooth connection is not private. An eavesdropper can
> listen to all communication and possibly modify the communication, but
> the payer and payee won't necessarily know if eavesdropping occurs
> unless communication is also modified (which could be difficult to do
> for a really low range communication).
> 
> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> unmodified but actually monitored by an eavesdropper) and use that
> public key received via NFC to encrypt a session key and send it back
> via bluetooth, to then initiate an encrypted bluetooth connection using
> that session key for the remaining communication, then the payee still
> receives payment as expected and the payer sends the payment they
> expected, and the eavesdropper doesn't see anything.
> 
> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> actually modified by an eavesdropper) and use that public key received
> via NFC to encrypt a session key and send it back via bluetooth, to then
> initiate an encrypted bluetooth connection using that session key for
> the remaining communication, then the payee receives no payment and the
> attack is quickly identified because the customer receives no product
> for their payment and they notify the payee, and hopefully the problem
> remedied and no further customers are affected. The privacy loss will be
> significantly reduced and the motive for such attacks will be reduced.
> It's possible a really sophisticated modification could be done where
> the attacker encrypts and decrypts the communication and then relays to
> each party (without them knowing or any glitches detected), but I guess
> I'm not sure how easy that would be on such a close proximity device?
> 
> Erick Voskuil mentioned this same problem would even occur if you had a
> hardwired connection to the payment terminal and those wires were
> compromised. I guess I still think what I am saying would be better in
> that case. There is also more obvious physical tampering required to
> mess with wires.
> 
> I'm not sure if there is any trust anchor required of the payer by the
> payee, is there? Eric also mentioned a need for this. Why does the payer
> care who they are as long as they get a payment received? Just to avoid
> a sophisticated modification" that I mention above? I can see how this
> could be the case for a longer range communication (like over the
> internet), but I'm not convinced it will be easy on really short ranges?
> It's almost like the attacker would be better off to just replace the
> entire POS internals than mess with an attack like that, in which case
> everything we could do locally (other than the payment request signing
> using PKI), is useless.
> 
> I'm not a cryptography expert so I apologize if there is something
> rudimentary that I am missing here.
> 
> Andy Schroder
> 
> On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
>> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>>> 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. 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. 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?
>> I think the "trust by proximity" is the best we've got. If we don't
>> trust the NFC link (or the QR code scan), what other options have we
>> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
>> as well of course.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> 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=190641631&iu=/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 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=190641631&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 7762 bytes --]

On 02/23/2015 01:49 AM, Andreas Schildbach wrote:
> I think at this point I'd like to bring back my original suggestion of
> using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
> transmit some secret that could be eavesdropped, 

Hi Andreas,

DHKE will not improve the situation. Either we use a simple method to
transfer a session key or a complex method.

> but at least the session could not be decrypted from recordings.

DHKE doesn't offer greater forward secrecy than private transfer of a
session key, in fact it's lesser.

> Anyway, establishing a "mostly secure" session is clearly an improvement
> to no protection at all. If we can't find a solution to the dilemma of
> how to exchange the secret, I suggest going ahead with what we have and
> make the best from it.

I don't see that there is a dilemma. The current proposal has a
significant privacy problem that can be easily resolved, and the
resolution actually makes the implementation simpler.

e

> On 02/23/2015 08:36 AM, Andy Schroder wrote:
>> I agree that NFC is the best we have as far as a trust anchor that you
>> are paying the right person. The thing I am worried about is the privacy
>> loss that could happen if there is someone passively monitoring the
>> connection. So, in response to some of your comments below and also in
>> response to some of Eric Voskuil's comments in another recent e-mail:
>>
>> Consider some cases:
>>
>> If NFC is assumed private, then sending the session key over the NFC
>> connection gives the payer and the payee assumed confidence that that a
>> private bluetooth connection can be created.
>>
>> If the NFC actually isn't private, then by sending the session key over
>> it means the bluetooth connection is not private. An eavesdropper can
>> listen to all communication and possibly modify the communication, but
>> the payer and payee won't necessarily know if eavesdropping occurs
>> unless communication is also modified (which could be difficult to do
>> for a really low range communication).
>>
>> If we send a public key of the payee over the NFC connection (in place
>> of a session key) and the NFC connection is assumed trusted (and is
>> unmodified but actually monitored by an eavesdropper) and use that
>> public key received via NFC to encrypt a session key and send it back
>> via bluetooth, to then initiate an encrypted bluetooth connection using
>> that session key for the remaining communication, then the payee still
>> receives payment as expected and the payer sends the payment they
>> expected, and the eavesdropper doesn't see anything.
>>
>> If we send a public key of the payee over the NFC connection (in place
>> of a session key) and the NFC connection is assumed trusted (and is
>> actually modified by an eavesdropper) and use that public key received
>> via NFC to encrypt a session key and send it back via bluetooth, to then
>> initiate an encrypted bluetooth connection using that session key for
>> the remaining communication, then the payee receives no payment and the
>> attack is quickly identified because the customer receives no product
>> for their payment and they notify the payee, and hopefully the problem
>> remedied and no further customers are affected. The privacy loss will be
>> significantly reduced and the motive for such attacks will be reduced.
>> It's possible a really sophisticated modification could be done where
>> the attacker encrypts and decrypts the communication and then relays to
>> each party (without them knowing or any glitches detected), but I guess
>> I'm not sure how easy that would be on such a close proximity device?
>>
>> Erick Voskuil mentioned this same problem would even occur if you had a
>> hardwired connection to the payment terminal and those wires were
>> compromised. I guess I still think what I am saying would be better in
>> that case. There is also more obvious physical tampering required to
>> mess with wires.
>>
>> I'm not sure if there is any trust anchor required of the payer by the
>> payee, is there? Eric also mentioned a need for this. Why does the payer
>> care who they are as long as they get a payment received? Just to avoid
>> a sophisticated modification" that I mention above? I can see how this
>> could be the case for a longer range communication (like over the
>> internet), but I'm not convinced it will be easy on really short ranges?
>> It's almost like the attacker would be better off to just replace the
>> entire POS internals than mess with an attack like that, in which case
>> everything we could do locally (other than the payment request signing
>> using PKI), is useless.
>>
>> I'm not a cryptography expert so I apologize if there is something
>> rudimentary that I am missing here.
>>
>> Andy Schroder
>>
>> On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
>>> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>>>> 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. 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. 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?
>>> I think the "trust by proximity" is the best we've got. If we don't
>>> trust the NFC link (or the QR code scan), what other options have we
>>> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
>>> as well of course.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> 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=190641631&iu=/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 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=190641631&iu=/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 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]

>
> DHKE will not improve the situation. Either we use a simple method to
> transfer a session key or a complex method.
>

You're right that just sending the session key is simpler. I originally
suggested doing ECDHE to set up an encrypted channel for the following
reasons:

   1. URIs are put in QR codes more often than NFC tags. QR codes have
   limited space. The more stuff you pack into them, the slower and flakier
   the scanning process becomes.

   For normal wallets, doing ECDH over secp256k1 to derive a session key
   means we can reuse the address that was put in the URI already for
   pre-BIP70 wallets, thus we don't have to expand the URI at all except
   perhaps to flag that crypted Bluetooth connections are supported. Win!

   2. If the wallet is a watching wallet, this won't work and in that case
   you would need to put a separate key into the URI. However, this key is
   ephemeral and does not need to be very strong. So we can generate a regular
   secp256k1 key and then put say 5-8 prefix bytes into the URI as a new
   parameter. The public key can then be provided in full in the clear over
   the Bluetooth connection and the session key derived. If we put the session
   key into the URI in full, then we could not use this trick. Win!

   3. It's quite common in low tech scenarios like little coffee shops to
   just print a QR code and put it in the menu, or sticky tape it to the back
   wall of the shop.

   In these cases, it's possible that the device is actually hanging around
   in the shop somewhere but having the QR code somewhere larger and more
   accessible than the shop devices screen is highly convenient. However it
   means the data is entirely static.

   Putting/reusing an identity key from the URI means the session keys are
   always unique and known only to both devices, even though the bootstrap
   data is public.

   4. Doing ECDHE to derive the keys means we can derive a MAC key as well
   as an AES key. Otherwise you have the issue of exchanging both, which again
   uses up valuable bootstrap space.

So for a small increase in session setup complexity we potentially avoid
troubling problems down the line where people the same functionality from
NFC and QR code based bootstrap, but we can't provide it.

These discussions keep coming up. I think the next step is for someone to
upgrade Andreas' wallet to support encrypted connections and the TBIPs, to
see what happens.

Re: the h= parameter. I only objected to requiring this when the payment
request is also signed. It adds complexity, uses space, and the rationale
was "the PKI can't be trusted" even though it's been used to protect credit
card payments for 20 years without any issues. In the case of unsigned
payment requests, sure ... but with a proper implementation of an encrypted
Bluetooth channel it'd be unnecessary as the channel establishment process
would guarantee authenticity anyway.

But don't let me hold you guys back! I'd rather see something that works
than an endless debate about the perfect arrangement of hashes and URI
parameters :)

[-- Attachment #2: Type: text/html, Size: 3465 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

On 02/23/2015 11:58 AM, Mike Hearn wrote:

> You're right that just sending the session key is simpler. I
> originally suggested doing ECDHE to set up an encrypted channel
> for the following reasons: [...]

I read from your answer that even if we use ECDHE, we can't use it for
every situation. So in any case we need the simple bootstrap via a
session key parameter. My suggestion is defer ECDHE for now but keep it
in mind. We can add it later I think.

> These discussions keep coming up. I think the next step is for someone
> to upgrade Andreas' wallet to support encrypted connections and the
> TBIPs, to see what happens.

I happily step up and do the implementation work on the app side. A
first step could be:

- If there is an "s" parameter present wrap the Bluetooth connections
with AES. Sounds good?

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

>
> I read from your answer that even if we use ECDHE, we can't use it for
> every situation.
>

Which situations do you mean? I think it can be used in every situation.
It's the opposite way around - a fixed session key in the URI cannot be
used in every situation.

[-- Attachment #2: Type: text/html, Size: 497 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

On 02/23/2015 01:18 PM, Mike Hearn wrote:
>     I read from your answer that even if we use ECDHE, we can't use it for
>     every situation.
> 
> Which situations do you mean? I think it can be used in every situation.
> It's the opposite way around - a fixed session key in the URI cannot be
> used in every situation.

Ok sorry probably I read wrong.

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Jan Vornberger]

Hey!

On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
> It's maybe not a bad idea for the wallet to try all payment_url
> mechanisms in parallel. Should we add this as a recommendation to
> wallets in TBIP75?

It doesn't need to be a recommendation I think, but maybe it would be
good to mention that a wallet may do that, if it wants.

> I actually also happen to be using nfcpy. I am having some
> reliability issues as well with it. What exactly are your problems?

Aw, interesting. Sometimes transfers seem to start and then not complete
in some way and occasionally the NFC dongle is then totally 'stuck' in some
way afterwards, that even after restarting the Python script or
reloading the driver nothing works anymore. I have to actually unplug
the dongle and plug it in again. Obviously not exactly production ready.
I had the same problems with the command line tools based on libnfc, so
it might be a problem lower down the stack. I'm not sure I have the
expertise to troubleshoot that.

> I have seen your video before. I guess I'm wondering how your
> prototype works with bitpay and bluetooth. Doesn't bitpay sign the
> payment request for you with an https based payment_url? If so, how
> do you add the bluetooth payment_url while keeping their signature
> valid?

Good point, I'm currently simply removing the signature, so that I can
modify the payment request. I haven't spoken with BitPay yet, but I hope
that they will extend their API at some point to set additional
payment_urls or provide a Bluetooth MAC and then I can do it properly
with signed requests.

> In your video it looks like the phone still has cellular and
> wifi reception (it is not offline).

You are right, I forgot to actually disable wifi and cellular data when
recording the video. But as you know it would work the same way offline.

> Regarding the NFC data formats. I would like to clarify that the
> wallets are having those events dispatched by the android OS. The
> "URI" and "mime type" events are sent to the application in the same
> way as from other sources such as a web browser, e-mail, stand alone
> QR code scanner app, etc.. So, I don't think the wallet actually
> knows it is receiving the event from NFC. That is one reason why so
> many existing wallets happen to support BIP21 payment request via
> NFC. Andreas can correct me if I am wrong on these statements. I'm a
> little weary sending the "mime type" based format over NFC because
> of backwards compatibility and because of the long certificate chain
> that needs to be transferred. You want that tap to be as robust and
> fast as possible. A bluetooth connection can have a retry without
> any user interaction.

There is a specific NFC intent that you have to list in your Android
manifest, but you are right that if you already support BIP21 URIs then
it is often fairly easy and quick to also support them via NFC.

Whereas the mime type approach means that you necessarily need to be
able to actually understand BIP70, which a lot of wallet don't yet. But
personally that wouldn't hold me back using the mime type if I feel it's
the better experience. Those wallets simply have to fall back on
scanning the QR code in the meantime and then get up to speed on their
NFC and BIP70 support.

I'm still concerned that the fact, that Bluetooth is often disabled, is a
problem for the UX. And it's not just a one-time thing as with NFC,
which is - in my experience - also often disabled, but then people turn
it on and leave it on. But with Bluetooth the Android system is geared
much more towards turning it off after use and people have this general
idea of 'it uses energy, so I should disable it' and sometimes also
'Bluetooth is insecure and if I leave it on I will get hacked'. So
chances are, Bluetooth will be off most of the time, which means
everytime you pay the dialog 'Turn on Bluetooth?' will pop up, which
isn't exactly streamlined.

So the advantage of transmitting the whole BIP70 payment request via NFC
I see is, that you don't need Bluetooth to get the payment request and
for sending the transaction back the wallet can then make an intelligent
decision and first try via HTTP and only after that fails, say something
like: "You are currently offline, turn on and transmit via Bluetooth
instead?". Much less confusing to the user, in my opinion.

Another idea could be to request the permission BLUETOOTH_ADMIN which,
as far as I know, allows you to programmatically turn on Bluetooth
without user interaction. The wallet could then have a setting somewhere
that says 'automatically turn on Bluetooth during payments' which would
enable and then disable (if it was off before) Bluetooth during the
payment process. That should also be a decent compromise, at the cost of
another permission.

> There is also the "ack" memo that I mentioned in reference [2]. I
> think we can improve upon this really. Can we make a new status
> field or different bluetooth message header? I know Andreas didn't
> want to change it because that is how his app already works, but I
> don't think the way it is is ideal.

I'm fine with doing changes here - I don't think there is all that much
stuff out there yet which would break from it. At the moment I'm also
modifying BitPay's memo field to contain 'ack', as Andreas' wallet
otherwise reports a failure if I transmit the original via Bluetooth. :-)
But I was assuming that was temporary anyway (?).

Jan

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

>
> At the moment I'm also modifying BitPay's memo field to contain 'ack', as
> Andreas' wallet otherwise reports a failure if I transmit the original via
> Bluetooth. :-)
>

Huh?

[-- Attachment #2: Type: text/html, Size: 419 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Jan Vornberger]

On Mon, Feb 23, 2015 at 05:59:34PM +0100, Mike Hearn wrote:
> >
> > At the moment I'm also modifying BitPay's memo field to contain 'ack', as
> > Andreas' wallet otherwise reports a failure if I transmit the original via
> > Bluetooth. :-)
> >
> 
> Huh?

For HTTP it checks whether 'nack' is _not_ presented:

  https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/offline/DirectPaymentTask.java#L133

But via Bluetooth it checks for 'ack' directly:

  https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/offline/DirectPaymentTask.java#L238

The latter should probably be at least changed to the reverse check as
for HTTP, but in general some non-memo way of doing that would be nice
of course.

Jan

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

>
> But via Bluetooth it checks for 'ack' directly:


We need a BIP70 conformance suite really. There are so many deviations from
the spec out there already and it's brand new :(

[-- Attachment #2: Type: text/html, Size: 409 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 4035 bytes --]

Mike,

Before addressing other issues I could use some clarification on your
intent.

In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):

> doing ECDH over secp256k1 to derive a session key means we can reuse
> the address that was put in the URI already for pre-BIP70 wallets

In another statement you refer to derivation of a session key from a
public key (passed via  BT):

> The public key can then be provided in full in the clear over the
> Bluetooth connection and the session key derived.

I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?

e

On 02/23/2015 02:58 AM, Mike Hearn wrote:
>     DHKE will not improve the situation. Either we use a simple method to
>     transfer a session key or a complex method.
> 
> You're right that just sending the session key is simpler. I originally
> suggested doing ECDHE to set up an encrypted channel for the following
> reasons:
> 
>  1. URIs are put in QR codes more often than NFC tags. QR codes have
>     limited space. The more stuff you pack into them, the slower and
>     flakier the scanning process becomes.
> 
>     For normal wallets, doing ECDH over secp256k1 to derive a session
>     key means we can reuse the address that was put in the URI already
>     for pre-BIP70 wallets, thus we don't have to expand the URI at all
>     except perhaps to flag that crypted Bluetooth connections are
>     supported. Win!
> 
>  2. If the wallet is a watching wallet, this won't work and in that case
>     you would need to put a separate key into the URI. However, this key
>     is ephemeral and does not need to be very strong. So we can generate
>     a regular secp256k1 key and then put say 5-8 prefix bytes into the
>     URI as a new parameter. The public key can then be provided in full
>     in the clear over the Bluetooth connection and the session key
>     derived. If we put the session key into the URI in full, then we
>     could not use this trick. Win!
> 
>  3. It's quite common in low tech scenarios like little coffee shops to
>     just print a QR code and put it in the menu, or sticky tape it to
>     the back wall of the shop.
> 
>     In these cases, it's possible that the device is actually hanging
>     around in the shop somewhere but having the QR code somewhere larger
>     and more accessible than the shop devices screen is highly
>     convenient. However it means the data is entirely static.
> 
>     Putting/reusing an identity key from the URI means the session keys
>     are always unique and known only to both devices, even though the
>     bootstrap data is public.
> 
>  4. Doing ECDHE to derive the keys means we can derive a MAC key as well
>     as an AES key. Otherwise you have the issue of exchanging both,
>     which again uses up valuable bootstrap space.
> 
> So for a small increase in session setup complexity we potentially avoid
> troubling problems down the line where people the same functionality
> from NFC and QR code based bootstrap, but we can't provide it.
> 
> These discussions keep coming up. I think the next step is for someone
> to upgrade Andreas' wallet to support encrypted connections and the
> TBIPs, to see what happens.
> 
> Re: the h= parameter. I only objected to requiring this when the payment
> request is also signed. It adds complexity, uses space, and the
> rationale was "the PKI can't be trusted" even though it's been used to
> protect credit card payments for 20 years without any issues. In the
> case of unsigned payment requests, sure ... but with a proper
> implementation of an encrypted Bluetooth channel it'd be unnecessary as
> the channel establishment process would guarantee authenticity anyway.
> 
> But don't let me hold you guys back! I'd rather see something that works
> than an endless debate about the perfect arrangement of hashes and URI
> parameters :)
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

>
> I don't see how you propose to treat the bitcoin address as a secp256k1
> public key, or do you mean something else?
>

Sorry, I skipped a step. I shouldn't make assumptions about what's obvious.
The server would provide the public key and the client would convert it to
address form then match against the URI it has scanned. If it didn't match,
stop at that point.

[-- Attachment #2: Type: text/html, Size: 626 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On 02/23/2015 03:11 PM, Mike Hearn wrote:
>> I don't see how you propose to treat the bitcoin address as a
>> secp256k1 public key, or do you mean something else?
>
> Sorry, I skipped a step. I shouldn't make assumptions about what's
> obvious.

No problem, we don't all have the same context. I may have missed prior
discussion.

> The server would provide the public key and the client would
> convert it to address form then match against the URI it has scanned.
> If it didn't match, stop at that point.

Does this not also require the BT publication of the script for a P2SH
address?

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 4331 bytes --]

Andy, adding to my previous post below:

On 02/23/2015 01:40 AM, Eric Voskuil wrote:
> On 02/22/2015 11:36 PM, Andy Schroder wrote:
...
>> It's possible a really sophisticated modification could be done where
>> the attacker encrypts and decrypts the communication and then relays to
>> each party (without them knowing or any glitches detected), but I guess
>> I'm not sure how easy that would be on such a close proximity device?
> 
> If the NFC tap is sufficiently private, privacy is easy to achieve for
> the subsequent communication. If it is not, privacy can be completely
> compromised. The question is only how much more difficult is the attack.
> 
> With the public cert tap, the level of difficulty is much lower for
> capturing selected payment requests. The interloper no longer needs to
> invade the space of the NFC terminal and can instead impersonate the
> payer from a safe distance. Nobody gets paid, but privacy is compromised.

This problem in the preceding paragraph can be resolved by sending a
unique public key on each NFC tap. In that case an attacker would need
to monitor the NFC communication.

The talk of wrapping the connection in SSL led me to believe you were
talking about a static public certificate. However that's not a
necessary assumption here and may not be what you intended.

> The level of difficulty in the case where the interloper wants to taint
> transactions may appear lower, but it is not:
> 
> With the session key tap the interloper must compromise the NFC location
> and then monitor the BT traffic. Monitoring BT traffic without being
> party to the connection is presumably not rocket surgery, but not
> standard BT design either.
> 
> With the public cert tap the interloper must also compromise the NFC
> location and communicate over BT. Therefore the hardware and physical
> attack requirements are similar. The only added difficulty is that the
> attack on the NFC terminal attack is active (modifying the MAC address
> directing the payer to the BT service).

I believe your central claim was that the difference in the two
bootstrapping approaches (public key vs. session key) is that by using a
unique public key per tap, the attack requires an active vs. passive
attack on the NFC terminal. I just wanted to make clear here that I
agree with that assessment.

The symmetric key approach is based on the idea that these attacks are
comparable in difficulty and otherwise identical in privacy loss.

However, the difference in implementation amounts to about +23
additional encoded characters for the BT/LE URL, assuming use of the
secp256k1 curve for DHE. This is really not a material issue in the case
of the NFC tap. The entire URI+URL could be as small as:

bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP

In comparison to a symmetric key:

bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E

It also does not change the protocol design or complexity at all - it
would just swap out an AES key for a secp256k1 public key.

bitcoin:[address]?bt:<mac>/<key>

If that gets us aligned I'm all for it.

> However impersonating the payer is just a matter of software - no more
> difficult than the session key attack. In fact it may be much easier to
> implement, as the attack can use supported BT features because the
> attacker has directed the payer to connect to him and is connecting to
> the receiver as if he was a payer.
> 
> But it gets worse for the public cert tap, since a more sophisticated
> attacker can set himself up in the same position without subverting the
> NFC terminal at all. By broadcasting a more powerful BT service on the
> same advertised MAC address, the attacker can capture traffic and relay
> it to the intended service.

I'm retracting the last paragraph, since the interloper, without
invading the NFC connection (by substituting the public cert), could not
read the relayed traffic. It was getting late :/

> So in sum, reliance on a public cert makes the communication less
> private under the same physical set of constraints. The difference
> results from the receiver allowing non-proximate payers to impersonate
> proximate payers from a distance by generating their own session keys
> and submitting them over BT.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1: Type: text/plain, Size: 9167 bytes --]


I was saying provide a public key via NFC (or a public key fingerprint 
and then send the full public key over bluetooth). Instead of providing 
a new public key on each tap, why can't the payee just stop accepting 
connections from new parties on that "resource" after a session key has 
been received from the first person? If the person decides to have there 
friend or family pay for them instead and cancel the payment, they could 
just hit cancel on the POS or something (on my fuel pump I have a switch 
that needs to be turned, the purpose of this is to avoid wasting too 
many addresses) and/or do another NFC tap (if you're providing QR codes 
you'd still need a button of some kind though so it knows to refresh 
it), or the POS can just provide a completely new payment request to any 
new connections on that same "resource" which use a different session key.

I feel like the authentication of the payer to the payee in any future 
connections after they receive the session key from them (which was 
encrypted with the payees public key), comes from the fact that they are 
sending responses back that are encrypted using the session key they 
gave to the payee. The way I am seeing it is that the NFC tap or QR code 
scan is acting in addition to the visual name check on the signature 
verification in the wallet. If the certificate used isn't signed by a CA 
(self signed), it may be fine as long as you heard about it via NFC or 
QR code. I don't think it will require PKI and should still work 
wallet-to-wallet.

It sounds like you are saying I'm proposing the customer is going to 
need a certificate signed by CA? If so, why? I don't need this for any 
https website I visit. It's not like the payee is sending anything to 
the payer that is private. The payment request only becomes private if 
something is actually received to it, otherwise, it is just discarded 
and it doesn't matter. Those bitcoin addresses are never used. It's just 
like a shopping cart on a website where someone aborts payment and 
cancels the order.

At one point I was thinking we could do something similar to Mike 
Hearn's suggestion in another recent e-mail where we re-use some 
existing part of the bitcoin URI to bootstrap some trust in a public key 
that the payee next sends via bluetooth after the NFC connection. Now 
that I'm reviewing my notes though, I can't see how this will work with 
a watching only wallet or if no backwards compatible (to BIP21) bitcoin 
address is presented in the URI (as Mike said).

What I was saying above about how you can stop accepting connections on 
that "resource" after a session key has been received by the first 
person could be problematic though. An evil person could just start 
making connections to every device they can, just to be mean, which 
would not allow the POS operator to receive payments from their real 
customers. If you do the other option I proposed, which is to just keep 
giving out new payment requests, you have other problems (on top of 
wasting addresses), which are that you can still have mean people giving 
you a denial of service attach on your hardware, or you could have an 
unusual situation where two people pay (don't know why they would do 
this though), so that is why I'm suggesting a manual tap or button press 
or switch turn being required.

I guess as more of a abuse filter, a new "resource" could be given 
instead with each tap, and the POS would just ignore all requests to an 
inactive resource. You may say, why not send a new public key (as you 
suggested) instead of a new "resource" with each tap (or button press if 
using QR codes), and then you can skip the sending of a static public 
key (or public key fingerprint), and ignore any data that is not 
encrypted with that public key. Maybe that is a better idea because it 
will shorten the bitcoin URI. However, I don't think its required from a 
privacy standpoint, it primarily just aids in combining the public key 
fingerprint with the changing "resource" name used to filter abuse. Or, 
am I missing something?


So, after thinking through the abuse scenarios I mentioned above, I 
think I am agreeing with you, but the reason I'm writing all this is to 
hopefully just get some feedback on my logic to learn something from 
this discussion. I do think sending a unique public key over NFC has to 
be better than a unique session key. It adds one more step, but seems to 
help. If we do this, can we then safely get rid of the h= parameter? 
That should make Mike Hearn happy, and also may alleviate the base64url 
debate?


Andy Schroder

On 02/23/2015 09:55 PM, Eric Voskuil wrote:
> Andy, adding to my previous post below:
>
> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
> ...
>>> It's possible a really sophisticated modification could be done where
>>> the attacker encrypts and decrypts the communication and then relays to
>>> each party (without them knowing or any glitches detected), but I guess
>>> I'm not sure how easy that would be on such a close proximity device?
>> If the NFC tap is sufficiently private, privacy is easy to achieve for
>> the subsequent communication. If it is not, privacy can be completely
>> compromised. The question is only how much more difficult is the attack.
>>
>> With the public cert tap, the level of difficulty is much lower for
>> capturing selected payment requests. The interloper no longer needs to
>> invade the space of the NFC terminal and can instead impersonate the
>> payer from a safe distance. Nobody gets paid, but privacy is compromised.
> This problem in the preceding paragraph can be resolved by sending a
> unique public key on each NFC tap. In that case an attacker would need
> to monitor the NFC communication.
>
> The talk of wrapping the connection in SSL led me to believe you were
> talking about a static public certificate. However that's not a
> necessary assumption here and may not be what you intended.
>
>> The level of difficulty in the case where the interloper wants to taint
>> transactions may appear lower, but it is not:
>>
>> With the session key tap the interloper must compromise the NFC location
>> and then monitor the BT traffic. Monitoring BT traffic without being
>> party to the connection is presumably not rocket surgery, but not
>> standard BT design either.
>>
>> With the public cert tap the interloper must also compromise the NFC
>> location and communicate over BT. Therefore the hardware and physical
>> attack requirements are similar. The only added difficulty is that the
>> attack on the NFC terminal attack is active (modifying the MAC address
>> directing the payer to the BT service).
> I believe your central claim was that the difference in the two
> bootstrapping approaches (public key vs. session key) is that by using a
> unique public key per tap, the attack requires an active vs. passive
> attack on the NFC terminal. I just wanted to make clear here that I
> agree with that assessment.
>
> The symmetric key approach is based on the idea that these attacks are
> comparable in difficulty and otherwise identical in privacy loss.
>
> However, the difference in implementation amounts to about +23
> additional encoded characters for the BT/LE URL, assuming use of the
> secp256k1 curve for DHE. This is really not a material issue in the case
> of the NFC tap. The entire URI+URL could be as small as:
>
> bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>
> In comparison to a symmetric key:
>
> bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E
>
> It also does not change the protocol design or complexity at all - it
> would just swap out an AES key for a secp256k1 public key.
>
> bitcoin:[address]?bt:<mac>/<key>
>
> If that gets us aligned I'm all for it.
>
>> However impersonating the payer is just a matter of software - no more
>> difficult than the session key attack. In fact it may be much easier to
>> implement, as the attack can use supported BT features because the
>> attacker has directed the payer to connect to him and is connecting to
>> the receiver as if he was a payer.
>>
>> But it gets worse for the public cert tap, since a more sophisticated
>> attacker can set himself up in the same position without subverting the
>> NFC terminal at all. By broadcasting a more powerful BT service on the
>> same advertised MAC address, the attacker can capture traffic and relay
>> it to the intended service.
> I'm retracting the last paragraph, since the interloper, without
> invading the NFC connection (by substituting the public cert), could not
> read the relayed traffic. It was getting late :/
>
>> So in sum, reliance on a public cert makes the communication less
>> private under the same physical set of constraints. The difference
>> results from the receiver allowing non-proximate payers to impersonate
>> proximate payers from a distance by generating their own session keys
>> and submitting them over BT.
> e
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1: Type: text/plain, Size: 7145 bytes --]


Andy Schroder

On 02/23/2015 10:09 AM, Jan Vornberger wrote:
> Hey!
>
> On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
>> It's maybe not a bad idea for the wallet to try all payment_url
>> mechanisms in parallel. Should we add this as a recommendation to
>> wallets in TBIP75?
> It doesn't need to be a recommendation I think, but maybe it would be
> good to mention that a wallet may do that, if it wants.
>
>> I actually also happen to be using nfcpy. I am having some
>> reliability issues as well with it. What exactly are your problems?
> Aw, interesting. Sometimes transfers seem to start and then not complete
> in some way and occasionally the NFC dongle is then totally 'stuck' in some
> way afterwards, that even after restarting the Python script or
> reloading the driver nothing works anymore. I have to actually unplug
> the dongle and plug it in again. Obviously not exactly production ready.
> I had the same problems with the command line tools based on libnfc, so
> it might be a problem lower down the stack. I'm not sure I have the
> expertise to troubleshoot that.



I've had similar issues where the NFC device has to be disconnected and 
reconnected. I've got lots of error checking in my code on the NFC 
device, which helps, but still has problems sometimes. I've found if I 
limit how quickly a new connection can be made, that reduces the 
problem. Have you tried this?



What command line tool are you using with libnfc?





>
>> I have seen your video before. I guess I'm wondering how your
>> prototype works with bitpay and bluetooth. Doesn't bitpay sign the
>> payment request for you with an https based payment_url? If so, how
>> do you add the bluetooth payment_url while keeping their signature
>> valid?
> Good point, I'm currently simply removing the signature, so that I can
> modify the payment request. I haven't spoken with BitPay yet, but I hope
> that they will extend their API at some point to set additional
> payment_urls or provide a Bluetooth MAC and then I can do it properly
> with signed requests.



This sounds weird to me. Why are you even using bitpay at all if you are 
already going through the effort to remove a signature and change the 
memo field? Wouldn't it be better to just manage everything yourself?




>
>> In your video it looks like the phone still has cellular and
>> wifi reception (it is not offline).
> You are right, I forgot to actually disable wifi and cellular data when
> recording the video. But as you know it would work the same way offline.
>
>> Regarding the NFC data formats. I would like to clarify that the
>> wallets are having those events dispatched by the android OS. The
>> "URI" and "mime type" events are sent to the application in the same
>> way as from other sources such as a web browser, e-mail, stand alone
>> QR code scanner app, etc.. So, I don't think the wallet actually
>> knows it is receiving the event from NFC. That is one reason why so
>> many existing wallets happen to support BIP21 payment request via
>> NFC. Andreas can correct me if I am wrong on these statements. I'm a
>> little weary sending the "mime type" based format over NFC because
>> of backwards compatibility and because of the long certificate chain
>> that needs to be transferred. You want that tap to be as robust and
>> fast as possible. A bluetooth connection can have a retry without
>> any user interaction.
> There is a specific NFC intent that you have to list in your Android
> manifest, but you are right that if you already support BIP21 URIs then
> it is often fairly easy and quick to also support them via NFC.
>
> Whereas the mime type approach means that you necessarily need to be
> able to actually understand BIP70, which a lot of wallet don't yet. But
> personally that wouldn't hold me back using the mime type if I feel it's
> the better experience. Those wallets simply have to fall back on
> scanning the QR code in the meantime and then get up to speed on their
> NFC and BIP70 support.
>
> I'm still concerned that the fact, that Bluetooth is often disabled, is a
> problem for the UX. And it's not just a one-time thing as with NFC,
> which is - in my experience - also often disabled, but then people turn
> it on and leave it on. But with Bluetooth the Android system is geared
> much more towards turning it off after use and people have this general
> idea of 'it uses energy, so I should disable it' and sometimes also
> 'Bluetooth is insecure and if I leave it on I will get hacked'. So
> chances are, Bluetooth will be off most of the time, which means
> everytime you pay the dialog 'Turn on Bluetooth?' will pop up, which
> isn't exactly streamlined.


I'm personally not to annoyed by the enable bluetooth popup. I do know 
what you mean about the "bluetooth is insecure, I should disable it" 
attitude. I used to have this same concern.


>
> So the advantage of transmitting the whole BIP70 payment request via NFC
> I see is, that you don't need Bluetooth to get the payment request and
> for sending the transaction back the wallet can then make an intelligent
> decision and first try via HTTP and only after that fails, say something
> like: "You are currently offline, turn on and transmit via Bluetooth
> instead?". Much less confusing to the user, in my opinion.


Well, with the multiple r parameters, they should also be able to do 
this on the payment request too.


>
> Another idea could be to request the permission BLUETOOTH_ADMIN which,
> as far as I know, allows you to programmatically turn on Bluetooth
> without user interaction. The wallet could then have a setting somewhere
> that says 'automatically turn on Bluetooth during payments' which would
> enable and then disable (if it was off before) Bluetooth during the
> payment process. That should also be a decent compromise, at the cost of
> another permission.


I'm personally very weary of more permissions. Have you checked out how 
many unnecessary permissions a lot of bitcoin wallets have? Many of them 
are ridiculous. Although this one may be somewhat warranted, I wouldn't 
encourage it if they can just fall back to cellular if they don't want 
to use bluetooth. If they don't have cellular reception, they can go 
through the effort of pressing the enable button that pops up.




>
>> There is also the "ack" memo that I mentioned in reference [2]. I
>> think we can improve upon this really. Can we make a new status
>> field or different bluetooth message header? I know Andreas didn't
>> want to change it because that is how his app already works, but I
>> don't think the way it is is ideal.
> I'm fine with doing changes here - I don't think there is all that much
> stuff out there yet which would break from it. At the moment I'm also
> modifying BitPay's memo field to contain 'ack', as Andreas' wallet
> otherwise reports a failure if I transmit the original via Bluetooth. :-)
> But I was assuming that was temporary anyway (?).
>
> Jan
>
>
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

>
> Does this not also require the BT publication of the script for a P2SH
> address?


You mean if the URI you're serving is like this?

   bitcoin:3aBcD........?bt=....

Yes it would. I guess then, the server would indicate both the script, and
the key within that script that it wanted to use. A bit more complex but
would still work to save URI space.

[-- Attachment #2: Type: text/html, Size: 631 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 15837 bytes --]

On 02/23/2015 09:53 PM, Andy Schroder wrote:
> I was saying provide a public key via NFC (or a public key fingerprint
> and then send the full public key over bluetooth). Instead of providing
> a new public key on each tap, why can't the payee just stop accepting
> connections from new parties on that "resource" after a session key has
> been received from the first person?

Because the presumption was that there was not an additional secret in
the URI. If the public key is reused then anyone can spoof a payer and
obtain payment requests.

Adding a secret to the URI can resolve this, as long as it is encrypted
with the public key before being transmitted back to BT. Otherwise the
secret can be intercepted and replayed to the terminal, encrypted with
the well-known public key.

So if you want to treat the "resource" as a secret this would work.
However the resource was designed as a public session identifier,
leading the byte stream. This changes it to private session identifier,
which loses some utility.

Also, reuse of the public key introduces a forward secrecy problem and
the potential for persistent seller impersonation in the case of
undiscovered key compromise.

But there's really no benefit to reusing the key. An ephemeral key
resolves these issues and can also seed the public resource name.

> If the person decides to have there
> friend or family pay for them instead and cancel the payment, they could
> just hit cancel on the POS or something (on my fuel pump I have a switch
> that needs to be turned, the purpose of this is to avoid wasting too
> many addresses)

Don't you have someone stop by the pump once a week and empty out the
addresses? :)

> and/or do another NFC tap (if you're providing QR codes
> you'd still need a button of some kind though so it knows to refresh
> it), or the POS can just provide a completely new payment request to any
> new connections on that same "resource" which use a different session key.
> 
> I feel like the authentication of the payer to the payee in any future
> connections after they receive the session key from them (which was
> encrypted with the payees public key), comes from the fact that they are
> sending responses back that are encrypted using the session key they
> gave to the payee. The way I am seeing it is that the NFC tap or QR code
> scan is acting in addition to the visual name check on the signature
> verification in the wallet.

With a secure channel that identifies the parties by proximity, the
reason for the payment request signature is for the payer to obtain a
non-repudiation guarantee. But it also serves as a defense-in-depth
solution to a compromise of the channel (though does not offer a benefit
in the case of seller terminal/cert compromise).

> If the certificate used isn't signed by a CA
> (self signed), it may be fine as long as you heard about it via NFC or
> QR code. I don't think it will require PKI and should still work
> wallet-to-wallet.

In that case the cert provides no benefit. A self-signed cert can be
repudiated and if the channel is compromised anyone can sign the payment
request.

> It sounds like you are saying I'm proposing the customer is going to
> need a certificate signed by CA? If so, why? 

This was not a serious proposal, it was to point out what would become
necessary if the payer could not be identified by proximity.

In the case where a public key is reused, any payer can contact the BT
terminal and obtain the payment request. If the merchant can't rely on
proximity (i.e. can't trust the integrity of the NFC connection) then he
would have to fall back on some other means of identifying the payer. A
mutual verbal/visual confirmation could work, but the point of of NFC+BT
is elimination of that hassle.

Yes, it sounds a bit wild, but I have seen on this list a serious
proposal to have people broadcast their photo, having the merchant
select them and push to them the payment request. Of course anyone can
spoof another's image, so at some point your image would need to be
certified, and hence a CA.

I wouldn't go there, but was just making the point.

> I don't need this for any https website I visit.

When you go to a web site you first establish a private communication.
The site doesn't know who you are (hopefully). Then you log on with your
secret, or proof of it, establishing who you are. Customer identity
problem solved.

Or you create an account, providing your relevant identity information
which effectively becomes who you are to the site.

Or you shop anonymously and when you go to check out they know that if
you pay, you get permission to direct the product shipment. And only you
can see the bill. This because your session binds your shopping to your
bill and payment.

However when you go to the local adult shop to pick up some love toys,
the person at the counter has no idea who's asking their terminal for a
payment request. You having the shop's public cert doesn't help them
with that problem (nor does some anonymous signal sending them a photo
of you). Protecting your privacy ironically requires that they know who
you are - electronically. That means some sort of crazy consumer cert
(not sure that would fly in the love shop)... or trust in
(electronically anonymous) proximity.

> It's not like the payee is sending anything to
> the payer that is private. The payment request only becomes private if
> something is actually received to it, otherwise, it is just discarded
> and it doesn't matter.

The payment request is private. It's a (potentially signed) proposal to
contract. It can contain interesting information.

> Those bitcoin addresses are never used. It's just
> like a shopping cart on a website where someone aborts payment and
> cancels the order.

Very much so, but in that case your neighbors can't read your potential
transactions because your session is secured.

> At one point I was thinking we could do something similar to Mike
> Hearn's suggestion in another recent e-mail where we re-use some
> existing part of the bitcoin URI to bootstrap some trust in a public key
> that the payee next sends via bluetooth after the NFC connection. Now
> that I'm reviewing my notes though, I can't see how this will work with
> a watching only wallet or if no backwards compatible (to BIP21) bitcoin
> address is presented in the URI (as Mike said).

It can work, but you just end up putting an additional value on the URI
(for watchers), requiring legacy addresses (for non-watchers), adding
P2SH scripts to the BT broadcast of the public key, and adding another
BT round trip to obtain a public key before establishing the session.

A few bytes on the NFC tap is a non-issue, especially in comparison to
the additional complexity and BT traffic. Those choices are really all
based on providing private offline transaction support originating from
generally not private QR code scanning. But QR+BT is not the same as NFC+BT.

Honestly I think it would be reasonable to use the technique with QR+BT,
accepting the limitations for the legacy system while not unduly
burdening NFC+BT just for an unachievable cross-consistency goal. Always
passing the key on the URL for NFC but giving a non-NFC wallet the
option to ask a BT terminal for a public key seems not just reasonable
but optimal if we want to support the QR+BT scenario.

Note also that the BT-only scenario is different as well (see recent
discussion on Airbitz BLE wallet, resulting in the RedPhone-based
proposal). And finally, QR-only and NFC-only are also different. The
URIs can be consistent, but the communication protocol will vary.

> What I was saying above about how you can stop accepting connections on
> that "resource" after a session key has been received by the first
> person could be problematic though. An evil person could just start
> making connections to every device they can, just to be mean, which
> would not allow the POS operator to receive payments from their real
> customers. If you do the other option I proposed, which is to just keep
> giving out new payment requests, you have other problems (on top of
> wasting addresses), which are that you can still have mean people giving
> you a denial of service attach on your hardware, or you could have an
> unusual situation where two people pay (don't know why they would do
> this though), so that is why I'm suggesting a manual tap or button press
> or switch turn being required.

Yes, but even with a manual button you could have these problems. The
data transfer needs to be proximate as well.

> I guess as more of a abuse filter, a new "resource" could be given
> instead with each tap, and the POS would just ignore all requests to an
> inactive resource. You may say, why not send a new public key (as you
> suggested) instead of a new "resource" with each tap (or button press if
> using QR codes), and then you can skip the sending of a static public
> key (or public key fingerprint), and ignore any data that is not
> encrypted with that public key. Maybe that is a better idea because it
> will shorten the bitcoin URI. However, I don't think its required from a
> privacy standpoint, it primarily just aids in combining the public key
> fingerprint with the changing "resource" name used to filter abuse. Or,
> am I missing something?

I think this question is covered above.

> So, after thinking through the abuse scenarios I mentioned above, I
> think I am agreeing with you, but the reason I'm writing all this is to
> hopefully just get some feedback on my logic to learn something from
> this discussion. I do think sending a unique public key over NFC has to
> be better than a unique session key. It adds one more step, but seems to
> help. 

It doesn't actually add another step to the protocol, just some
different but simple code on each end. The only downside is that it
extends the NFC URL about 23 characters.

> If we do this, can we then safely get rid of the h= parameter?

Absolutely, and I believe Mike ack'd this on a previous post today.

> That should make Mike Hearn happy, and also may alleviate the base64url
> debate?

Others may not be aware of the encoding squabble (not sure if it
qualifies as debate). In the proposed URL, it affects the mac address
and the key:

bitcoin:[address]?bt:<mac>/<key>

base58:
bitcoin:?r=bt:12rAs9mM/234KF8hPkXq5pa6pT1wnJC3hVH7W6yB2Wtw24ztzGtBc4

base64url:
bitcoin:?r=bt:ABBgss5s/A3xWlhB1GI_t2NMR9Zq9E47hZOzmZ6eZTS8sbq-liugh

I prefer base58 because it's available to all bitcoin libraries, nearly
as compact as base64 (+1 byte in our example) and better standardized.
Some embedded device people might care about having to incorporate
base64 as well as base58.

It's also better looking (no - or _ characters) and more consistent in
the proposed URL (all three values would be base58, as opposed to one
base58 and two base64url). There may be some idea that base58 is just
for bitcoin addresses (not true) or designed for humans... that's sort
of the point, but it's also good for URLs.

e

> On 02/23/2015 09:55 PM, Eric Voskuil wrote:
>> Andy, adding to my previous post below:
>>
>> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
>> ...
>>>> It's possible a really sophisticated modification could be done where
>>>> the attacker encrypts and decrypts the communication and then relays to
>>>> each party (without them knowing or any glitches detected), but I guess
>>>> I'm not sure how easy that would be on such a close proximity device?
>>> If the NFC tap is sufficiently private, privacy is easy to achieve for
>>> the subsequent communication. If it is not, privacy can be completely
>>> compromised. The question is only how much more difficult is the attack.
>>>
>>> With the public cert tap, the level of difficulty is much lower for
>>> capturing selected payment requests. The interloper no longer needs to
>>> invade the space of the NFC terminal and can instead impersonate the
>>> payer from a safe distance. Nobody gets paid, but privacy is
>>> compromised.
>> This problem in the preceding paragraph can be resolved by sending a
>> unique public key on each NFC tap. In that case an attacker would need
>> to monitor the NFC communication.
>>
>> The talk of wrapping the connection in SSL led me to believe you were
>> talking about a static public certificate. However that's not a
>> necessary assumption here and may not be what you intended.
>>
>>> The level of difficulty in the case where the interloper wants to taint
>>> transactions may appear lower, but it is not:
>>>
>>> With the session key tap the interloper must compromise the NFC location
>>> and then monitor the BT traffic. Monitoring BT traffic without being
>>> party to the connection is presumably not rocket surgery, but not
>>> standard BT design either.
>>>
>>> With the public cert tap the interloper must also compromise the NFC
>>> location and communicate over BT. Therefore the hardware and physical
>>> attack requirements are similar. The only added difficulty is that the
>>> attack on the NFC terminal attack is active (modifying the MAC address
>>> directing the payer to the BT service).
>> I believe your central claim was that the difference in the two
>> bootstrapping approaches (public key vs. session key) is that by using a
>> unique public key per tap, the attack requires an active vs. passive
>> attack on the NFC terminal. I just wanted to make clear here that I
>> agree with that assessment.
>>
>> The symmetric key approach is based on the idea that these attacks are
>> comparable in difficulty and otherwise identical in privacy loss.
>>
>> However, the difference in implementation amounts to about +23
>> additional encoded characters for the BT/LE URL, assuming use of the
>> secp256k1 curve for DHE. This is really not a material issue in the case
>> of the NFC tap. The entire URI+URL could be as small as:
>>
>> bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>>
>> In comparison to a symmetric key:
>>
>> bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E
>>
>> It also does not change the protocol design or complexity at all - it
>> would just swap out an AES key for a secp256k1 public key.
>>
>> bitcoin:[address]?bt:<mac>/<key>
>>
>> If that gets us aligned I'm all for it.
>>
>>> However impersonating the payer is just a matter of software - no more
>>> difficult than the session key attack. In fact it may be much easier to
>>> implement, as the attack can use supported BT features because the
>>> attacker has directed the payer to connect to him and is connecting to
>>> the receiver as if he was a payer.
>>>
>>> But it gets worse for the public cert tap, since a more sophisticated
>>> attacker can set himself up in the same position without subverting the
>>> NFC terminal at all. By broadcasting a more powerful BT service on the
>>> same advertised MAC address, the attacker can capture traffic and relay
>>> it to the intended service.
>> I'm retracting the last paragraph, since the interloper, without
>> invading the NFC connection (by substituting the public cert), could not
>> read the relayed traffic. It was getting late :/
>>
>>> So in sum, reliance on a public cert makes the communication less
>>> private under the same physical set of constraints. The difference
>>> results from the receiver allowing non-proximate payers to impersonate
>>> proximate payers from a distance by generating their own session keys
>>> and submitting them over BT.
>> e
>>
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Jan Vornberger]

On Tue, Feb 24, 2015 at 01:14:43AM -0500, Andy Schroder wrote:
> I've had similar issues where the NFC device has to be disconnected
> and reconnected. I've got lots of error checking in my code on the
> NFC device, which helps, but still has problems sometimes. I've
> found if I limit how quickly a new connection can be made, that
> reduces the problem. Have you tried this?

I have a limit there, yes, but maybe I need to raise it. I'd rather
would like it to simply not jam up instead though. :-)

> What command line tool are you using with libnfc?

I don't remember exactly right now, but the Debian packages 'libnfc-bin'
and 'libnfc-examples' have some binaries and I think I used one of them
to present an NFC URI record and I ran into similar problems with
instability.

> This sounds weird to me. Why are you even using bitpay at all if you
> are already going through the effort to remove a signature and
> change the memo field?

For their tie-in with the traditional banking system, i.e. cash-out in
fiat. Here in Germany that might currently be the only feasible way of
accepting bitcoins commercially, because of unresolved questions around
VAT - but that's another topic.

Jan

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 20411 bytes --]

Hello,

I think were talking about a lot of the same things. There is one key 
piece of information that I was not thinking about until you made it 
clear. Why the payee needs to identify the payer. In my fuel pump 
application, they really don't, so I wasn't thinking closely about these 
other situations. With my fuel pump, it won't even let you do anything 
until you sign a transaction and submit it. So, the payment request 
contains no personal information, it's just a request for payment, and 
not for anything specific. It doesn't know or care what you are going to 
buy until you make a prepayment, because there is no use in trying to 
start doing business without a signed transaction. This approach 
minimizes risk because once you dispense a fuel, or anything else, it's 
not like you can easily give it back if you happened to not have any 
funds. It also makes it a higher chance for a confirmation before the 
customer leaves. Other transactions have similar post payment 
traditions, like a restaurant (not fast food), where the seller doesn't 
know if you actually have enough money until you've already consumed the 
food, but this work flow seems to be a culturally driven one rather than 
risk driven.

In the discussion about an https website, there are many websites where 
no login or authentication by the client required to have a private 
connection. With a shopping website though, the customer can identify 
themselves without logging in by saying (in band) what they are 
intending to buy after the private connection has been established. At a 
cash register in person the items being purchased have no tie to the 
customer. The items being purchased were communicated to the seller out 
of band (in real life) and insecurely to establish that link. You are 
trying to make a tie between that list of items and the buyer 
separately, and that is why some unique identifier needs to be 
transmitted via NFC.

Stepping a bit back: I guess I'm wondering if it would be useful to 
encourage an opposite work flow where a micro payment channel is setup 
for most purchases. For example, if I go to the grocery store, it 
usually takes a minute or so to check out. If I immediately tap and open 
up a payment channel with the store when I start checkout, rather than 
finish, there can be more network propagation of that transaction while 
they are scanning all the items. They'll see the channel is open and 
start adding all the items I want to buy to that micro payment channel. 
I'm identified because I made a payment, not because I've transmitted a 
unique resource or used a unique public key to encrypt communication. A 
payment terminal would not allow for new payment channels to be open 
until the currently active one is closed. If I don't have enough funds 
left in the payment channel, they just stop scanning items. There may be 
some additional privacy implications of setting up micro payment 
channels all the time for everyday purchases. It also may not work for 
every sales case, so we may still need some way to authenticate the 
payer with a unique identifier. So, maybe we don't want to do this, but 
it is just a thought to consider.


So, unless someone thinks what I am proposing in my previous paragraph 
has any potential (as a complete solution, not a complement to 
solutions), the plan is the following:

  * Get rid of the "h=" parameter
  * Add a "s=" parameter that uses a unique public key for each session.
    This public key identifies the payee to the payer and payer to the
    payee.
  * 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?
  * 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?



Andy Schroder

On 02/24/2015 06:28 AM, Eric Voskuil wrote:
> On 02/23/2015 09:53 PM, Andy Schroder wrote:
>> I was saying provide a public key via NFC (or a public key fingerprint
>> and then send the full public key over bluetooth). Instead of providing
>> a new public key on each tap, why can't the payee just stop accepting
>> connections from new parties on that "resource" after a session key has
>> been received from the first person?
> Because the presumption was that there was not an additional secret in
> the URI. If the public key is reused then anyone can spoof a payer and
> obtain payment requests.
>
> Adding a secret to the URI can resolve this, as long as it is encrypted
> with the public key before being transmitted back to BT. Otherwise the
> secret can be intercepted and replayed to the terminal, encrypted with
> the well-known public key.
>
> So if you want to treat the "resource" as a secret this would work.
> However the resource was designed as a public session identifier,
> leading the byte stream. This changes it to private session identifier,
> which loses some utility.
>
> Also, reuse of the public key introduces a forward secrecy problem and
> the potential for persistent seller impersonation in the case of
> undiscovered key compromise.
>
> But there's really no benefit to reusing the key. An ephemeral key
> resolves these issues and can also seed the public resource name.
>
>> If the person decides to have there
>> friend or family pay for them instead and cancel the payment, they could
>> just hit cancel on the POS or something (on my fuel pump I have a switch
>> that needs to be turned, the purpose of this is to avoid wasting too
>> many addresses)
> Don't you have someone stop by the pump once a week and empty out the
> addresses? :)
>
>> and/or do another NFC tap (if you're providing QR codes
>> you'd still need a button of some kind though so it knows to refresh
>> it), or the POS can just provide a completely new payment request to any
>> new connections on that same "resource" which use a different session key.
>>
>> I feel like the authentication of the payer to the payee in any future
>> connections after they receive the session key from them (which was
>> encrypted with the payees public key), comes from the fact that they are
>> sending responses back that are encrypted using the session key they
>> gave to the payee. The way I am seeing it is that the NFC tap or QR code
>> scan is acting in addition to the visual name check on the signature
>> verification in the wallet.
> With a secure channel that identifies the parties by proximity, the
> reason for the payment request signature is for the payer to obtain a
> non-repudiation guarantee. But it also serves as a defense-in-depth
> solution to a compromise of the channel (though does not offer a benefit
> in the case of seller terminal/cert compromise).
>
>> If the certificate used isn't signed by a CA
>> (self signed), it may be fine as long as you heard about it via NFC or
>> QR code. I don't think it will require PKI and should still work
>> wallet-to-wallet.
> In that case the cert provides no benefit. A self-signed cert can be
> repudiated and if the channel is compromised anyone can sign the payment
> request.
>
>> It sounds like you are saying I'm proposing the customer is going to
>> need a certificate signed by CA? If so, why?
> This was not a serious proposal, it was to point out what would become
> necessary if the payer could not be identified by proximity.
>
> In the case where a public key is reused, any payer can contact the BT
> terminal and obtain the payment request. If the merchant can't rely on
> proximity (i.e. can't trust the integrity of the NFC connection) then he
> would have to fall back on some other means of identifying the payer. A
> mutual verbal/visual confirmation could work, but the point of of NFC+BT
> is elimination of that hassle.
>
> Yes, it sounds a bit wild, but I have seen on this list a serious
> proposal to have people broadcast their photo, having the merchant
> select them and push to them the payment request. Of course anyone can
> spoof another's image, so at some point your image would need to be
> certified, and hence a CA.
>
> I wouldn't go there, but was just making the point.
>
>> I don't need this for any https website I visit.
> When you go to a web site you first establish a private communication.
> The site doesn't know who you are (hopefully). Then you log on with your
> secret, or proof of it, establishing who you are. Customer identity
> problem solved.
>
> Or you create an account, providing your relevant identity information
> which effectively becomes who you are to the site.
>
> Or you shop anonymously and when you go to check out they know that if
> you pay, you get permission to direct the product shipment. And only you
> can see the bill. This because your session binds your shopping to your
> bill and payment.
>
> However when you go to the local adult shop to pick up some love toys,
> the person at the counter has no idea who's asking their terminal for a
> payment request. You having the shop's public cert doesn't help them
> with that problem (nor does some anonymous signal sending them a photo
> of you). Protecting your privacy ironically requires that they know who
> you are - electronically. That means some sort of crazy consumer cert
> (not sure that would fly in the love shop)... or trust in
> (electronically anonymous) proximity.
>
>> It's not like the payee is sending anything to
>> the payer that is private. The payment request only becomes private if
>> something is actually received to it, otherwise, it is just discarded
>> and it doesn't matter.
> The payment request is private. It's a (potentially signed) proposal to
> contract. It can contain interesting information.
>
>> Those bitcoin addresses are never used. It's just
>> like a shopping cart on a website where someone aborts payment and
>> cancels the order.
> Very much so, but in that case your neighbors can't read your potential
> transactions because your session is secured.
>
>> At one point I was thinking we could do something similar to Mike
>> Hearn's suggestion in another recent e-mail where we re-use some
>> existing part of the bitcoin URI to bootstrap some trust in a public key
>> that the payee next sends via bluetooth after the NFC connection. Now
>> that I'm reviewing my notes though, I can't see how this will work with
>> a watching only wallet or if no backwards compatible (to BIP21) bitcoin
>> address is presented in the URI (as Mike said).
> It can work, but you just end up putting an additional value on the URI
> (for watchers), requiring legacy addresses (for non-watchers), adding
> P2SH scripts to the BT broadcast of the public key, and adding another
> BT round trip to obtain a public key before establishing the session.
>
> A few bytes on the NFC tap is a non-issue, especially in comparison to
> the additional complexity and BT traffic. Those choices are really all
> based on providing private offline transaction support originating from
> generally not private QR code scanning. But QR+BT is not the same as NFC+BT.
>
> Honestly I think it would be reasonable to use the technique with QR+BT,
> accepting the limitations for the legacy system while not unduly
> burdening NFC+BT just for an unachievable cross-consistency goal. Always
> passing the key on the URL for NFC but giving a non-NFC wallet the
> option to ask a BT terminal for a public key seems not just reasonable
> but optimal if we want to support the QR+BT scenario.
>
> Note also that the BT-only scenario is different as well (see recent
> discussion on Airbitz BLE wallet, resulting in the RedPhone-based
> proposal). And finally, QR-only and NFC-only are also different. The
> URIs can be consistent, but the communication protocol will vary.
>
>> What I was saying above about how you can stop accepting connections on
>> that "resource" after a session key has been received by the first
>> person could be problematic though. An evil person could just start
>> making connections to every device they can, just to be mean, which
>> would not allow the POS operator to receive payments from their real
>> customers. If you do the other option I proposed, which is to just keep
>> giving out new payment requests, you have other problems (on top of
>> wasting addresses), which are that you can still have mean people giving
>> you a denial of service attach on your hardware, or you could have an
>> unusual situation where two people pay (don't know why they would do
>> this though), so that is why I'm suggesting a manual tap or button press
>> or switch turn being required.
> Yes, but even with a manual button you could have these problems. The
> data transfer needs to be proximate as well.
>
>> I guess as more of a abuse filter, a new "resource" could be given
>> instead with each tap, and the POS would just ignore all requests to an
>> inactive resource. You may say, why not send a new public key (as you
>> suggested) instead of a new "resource" with each tap (or button press if
>> using QR codes), and then you can skip the sending of a static public
>> key (or public key fingerprint), and ignore any data that is not
>> encrypted with that public key. Maybe that is a better idea because it
>> will shorten the bitcoin URI. However, I don't think its required from a
>> privacy standpoint, it primarily just aids in combining the public key
>> fingerprint with the changing "resource" name used to filter abuse. Or,
>> am I missing something?
> I think this question is covered above.
>
>> So, after thinking through the abuse scenarios I mentioned above, I
>> think I am agreeing with you, but the reason I'm writing all this is to
>> hopefully just get some feedback on my logic to learn something from
>> this discussion. I do think sending a unique public key over NFC has to
>> be better than a unique session key. It adds one more step, but seems to
>> help.
> It doesn't actually add another step to the protocol, just some
> different but simple code on each end. The only downside is that it
> extends the NFC URL about 23 characters.
>
>> If we do this, can we then safely get rid of the h= parameter?
> Absolutely, and I believe Mike ack'd this on a previous post today.
>
>> That should make Mike Hearn happy, and also may alleviate the base64url
>> debate?
> Others may not be aware of the encoding squabble (not sure if it
> qualifies as debate). In the proposed URL, it affects the mac address
> and the key:
>
> bitcoin:[address]?bt:<mac>/<key>
>
> base58:
> bitcoin:?r=bt:12rAs9mM/234KF8hPkXq5pa6pT1wnJC3hVH7W6yB2Wtw24ztzGtBc4
>
> base64url:
> bitcoin:?r=bt:ABBgss5s/A3xWlhB1GI_t2NMR9Zq9E47hZOzmZ6eZTS8sbq-liugh
>
> I prefer base58 because it's available to all bitcoin libraries, nearly
> as compact as base64 (+1 byte in our example) and better standardized.
> Some embedded device people might care about having to incorporate
> base64 as well as base58.
>
> It's also better looking (no - or _ characters) and more consistent in
> the proposed URL (all three values would be base58, as opposed to one
> base58 and two base64url). There may be some idea that base58 is just
> for bitcoin addresses (not true) or designed for humans... that's sort
> of the point, but it's also good for URLs.
>
> e
>
>> On 02/23/2015 09:55 PM, Eric Voskuil wrote:
>>> Andy, adding to my previous post below:
>>>
>>> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>>>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
>>> ...
>>>>> It's possible a really sophisticated modification could be done where
>>>>> the attacker encrypts and decrypts the communication and then relays to
>>>>> each party (without them knowing or any glitches detected), but I guess
>>>>> I'm not sure how easy that would be on such a close proximity device?
>>>> If the NFC tap is sufficiently private, privacy is easy to achieve for
>>>> the subsequent communication. If it is not, privacy can be completely
>>>> compromised. The question is only how much more difficult is the attack.
>>>>
>>>> With the public cert tap, the level of difficulty is much lower for
>>>> capturing selected payment requests. The interloper no longer needs to
>>>> invade the space of the NFC terminal and can instead impersonate the
>>>> payer from a safe distance. Nobody gets paid, but privacy is
>>>> compromised.
>>> This problem in the preceding paragraph can be resolved by sending a
>>> unique public key on each NFC tap. In that case an attacker would need
>>> to monitor the NFC communication.
>>>
>>> The talk of wrapping the connection in SSL led me to believe you were
>>> talking about a static public certificate. However that's not a
>>> necessary assumption here and may not be what you intended.
>>>
>>>> The level of difficulty in the case where the interloper wants to taint
>>>> transactions may appear lower, but it is not:
>>>>
>>>> With the session key tap the interloper must compromise the NFC location
>>>> and then monitor the BT traffic. Monitoring BT traffic without being
>>>> party to the connection is presumably not rocket surgery, but not
>>>> standard BT design either.
>>>>
>>>> With the public cert tap the interloper must also compromise the NFC
>>>> location and communicate over BT. Therefore the hardware and physical
>>>> attack requirements are similar. The only added difficulty is that the
>>>> attack on the NFC terminal attack is active (modifying the MAC address
>>>> directing the payer to the BT service).
>>> I believe your central claim was that the difference in the two
>>> bootstrapping approaches (public key vs. session key) is that by using a
>>> unique public key per tap, the attack requires an active vs. passive
>>> attack on the NFC terminal. I just wanted to make clear here that I
>>> agree with that assessment.
>>>
>>> The symmetric key approach is based on the idea that these attacks are
>>> comparable in difficulty and otherwise identical in privacy loss.
>>>
>>> However, the difference in implementation amounts to about +23
>>> additional encoded characters for the BT/LE URL, assuming use of the
>>> secp256k1 curve for DHE. This is really not a material issue in the case
>>> of the NFC tap. The entire URI+URL could be as small as:
>>>
>>> bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>>>
>>> In comparison to a symmetric key:
>>>
>>> bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E
>>>
>>> It also does not change the protocol design or complexity at all - it
>>> would just swap out an AES key for a secp256k1 public key.
>>>
>>> bitcoin:[address]?bt:<mac>/<key>
>>>
>>> If that gets us aligned I'm all for it.
>>>
>>>> However impersonating the payer is just a matter of software - no more
>>>> difficult than the session key attack. In fact it may be much easier to
>>>> implement, as the attack can use supported BT features because the
>>>> attacker has directed the payer to connect to him and is connecting to
>>>> the receiver as if he was a payer.
>>>>
>>>> But it gets worse for the public cert tap, since a more sophisticated
>>>> attacker can set himself up in the same position without subverting the
>>>> NFC terminal at all. By broadcasting a more powerful BT service on the
>>>> same advertised MAC address, the attacker can capture traffic and relay
>>>> it to the intended service.
>>> I'm retracting the last paragraph, since the interloper, without
>>> invading the NFC connection (by substituting the public cert), could not
>>> read the relayed traffic. It was getting late :/
>>>
>>>> So in sum, reliance on a public cert makes the communication less
>>>> private under the same physical set of constraints. The difference
>>>> results from the receiver allowing non-proximate payers to impersonate
>>>> proximate payers from a distance by generating their own session keys
>>>> and submitting them over BT.
>>> e
>>>
>>


[-- Attachment #1.2: Type: text/html, Size: 23444 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 22437 bytes --]

On 02/24/2015 11:49 AM, Andy Schroder wrote:
> Hello,
> 
> I think were talking about a lot of the same things. There is one key
> piece of information that I was not thinking about until you made it
> clear. Why the payee needs to identify the payer. In my fuel pump
> application, they really don't, so I wasn't thinking closely about these
> other situations. With my fuel pump, it won't even let you do anything
> until you sign a transaction and submit it. So, the payment request
> contains no personal information, it's just a request for payment, and
> not for anything specific. It doesn't know or care what you are going to
> buy until you make a prepayment, because there is no use in trying to
> start doing business without a signed transaction. This approach
> minimizes risk because once you dispense a fuel, or anything else, it's
> not like you can easily give it back if you happened to not have any
> funds. It also makes it a higher chance for a confirmation before the
> customer leaves. Other transactions have similar post payment
> traditions, like a restaurant (not fast food), where the seller doesn't
> know if you actually have enough money until you've already consumed the
> food, but this work flow seems to be a culturally driven one rather than
> risk driven.
> 
> In the discussion about an https website, there are many websites where
> no login or authentication by the client required to have a private
> connection. With a shopping website though, the customer can identify
> themselves without logging in by saying (in band) what they are
> intending to buy after the private connection has been established. At a
> cash register in person the items being purchased have no tie to the
> customer. The items being purchased were communicated to the seller out
> of band (in real life) and insecurely to establish that link. You are
> trying to make a tie between that list of items and the buyer
> separately, and that is why some unique identifier needs to be
> transmitted via NFC.
> 
> Stepping a bit back: I guess I'm wondering if it would be useful to
> encourage an opposite work flow where a micro payment channel is setup
> for most purchases. For example, if I go to the grocery store, it
> usually takes a minute or so to check out. If I immediately tap and open
> up a payment channel with the store when I start checkout, rather than
> finish, there can be more network propagation of that transaction while
> they are scanning all the items. They'll see the channel is open and
> start adding all the items I want to buy to that micro payment channel.
> I'm identified because I made a payment, not because I've transmitted a
> unique resource or used a unique public key to encrypt communication. A
> payment terminal would not allow for new payment channels to be open
> until the currently active one is closed. If I don't have enough funds
> left in the payment channel, they just stop scanning items. There may be
> some additional privacy implications of setting up micro payment
> channels all the time for everyday purchases. It also may not work for
> every sales case, so we may still need some way to authenticate the
> payer with a unique identifier. So, maybe we don't want to do this, but
> it is just a thought to consider.

It's an interesting thought. As you say, it may be more of a cultural
than technical issue.

> So, unless someone thinks what I am proposing in my previous paragraph
> has any potential (as a complete solution, not a complement to
> solutions), the plan is the following:
> 
>   * Get rid of the "h=" parameter

Agree.

>   * Add a "s=" parameter that uses a unique public key for each session.
>     This public key identifies the payee to the payer and payer to the
>     payee.

This would be the simple model, which just tacks on another parameter to
the bitcoin URL:

bitcoin:[address]?bt=<mac>&s=<key>

But we should also look at the more flexible "r#" approach from your
existing TBIPs, which would yield:

bitcoin:[address]?r=bt:<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) be
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 that
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

> On 02/24/2015 06:28 AM, Eric Voskuil wrote:
>> On 02/23/2015 09:53 PM, Andy Schroder wrote:
>>> I was saying provide a public key via NFC (or a public key fingerprint
>>> and then send the full public key over bluetooth). Instead of providing
>>> a new public key on each tap, why can't the payee just stop accepting
>>> connections from new parties on that "resource" after a session key has
>>> been received from the first person?
>> Because the presumption was that there was not an additional secret in
>> the URI. If the public key is reused then anyone can spoof a payer and
>> obtain payment requests.
>>
>> Adding a secret to the URI can resolve this, as long as it is encrypted
>> with the public key before being transmitted back to BT. Otherwise the
>> secret can be intercepted and replayed to the terminal, encrypted with
>> the well-known public key.
>>
>> So if you want to treat the "resource" as a secret this would work.
>> However the resource was designed as a public session identifier,
>> leading the byte stream. This changes it to private session identifier,
>> which loses some utility.
>>
>> Also, reuse of the public key introduces a forward secrecy problem and
>> the potential for persistent seller impersonation in the case of
>> undiscovered key compromise.
>>
>> But there's really no benefit to reusing the key. An ephemeral key
>> resolves these issues and can also seed the public resource name.
>>
>>> If the person decides to have there
>>> friend or family pay for them instead and cancel the payment, they could
>>> just hit cancel on the POS or something (on my fuel pump I have a switch
>>> that needs to be turned, the purpose of this is to avoid wasting too
>>> many addresses)
>> Don't you have someone stop by the pump once a week and empty out the
>> addresses? :)
>>
>>> and/or do another NFC tap (if you're providing QR codes
>>> you'd still need a button of some kind though so it knows to refresh
>>> it), or the POS can just provide a completely new payment request to any
>>> new connections on that same "resource" which use a different session key.
>>>
>>> I feel like the authentication of the payer to the payee in any future
>>> connections after they receive the session key from them (which was
>>> encrypted with the payees public key), comes from the fact that they are
>>> sending responses back that are encrypted using the session key they
>>> gave to the payee. The way I am seeing it is that the NFC tap or QR code
>>> scan is acting in addition to the visual name check on the signature
>>> verification in the wallet.
>> With a secure channel that identifies the parties by proximity, the
>> reason for the payment request signature is for the payer to obtain a
>> non-repudiation guarantee. But it also serves as a defense-in-depth
>> solution to a compromise of the channel (though does not offer a benefit
>> in the case of seller terminal/cert compromise).
>>
>>> If the certificate used isn't signed by a CA
>>> (self signed), it may be fine as long as you heard about it via NFC or
>>> QR code. I don't think it will require PKI and should still work
>>> wallet-to-wallet.
>> In that case the cert provides no benefit. A self-signed cert can be
>> repudiated and if the channel is compromised anyone can sign the payment
>> request.
>>
>>> It sounds like you are saying I'm proposing the customer is going to
>>> need a certificate signed by CA? If so, why? 
>> This was not a serious proposal, it was to point out what would become
>> necessary if the payer could not be identified by proximity.
>>
>> In the case where a public key is reused, any payer can contact the BT
>> terminal and obtain the payment request. If the merchant can't rely on
>> proximity (i.e. can't trust the integrity of the NFC connection) then he
>> would have to fall back on some other means of identifying the payer. A
>> mutual verbal/visual confirmation could work, but the point of of NFC+BT
>> is elimination of that hassle.
>>
>> Yes, it sounds a bit wild, but I have seen on this list a serious
>> proposal to have people broadcast their photo, having the merchant
>> select them and push to them the payment request. Of course anyone can
>> spoof another's image, so at some point your image would need to be
>> certified, and hence a CA.
>>
>> I wouldn't go there, but was just making the point.
>>
>>> I don't need this for any https website I visit.
>> When you go to a web site you first establish a private communication.
>> The site doesn't know who you are (hopefully). Then you log on with your
>> secret, or proof of it, establishing who you are. Customer identity
>> problem solved.
>>
>> Or you create an account, providing your relevant identity information
>> which effectively becomes who you are to the site.
>>
>> Or you shop anonymously and when you go to check out they know that if
>> you pay, you get permission to direct the product shipment. And only you
>> can see the bill. This because your session binds your shopping to your
>> bill and payment.
>>
>> However when you go to the local adult shop to pick up some love toys,
>> the person at the counter has no idea who's asking their terminal for a
>> payment request. You having the shop's public cert doesn't help them
>> with that problem (nor does some anonymous signal sending them a photo
>> of you). Protecting your privacy ironically requires that they know who
>> you are - electronically. That means some sort of crazy consumer cert
>> (not sure that would fly in the love shop)... or trust in
>> (electronically anonymous) proximity.
>>
>>> It's not like the payee is sending anything to
>>> the payer that is private. The payment request only becomes private if
>>> something is actually received to it, otherwise, it is just discarded
>>> and it doesn't matter.
>> The payment request is private. It's a (potentially signed) proposal to
>> contract. It can contain interesting information.
>>
>>> Those bitcoin addresses are never used. It's just
>>> like a shopping cart on a website where someone aborts payment and
>>> cancels the order.
>> Very much so, but in that case your neighbors can't read your potential
>> transactions because your session is secured.
>>
>>> At one point I was thinking we could do something similar to Mike
>>> Hearn's suggestion in another recent e-mail where we re-use some
>>> existing part of the bitcoin URI to bootstrap some trust in a public key
>>> that the payee next sends via bluetooth after the NFC connection. Now
>>> that I'm reviewing my notes though, I can't see how this will work with
>>> a watching only wallet or if no backwards compatible (to BIP21) bitcoin
>>> address is presented in the URI (as Mike said).
>> It can work, but you just end up putting an additional value on the URI
>> (for watchers), requiring legacy addresses (for non-watchers), adding
>> P2SH scripts to the BT broadcast of the public key, and adding another
>> BT round trip to obtain a public key before establishing the session.
>>
>> A few bytes on the NFC tap is a non-issue, especially in comparison to
>> the additional complexity and BT traffic. Those choices are really all
>> based on providing private offline transaction support originating from
>> generally not private QR code scanning. But QR+BT is not the same as NFC+BT.
>>
>> Honestly I think it would be reasonable to use the technique with QR+BT,
>> accepting the limitations for the legacy system while not unduly
>> burdening NFC+BT just for an unachievable cross-consistency goal. Always
>> passing the key on the URL for NFC but giving a non-NFC wallet the
>> option to ask a BT terminal for a public key seems not just reasonable
>> but optimal if we want to support the QR+BT scenario.
>>
>> Note also that the BT-only scenario is different as well (see recent
>> discussion on Airbitz BLE wallet, resulting in the RedPhone-based
>> proposal). And finally, QR-only and NFC-only are also different. The
>> URIs can be consistent, but the communication protocol will vary.
>>
>>> What I was saying above about how you can stop accepting connections on
>>> that "resource" after a session key has been received by the first
>>> person could be problematic though. An evil person could just start
>>> making connections to every device they can, just to be mean, which
>>> would not allow the POS operator to receive payments from their real
>>> customers. If you do the other option I proposed, which is to just keep
>>> giving out new payment requests, you have other problems (on top of
>>> wasting addresses), which are that you can still have mean people giving
>>> you a denial of service attach on your hardware, or you could have an
>>> unusual situation where two people pay (don't know why they would do
>>> this though), so that is why I'm suggesting a manual tap or button press
>>> or switch turn being required.
>> Yes, but even with a manual button you could have these problems. The
>> data transfer needs to be proximate as well.
>>
>>> I guess as more of a abuse filter, a new "resource" could be given
>>> instead with each tap, and the POS would just ignore all requests to an
>>> inactive resource. You may say, why not send a new public key (as you
>>> suggested) instead of a new "resource" with each tap (or button press if
>>> using QR codes), and then you can skip the sending of a static public
>>> key (or public key fingerprint), and ignore any data that is not
>>> encrypted with that public key. Maybe that is a better idea because it
>>> will shorten the bitcoin URI. However, I don't think its required from a
>>> privacy standpoint, it primarily just aids in combining the public key
>>> fingerprint with the changing "resource" name used to filter abuse. Or,
>>> am I missing something?
>> I think this question is covered above.
>>
>>> So, after thinking through the abuse scenarios I mentioned above, I
>>> think I am agreeing with you, but the reason I'm writing all this is to
>>> hopefully just get some feedback on my logic to learn something from
>>> this discussion. I do think sending a unique public key over NFC has to
>>> be better than a unique session key. It adds one more step, but seems to
>>> help. 
>> It doesn't actually add another step to the protocol, just some
>> different but simple code on each end. The only downside is that it
>> extends the NFC URL about 23 characters.
>>
>>> If we do this, can we then safely get rid of the h= parameter?
>> Absolutely, and I believe Mike ack'd this on a previous post today.
>>
>>> That should make Mike Hearn happy, and also may alleviate the base64url
>>> debate?
>> Others may not be aware of the encoding squabble (not sure if it
>> qualifies as debate). In the proposed URL, it affects the mac address
>> and the key:
>>
>> bitcoin:[address]?bt:<mac>/<key>
>>
>> base58:
>> bitcoin:?r=bt:12rAs9mM/234KF8hPkXq5pa6pT1wnJC3hVH7W6yB2Wtw24ztzGtBc4
>>
>> base64url:
>> bitcoin:?r=bt:ABBgss5s/A3xWlhB1GI_t2NMR9Zq9E47hZOzmZ6eZTS8sbq-liugh
>>
>> I prefer base58 because it's available to all bitcoin libraries, nearly
>> as compact as base64 (+1 byte in our example) and better standardized.
>> Some embedded device people might care about having to incorporate
>> base64 as well as base58.
>>
>> It's also better looking (no - or _ characters) and more consistent in
>> the proposed URL (all three values would be base58, as opposed to one
>> base58 and two base64url). There may be some idea that base58 is just
>> for bitcoin addresses (not true) or designed for humans... that's sort
>> of the point, but it's also good for URLs.
>>
>> e
>>
>>> On 02/23/2015 09:55 PM, Eric Voskuil wrote:
>>>> Andy, adding to my previous post below:
>>>>
>>>> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>>>>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
>>>> ...
>>>>>> It's possible a really sophisticated modification could be done where
>>>>>> the attacker encrypts and decrypts the communication and then relays to
>>>>>> each party (without them knowing or any glitches detected), but I guess
>>>>>> I'm not sure how easy that would be on such a close proximity device?
>>>>> If the NFC tap is sufficiently private, privacy is easy to achieve for
>>>>> the subsequent communication. If it is not, privacy can be completely
>>>>> compromised. The question is only how much more difficult is the attack.
>>>>>
>>>>> With the public cert tap, the level of difficulty is much lower for
>>>>> capturing selected payment requests. The interloper no longer needs to
>>>>> invade the space of the NFC terminal and can instead impersonate the
>>>>> payer from a safe distance. Nobody gets paid, but privacy is
>>>>> compromised.
>>>> This problem in the preceding paragraph can be resolved by sending a
>>>> unique public key on each NFC tap. In that case an attacker would need
>>>> to monitor the NFC communication.
>>>>
>>>> The talk of wrapping the connection in SSL led me to believe you were
>>>> talking about a static public certificate. However that's not a
>>>> necessary assumption here and may not be what you intended.
>>>>
>>>>> The level of difficulty in the case where the interloper wants to taint
>>>>> transactions may appear lower, but it is not:
>>>>>
>>>>> With the session key tap the interloper must compromise the NFC location
>>>>> and then monitor the BT traffic. Monitoring BT traffic without being
>>>>> party to the connection is presumably not rocket surgery, but not
>>>>> standard BT design either.
>>>>>
>>>>> With the public cert tap the interloper must also compromise the NFC
>>>>> location and communicate over BT. Therefore the hardware and physical
>>>>> attack requirements are similar. The only added difficulty is that the
>>>>> attack on the NFC terminal attack is active (modifying the MAC address
>>>>> directing the payer to the BT service).
>>>> I believe your central claim was that the difference in the two
>>>> bootstrapping approaches (public key vs. session key) is that by using a
>>>> unique public key per tap, the attack requires an active vs. passive
>>>> attack on the NFC terminal. I just wanted to make clear here that I
>>>> agree with that assessment.
>>>>
>>>> The symmetric key approach is based on the idea that these attacks are
>>>> comparable in difficulty and otherwise identical in privacy loss.
>>>>
>>>> However, the difference in implementation amounts to about +23
>>>> additional encoded characters for the BT/LE URL, assuming use of the
>>>> secp256k1 curve for DHE. This is really not a material issue in the case
>>>> of the NFC tap. The entire URI+URL could be as small as:
>>>>
>>>> bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>>>>
>>>> In comparison to a symmetric key:
>>>>
>>>> bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E
>>>>
>>>> It also does not change the protocol design or complexity at all - it
>>>> would just swap out an AES key for a secp256k1 public key.
>>>>
>>>> bitcoin:[address]?bt:<mac>/<key>
>>>>
>>>> If that gets us aligned I'm all for it.
>>>>
>>>>> However impersonating the payer is just a matter of software - no more
>>>>> difficult than the session key attack. In fact it may be much easier to
>>>>> implement, as the attack can use supported BT features because the
>>>>> attacker has directed the payer to connect to him and is connecting to
>>>>> the receiver as if he was a payer.
>>>>>
>>>>> But it gets worse for the public cert tap, since a more sophisticated
>>>>> attacker can set himself up in the same position without subverting the
>>>>> NFC terminal at all. By broadcasting a more powerful BT service on the
>>>>> same advertised MAC address, the attacker can capture traffic and relay
>>>>> it to the intended service.
>>>> I'm retracting the last paragraph, since the interloper, without
>>>> invading the NFC connection (by substituting the public cert), could not
>>>> read the relayed traffic. It was getting late :/
>>>>
>>>>> So in sum, reliance on a public cert makes the communication less
>>>>> private under the same physical set of constraints. The difference
>>>>> results from the receiver allowing non-proximate payers to impersonate
>>>>> proximate payers from a distance by generating their own session keys
>>>>> and submitting them over BT.
>>>> e
>>>>
>>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1: Type: text/plain, Size: 3576 bytes --]

We can change "resource" to "Session ID" if you want.

I think the URL scheme should be:

bitcoin:[address]?r=bt:<mac>&s=<PublicKey>

But when connecting to the mac, the client indicates the SessionID in 
the header, and as you say, SessionID is derived in some way from PublicKey.

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 
message. The other thing is it can be used with more protocols without 
taking up more space in the URL.

However, by loosing the h= parameter, I think we are now loosing some 
benefit it brought to https based connections if the customer doesn't 
want to use bluetooth. Right?

Also, you talk about a new public key (and session ID) for each tap. I 
guess I'm wondering about this though. If the public key is compromised 
on the first tap, isn't their payment request already compromised?




Since we are securing everything, can we change the message header 
format from what Schildbach's bitcoin wallet implements to something 
more consistent? Maybe we can create a new UUID for this secure service 
so Schildbach's bitcoin wallet can still maintain backwards compatibility.




Andy Schroder

On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>>    * Add a "s=" parameter that uses a unique public key for each session.
>>      This public key identifies the payee to the payer and payer to the
>>      payee.
> This would be the simple model, which just tacks on another parameter to
> the bitcoin URL:
>
> bitcoin:[address]?bt=<mac>&s=<key>
>
> But we should also look at the more flexible "r#" approach from your
> existing TBIPs, which would yield:
>
> bitcoin:[address]?r=bt:<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) be
> 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 that
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 6308 bytes --]

On 02/24/2015 02:50 PM, Andy Schroder wrote:
> We can change "resource" to "Session ID" if you want.
> 
> I think the URL scheme should be:
> 
> bitcoin:[address]?r=bt:<mac>&s=<PublicKey>

This is a question of proper URL semantics, as applied to the "bt" scheme.

From rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]:

"The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any)."

...

"The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a resource
within the scope of the URI's scheme and naming authority (if any). The
query component is indicated by the first question mark ("?") character
and terminated by a number sign ("#") character or by the end of the URI."

https://tools.ietf.org/html/rfc3986#section-3.3

The question therefore is whether <key> is (1) relative to the path
(hierarchical) or (2) independent of the path and instead relative to
the scheme and naming authority.

The "bt" scheme does not include a naming authority, and as such the
question is simply whether <key> is relative to "bt" or relative to the
path, which is <mac>. Quite clearly <key> is valid only in the context
of <mac>, not relevant to all <mac>s.

As such one must conclude that the proper form is:

bt:<mac>/<key>

> But when connecting to the mac, the client indicates the SessionID in
> the header, and as you say, SessionID is derived in some way from
> PublicKey.

Yes.

> 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
> message. The other thing is it can be used with more protocols without
> taking up more space in the URL.
> 
> However, by loosing the h= parameter, I think we are now loosing some
> benefit it brought to https based connections if the customer doesn't
> want to use bluetooth. Right?

I don't believe that the BIP-70 protocol over https has any need for the
parameter. It was only useful because the NFC/BT session wasn't secured.
So I don't think anything is lost.

> Also, you talk about a new public key (and session ID) for each tap. I
> guess I'm wondering about this though. If the public key is compromised
> on the first tap, isn't their payment request already compromised?

Yes, but that is not the problem that non-reuse is designed to resolve.

Reuse of the public key creates a forward secrecy problem. If 1000
sessions are recorded, and later the private key associated with the
reused public key is compromized, all of the sessions are retroactively
compromised.

Another problem is persistent impersonation. If the one associated
private key is compromised, and nobody knows it, the attacker can not
only monitor all transactions but can selectively steal payments (if
they aren't signed and verified). This is BTW also a good reason to not
use HD generation of these session keys.

Another problem is that any payer can use the well-known public key to
obtain payment requests.

Another problem is that without a unique public key there is no unique
session id, so that would need to be added explicitly on the URI.

> Since we are securing everything, can we change the message header
> format from what Schildbach's bitcoin wallet implements to something
> more consistent?

Could you spell this out, I'm not familiar with the implementation, just
the proposals.

> Maybe we can create a new UUID for this secure service
> so Schildbach's bitcoin wallet can still maintain backwards compatibility.

That may be necessary depending on the implementation of existing
terminals, but I'm not familiar enough to speculate.

e

> On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>>>    * Add a "s=" parameter that uses a unique public key for each
>>> session.
>>>      This public key identifies the payee to the payer and payer to the
>>>      payee.
>> This would be the simple model, which just tacks on another parameter to
>> the bitcoin URL:
>>
>> bitcoin:[address]?bt=<mac>&s=<key>
>>
>> But we should also look at the more flexible "r#" approach from your
>> existing TBIPs, which would yield:
>>
>> bitcoin:[address]?r=bt:<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) be
>> 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 that
>> 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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

On 02/24/2015 11:41 AM, Mike Hearn wrote:
>     Does this not also require the BT publication of the script for a P2SH
>     address?
> 
> 
> You mean if the URI you're serving is like this?
> 
>    bitcoin:3aBcD........?bt=....
> 
> Yes it would. I guess then, the server would indicate both the script,
> and the key within that script that it wanted to use. A bit more complex
> but would still work to save URI space.

What if the script doesn't use any key at all?

Somehow this "re-using" the fallback address idea feels less and less
appealing to me. I think we should add our own parameter and let go of
fallback addresses as soon as possible. If will waste space during the
transition period, but after that it should make no difference any more.

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andreas Schildbach]

On 02/23/2015 04:09 PM, Jan Vornberger wrote:

> I'm still concerned that the fact, that Bluetooth is often disabled, is a
> problem for the UX. And it's not just a one-time thing as with NFC,
> which is - in my experience - also often disabled, but then people turn
> it on and leave it on.

It's the same with Bluetooth. More and more people use audio via
Bluetooth, mostly because they use a headset or stream their music to
their stereo at home.

Those that still switch off Bluetooth all the time can simply press a
button. It can't be any easier.

> Another idea could be to request the permission BLUETOOTH_ADMIN which,
> as far as I know, allows you to programmatically turn on Bluetooth
> without user interaction.

True, but those people who switch off Bluetooth will also simply not
install the app because of that permission.

If only Android had optional permissions... )-:

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 9716 bytes --]







Manually quoting a reply from Andreas that was sent privately while the 
e-mail list was 2 days delayed delivering messages ....

On 02/25/2015 02:45 AM, Andreas Schildbach wrote:
> Bear in mind that the "bt:" scheme is already in use by ~700.000
> installations. If we change the protocol except just wrapping a secure
> layer, we should change the scheme to for example "bs:" (Bluetooth secure).

This bs: is not a bad idea. Is bts: any better/clearer than bs:?

>
> That said, I don't like the idea to fold the resource name and the
> session key into one. Resource names can be shared by multiple
> protocols, for example a merchant may publish payment requests under
> bt:<mac>/r1*and*  https://<domain>/r1. If you want to save space and
> don't need resources, you can always just use bt:<mac> and a default
> resource (bt:<mac>/) is assumed.

I'm going to agree with Andreas on this. The other thing is we are 
making the resource name derived from the public key, so we are not even 
directly sending the resource name.

>
> Have we decided on the use (or non-use) of a DHKE (or similar) protocol
> like Mike suggested?


We are planning to send a unique public key of the payee via NFC. See 
other e-mails now that the e-mail list finally forwarded them through 
the other day.
















Now for Eric's e-mail... More below.


On 02/24/2015 09:09 PM, Eric Voskuil wrote:
> On 02/24/2015 02:50 PM, Andy Schroder wrote:
>> We can change "resource" to "Session ID" if you want.
>>
>> I think the URL scheme should be:
>>
>> bitcoin:[address]?r=bt:<mac>&s=<PublicKey>
> This is a question of proper URL semantics, as applied to the "bt" scheme.
>
>  From rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]:
>
> "The path component contains data, usually organized in hierarchical
> form, that, along with data in the non-hierarchical query component
> (Section 3.4), serves to identify a resource within the scope of the
> URI's scheme and naming authority (if any)."
>
> ...
>
> "The query component contains non-hierarchical data that, along with
> data in the path component (Section 3.3), serves to identify a resource
> within the scope of the URI's scheme and naming authority (if any). The
> query component is indicated by the first question mark ("?") character
> and terminated by a number sign ("#") character or by the end of the URI."
>
> https://tools.ietf.org/html/rfc3986#section-3.3
>
> The question therefore is whether <key> is (1) relative to the path
> (hierarchical) or (2) independent of the path and instead relative to
> the scheme and naming authority.
>
> The "bt" scheme does not include a naming authority, and as such the
> question is simply whether <key> is relative to "bt" or relative to the
> path, which is <mac>. Quite clearly <key> is valid only in the context
> of <mac>, not relevant to all <mac>s.
>
> As such one must conclude that the proper form is:
>
> bt:<mac>/<key>


See my comments above.


>
>> But when connecting to the mac, the client indicates the SessionID in
>> the header, and as you say, SessionID is derived in some way from
>> PublicKey.
> Yes.
>
>> 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
>> message. The other thing is it can be used with more protocols without
>> taking up more space in the URL.
>>
>> However, by loosing the h= parameter, I think we are now loosing some
>> benefit it brought to https based connections if the customer doesn't
>> want to use bluetooth. Right?
> I don't believe that the BIP-70 protocol over https has any need for the
> parameter. It was only useful because the NFC/BT session wasn't secured.
> So I don't think anything is lost.

This may be true. Andreas, do you agree? I feel like there was something 
in your app where it did not currently compare the domain name to domain 
name the digital signature in the payment request used though. Maybe 
this was only for bluetooth though? However, can we trust DNS though? 
Seems like it is not too hard to get an alternate signed certificate for 
a domain name, and if you can serve false DNS and/or change TCP/IP 
routing, then your secure link can break down?



>
>> Also, you talk about a new public key (and session ID) for each tap. I
>> guess I'm wondering about this though. If the public key is compromised
>> on the first tap, isn't their payment request already compromised?
> Yes, but that is not the problem that non-reuse is designed to resolve.
>
> Reuse of the public key creates a forward secrecy problem. If 1000
> sessions are recorded, and later the private key associated with the
> reused public key is compromized, all of the sessions are retroactively
> compromised.
>
> Another problem is persistent impersonation. If the one associated
> private key is compromised, and nobody knows it, the attacker can not
> only monitor all transactions but can selectively steal payments (if
> they aren't signed and verified). This is BTW also a good reason to not
> use HD generation of these session keys.
>
> Another problem is that any payer can use the well-known public key to
> obtain payment requests.
>
> Another problem is that without a unique public key there is no unique
> session id, so that would need to be added explicitly on the URI.



I get what you are saying, but I don't know that 2 taps with the same 
public key is the same as 1000 uses of the same public key?



>
>> Since we are securing everything, can we change the message header
>> format from what Schildbach's bitcoin wallet implements to something
>> more consistent?
> Could you spell this out, I'm not familiar with the implementation, just
> the proposals.


If you'll check the proposed specification, the headers in each message 
(before the serialized payment request data is sent), are consistent 
from message to message.

https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki#Specification




>
>> Maybe we can create a new UUID for this secure service
>> so Schildbach's bitcoin wallet can still maintain backwards compatibility.
> That may be necessary depending on the implementation of existing
> terminals, but I'm not familiar enough to speculate.

I think we probably also want to combine new UUID's with Schildbach's 
suggestion (above) to use a new "bs:" (which I suggested maybe "bts:") 
protocol scheme.



>
> e
>
>> On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>>>>     * Add a "s=" parameter that uses a unique public key for each
>>>> session.
>>>>       This public key identifies the payee to the payer and payer to the
>>>>       payee.
>>> This would be the simple model, which just tacks on another parameter to
>>> the bitcoin URL:
>>>
>>> bitcoin:[address]?bt=<mac>&s=<key>
>>>
>>> But we should also look at the more flexible "r#" approach from your
>>> existing TBIPs, which would yield:
>>>
>>> bitcoin:[address]?r=bt:<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) be
>>> 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 that
>>> 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
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #1.2: Type: text/html, Size: 13466 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]

On 02/26/2015 04:30 AM, Andreas Schildbach wrote:
> On 02/24/2015 11:41 AM, Mike Hearn wrote:
>> On 02/23/2015 04:10 PM, Eric Voskuil wrote:
>>> Does this not also require the BT publication of the script for a P2SH
>>> address?
>>
>> You mean if the URI you're serving is like this?
>>
>>    bitcoin:3aBcD........?bt=....
>>
>> Yes it would. I guess then, the server would indicate both the script,
>> and the key within that script that it wanted to use. A bit more complex
>> but would still work to save URI space.
> 
> What if the script doesn't use any key at all?
> 
> Somehow this "re-using" the fallback address idea feels less and less
> appealing to me. I think we should add our own parameter and let go of
> fallback addresses as soon as possible. If will waste space during the
> transition period, but after that it should make no difference any more.

Agree. The amount of bitcoin URI space in question isn't a material
issue when it comes to NFC. The more significant considerations here are
the additional BT round trip to establish a session, greater complexity,
and the potential lack of a correlating address (as you point out above).

On the other hand I think the approach has merit in a scenario where the
bitcoin URI is read from a QR code and BT is available (IOW no NFC).
Generalizing it to the NFC-based bitcoin URI is the problem.

A much cleaner generalization is to rationalize the two approaches
*after* the bitcoin URI has been read (from either NFC or QR). In the QR
scenario the wallet can obtain a verifiable public key from the BT
terminal (subject to some limitations as discussed above). In the NFC
scenario the public key is just passed in the URI. The scenarios come
together at the point where they both have the public key (and the mac
address).

This of course implies that the the BT URL scheme, in order to be used
in both places, would have to allow the public key to be optional. But
in an NFC tap it would be present and in a QR scan it would not.

QR-BT
bitcoin:<bitcoin-address>?bts:<mac-address>

NFC-BT
bitcoin:[bitcoin-address]?bts:<mac-address>/<public-key>

As you say, this prevents the NFC scenario from perpetuating the
fallback address as a requirement, which eventually shortens the bitcoin
URI.

Making the public key a requirement when used with NFC would simplify
wallet development for NFC only wallets. But if a wallet supported both
NFC and QR scanning it wouldn't make much difference. So it's not
unreasonable to think of it like this:

QR-BT/NFC-BT
bitcoin:<bitcoin-address>?bts:<mac-address>
bitcoin:[bitcoin-address]?bts:<mac-address>/<public-key>

This provides greater generality, but it creates a situation where
NFC-only wallets need to support the more complex approach, and where
use in QR codes would have scanning issues. So I think it's better to
specify limits on each as in the first example.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 47 bytes --]

The list appears dead, this is a test.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]