* [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
@ 2015-02-22 19:08 Jan Vornberger
2015-02-22 22:37 ` Andy Schroder
` (2 more replies)
0 siblings, 3 replies; 45+ messages in thread
From: Jan Vornberger @ 2015-02-22 19:08 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 19:08 [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback Jan Vornberger @ 2015-02-22 22:37 ` Andy Schroder 2015-02-22 23:06 ` Eric Voskuil ` (2 more replies) 2015-02-22 22:39 ` Eric Voskuil 2015-02-23 0:48 ` Andreas Schildbach 2 siblings, 3 replies; 45+ messages in thread From: Andy Schroder @ 2015-02-22 22:37 UTC (permalink / raw) To: Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 22:37 ` Andy Schroder @ 2015-02-22 23:06 ` Eric Voskuil 2015-02-22 23:32 ` Andy Schroder 2015-02-23 0:58 ` Andreas Schildbach 2015-02-23 15:09 ` Jan Vornberger 2 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-22 23:06 UTC (permalink / raw) To: Andy Schroder, Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 23:06 ` Eric Voskuil @ 2015-02-22 23:32 ` Andy Schroder 2015-02-23 0:05 ` Eric Voskuil 2015-02-23 1:02 ` Andreas Schildbach 0 siblings, 2 replies; 45+ messages in thread From: Andy Schroder @ 2015-02-22 23:32 UTC (permalink / raw) To: Eric Voskuil, Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 23:32 ` Andy Schroder @ 2015-02-23 0:05 ` Eric Voskuil 2015-02-23 1:02 ` Andreas Schildbach 1 sibling, 0 replies; 45+ messages in thread From: Eric Voskuil @ 2015-02-23 0:05 UTC (permalink / raw) To: Andy Schroder, Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 23:32 ` Andy Schroder 2015-02-23 0:05 ` Eric Voskuil @ 2015-02-23 1:02 ` Andreas Schildbach 2015-02-23 7:36 ` Andy Schroder 1 sibling, 1 reply; 45+ messages in thread From: Andreas Schildbach @ 2015-02-23 1:02 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 1:02 ` Andreas Schildbach @ 2015-02-23 7:36 ` Andy Schroder 2015-02-23 9:13 ` Natanael ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Andy Schroder @ 2015-02-23 7:36 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 7:36 ` Andy Schroder @ 2015-02-23 9:13 ` Natanael 2015-02-23 9:40 ` Eric Voskuil 2015-02-23 9:49 ` Andreas Schildbach 2 siblings, 0 replies; 45+ messages in thread From: Natanael @ 2015-02-23 9:13 UTC (permalink / raw) To: Andy Schroder; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 7:36 ` Andy Schroder 2015-02-23 9:13 ` Natanael @ 2015-02-23 9:40 ` Eric Voskuil 2015-02-24 2:55 ` Eric Voskuil 2015-02-23 9:49 ` Andreas Schildbach 2 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-23 9:40 UTC (permalink / raw) To: Andy Schroder, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 9:40 ` Eric Voskuil @ 2015-02-24 2:55 ` Eric Voskuil 2015-02-24 5:53 ` Andy Schroder 0 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-24 2:55 UTC (permalink / raw) To: Andy Schroder, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 2:55 ` Eric Voskuil @ 2015-02-24 5:53 ` Andy Schroder 2015-02-24 11:28 ` Eric Voskuil 0 siblings, 1 reply; 45+ messages in thread From: Andy Schroder @ 2015-02-24 5:53 UTC (permalink / raw) To: Eric Voskuil, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 5:53 ` Andy Schroder @ 2015-02-24 11:28 ` Eric Voskuil 2015-02-24 19:49 ` Andy Schroder 0 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-24 11:28 UTC (permalink / raw) To: Andy Schroder, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 11:28 ` Eric Voskuil @ 2015-02-24 19:49 ` Andy Schroder 2015-02-24 22:14 ` Eric Voskuil 0 siblings, 1 reply; 45+ messages in thread From: Andy Schroder @ 2015-02-24 19:49 UTC (permalink / raw) To: Eric Voskuil, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 19:49 ` Andy Schroder @ 2015-02-24 22:14 ` Eric Voskuil 2015-02-24 22:50 ` Andy Schroder 0 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-24 22:14 UTC (permalink / raw) To: Andy Schroder, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 22:14 ` Eric Voskuil @ 2015-02-24 22:50 ` Andy Schroder 2015-02-25 2:09 ` Eric Voskuil 0 siblings, 1 reply; 45+ messages in thread From: Andy Schroder @ 2015-02-24 22:50 UTC (permalink / raw) To: Eric Voskuil, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 22:50 ` Andy Schroder @ 2015-02-25 2:09 ` Eric Voskuil 2015-02-28 9:46 ` Andy Schroder 0 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-25 2:09 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-25 2:09 ` Eric Voskuil @ 2015-02-28 9:46 ` Andy Schroder 0 siblings, 0 replies; 45+ messages in thread From: Andy Schroder @ 2015-02-28 9:46 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 7:36 ` Andy Schroder 2015-02-23 9:13 ` Natanael 2015-02-23 9:40 ` Eric Voskuil @ 2015-02-23 9:49 ` Andreas Schildbach 2015-02-23 10:08 ` Eric Voskuil 2 siblings, 1 reply; 45+ messages in thread From: Andreas Schildbach @ 2015-02-23 9:49 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 9:49 ` Andreas Schildbach @ 2015-02-23 10:08 ` Eric Voskuil 2015-02-23 10:58 ` Mike Hearn 0 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-23 10:08 UTC (permalink / raw) To: Andreas Schildbach, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 10:08 ` Eric Voskuil @ 2015-02-23 10:58 ` Mike Hearn 2015-02-23 11:58 ` Andreas Schildbach 2015-02-23 23:00 ` Eric Voskuil 0 siblings, 2 replies; 45+ messages in thread From: Mike Hearn @ 2015-02-23 10:58 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 10:58 ` Mike Hearn @ 2015-02-23 11:58 ` Andreas Schildbach 2015-02-23 12:18 ` Mike Hearn 2015-02-23 23:00 ` Eric Voskuil 1 sibling, 1 reply; 45+ messages in thread From: Andreas Schildbach @ 2015-02-23 11:58 UTC (permalink / raw) To: bitcoin-development 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 11:58 ` Andreas Schildbach @ 2015-02-23 12:18 ` Mike Hearn 2015-02-23 12:30 ` Andreas Schildbach 0 siblings, 1 reply; 45+ messages in thread From: Mike Hearn @ 2015-02-23 12:18 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 12:18 ` Mike Hearn @ 2015-02-23 12:30 ` Andreas Schildbach 0 siblings, 0 replies; 45+ messages in thread From: Andreas Schildbach @ 2015-02-23 12:30 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 10:58 ` Mike Hearn 2015-02-23 11:58 ` Andreas Schildbach @ 2015-02-23 23:00 ` Eric Voskuil 2015-02-23 23:11 ` Mike Hearn 1 sibling, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-23 23:00 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 23:00 ` Eric Voskuil @ 2015-02-23 23:11 ` Mike Hearn 2015-02-24 0:10 ` Eric Voskuil 0 siblings, 1 reply; 45+ messages in thread From: Mike Hearn @ 2015-02-23 23:11 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 23:11 ` Mike Hearn @ 2015-02-24 0:10 ` Eric Voskuil 2015-02-24 10:41 ` Mike Hearn 0 siblings, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-24 0:10 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 0:10 ` Eric Voskuil @ 2015-02-24 10:41 ` Mike Hearn 2015-02-26 12:30 ` Andreas Schildbach 0 siblings, 1 reply; 45+ messages in thread From: Mike Hearn @ 2015-02-24 10:41 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Dev, Andreas Schildbach [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 10:41 ` Mike Hearn @ 2015-02-26 12:30 ` Andreas Schildbach 2015-03-03 0:54 ` Eric Voskuil 0 siblings, 1 reply; 45+ messages in thread From: Andreas Schildbach @ 2015-02-26 12:30 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-26 12:30 ` Andreas Schildbach @ 2015-03-03 0:54 ` Eric Voskuil 0 siblings, 0 replies; 45+ messages in thread From: Eric Voskuil @ 2015-03-03 0:54 UTC (permalink / raw) To: Andreas Schildbach, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 22:37 ` Andy Schroder 2015-02-22 23:06 ` Eric Voskuil @ 2015-02-23 0:58 ` Andreas Schildbach 2015-02-23 15:09 ` Jan Vornberger 2 siblings, 0 replies; 45+ messages in thread From: Andreas Schildbach @ 2015-02-23 0:58 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 22:37 ` Andy Schroder 2015-02-22 23:06 ` Eric Voskuil 2015-02-23 0:58 ` Andreas Schildbach @ 2015-02-23 15:09 ` Jan Vornberger 2015-02-23 16:59 ` Mike Hearn ` (2 more replies) 2 siblings, 3 replies; 45+ messages in thread From: Jan Vornberger @ 2015-02-23 15:09 UTC (permalink / raw) To: Andy Schroder; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 15:09 ` Jan Vornberger @ 2015-02-23 16:59 ` Mike Hearn 2015-02-23 19:56 ` Jan Vornberger 2015-02-24 6:14 ` Andy Schroder 2015-02-26 12:37 ` Andreas Schildbach 2 siblings, 1 reply; 45+ messages in thread From: Mike Hearn @ 2015-02-23 16:59 UTC (permalink / raw) To: Jan Vornberger; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 16:59 ` Mike Hearn @ 2015-02-23 19:56 ` Jan Vornberger 2015-02-23 20:31 ` Mike Hearn 0 siblings, 1 reply; 45+ messages in thread From: Jan Vornberger @ 2015-02-23 19:56 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 19:56 ` Jan Vornberger @ 2015-02-23 20:31 ` Mike Hearn 0 siblings, 0 replies; 45+ messages in thread From: Mike Hearn @ 2015-02-23 20:31 UTC (permalink / raw) To: Jan Vornberger; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 15:09 ` Jan Vornberger 2015-02-23 16:59 ` Mike Hearn @ 2015-02-24 6:14 ` Andy Schroder 2015-02-24 15:41 ` Jan Vornberger 2015-02-26 12:37 ` Andreas Schildbach 2 siblings, 1 reply; 45+ messages in thread From: Andy Schroder @ 2015-02-24 6:14 UTC (permalink / raw) To: Jan Vornberger; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-24 6:14 ` Andy Schroder @ 2015-02-24 15:41 ` Jan Vornberger 0 siblings, 0 replies; 45+ messages in thread From: Jan Vornberger @ 2015-02-24 15:41 UTC (permalink / raw) To: Andy Schroder; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 15:09 ` Jan Vornberger 2015-02-23 16:59 ` Mike Hearn 2015-02-24 6:14 ` Andy Schroder @ 2015-02-26 12:37 ` Andreas Schildbach 2 siblings, 0 replies; 45+ messages in thread From: Andreas Schildbach @ 2015-02-26 12:37 UTC (permalink / raw) To: bitcoin-development 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... )-: ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 19:08 [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback Jan Vornberger 2015-02-22 22:37 ` Andy Schroder @ 2015-02-22 22:39 ` Eric Voskuil 2015-02-22 22:48 ` Eric Voskuil 2015-02-23 1:05 ` Andreas Schildbach 2015-02-23 0:48 ` Andreas Schildbach 2 siblings, 2 replies; 45+ messages in thread From: Eric Voskuil @ 2015-02-22 22:39 UTC (permalink / raw) To: Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 22:39 ` Eric Voskuil @ 2015-02-22 22:48 ` Eric Voskuil 2015-02-22 23:35 ` Andy Schroder 2015-02-23 1:05 ` Andreas Schildbach 1 sibling, 1 reply; 45+ messages in thread From: Eric Voskuil @ 2015-02-22 22:48 UTC (permalink / raw) To: Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 22:48 ` Eric Voskuil @ 2015-02-22 23:35 ` Andy Schroder 2015-02-23 0:46 ` Eric Voskuil 0 siblings, 1 reply; 45+ messages in thread From: Andy Schroder @ 2015-02-22 23:35 UTC (permalink / raw) To: Eric Voskuil, Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 23:35 ` Andy Schroder @ 2015-02-23 0:46 ` Eric Voskuil 0 siblings, 0 replies; 45+ messages in thread From: Eric Voskuil @ 2015-02-23 0:46 UTC (permalink / raw) To: Andy Schroder, Jan Vornberger, bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 22:39 ` Eric Voskuil 2015-02-22 22:48 ` Eric Voskuil @ 2015-02-23 1:05 ` Andreas Schildbach 2015-02-23 1:55 ` Aaron Voisine 1 sibling, 1 reply; 45+ messages in thread From: Andreas Schildbach @ 2015-02-23 1:05 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-23 1:05 ` Andreas Schildbach @ 2015-02-23 1:55 ` Aaron Voisine 0 siblings, 0 replies; 45+ messages in thread From: Aaron Voisine @ 2015-02-23 1:55 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Development [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback 2015-02-22 19:08 [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback Jan Vornberger 2015-02-22 22:37 ` Andy Schroder 2015-02-22 22:39 ` Eric Voskuil @ 2015-02-23 0:48 ` Andreas Schildbach 2 siblings, 0 replies; 45+ messages in thread From: Andreas Schildbach @ 2015-02-23 0:48 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
[parent not found: <54ED2F34.8090704@voskuil.org>]
[parent not found: <54ED3150.4020800@AndySchroder.com>]
[parent not found: <54ED7D8B.5070903@schildbach.de>]
* Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback [not found] ` <54ED7D8B.5070903@schildbach.de> @ 2015-02-25 9:20 ` Eric Voskuil 0 siblings, 0 replies; 45+ messages in thread From: Eric Voskuil @ 2015-02-25 9:20 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2015-03-03 0:54 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-22 19:08 [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback Jan Vornberger
2015-02-22 22:37 ` Andy Schroder
2015-02-22 23:06 ` Eric Voskuil
2015-02-22 23:32 ` Andy Schroder
2015-02-23 0:05 ` Eric Voskuil
2015-02-23 1:02 ` Andreas Schildbach
2015-02-23 7:36 ` Andy Schroder
2015-02-23 9:13 ` Natanael
2015-02-23 9:40 ` Eric Voskuil
2015-02-24 2:55 ` Eric Voskuil
2015-02-24 5:53 ` Andy Schroder
2015-02-24 11:28 ` Eric Voskuil
2015-02-24 19:49 ` Andy Schroder
2015-02-24 22:14 ` Eric Voskuil
2015-02-24 22:50 ` Andy Schroder
2015-02-25 2:09 ` Eric Voskuil
2015-02-28 9:46 ` Andy Schroder
2015-02-23 9:49 ` Andreas Schildbach
2015-02-23 10:08 ` Eric Voskuil
2015-02-23 10:58 ` Mike Hearn
2015-02-23 11:58 ` Andreas Schildbach
2015-02-23 12:18 ` Mike Hearn
2015-02-23 12:30 ` Andreas Schildbach
2015-02-23 23:00 ` Eric Voskuil
2015-02-23 23:11 ` Mike Hearn
2015-02-24 0:10 ` Eric Voskuil
2015-02-24 10:41 ` Mike Hearn
2015-02-26 12:30 ` Andreas Schildbach
2015-03-03 0:54 ` Eric Voskuil
2015-02-23 0:58 ` Andreas Schildbach
2015-02-23 15:09 ` Jan Vornberger
2015-02-23 16:59 ` Mike Hearn
2015-02-23 19:56 ` Jan Vornberger
2015-02-23 20:31 ` Mike Hearn
2015-02-24 6:14 ` Andy Schroder
2015-02-24 15:41 ` Jan Vornberger
2015-02-26 12:37 ` Andreas Schildbach
2015-02-22 22:39 ` Eric Voskuil
2015-02-22 22:48 ` Eric Voskuil
2015-02-22 23:35 ` Andy Schroder
2015-02-23 0:46 ` Eric Voskuil
2015-02-23 1:05 ` Andreas Schildbach
2015-02-23 1:55 ` Aaron Voisine
2015-02-23 0:48 ` Andreas Schildbach
[not found] <54ED2F34.8090704@voskuil.org>
[not found] ` <54ED3150.4020800@AndySchroder.com>
[not found] ` <54ED7D8B.5070903@schildbach.de>
2015-02-25 9:20 ` Eric Voskuil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox