[Bitcoin-development] Proposal to address Bitcoin malware

[Bitcoin-development] Proposal to address Bitcoin malware

[Brian Erdelyi]

[-- Attachment #1.1: Type: text/plain, Size: 1869 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2393 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

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

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]

Den 31 jan 2015 23:17 skrev "Brian Erdelyi" <brian.erdelyi@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.

[-- Attachment #2: Type: text/html, Size: 2733 bytes --]

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

[Brian Erdelyi]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 1261 bytes --]

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

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

Den 1 feb 2015 00:05 skrev "Brian Erdelyi" <brian.erdelyi@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.

[-- Attachment #2: Type: text/html, Size: 2120 bytes --]

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

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

Den 1 feb 2015 00:37 skrev "Natanael" <natanael.l@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.

[-- Attachment #2: Type: text/html, Size: 498 bytes --]

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

[Brian Erdelyi]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 1992 bytes --]

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

[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.erdelyi@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
>

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4284 bytes --]

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.habovstiak@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.erdelyi@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
>

[-- Attachment #2: Type: text/html, Size: 5468 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 958 bytes --]

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

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

[mbde]

> 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=5gyBC9irTsM&t=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.erdelyi@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

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?

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

[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.erdelyi@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

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

We're way ahead of you guys ;)

On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak <
martin.habovstiak@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.

[-- Attachment #2: Type: text/html, Size: 1560 bytes --]

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

[Martin Habovštiak]

Do you have anything that is NOT some web application?

2015-02-02 18:59 GMT+01:00 Mike Hearn <mike@plan99.net>:
> We're way ahead of you guys ;)
>
> On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak
> <martin.habovstiak@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.

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

[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.erdelyi@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

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 <martin.habovstiak@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.erdelyi@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

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

[Brian Erdelyi]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]


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


[-- Attachment #2: Type: text/html, Size: 746 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 844 bytes --]

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

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

[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.erdelyi@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

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 802 bytes --]

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

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

[Joel Joonatan Kaartinen]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

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.erdelyi@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
>

[-- Attachment #2: Type: text/html, Size: 2878 bytes --]

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

[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

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

[Brian Erdelyi]

[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

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.kaartinen@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.erdelyi@gmail.com <mailto:brian.erdelyi@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>
> 


[-- Attachment #2: Type: text/html, Size: 4200 bytes --]

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

[Pedro Worcel]

[-- Attachment #1: Type: text/plain, Size: 3790 bytes --]

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.kaartinen@gmail.com <mailto:joel.kaartinen@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.erdelyi@gmail.com <mailto:brian.erdelyi@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


[-- Attachment #2: Type: text/html, Size: 8063 bytes --]

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

[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.kaartinen@gmail.com <mailto:joel.kaartinen@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.erdelyi@gmail.com <mailto:brian.erdelyi@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
> 

-- 
devrandom / Miron

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

[Brian Erdelyi]

[-- Attachment #1.1: Type: text/plain, Size: 4578 bytes --]

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 <pedro@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.kaartinen@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.erdelyi@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

[-- Attachment #1.2: Type: text/html, Size: 9264 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2358 bytes --]

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.

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

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 6580 bytes --]

On Feb 2, 2015, at 11:53 AM, Mike Hearn <mike@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.erdelyi@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 may require a non-trivial amount of time and money.

In a scenario where the user signs with HW, then sends the transaction to a third party for a second of three signatures, and finally to a second platform for user verification, a HW thief needs to collude with the third party or the second platform before the owner becomes aware of the theft (notifying the third party). This of course implies that keeping both the fist and second platforms in close proximity constitutes collusion from a physical security standpoint. This is probably sufficient justification for not implementing such a model, especially given the cost and complexity of stealing and cracking a well-designed device. A device backup would provide comparable time to recover with far less complexity (and loss of privacy).

Incidentally the hardware wallet idea breaks down once any aspect of the platform or network to which it connects must be trusted, so for these purposes I do not consider certain hybrid models as hardware wallets at all. For example one such device trusts that the compromised computer does not carry out a MITM attack between the signing device and a shared secret entered in parts over time by the user. This reduces to a single factor with no protection against a compromised platform.

Of course these questions address integrity, not privacy. Use of a third party implies loss of privacy to that party, and with weak comsec to the network. Similarly, use of hardware signing devices implies loss of privacy to the compromised platforms with which they exchange transactions.

e

[-- Attachment #2: Type: text/html, Size: 9483 bytes --]

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

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 7360 bytes --]

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.erdelyi@gmail.com
>>> <mailto:brian.erdelyi@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 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 may require a non-trivial
> amount of time and money.
> 
> In a scenario where the user signs with HW, then sends the transaction
> to a third party for a second of three signatures, and finally to a
> second platform for user verification, a HW thief needs to collude with
> the third party or the second platform before the owner becomes aware of
> the theft (notifying the third party). This of course implies that
> keeping both the fist and second platforms in close proximity
> constitutes collusion from a physical security standpoint. This is
> probably sufficient justification for not implementing such a model,
> especially given the cost and complexity of stealing and cracking a
> well-designed device. A device backup would provide comparable time to
> recover with far less complexity (and loss of privacy).
> 
> Incidentally the hardware wallet idea breaks down once any aspect of the
> platform or network to which it connects must be trusted, so for these
> purposes I do not consider certain hybrid models as hardware wallets at
> all. For example one such device trusts that the compromised computer
> does not carry out a MITM attack between the signing device and a shared
> secret entered in parts over time by the user. This reduces to a single
> factor with no protection against a compromised platform.
> 
> Of course these questions address integrity, not privacy. Use of a third
> party implies loss of privacy to that party, and with weak comsec to the
> network. Similarly, use of hardware signing devices implies loss of
> privacy to the compromised platforms with which they exchange transactions.
> 
> e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]