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

2015-02-03 Thread Brian Erdelyi

 Regardless, I think a standard for passing partially signed transactions 
 around might make sense (maybe a future extension to BIP70), with attention 
 to both PC - small hardware devices and pushing stuff around on the 
 Internet.  It would be great if users had a choice of hardware signing 
 devices, local software and third-party cosigning services that would all 
 interoperate out of the box to enable easy multisig security, which in the 
 BTC world subsumes the goals of 2FA.

I think a standard for passing partially signed transactions is a great idea as 
well.  This would support interoperability of wallets/clients and third-party 
services (if users choose to use them).

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

 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
Bitcoin

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 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 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 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 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-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


[Bitcoin-development] Proposal to address Bitcoin malware

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