Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 signature.asc Description: OpenPGP digital signature -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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:macs=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 macs. 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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... )-: -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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=macs=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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
We can change resource to Session ID if you want. I think the URL scheme should be: bitcoin:[address]?r=bt:macs=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=macs=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 signature.asc Description: OpenPGP digital signature -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
The list appears dead, this is a test. e signature.asc Description: OpenPGP digital signature -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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:macs=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 macs. 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=macs=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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 :) -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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? -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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? -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 :( -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 :) signature.asc Description: OpenPGP digital signature -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Den 23 feb 2015 08:38 skrev Andy Schroder i...@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/ -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 signature.asc Description: OpenPGP digital signature -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 signature.asc Description: OpenPGP digital signature -- 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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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. -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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.
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 -- 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=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
