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

[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

[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

[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  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 
>>>  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  
>>> 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, f

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

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

[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

[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

[Brian Erdelyi]

> We're way ahead of you guys ;)
> 
> 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

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

[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

[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

[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

[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

[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