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. 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. 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. 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
There are a couple of attack vectors to consider: * The recipient's machine is compromised * The sender's machine is compromised Excellent point of the recipient being compromised. -- 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
Joel, The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address was replaced, you should see this on the mobile device as it won’t match where you were intending to send it. You can then not provide the second signature. Brian Erdelyi On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen joel.kaarti...@gmail.com wrote: If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok. - Joel On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi brian.erde...@gmail.com mailto:brian.erde...@gmail.com 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. 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. 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/ http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development 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
Transaction initiated and signed on device #1. Transaction is sent to device #2. On device #2 you verify the transaction and if authorized you provide the second signature. Brian Erdelyi Sent from my iPhone On Feb 2, 2015, at 5:09 PM, Pedro Worcel pe...@worcel.com wrote: Where would you verify that? On 2/3/2015 10:03 AM, Brian Erdelyi wrote: Joel, The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address was replaced, you should see this on the mobile device as it won’t match where you were intending to send it. You can then not provide the second signature. Brian Erdelyi On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen joel.kaarti...@gmail.com wrote: If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok. - Joel On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi brian.erde...@gmail.com 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. 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. 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 -- 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 smime.p7s Description: S/MIME cryptographic 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok. - Joel On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi brian.erde...@gmail.com 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. 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. 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 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 to
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
We're way ahead of you guys ;) https://www.bitcoinauthenticator.org/ https://www.bitcoinauthenticator.org/ - does this already, currently in alpha I’m just late to the party I guess. Thanks for the links. -- 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
Do you have anything that is NOT some web application? 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. -- 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
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
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 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? 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. -- 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
I think what he is saying is that there is no point in having three signatures if they are not segregated in a secure manner. This is to say, if you use your computer as one factor, and a third party website as another, but you use the same computer to access the website, there is no gain in security. Another example would be an android phone. If your computer is compromised and your browser is authenticated to your Google account, you could remotely install an app on your phone. I don't know if I understood/explained myself correctly; I think two factor is better than one and there is a security gain if implemented securely. Cheers! Pedro On 2/3/2015 8: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. 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. 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 to address Bitcoin malware
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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Do you have anything that is NOT some web application? 2015-02-02 18:59 GMT+01:00 Mike Hearn m...@plan99.net: We're way ahead of you guys ;) On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak martin.habovst...@gmail.com wrote: Good idea. I think this could be even better: instead of using third party, send partially signed TX from computer to smartphone. In case, you are paranoid, make 3oo5 address made of two cold storage keys, one on desktop/laptop, one on smartphone, one using third party. https://www.bitcoinauthenticator.org/ - does this already, currently in alpha 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. BitGo, CryptoCorp and (slight variant) GreenAddress all offer this model. -- 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
Good idea. I think this could be even better: instead of using third party, send partially signed TX from computer to smartphone. In case, you are paranoid, make 3oo5 address made of two cold storage keys, one on desktop/laptop, one on smartphone, one using third party. If it isn't enough, add requirement of another four keys, so you have three desktops with different OS (Linux, Windows, Mac) and three mobile OS (Android, iOS, Windows Phone), third party and some keys in cold storage. Also, I forgot HW wallets, so at least Trezor and Ledger. I believe this scheme is unpenetrable by anyone, including NSA, FBI, CIA, NBU... Jokes aside, I think leaving out third party is important for privacy reasons. Stay safe! 2015-02-02 18:40 GMT+01:00 Brian Erdelyi brian.erde...@gmail.com: 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
Martin, Yes, the second signing could be done by a mobile device that I owned and controlled (I wasn't thinking that initially). I was thinking that online services are popular because of convenience and there should be a better way to address security (privacy issues not withstanding). I think these are practical approaches and just doing a sanity check. Thanks for the vote of confidence. Brian Erdelyi Sent from my iPad On Feb 2, 2015, at 1:54 PM, Martin Habovštiak martin.habovst...@gmail.com wrote: Good idea. I think this could be even better: instead of using third party, send partially signed TX from computer to smartphone. In case, you are paranoid, make 3oo5 address made of two cold storage keys, one on desktop/laptop, one on smartphone, one using third party. If it isn't enough, add requirement of another four keys, so you have three desktops with different OS (Linux, Windows, Mac) and three mobile OS (Android, iOS, Windows Phone), third party and some keys in cold storage. Also, I forgot HW wallets, so at least Trezor and Ledger. I believe this scheme is unpenetrable by anyone, including NSA, FBI, CIA, NBU... Jokes aside, I think leaving out third party is important for privacy reasons. Stay safe! 2015-02-02 18:40 GMT+01:00 Brian Erdelyi brian.erde...@gmail.com: 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
BIP70 is quite safe agains MitB. If user copies URL belonging to other merchant, he would see the fact after entering it into his wallet application. The only problem is, attacker can buy from the same merchant with user's money. (sending him different URL) This can be mitigated by merchant setting memo to the description of the basket and some user info (e.g. address to which goods are sent). I think BIP 70 does a good job at verifying where the payment request came from. I’m not convinced this is the same as verifying the transaction (ideally OOB). But if whole computer is compromised, you're already screwed. Trezor should help, but I'm not sure if it supports BIP70. The reason for OOB verification is if the entire computer is compromised. Again, this may only be possible with a trusted intermediary or a web wallet. 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
BIP70 is quite safe agains MitB. If user copies URL belonging to other merchant, he would see the fact after entering it into his wallet application. The only problem is, attacker can buy from the same merchant with user's money. (sending him different URL) This can be mitigated by merchant setting memo to the description of the basket and some user info (e.g. address to which goods are sent). But if whole computer is compromised, you're already screwed. Trezor should help, but I'm not sure if it supports BIP70. 2015-02-01 14:49 GMT+02:00 Brian Erdelyi brian.erde...@gmail.com: In online banking, the banks generate account numbers. An attacker cannot generate their own account number and the likelihood of an attacker having the same account number that I am trying to transfer funds to is low and this is why OCRA is effective with online banking. With Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time? I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification). I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? Perhaps this is something that can only be supported when sending money with web based wallets. 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 to address Bitcoin malware
I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? No. It cannot be done in the Bitcoin context. Your wallet MUST be secure. Otherwise BIP70 is irrelevant - if the attacker can make your wallet sign some other transaction than what you expect, they can also just steal your private keys and use them directly. BIP70 is based on the assumption of a secure signing core that cannot be compromised, with devices like the TREZOR and 2-factor pairings of desktops and mobiles being an obvious use case. -- 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 online banking, the banks generate account numbers. An attacker cannot generate their own account number and the likelihood of an attacker having the same account number that I am trying to transfer funds to is low and this is why OCRA is effective with online banking. With Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time? I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification). I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? Perhaps this is something that can only be supported when sending money with web based wallets. 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
TREZOR does not support BIP70. I think they planned to work on it after multi-sig support, which is now done, so I'm hoping that it's next on their roadmap. The signing features of BIP70 have (fortunately!) been implemented by payment processors quite early, before we really have the client side fully figured out and implemented. Mobile wallets (Android, iOS) do implement it and they are reasonably secure, for desktops we need TREZOR and we need the Bitcoin Authenticator 2-factor wallet to support it. I think they do, but can't remember exactly. Either they do, or it's on their roadmap. On Sun, Feb 1, 2015 at 2:31 PM, Martin Habovštiak martin.habovst...@gmail.com wrote: BIP70 is quite safe agains MitB. If user copies URL belonging to other merchant, he would see the fact after entering it into his wallet application. The only problem is, attacker can buy from the same merchant with user's money. (sending him different URL) This can be mitigated by merchant setting memo to the description of the basket and some user info (e.g. address to which goods are sent). But if whole computer is compromised, you're already screwed. Trezor should help, but I'm not sure if it supports BIP70. 2015-02-01 14:49 GMT+02:00 Brian Erdelyi brian.erde...@gmail.com: In online banking, the banks generate account numbers. An attacker cannot generate their own account number and the likelihood of an attacker having the same account number that I am trying to transfer funds to is low and this is why OCRA is effective with online banking. With Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time? I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification ( http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification ). I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? Perhaps this is something that can only be supported when sending money with web based wallets. 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 -- 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
This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE. Since it's not very widely used outside of Austria and Germany, this may be interesting for some: there is a second factor scheme called cardTAN or chipTAN where authentication codes are generated on a device which is not specifically linked to an accout. When authenticating an online banking transaction the process is as follows: http://i.imgur.com/eWsffsp.jpg 1. Insert bank card into TAN generator 2. Scan flickering code on screen with the device's photodetector 3. Confirm amount to transfer and recipient on the generator 4. Finalize online banking transaction by entering a challenge-response generated by the device https://www.youtube.com/watch?v=5gyBC9irTsMt=22s http://en.wikipedia.org/wiki/Transaction_authentication_number#chipTAN_.2F_cardTAN Original Message *Subject: *[Bitcoin-development] Proposal to address Bitcoin malware *From: *Brian Erdelyi brian.erde...@gmail.com *To: *bitcoin-development@lists.sourceforge.net *Date: *Sat, 31 Jan 2015 18:15:53 -0400 Hello all, The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites. Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE. Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions? I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address? 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 to address Bitcoin malware
Den 31 jan 2015 23:17 skrev Brian Erdelyi brian.erde...@gmail.com: Hello all, The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites. Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE. Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions? I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address? See vanitygen. Yes, 8 characters can be bruteforced. You need about 100 bits of security for strong security, and at the very least NOT less than ~64 (see distributed bruteforce projects attacking 64 bit keys for reference, you can find plenty via Google). You shouldn't rely on mechanisms intended to be used for one-shot auth where the secret is supposed to be unguessable for another system where the attacker knows what the target string is and have a fair amount of time to attempt bruteforce. Use something more like HMAC instead. -- 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
Den 1 feb 2015 00:05 skrev Brian Erdelyi brian.erde...@gmail.com: See vanitygen. Yes, 8 characters can be brute forced. Thank you for this reference. Interesting to see that there is a tool to generate a vanity bitcoin address. I am still researching viruses that are designed to manipulate a bitcoin address. I suspect they are primitive in that they use a hardcoded rogue bitcoin address as opposed to dynamically generating one. As a start, this would help protect against malware that uses a static rogue bitcoin address. The next thing would be for the malware to brute-force the legitimate bitcoin address and generate a rogue bitcoin address that would produce the same 8 digit code. Curious to know how long this brute force would take? Or perhaps, before converting to 8 digits there is some other hashing function that is performed. Brian Erdelyi To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries. log(50M)/log(2) = 25.6 bits of entropy. One try = generate a random number, use it to generate an ECDSA keypair, SHA256 and RIPEMD160 hash the public key per Bitcoin specs, then run that OCRA hashing code, then compare strings. Considering the ECDSA operations is by a large margin slower than all the hash functions, consider them to just add a small percentage in performance drop vs regular vanitygen usage. My non-gaming laptop performed IIRC at *a few million keys per second* with OpenCL. I've used it to search for 6 character strings in the base58 Bitcoin addresses with it in 15 minutes to half an hour or so. That's about 35 bits of entropy (rough estimate, there's some details with padding in the base58 representation that alters it). So 2^(35-26) ~= 1 in 500 of that time, and that's if you use a laptop instead of a GPU rig. Seconds at worst. Milliseconds if done on a rig. -- 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
See vanitygen. Yes, 8 characters can be brute forced. Thank you for this reference. Interesting to see that there is a tool to generate a vanity bitcoin address. I am still researching viruses that are designed to manipulate a bitcoin address. I suspect they are primitive in that they use a hardcoded rogue bitcoin address as opposed to dynamically generating one. As a start, this would help protect against malware that uses a static rogue bitcoin address. The next thing would be for the malware to brute-force the legitimate bitcoin address and generate a rogue bitcoin address that would produce the same 8 digit code. Curious to know how long this brute force would take? Or perhaps, before converting to 8 digits there is some other hashing function that is performed. 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Den 1 feb 2015 00:37 skrev Natanael natanae...@gmail.com: To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries. log(50M)/log(2) = 25.6 bits of entropy. Oops. Used the wrong number in the entropy calculation. Add one bit, the division by 2 wasn't supposed to be used in the entropy calculation. Doesn't change the equation much, though. -- 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
[Bitcoin-development] Proposal to address Bitcoin malware
Hello all, The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites. Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE https://www.youtube.com/watch?v=Sh2Iha88agE. Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions? I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address? Brian Erdelyi signature.asc Description: Message signed with OpenPGP using GPGMail -- 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