Re: [Bitcoin-development] Proposal to address Bitcoin malware
On Feb 2, 2015, at 11:53 AM, Mike Hearn m...@plan99.net wrote: In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it matches what they input to the first factor. Ideally, using BIP70, but I don't know if BA actually uses that currently. It's the same model as the TREZOR, except with a desktop app instead of myTREZOR and a phone instead of a dedicated hardware device. Sorry for the slow reply, traveling. My comments were made in reference to this proposal: On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com wrote: Another concept... It should be possible to use multisig wallets to protect against malware. For example, a user could generate a wallet with 3 keys and require a transaction that has been signed by 2 of those keys. One key is placed in cold storage and anther sent to a third-party. It is now possible to generate and sign transactions on the users computer and send this signed transaction to the third-party for the second signature. This now permits the use of out of band transaction verification techniques before the third party signs the transaction and sends to the blockchain. If the third-party is malicious or becomes compromised they would not have the ability to complete transactions as they only have one private key. If the third-party disappeared, the user could use the key in cold storage to sign transactions and send funds to a new wallet. Thoughts? In the multisig scenario the presumption is of a user platform compromised by malware. It envisions a user signing a 2 of 3 output with a first signature. The precondition that the platform is compromised implies that this process results in a loss of integrity of the private key, and as such if it were not for the second signature requirement, the malware would be able to spend the output. This may be extended to all of the keys in the wallet. The scenario envisions sending the signed transaction to an another (third) party. The objective is for the third party to provide the second signature, thereby spending the output as intended by the user, who is not necessarily the first signer. The send must be authenticated to the user. Otherwise the third party would have to sign anything it received, obviously rendering the second signature pointless. This implies that the compromised platform must transmit a secret, or proof of a secret, to the third party. The problem is that the two secrets are not independent if the first platform is compromised. So of course the malware has the ability to sign, impersonate the user and send to the third party. So the third party *must* send the transaction to an *independent* platform for verification by the user, and obtain consent before adding the second signature. The user, upon receiving the transaction details, must be able to verify, on the independent platform, that the details match those of the transaction that user presumably signed. Even for simple transactions this must include amount, address and fees. The central assumptions are that, while the second user platform may be compromised, the attack against the second platform is not coordinated with that of the first, nor is the third party in collusion with the first platform. Upon these assumptions rests the actual security benefit (increased difficulty of the coordinated attack). The strength of these assumptions is an interesting question, since it is hard to quantify. But without independence the entire security model is destroyed and there is thus no protection whatsoever against malware. So for example a web-based or other third-party-provisioned implementation of the first platform breaks the anti-collusion assumption. Also, weak comsec allows an attack against the second platform to be carried out against its network. So for example a simple SMS-based confirmation could be executed by the first platform alone and thereby also break the the anti-collusion assumption. This is why I asked how independence is maintained. The assumption of a hardware wallet scenario is that the device itself is not compromised. So the scenario is not the same. If the user signs with a hardware wallet, nothing can collude with that process, with one caveat. While a hardware wallet is not subject to onboard malware, it is not inconceivable that its keys could be extracted through probing or other direct attack against the hardware. It's nevertheless an assumption of hardware wallets that these attacks require loss of the hardware. Physical possession constitutes compromise. So the collusion model with a hardware wallet does exist, it just requires device possession. Depending on the implementation the extraction
Re: [Bitcoin-development] Proposal to address Bitcoin malware
One clarification below. e On 02/02/2015 02:54 PM, Eric Voskuil wrote: On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote: In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it matches what they input to the first factor. Ideally, using BIP70, but I don't know if BA actually uses that currently. It's the same model as the TREZOR, except with a desktop app instead of myTREZOR and a phone instead of a dedicated hardware device. Sorry for the slow reply, traveling. My comments were made in reference to this proposal: On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com mailto:brian.erde...@gmail.com wrote: Another concept... It should be possible to use multisig wallets to protect against malware. For example, a user could generate a wallet with 3 keys and require a transaction that has been signed by 2 of those keys. One key is placed in cold storage and anther sent to a third-party. It is now possible to generate and sign transactions on the users computer and send this signed transaction to the third-party for the second signature. This now permits the use of out of band transaction verification techniques before the third party signs the transaction and sends to the blockchain. If the third-party is malicious or becomes compromised they would not have the ability to complete transactions as they only have one private key. If the third-party disappeared, the user could use the key in cold storage to sign transactions and send funds to a new wallet. Thoughts? My comments below start out with the presumption of user platform compromise, but the same analysis holds for the case where the user platform is clean but a web wallet is compromised. Obviously the idea is that either or both may be compromised, but integrity is retained as long as both are not compromised and in collusion. In the multisig scenario the presumption is of a user platform compromised by malware. It envisions a user signing a 2 of 3 output with a first signature. The precondition that the platform is compromised implies that this process results in a loss of integrity of the private key, and as such if it were not for the second signature requirement, the malware would be able to spend the output. This may be extended to all of the keys in the wallet. The scenario envisions sending the signed transaction to an another (third) party. The objective is for the third party to provide the second signature, thereby spending the output as intended by the user, who is not necessarily the first signer. The send must be authenticated to the user. Otherwise the third party would have to sign anything it received, obviously rendering the second signature pointless. This implies that the compromised platform must transmit a secret, or proof of a secret, to the third party. The problem is that the two secrets are not independent if the first platform is compromised. So of course the malware has the ability to sign, impersonate the user and send to the third party. So the third party *must* send the transaction to an *independent* platform for verification by the user, and obtain consent before adding the second signature. The user, upon receiving the transaction details, must be able to verify, on the independent platform, that the details match those of the transaction that user presumably signed. Even for simple transactions this must include amount, address and fees. The central assumptions are that, while the second user platform may be compromised, the attack against the second platform is not coordinated with that of the first, nor is the third party in collusion with the first platform. Upon these assumptions rests the actual security benefit (increased difficulty of the coordinated attack). The strength of these assumptions is an interesting question, since it is hard to quantify. But without independence the entire security model is destroyed and there is thus no protection whatsoever against malware. So for example a web-based or other third-party-provisioned implementation of the first platform breaks the anti-collusion assumption. Also, weak comsec allows an attack against the second platform to be carried out against its network. So for example a simple SMS-based confirmation could be executed by the first platform alone and thereby also break the the anti-collusion assumption. This is why I asked how independence is maintained. The assumption of a hardware wallet scenario is that the device itself is not compromised. So the scenario is not the same. If the user signs with a hardware wallet, nothing can collude with that process, with one caveat. While a hardware wallet is not subject
Re: [Bitcoin-development] Proposal to address Bitcoin malware
On 02/02/2015 11:58 AM, Brian Erdelyi wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. No, that's not it. Sorry for not being clear. Independence of control is the central issue in the analysis of a multiple factor system. If an attack compromises one factor there must be no way for that attack to reduce the difficulty of obtaining the other factors. Some factors (secrets), like a fingerprint, aren't very secret at all. But getting someone's fingerprint doesn't also help the attacker get a PIN. That factor must be attacked independently. But if the PIN is encrypted with the fingerprint in a public store, then the PIN is not independent of the fingerprint and there is really only one secret. If multiple factors are coincident (located within the same security perimeter) they are compromized coincidentally. Coincidence has the same effect as dependence. Consider a credit card with a security code printed on the back. A successful attack on the leather wallet yields both secrets. Individual environments can be compromised with some difficulty (e.g. desktop malware, fingerprint lift, dictionary attack, brute force PIN, etc.). For the sake of simplicity, let that chance of successful independent attack on any factor be 1 in 2 and the resulting probability of successful concurrent attack on any n factors be 1 in 2^n. If m factors are dependent/coincident on others the relation becomes 1 in 2^(n-m). Any multi-factor web wallet that handles the user's keys in the browser and authenticates the user in the browser to authorize service signing is effectively single factor. One attack may be launched by an insider, or externally, against the web app, executing in the browser, gaining coincident access to two secrets. Browser/desktop malware can accomplish the same. The difficulty is 1 in 2 vs. the expected 1 in 4. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. I'm not questioning the motive, I agree it's worth trying. But trying is not succeeding. Increasing user (and/or system) complexity without increasing integrity or privacy is a poor trade, and worse if the user is misled. 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] Proposal to address Bitcoin malware
In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Sent from my iPhone On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com wrote: Another concept... It should be possible to use multisig wallets to protect against malware. For example, a user could generate a wallet with 3 keys and require a transaction that has been signed by 2 of those keys. One key is placed in cold storage and anther sent to a third-party. It is now possible to generate and sign transactions on the users computer and send this signed transaction to the third-party for the second signature. This now permits the use of out of band transaction verification techniques before the third party signs the transaction and sends to the blockchain. If the third-party is malicious or becomes compromised they would not have the ability to complete transactions as they only have one private key. If the third-party disappeared, the user could use the key in cold storage to sign transactions and send funds to a new wallet. Thoughts? -- 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 -- 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] Proposal to address Bitcoin malware
Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. On Feb 2, 2015, at 11:35 AM, Brian Erdelyi brian.erde...@gmail.com wrote: Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android on mobile. It could be adapted to use BitGo as a third party key holder with SMS authenticator relatively easily, I think. We did the bulk of all the needed work last year as part of the bitcoinj multisig work. Then you'd have a server involved, but not a web app. I really like the concept of Bitcoin Authenticator and think it’s exactly what I was describing (without a third-party). I think it’s a bit confusing when they describe Bitcoin Authenticator as 2FA. I think it may be more accurate to describe it as out of band transaction verification/signing or dual transaction signing. Regardless, it’s very exciting to see others are thinking about this too. Brian Erdelyi -- 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 -- 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 12:28 PM, Mike Hearn wrote: The donation to live performer example is good - there's no issue of accidentally paying for someone else in this context as there's only one recipient, but many senders. I'm not sure you could assume this, even if the payer only received one broadcast. And if the payer receives multiple, it constitutes a DOS on the scenario, potentially unintentional. The issue of confused payments remains in other situations though. Agree, the problem of the payer strongly identifying the receiver requires either proximity (NFC or QR code scan from the known-good source) or PKI/WoT. The problem can't be resolved through a broadcast. For the coffee shop use case, it'd be nicer (I think) if we aim for a Square-style UI where the device broadcasts a (link to) a photo of the user combined with a bluetooth MAC. Then the merchant tablet can show faces of people in the shop, and can push a payment request to the users device. That device can then buzz the user, show a confirmation screen, put something on their smart watch etc or just auto-authorise the payment because the BIP70 signature is from a trusted merchant. User never even needs to touch their phone at all. I'm imagining myself walking around broadcasting my photo and MAC address while hucksters push payment requests to me for approval, while recording my photo and correlating it to my address. It will pretty quickly turn in to a scenario where I need to touch something before this is turned on. On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey p...@airbitz.co mailto:p...@airbitz.co wrote: The BIP70 protocol would preclude individuals from utilizing the P2P transfer spec. It would also require that a Sender have internet connectivity to get the payment protocol info. BLE could enable payment w/o internet by first transferring the URI to from Recipient to Sender. Then in the future, we could sign a Tx and send it over BLE back to the recipient (who would still need internet to verify the Tx). This is an important use case for areas with poor 3G/4G connectivity as I've experience myself. Also, due to Android issues, NFC is incredibly clunky. The URI Sender is required to tap the screen *while* the two phones are in contact. We support NFC the same way Bitcoin Wallet does, but unless the payment recipient has a custom Android device (which a merchant might) then the usage model is worse than scanning a QR code. BLE also allows people to pay at a distance such as for a donation to a live performer. We'll look at adding this to the Motivation section. From: Andreas Schildbach andreas@sc... - 2015-02-05 13:47:04 Thanks Paul, for writing up your protocol! First thoughts: For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. URIs mainly stick around because of QR codes limited capacity. BIP70 would partly address the copycat problem by signing payment requests. In your Motivation section, I miss some words about NFC. NFC already addresses all of the usability issues mentioned and is supported by mobile wallets since 2011. That doesn't mean your method doesn't make sense in some situations, but I think it should be explained why to prefer broadcasting payment requests over picking them up via near field radio. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Yes, a stellar device for mass surveillance coupled with transaction tainting. e On Feb 5, 2015, at 1:19 PM, Brian Hoffman brianchoff...@gmail.com wrote: This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. Yes you could photograph people but it's way more burdensome. Sorry to go off topic a little. On Feb 5, 2015, at 3:50 PM, Mike Hearn m...@plan99.net wrote: I'm imagining myself walking around broadcasting my photo and MAC address while hucksters push payment requests to me for approval I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;) Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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 -- 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 12:50 PM, Mike Hearn wrote: I'm imagining myself walking around broadcasting my photo and MAC address while hucksters push payment requests to me for approval I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;) Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Interesting take on privacy. But the market will of course decide. Would the merchant be broadcasting payment requests in the clear, or would they be encrypted with a public key of the spender? Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. Not sure I'd shoot for a system that's guaranteed to require PKI with blacklisting and spam filtering. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
BLE has an advertised range of over 100m. http://www.bluetooth.com/Pages/low-energy-tech-info.aspx In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver. WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net wrote: This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Hi Paul, The issue is in the establishment of trust. Anyone can broadcast the initial information. e On Feb 5, 2015, at 2:01 PM, Paul Puey p...@airbitz.co wrote: The broadcast is ONLY done when the wallet is in Receive mode. Same as when the QR code is visible. The use of the *Name* section is specifically so that a recipient can broadcast their name/handle. Not so the recipient would broadcast the name of the Sender. On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn m...@plan99.net wrote: I'm imagining myself walking around broadcasting my photo and MAC address while hucksters push payment requests to me for approval I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;) Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. e On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co wrote: So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? If so, I send it. If there are two Monkey Dude's Then I have to bother with the address prefix, but not otherwise. On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil e...@voskuil.org wrote: BLE has an advertised range of over 100m. http://www.bluetooth.com/Pages/low-energy-tech-info.aspx In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver. WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net wrote: This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 02:08 PM, Paul Puey wrote: Although not perfect, and it may require visual/verbal verification, I don't see what the trust issue is. I agree that with manual verification between the parties the worst problem becomes DOS, which is certainly not catastrophic. But the objective is to the extent possible improve upon the cumbersome process of QR code, NFC signal, or textual address scanning. Given that there would be no way to know you are under attack, with the exception of manual confirmation, it would seem unwise to ever rely on the automation. If the automation cannot be relied upon, it may actually make matters worse. People would either take their chances by relying on it or go through a more complex process. In terms of the difficulty of an attack, it's important to recognize that all attacks (DOS, privacy, integrity) in this scenario can be fully-automated and executed over the air by a black box at some distance: * DOS is possible by rebroadcasting a similar request. * Privacy is compromised by monitoring for payment requests and correlating them to location and potentially images of parties. * Integrity is compromised by either: (1) Rebroadcasting a similar transaction with a bogus address but with the same leading characters; can't be spent but you lose your money. (2) Rebroadcasting with a valid address that doesn't match the leading characters, in the expectation that the user doesn't check manually. Regarding possible mitigation via BIP-70: A BIP-70 signed payment request in the initial broadcast can resolve the integrity issues, but because of the public nature of the broadcast coupled with strong public identity, the privacy compromise is much worse. Now transactions are cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. So the initial broadcast needs privacy, but then of course it cannot be a broadcast - it need to be a narrow cast. That brings us back to proximity-based establishment. I think that you could get away with this for a while, simply because of the narrow fields we are working in presently. But in a bitcoin world it would be very problematic. For this reason I wouldn't want to encourage standardization on this approach. e On 02/05/2015 02:10 PM, Eric Voskuil wrote: A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. e On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co mailto:p...@airbitz.co wrote: So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? If so, I send it. If there are two Monkey Dude's Then I have to bother with the address prefix, but not otherwise. On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil e...@voskuil.org mailto:e...@voskuil.org wrote: BLE has an advertised range of over 100m. http://www.bluetooth.com/Pages/low-energy-tech-info.aspx In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver. WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote: A BIP-70 signed payment request in the initial broadcast can resolve the integrity issues, but because of the public nature of the broadcast coupled with strong public identity, the privacy compromise is much worse. Now transactions are cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 03:34 PM, Roy Badami wrote: For peer-to-peer payments, how common do we think that the payment is of an ad hoc nature rather than to a known contact? If I want to pay my friends/colleagues/etc over a restaurant table there's no reason why I couldn't already have their public keys in my contact list - then it would be pretty straightforward to have a watertight mechanism where I would know who I was paying. You could probably even relatively securely bootstrap a key exchange over SMS, relying only on the contacts already having each other in their phonebooks. In this case there is no need for P2P communication, just pay to an address you already have for the other party. If you want to avoid address reuse, use stealth addressing. But yes, if you don't have a stealth address for the other party you can certainly communicate in private as peers where you trust that you share a public key. The core issue here is really bootstrapping of that trust in an ad hoc manner. As for comsumer-to-merchant transactions where the merchant is a bricks and mortar merchant, IMHO it absolutely has to be pay that terminal over there. It's the trust model we all currently use - whether paying cash or card - and it's the only trust model that works IMHO (and customers and businesses alike are well aware of the risks of a fraudster standing behind the counter pretending to be an employee accepting payment - and by and large are pretty good at mitigating it). OTOH as we've discussed here before there are many use cases where the custoemr doesn't actually know or care about the name of the shop or bar they walked into but is pretty damn sure that they need to make payment to the person over there behind the counter. Yes, proximity is practically the universal solution to the problem of the payer identifying the correct seller in any face-to-face scenario. Granted, there are cases taht dont' fall into either of the above - but they're the cases that are (a) harder to figure out how to authenticate and consequently (b) the use cases that are going to be most subject to attempted fraud. When identification is required (show me some id before I pay you) it equates to the BIP-70 scenario in the bitcoin model. This is also required in order guard against repudiation (give me a signed receipt). On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote: On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil e...@voskuil.org wrote: A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. You are right, of course. There is no way to make Bluetooth 100% secure, since it is an over-the-air technology. You could try securing it using a CA or other identity server, but now you've excluded ad-hoc person-to-person payments. Plus, you need an active internet connection to reach the CA. You can try using proximity as a substitute for identity, like requiring NFC to kick-start the connection, but at that point you might as well use QR codes. This BIP is not trying to provide absolute bullet-proof security, since that's impossible given the physical limitations of the Bluetooth technology. Instead, it's trying to provide the best-possible security given those constraints. In exchange for this, we get greatly enhanced usability in common scenarios. There are plenty of usable, real-world technologies with big security holes. Anybody with lock-picking experience will tell you this, but nobody is welding their front door shut. The ability to go in and out is worth the security risk. Bluetooth payments add a whole new dimension to real-world Bitcoin usability. Do we shut that down because it can't be made perfect, or do we do the best we can and move forward? -William -- 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 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
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote: That's exactly what I though when seeing the RedPhone code, but after I studied the commit protocol I realized it's actually secure and convenient way to do it. You should do that too. :) I was analyzing the model as you described it to me. A formal analysis of the security model of a particular implementation, based on inference from source code, is a bit beyond what I signed up for. But I'm perfectly willing to comment on your description of the model if you are willing to indulge me. Shortly, how it works: The initiator of the connection sends commit message containing the hash of his temporary public ECDH part, second party sends back their public ECDH part and then initiator sends his public ECDH part in open. All three messages are hashed together and the first two bytes are used to select two words from a shared dictionary which are displayed on the screen of both the initiator and the second party. The parties communicate those two words and verify they match. How do they compare words if they haven't yet established a secure channel? If an attacker wants to do MITM, he has a chance of choosing right public parts 1:65536. There is no way to brute-force it, since that would be noticed immediately. If instead of two words based on the first two bytes, four words from BIP39 wordlist were chosen, it would provide entropy of 44 bits which I believe should be enough even for paranoid people. How this would work in Bitcoin payment scenario: user's phone broadcasts his name, merchant inputs amount and selects the name from the list, commit message is sent (and then the remaining two messages), merchant spells four words he sees on the screen and buyer confirms transaction after verifying that words match. So the assumption is that there exists a secure (as in proximity-based) communication channel? e 2015-02-06 0:46 GMT+01:00 Eric Voskuil e...@voskuil.org: On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote: A BIP-70 signed payment request in the initial broadcast can resolve the integrity issues, but because of the public nature of the broadcast coupled with strong public identity, the privacy compromise is much worse. Now transactions are cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
Hi Andy, This is good stuff. I've spent quite a bit of time on this question, but set aside most of it earlier in the year in order to make some progress in other areas. I did review what I found available at the time pertaining to the Schildbach implementation and these questions. Skimming the links now I'm encouraged, but I see several things that I'd like to discuss at greater length than is appropriate here. The main advantage of BLE over BT is that it uses much less power, with a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can be even greater and connection latency lower than BT. For payment purposes the lower bandwidth isn't much of a hit. e On 02/05/2015 03:38 PM, Andy Schroder wrote: Hello, With the recent discussion started today regarding another bluetooth communication proposal created by Airbitz, I'd like to bring people's attention back to this proposal that saw little discussion last fall. I guess I'm not sure why two proposals are being created. Is their some advantage of using bluetooth low energy over standard bluetooth (I'm not well versed in bluetooth low energy)? This NFC coupled approach seems to avoid a lot of issues with identifying the correct payee. You can see this proposed scheme demonstrated in action in a POS application in the video link below which demonstrates it with my fuel pump and Andreas Schildbach's wallet. There was a small discussion that occurred after my original announcement below. If you are new to this e-mail list, you can find an archive of those few replies here: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html Since this original announcement, a few improvements have been made to the proposal: 1. Improved documentation and explanation of the use cases in Schildbach's wallet's wiki 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests 2. Issue with the payment_url field has resolved by changing to a repeated field and requiring the wallet to search for the protocol they want to use, rather than expecting it to be a certain element number in the list. 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki Although there are some interesting use cases of Airbitz's proposal's work flow, tapping an NFC radio with a 5 mm range requires much less brain power and time than picking the correct name on the app's screen. The manual name picking is going to be especially crazy in a very congested location. The payer isn't ever going to want to have to try and figure out what register or payment terminal they are at for most applications I would ever use. I'd like to see something happen with this technology. I've also noticed that micropayment channels have little formality to being established practically and it would be awesome if they could be managed over bluetooth as well. Maybe more improvements to the payment protocol can simultaneously result (and also extended to bluetooth) that embrace the establishment of micropayment channels. Andy Schroder On 10/17/2014 03:58 PM, Andy Schroder wrote: Hello, I'd like to introduce two proposed BIPs. They are primarily focused on implementing the payment protocol using bluetooth connections. I've been working on automated point of sale devices and bluetooth communication is critical in my mind due to the potential lack of internet access at many points of sale, either due to lack of cellular internet coverage, lack of payee providing wireless internet, and/or due to financial constraints of the payer prohibiting them from maintaining a cellular internet service plan. These BIPs are largely modeled after the current functionality of Andreas Schildbach's android Bitcoin Wallet's bluetooth capability. I've discussed the communication scheme with him in depth and believe these proposals to clearly and accurately represent the communication scheme. There is also an additional h= parameter added to the bitcoin: URI scheme which applies to both bluetooth and http payment protocol requests which allows for a hash of the payment request to be included. This hash was proposed by Andreas as an amendment to BIP72, but others preferred not to amend BIP72 since it has already been put into place. The current version of Schildbach's bitcoin wallet already supports the h parameter. I'd appreciate feedback from everyone, particularly wallet developers as widespread bluetooth support among wallets is very important to me. I'm also very new to this mailing list as well as the BIP writing process, so I'd appreciate your understanding if my conventions are not standard. I am currently using the naming conventions TBIP, so that I can propose /temporary/ BIP numbers, and cross reference between the two. Obviously these will change if the BIPs are formally adopted. You can find a copy of these proposed BIPs at the following links:
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 04:49 PM, Paul Puey wrote: The trust can be considered bootstrapped by visual verification of the address prefix. Another (unspendable) address can trivially match the prefix. Imagine someone walking around in a mall with a phone in the pocket with a malicious app, just disrupting business by causing money to be burned. Manual verification doesn't fix this attack. If we are really concerned about someone jamming a Bluetooth signal in a coffeeshop then the UI can encourage verification of the prefix. I don't think it would be great to constrain a standard implementation to low cost purchases or the need for manual verification, but again manual prefix verification isn't actually a solution. Much like how regular Bluetooth requires 'pairing' via entering a 4-6 digit code. An appeal to the security of BT bootstrapping isn't exactly flattering. You know I love Airbitz, and I know you guys are extremely privacy conscious. I personally would have no problem using this feature under certain circumstances. My question is only whether it would be wise to standardize on the proposal as-is. e On Feb 5, 2015, at 3:46 PM, Eric Voskuil e...@voskuil.org mailto:e...@voskuil.org wrote: On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote: A BIP-70 signed payment request in the initial broadcast can resolve the integrity issues, but because of the public nature of the broadcast coupled with strong public identity, the privacy compromise is much worse. Now transactions are cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 04:36 PM, Martin Habovštiak wrote: I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :) Notice from my original comment: A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). I said this could only be accomplished using a shared secret or a trusted public key. Exchanging a value that is derived from a pair of public keys is a distinction without a difference. The problem remains that the parties must have a secure/out-of-band channel for communicating this value. The fact that they are face-to-face establishes this channel, but that brings us back to the original problem, as it requires manual verification - as in visual/audible scanning of the two values for comparison. At that point the visual comparison of the address, or some value derived from it, is simpler. In case of RedPhone, you read those words verbally over not-yet- verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time. This is reasonable, but wouldn't help in the case of an ad-hoc connection between parties who don't know each other well. I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.) I appreciate the offer. I really don't trust *any* smartphone as a platform for secure communication/data. But encrypting on the wire does of course shrink the attack surface and increase the attacker's cost. e Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil e...@voskuil.org napísal: On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote: That's exactly what I though when seeing the RedPhone code, but after I studied the commit protocol I realized it's actually secure and convenient way to do it. You should do that too. :) I was analyzing the model as you described it to me. A formal analysis of the security model of a particular implementation, based on inference from source code, is a bit beyond what I signed up for. But I'm perfectly willing to comment on your description of the model if you are willing to indulge me. Shortly, how it works: The initiator of the connection sends commit message containing the hash of his temporary public ECDH part, second party sends back their public ECDH part and then initiator sends his public ECDH part in open. All three messages are hashed together and the first two bytes are used to select two words from a shared dictionary which are displayed on the screen of both the initiator and the second party. The parties communicate those two words and verify they match. How do they compare words if they haven't yet established a secure channel? If an attacker wants to do MITM, he has a chance of choosing right public parts 1:65536. There is no way to brute-force it, since that would be noticed immediately. If instead of two words based on the first two bytes, four words from BIP39 wordlist were chosen, it would provide entropy of 44 bits which I believe should be enough even for paranoid people. How this would work in Bitcoin payment scenario: user's phone broadcasts his name, merchant inputs amount and selects the name from the list, commit message is sent (and then the remaining two messages), merchant spells four words he sees on the screen and buyer confirms transaction after verifying that words match. So the assumption is that there exists a secure (as in proximity-based) communication channel? e 2015-02-06 0:46 GMT+01:00 Eric Voskuil e...@voskuil.org: On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote: A BIP-70 signed payment request in the initial broadcast can resolve the integrity issues, but because of the public nature of the broadcast coupled with strong public identity, the privacy compromise is much worse. Now transactions are cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
On 02/06/2015 12:40 AM, Andreas Schildbach wrote: On 02/06/2015 01:36 AM, Eric Voskuil wrote: The main advantage of BLE over BT is that it uses much less power, with a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can be even greater and connection latency lower than BT. For payment purposes the lower bandwidth isn't much of a hit. I'm all for extending the BT:mac scheme to Bluetooth LE. If you have ideas how this can be done please let us know. I haven't had a chance to play around with LE because none of my devices support it. I suspect the way how Bluetooth LE transfers files (like payment requests) is opening a plain old Bluetooth socket. If this is true, I'm afraid Bluetooth LE would not add anything for sending the BIP70 messages back and forth. Note signed payment requests can easily be 4 kB in size, so speed *does* matter. Hi Andreas, I haven't expressed any preference for BLE, just answering questions that were raised about it. The main thing that BLE brings to the table is increased battery life, but with larger transfers that benefit is reduced. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/06/2015 12:59 AM, Roy Badami wrote: In this case there is no need for P2P communication, just pay to an address you already have for the other party. If you want to avoid address reuse, use stealth addressing. But yes, if you don't have a stealth address for the other party you can certainly communicate in private as peers where you trust that you share a public key. The core issue here is really bootstrapping of that trust in an ad hoc manner. Something interactive might still be nicer, though, to avoid the risk of paying to an address that the payee no longer has the private key for. Nooo!! Don't pay to that address. I lost my old phone so I generated a new wallet. Certainly, which brings us back to proximity. Which reminds me - it's important to keep in mind the scenario that arises when there is no person present to represent the receiver. Such as a vending machine purchase. Proximity in these cases is insufficient, as the receiver is not able to prevent application of a fraudulent NFC device or replacement of a static QR code. In these cases BIP-70 becomes essential. 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
Agree, range is not an issue. The trade-off is in battery vs. total time, which would be influenced primarily by the battery sensitivity of the platform. I'll send you a note to follow up. e On 02/05/2015 05:40 PM, Andy Schroder wrote: Hello, I personally would prefer as low of range as possible for this bluetooth application considering the connection is not yet encrypted (mentioned below), and even if it were, it seems like it is always going to be better in case there is some vulnerability. From my testing with a bluetooth radio inside my metal cabinet, the range is ~5 meters, which is more than enough. However, the connection is actually a bit slow when the whole certificate chain is included (~3-4s). You can sort of see this in my video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is actually spent verifying the signature, and I'm not sure how much of it is doing the fetching (I haven't done any detailed timings using adb logcat and looking at the log entries), but I do know it is a little slower than an HTTPS payment request fetch over wifi (~2-3s). The reason I know most of the time is the signature verification is because an HTTPS payment request fetch over wifi and verification using breadwallet on apple is much faster (1s) than HTTPS payment request on bitcoin wallet on android (apparently apple has a significantly more optimized signature verification algorithm). Bottom line is that there may be ~1s time transferring the data with this current bluetooth connection. Not sure how slow it will be with the BLE connection. Time is everything in a point of sale application. So, I guess what I am saying is it seems like the lower speed and range gain with bluetooth low energy are not a benefit in my opinion. I'm not sure that the latency gain will be a benefit either unless the speed issues I am noticing with regular bluetooth are actually a latency issue with just getting the connection established, or actually transmitting the payment request data. How much power is going to be used for just a few second payment? It's not like the bluetooth connection is maintained for a long time like it may be in other non bitcoin use cases. Where is a more appropriate place to discuss the other issues you have at length? 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] Subject: Re: Proposal to address Bitcoin malware
On 02/03/2015 04:04 AM, Will wrote: An idea for the bitcoin malware proposal below, the idea is at the bottom… ... The trick we need to look at is how to use the bitcoin network as a delivery mechanism to bypass the need for the trusted third party in the example above. Using the Bitcoin network would be a convenience, certainly not a requirement. Any public store (or other channel accessible to all signers) would do. Instead of the second factor routing through a 3rd party to the intended recipient, we have another option - one that doesn’t require core development either. Absolutely, there is no need for a trusted third party in the case of MFA unless that party has independent judgement in the decision to sign. For example, if the third party is the trustee of a fund from which a beneficiary wants to withdraw. If you are just routing a decision back to yourself a third party makes no sense. Oddly most of the services in operation today are doing just that. You will end up authenticating to the third party from a platform you control, which means that the platform must be trusted as much as the third party. Why not just trust the platform and no third party? It doesn't reduce the number of factors but it certainly reduces the attack surface. 1) Sender signs signature 1 via desktop bitcoin network 2/3 P2SH 2) Mobile app also used by sender receives req. from bitcoin network to sign signature - not through the site in 1 (similar to the 2nd channel between the website and security company above) 3) Sender signs signature 2 via mobile app (or any separate device operating on a different network - heck could be radio) 2/3 signatures, transaction authorized There's no need for the devices to be on independent networks. You can safely remove that constraint. The partially-signed transaction can be encrypted to the other signatories (for privacy) or it can be sent in the clear. And ultimately all platforms in the scheme are connected to the Internet, even if it's via sneakernet. The important requirement is that the signing platforms are independent and that the signers inspect the transactions on those platforms. This preserves the benefit of MFA, which is that the signing platforms must be compromised independently. ... If there was a way to perform 2/3 multisig without requiring a second band, performing the function safely by somehow knowing if the service is performed from a compromised device through some sort of on-blockchain anti-malware check by validating the signature of the signing application by comparing it to a signature recorded when the multisig address was funded, that would be a really neat breakthrough. Food for thought, but I can’t see how that could be executed in a way where signatures couldn’t be spoofed from a compromised device. If someone cracks that problem, it’s a really big advance for information security. Once you've done this you are talking about two independent signing platforms. Plug two trustworthy signing devices into a PC and you've done it. This is because the host environment (the PC in this case) is not trusted in the first place. Two untrusted environments are no better than one. It's only if the environments are trusted that they must be independent. But therein lies the problem. The physical proximity of two trusted hardware devices exposes them to a single attack in the case of physical theft or loss. So to guard against that threat the devices must be independently stored. This presents a problem when it comes to usage. This is the central problem of MFA. It's not possible to control multiple factors while not exposing them to compromise. This is true whether we are talking about multiple physical devices or a remote service, since in the remote case the secret must still be accessible to the person in control. In the case of truly independent decisions MFA is strongest. But short of that there's no reason for a remote third party. One can probably accept the risk of securing multiple devices with the home, etc - and needs to do this even if using a third party. On the other hand, walking around with all necessary factors, or keeping them in the same safe, is tantamount to having just one factor. e On 02/02/2015 02:54 PM, Eric Voskuil wrote: On Feb 2, 2015, at 11:53 AM http://airmail.calendar/2015-02-02%2011:53:00%20MST, Mike Hearn wrote: In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it matches what they input to the first factor. Ideally, using BIP70, but I don't know if BA actually uses that currently. It's the same model as the TREZOR, except with a desktop app instead of myTREZOR and a phone instead of a dedicated hardware device. Sorry
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Martin, I like your idea for the commit protocol in that it resolves the vandalous address substitution attack. However, I don't see a way to prevent privacy loss without adverse impact to the scenario. Anyone could perform the handshake and thereby obtain the payment request. Therefore to prevent inadvertent disclosure the customer must visually confirm the phrase and then verbally tell the merchant to proceed by sending the payment request. One might argue that it's sufficient to preserve the integrity of the transaction while suffering the privacy loss, especially given that a hijacked handshake should never result in a completed transaction - unless of course the hijacker pays. But imagine someone purchasing their meds. HIPAA requires the checkout queue to form behind a yellow line. That speaks directly to this question. e On 02/06/2015 01:07 AM, MⒶrtin HⒶboⓋštiak wrote: 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org: On 02/05/2015 04:36 PM, Martin Habovštiak wrote: I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :) Notice from my original comment: A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). I said this could only be accomplished using a shared secret or a trusted public key. Exchanging a value that is derived from a pair of public keys is a distinction without a difference. The problem remains that the parties must have a secure/out-of-band channel for communicating this value. The fact that they are face-to-face establishes this channel, but that brings us back to the original problem, as it requires manual verification - as in visual/audible scanning of the two values for comparison. At that point the visual comparison of the address, or some value derived from it, is simpler. I have never been against manual verification. What I'm trying to say is let's just make manual verification easier and more secure. Comparison of address is simpler for the coder but also simpler to attack. It has these problems: - Addresses broadcasted in plaintext (privacy issue) - Amounts broadcasted in plaintext (privacy issue) - Address is long - takes lot of time to verify (user experience issue) - Address prefix can be brute-forced, if too short or used to make black hole address if longer (vandalism issue) Commit protocol can be used for both the encryption and the authentication while user experience is not bad and everything is still secure. In case of RedPhone, you read those words verbally over not-yet- verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time. This is reasonable, but wouldn't help in the case of an ad-hoc connection between parties who don't know each other well. I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.) I appreciate the offer. I really don't trust *any* smartphone as a platform for secure communication/data. But encrypting on the wire does of course shrink the attack surface and increase the attacker's cost. e Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil e...@voskuil.org napísal: On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote: That's exactly what I though when seeing the RedPhone code, but after I studied the commit protocol I realized it's actually secure and convenient way to do it. You should do that too. :) I was analyzing the model as you described it to me. A formal analysis of the security model of a particular implementation, based on inference from source code, is a bit beyond what I signed up for. But I'm perfectly willing to comment on your description of the model if you are willing to indulge me. Shortly, how it works: The initiator of the connection sends commit message containing the hash of his temporary public ECDH part, second party sends back their public ECDH part and then initiator sends his public ECDH part in open. All three messages are hashed together and the first two bytes are used to select two words from a shared dictionary which are displayed on the screen of both the initiator and the second party. The parties communicate those two words and verify they match. How do they compare words if they haven't yet established a secure channel? If an attacker wants to do MITM, he has a chance of choosing right public parts 1:65536. There is no way to brute-force it, since that would be noticed immediately. If instead of two words based on the first two bytes, four words from BIP39 wordlist were chosen, it would provide
Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
On 02/10/2015 02:41 AM, Natanael wrote: Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak martin.habovst...@gmail.com mailto:martin.habovst...@gmail.com: Why would anyone want to do anything about payment before choosing what he wants to buy and for what price? I've never used Amazon but isn't filling a form with shipping information enough? That's not what this is about. BIP70 isn't just payment, it is about communication the terms of the sale. Hi Natanael, BIP70 exists for seller non-repudiation (i.e. a cryptographically signed receipt for payment) and establishing strong seller identity in a face-to-face or other non-web scenario (since TLS doesn't help). Anything else is incidental. Let's say you're visiting an international webshop. But they don't ship to your country. Wouldn't you want to know that before your start filling the cart? With this, your wallet / browser extension could tell you right away that you can't shop there. No time wasted! That's just one requirement of many where you would benefit from being told right away if it is acceptable for both parties or not. There's quite a bit that can be done with wallets and web sites, but personally I'd freak out if my wallet prompted me because I visited a web site. 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/10/2015 09:16 AM, MⒶrtin HⒶboⓋštiak wrote: I'm not sure if I was clear enough. Handshake should be used to establish authenticated AND encrypted communication using ECDH (or just DH, but I think it's easier to use ECDH, since required functions are already used in Bitcoin protocol), like RedPhone does. BTW knowledge of verification string is useless to the attacker. Yes, I think this was clear from your description. Yes, the customer must verify it verbally and the merchant shouldn't send the transaction before verification. Other possibility is that in case of differing verification strings new address is generated, so attacker doesn't know the address. But in this case, amount is leaked and there is quite high probability it can be found in the Blockchain. Yes, for each handshake the payment request would need to contain a different address, mitigating some of the privacy loss. Anyway, I don't believe the transaction can be made securely without such interaction except with white-listing public keys, so I see no reason why interaction should be problematic. It can be done securely and privately by transfer of a shared secret through a private channel. We don't have such strict regulations but I agree that security is important. Currently I think that verbal verification and manual confirmation is the best way to achieve high security and reasonable user-friendliness. I think for a broadcast model (e.g. Bluetooth only) that is the only want to ensure integrity and privacy. A narrow cast can use proximity to establish trust. 2015-02-10 17:55 GMT+01:00 Eric Voskuil e...@voskuil.org: Martin, I like your idea for the commit protocol in that it resolves the vandalous address substitution attack. However, I don't see a way to prevent privacy loss without adverse impact to the scenario. Anyone could perform the handshake and thereby obtain the payment request. Therefore to prevent inadvertent disclosure the customer must visually confirm the phrase and then verbally tell the merchant to proceed by sending the payment request. One might argue that it's sufficient to preserve the integrity of the transaction while suffering the privacy loss, especially given that a hijacked handshake should never result in a completed transaction - unless of course the hijacker pays. But imagine someone purchasing their meds. HIPAA requires the checkout queue to form behind a yellow line. That speaks directly to this question. e On 02/06/2015 01:07 AM, MⒶrtin HⒶboⓋštiak wrote: 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org: On 02/05/2015 04:36 PM, Martin Habovštiak wrote: I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :) Notice from my original comment: A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). I said this could only be accomplished using a shared secret or a trusted public key. Exchanging a value that is derived from a pair of public keys is a distinction without a difference. The problem remains that the parties must have a secure/out-of-band channel for communicating this value. The fact that they are face-to-face establishes this channel, but that brings us back to the original problem, as it requires manual verification - as in visual/audible scanning of the two values for comparison. At that point the visual comparison of the address, or some value derived from it, is simpler. I have never been against manual verification. What I'm trying to say is let's just make manual verification easier and more secure. Comparison of address is simpler for the coder but also simpler to attack. It has these problems: - Addresses broadcasted in plaintext (privacy issue) - Amounts broadcasted in plaintext (privacy issue) - Address is long - takes lot of time to verify (user experience issue) - Address prefix can be brute-forced, if too short or used to make black hole address if longer (vandalism issue) Commit protocol can be used for both the encryption and the authentication while user experience is not bad and everything is still secure. In case of RedPhone, you read those words verbally over not-yet- verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time. This is reasonable, but wouldn't help in the case of an ad-hoc connection between parties who don't know each other well. I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.) I appreciate the offer. I really don't trust *any* smartphone
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On 02/14/2015 05:13 AM, Peter Todd wrote: So stop wasting your time. Help get the consensus critical code out of Bitcoin Core and into a stand-alone libconsensus library... done https://github.com/libbitcoin/libbitcoin-consensus ... Then ... when the next time we decide to soft-fork Bitcoin the process isn't some secretive IRC discussion by a half-dozen core developers - and one guy who finds the term hilarious - but a full on DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW, complete with twinkle fingers. You seriously made me laugh out loud with this one Peter. 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/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
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
alleviate the base64url debate? Others may not be aware of the encoding squabble (not sure if it qualifies as debate). In the proposed URL, it affects the mac address and the key: bitcoin:[address]?bt:mac/key base58: bitcoin:?r=bt:12rAs9mM/234KF8hPkXq5pa6pT1wnJC3hVH7W6yB2Wtw24ztzGtBc4 base64url: bitcoin:?r=bt:ABBgss5s/A3xWlhB1GI_t2NMR9Zq9E47hZOzmZ6eZTS8sbq-liugh I prefer base58 because it's available to all bitcoin libraries, nearly as compact as base64 (+1 byte in our example) and better standardized. Some embedded device people might care about having to incorporate base64 as well as base58. It's also better looking (no - or _ characters) and more consistent in the proposed URL (all three values would be base58, as opposed to one base58 and two base64url). There may be some idea that base58 is just for bitcoin addresses (not true) or designed for humans... that's sort of the point, but it's also good for URLs. e On 02/23/2015 09:55 PM, Eric Voskuil wrote: Andy, adding to my previous post below: On 02/23/2015 01:40 AM, Eric Voskuil wrote: On 02/22/2015 11:36 PM, Andy Schroder wrote: ... It's possible a really sophisticated modification could be done where the attacker encrypts and decrypts the communication and then relays to each party (without them knowing or any glitches detected), but I guess I'm not sure how easy that would be on such a close proximity device? If the NFC tap is sufficiently private, privacy is easy to achieve for the subsequent communication. If it is not, privacy can be completely compromised. The question is only how much more difficult is the attack. With the public cert tap, the level of difficulty is much lower for capturing selected payment requests. The interloper no longer needs to invade the space of the NFC terminal and can instead impersonate the payer from a safe distance. Nobody gets paid, but privacy is compromised. This problem in the preceding paragraph can be resolved by sending a unique public key on each NFC tap. In that case an attacker would need to monitor the NFC communication. The talk of wrapping the connection in SSL led me to believe you were talking about a static public certificate. However that's not a necessary assumption here and may not be what you intended. The level of difficulty in the case where the interloper wants to taint transactions may appear lower, but it is not: With the session key tap the interloper must compromise the NFC location and then monitor the BT traffic. Monitoring BT traffic without being party to the connection is presumably not rocket surgery, but not standard BT design either. With the public cert tap the interloper must also compromise the NFC location and communicate over BT. Therefore the hardware and physical attack requirements are similar. The only added difficulty is that the attack on the NFC terminal attack is active (modifying the MAC address directing the payer to the BT service). I believe your central claim was that the difference in the two bootstrapping approaches (public key vs. session key) is that by using a unique public key per tap, the attack requires an active vs. passive attack on the NFC terminal. I just wanted to make clear here that I agree with that assessment. The symmetric key approach is based on the idea that these attacks are comparable in difficulty and otherwise identical in privacy loss. However, the difference in implementation amounts to about +23 additional encoded characters for the BT/LE URL, assuming use of the secp256k1 curve for DHE. This is really not a material issue in the case of the NFC tap. The entire URI+URL could be as small as: bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP In comparison to a symmetric key: bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E It also does not change the protocol design or complexity at all - it would just swap out an AES key for a secp256k1 public key. bitcoin:[address]?bt:mac/key If that gets us aligned I'm all for it. However impersonating the payer is just a matter of software - no more difficult than the session key attack. In fact it may be much easier to implement, as the attack can use supported BT features because the attacker has directed the payer to connect to him and is connecting to the receiver as if he was a payer. But it gets worse for the public cert tap, since a more sophisticated attacker can set himself up in the same position without subverting the NFC terminal at all. By broadcasting a more powerful BT service on the same advertised MAC address, the attacker can capture traffic and relay it to the intended service. I'm retracting the last paragraph, since the interloper, without invading the NFC connection (by substituting the public cert), could not read the relayed traffic. It was getting late :/ So in sum, reliance on a public cert makes the communication less private under the same physical set of constraints
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
as is prevents disclosure of any bits of the public key, which should be treated as a secret during the session. * When you said a new public key for each tap, do you see that as every single tap, or do you consider multiple taps from the same customer the same tap? Yes, since there would be no other way to distinguish between customers in some scenarios and this is the safest approach. We certainly won't run out of numbers, and unused sessions can be discarded based on any number of criteria, including discarding all but the most recent. That may may be sufficient for your vending machines given there's little if any call for parallelism. e On 02/24/2015 06:28 AM, Eric Voskuil wrote: On 02/23/2015 09:53 PM, Andy Schroder wrote: I was saying provide a public key via NFC (or a public key fingerprint and then send the full public key over bluetooth). Instead of providing a new public key on each tap, why can't the payee just stop accepting connections from new parties on that resource after a session key has been received from the first person? Because the presumption was that there was not an additional secret in the URI. If the public key is reused then anyone can spoof a payer and obtain payment requests. Adding a secret to the URI can resolve this, as long as it is encrypted with the public key before being transmitted back to BT. Otherwise the secret can be intercepted and replayed to the terminal, encrypted with the well-known public key. So if you want to treat the resource as a secret this would work. However the resource was designed as a public session identifier, leading the byte stream. This changes it to private session identifier, which loses some utility. Also, reuse of the public key introduces a forward secrecy problem and the potential for persistent seller impersonation in the case of undiscovered key compromise. But there's really no benefit to reusing the key. An ephemeral key resolves these issues and can also seed the public resource name. If the person decides to have there friend or family pay for them instead and cancel the payment, they could just hit cancel on the POS or something (on my fuel pump I have a switch that needs to be turned, the purpose of this is to avoid wasting too many addresses) Don't you have someone stop by the pump once a week and empty out the addresses? :) and/or do another NFC tap (if you're providing QR codes you'd still need a button of some kind though so it knows to refresh it), or the POS can just provide a completely new payment request to any new connections on that same resource which use a different session key. I feel like the authentication of the payer to the payee in any future connections after they receive the session key from them (which was encrypted with the payees public key), comes from the fact that they are sending responses back that are encrypted using the session key they gave to the payee. The way I am seeing it is that the NFC tap or QR code scan is acting in addition to the visual name check on the signature verification in the wallet. With a secure channel that identifies the parties by proximity, the reason for the payment request signature is for the payer to obtain a non-repudiation guarantee. But it also serves as a defense-in-depth solution to a compromise of the channel (though does not offer a benefit in the case of seller terminal/cert compromise). If the certificate used isn't signed by a CA (self signed), it may be fine as long as you heard about it via NFC or QR code. I don't think it will require PKI and should still work wallet-to-wallet. In that case the cert provides no benefit. A self-signed cert can be repudiated and if the channel is compromised anyone can sign the payment request. It sounds like you are saying I'm proposing the customer is going to need a certificate signed by CA? If so, why? This was not a serious proposal, it was to point out what would become necessary if the payer could not be identified by proximity. In the case where a public key is reused, any payer can contact the BT terminal and obtain the payment request. If the merchant can't rely on proximity (i.e. can't trust the integrity of the NFC connection) then he would have to fall back on some other means of identifying the payer. A mutual verbal/visual confirmation could work, but the point of of NFC+BT is elimination of that hassle. Yes, it sounds a bit wild, but I have seen on this list a serious proposal to have people broadcast their photo, having the merchant select them and push to them the payment request. Of course anyone can spoof another's image, so at some point your image would need to be certified, and hence a CA. I wouldn't go there, but was just making the point. I don't need this for any https website I visit. When you go to a web site you first establish a private communication. The site doesn't know who you
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
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
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
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
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
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
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] Proposed alternatives to the 20MB step
On 06/01/2015 08:55 AM, Mike Hearn wrote: Decentralization is the core of Bitcoin's security model and thus that's what gives Bitcoin its value. No. Usage is what gives Bitcoin value. Nonsense. Visa, Dollar, Euro, Yuan, Peso have usage. The value in Bitcoin is *despite* it's far lesser usage. Yes, the price is a function of demand, but demand is a function of utility. Despite orders of magnitude less usage than state currencies, Bitcoin has utility. This premium *only* exists due to its lack of centralized control. I would not work full time, or at all, on Bitcoin if it was not for decentralization; nor would I hold any of it. I doubt anyone would show an interest in Bitcoin if it was not decentralized. If it centralized even you would be forced to find something else to do, because Bitcoin usage would drop to zero. It's kind of maddening that I have to point this out. Decentralisation is a means to an end. No, it was/is the primary objective. Paypal had already been done. If anything is maddening it's that you of all people can't see this. When people talk about the core innovation of Bitcoin, it's a conversation about Byzantine Generals, not wicked growth hacking. in April 2009 and it was perfectly decentralised [...] every wallet was a full node and every computer was capable of mining. So if you believe what you just wrote [...] Bitcoin's value has gone down every day since An obvious non sequitur. By way of example, if 10 of 10 participants are capable of mining it is not more decentralized than if 1,000 in 100,000 are doing so. 1,000 *people* in control vs. 10 is two orders of magnitude more decentralized. The *percentage* of the community that mines is totally irrelevant, it's the absolute number of (independent) people that matters. I'm not making a statement on block size, just trying to help ensure that ill-considered ideas, like this inversion of the core value proposition, stay on the margins. e signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step
On 06/02/2015 04:03 AM, Mike Hearn wrote: 1,000 *people* in control vs. 10 is two orders of magnitude more decentralized. Yet Bitcoin has got worse by all these metrics: there was a time before mining pools when there were ~thousands of people mining with their local CPUs and GPUs. Now the number of full nodes that matter for block selection number in the dozens, and all the other miners just follow their blocks blindly. A mining pool is not a person, a full node is not a miner, and cooperation is not control. http://bravenewcoin.com/news/number-of-bitcoin-miners-far-higher-than-popular-estimates/ The entire Bitcoin ecosystem cooperates, that is what consensus means. Establishing proof of that cooperation is the purpose of Bitcoin. Decentralization is about keeping control out of the hands of the state (any entity that would substitute violence for consensus). Nobody has the power to compel the cooperation of individual miners in a pool. When state power is applied to a pool operator the miners (people) retain their vote. e signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
