Re: [Bitcoin-development] Proposal to address Bitcoin malware

2015-02-02 Thread devrandom
There are a couple of attack vectors to consider:

* The recipient's machine is compromised
* The sender's machine is compromised

BIP-70 and other ways of having the sender verify the destination on a
second device will help protect against sender compromise.  For a
person-to-person situation, you could verify the address by voice.

For the case where the recipient is compromised, you would want to
verify the address with the recipient's multisig security service.
Extending BIP-70 to allow multiple signatures would be one way to go
about this.  You would at least want to have a web page controlled by
the security service where you can verify addresses.

On 2015-02-02 01:09 PM, Pedro Worcel 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 mailto: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/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 mailto: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

2015-02-02 Thread Brian Erdelyi

 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

2015-02-02 Thread Brian Erdelyi
 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

2015-02-02 Thread Brian Erdelyi
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

2015-02-02 Thread Brian Erdelyi
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

2015-02-02 Thread Joel Joonatan Kaartinen
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

2015-02-02 Thread Eric Voskuil
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

2015-02-02 Thread Eric Voskuil
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

2015-02-02 Thread Eric Voskuil
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

2015-02-02 Thread Brian Erdelyi

 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

2015-02-02 Thread Mike Hearn

 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

2015-02-02 Thread Brian Erdelyi

 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

2015-02-02 Thread Eric Voskuil
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

2015-02-02 Thread Eric Voskuil
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

2015-02-02 Thread Mike Hearn

 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

2015-02-02 Thread Pedro Worcel
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

2015-02-02 Thread Brian Erdelyi
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

2015-02-02 Thread Martin Habovštiak
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

2015-02-02 Thread Martin Habovštiak
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

2015-02-02 Thread Brian Erdelyi
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

2015-02-01 Thread Brian Erdelyi

 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

2015-02-01 Thread Martin Habovštiak
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

2015-02-01 Thread Mike Hearn

 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

2015-02-01 Thread Brian Erdelyi

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

2015-02-01 Thread Mike Hearn
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

2015-02-01 Thread m...@bitwatch.co
 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

2015-01-31 Thread Natanael
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

2015-01-31 Thread Natanael
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

2015-01-31 Thread Brian Erdelyi
 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

2015-01-31 Thread Natanael
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