Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YIPt9-0003u5-BS for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 22:54:39 +0000 X-ACL-Warn: Received: from mail-pa0-f48.google.com ([209.85.220.48]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YIPt7-0005Rv-8q for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 22:54:39 +0000 Received: by mail-pa0-f48.google.com with SMTP id ey11so88143593pad.7 for ; Mon, 02 Feb 2015 14:54:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=ANCHNgsYTYRXY/JCWbRDWOqwdEZ/zneiwCqcjYWHP4Y=; b=KIDelbB9OUXFBXvOe7htxQao+cEb6k4i08Ws/Nh5PO2SyQ8sTK6VV0yM3QDIzip6V6 RkxbMwqp5ThjEUVL08rEeMVoJvMrWleUr1tEYLH6wCCyMOKrWAs9gfQsKLUEtuZEcnJ7 Z+0yGO57+wcn4ruxvRtwxZ5jubY7MZ8K+gx0so2vQD871o7Bd3QJieyP0H6xXUsBOPlP JU6xq/FQx+1V0le7QF91Lta+SaxzDXb1VSGvT3FOjMvRAw0orkai46shp/G3Lf3A8ogX kAMN+Whj/HHzyH7ogukp1Xcsxfs31kneWyCAoUOltRUz2Rpu+pyuu9JhWw9IR0EFfjpp 8dZg== X-Gm-Message-State: ALoCoQl+uSZIISiyR4s9eSWeSttv/SXSLC3Znel4GCJu83Wu4D4bhbHORv/VrEhcPxCjpwfexIlQ X-Received: by 10.68.135.136 with SMTP id ps8mr33366548pbb.130.1422917671509; Mon, 02 Feb 2015 14:54:31 -0800 (PST) Received: from [10.213.140.226] (mobile-166-171-250-018.mycingular.net. [166.171.250.18]) by mx.google.com with ESMTPSA id fo8sm101700pdb.74.2015.02.02.14.54.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Feb 2015 14:54:30 -0800 (PST) References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com> <54CE3816.6020505@bitwatch.co> <68C03646-02E7-43C6-9B73-E4697F3AA5FD@gmail.com> <05590A33-1802-4C15-91C0-8777ACD8440B@voskuil.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1915308F-CAFA-429B-8C17-BF6283246033 Message-Id: <1F2B5D9D-BD1E-4EFB-AD48-4B3E376D9661@voskuil.org> X-Mailer: iPad Mail (12B440) From: Eric Voskuil Date: Mon, 2 Feb 2015 14:54:25 -0800 To: Mike Hearn X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Headers-End: 1YIPt7-0005Rv-8q Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 22:54:39 -0000 --Apple-Mail-1915308F-CAFA-429B-8C17-BF6283246033 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote: >> In sending the first-signed transaction to another for second signature, h= ow does the first signer authenticate to the second without compromising the= independence of the two factors? >=20 > Not sure what you mean. The idea is the second factor displays the transac= tion and the user confirms it matches what they input to the first factor. I= deally, using BIP70, but I don't know if BA actually uses that currently. >=20 > It's the same model as the TREZOR, except with a desktop app instead of my= TREZOR and a phone instead of a dedicated hardware device.=20 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 wrote= : >=20 > Another concept... >=20 > 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 trans= action that has been signed by 2 of those keys. One key is placed in cold s= torage and anther sent to a third-party. >=20 > 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 signatur= e. This now permits the use of out of band transaction verification techniq= ues before the third party signs the transaction and sends to the blockchain= . >=20 > 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 s= ign transactions and send funds to a new wallet. >=20 > Thoughts? In the multisig scenario the presumption is of a user platform compromised b= y malware. It envisions a user signing a 2 of 3 output with a first signatur= e. The precondition that the platform is compromised implies that this proce= ss 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 spen= d 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 signatur= e, thereby spending the output as intended by the user, who is not necessari= ly the first signer. The send must be authenticated to the user. Otherwise t= he third party would have to sign anything it received, obviously rendering t= he second signature pointless. This implies that the compromised platform mu= st 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 platfor= m is compromised. So of course the malware has the ability to sign, imperson= ate 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 o= btain consent before adding the second signature. The user, upon receiving t= he 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 comp= romised, 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 difficul= ty of the coordinated attack). The strength of these assumptions is an inter= esting question, since it is hard to quantify. But without independence the e= ntire 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 o= f the first platform breaks the anti-collusion assumption. Also, weak comsec= allows an attack against the second platform to be carried out against its n= etwork. So for example a simple SMS-based confirmation could be executed by t= he first platform alone and thereby also break the the anti-collusion assump= tion. This is why I asked how independence is maintained. The assumption of a hardware wallet scenario is that the device itself is no= t compromised. So the scenario is not the same. If the user signs with a har= dware wallet, nothing can collude with that process, with one caveat. While a hardware wallet is not subject to onboard malware, it is not inconce= ivable that its keys could be extracted through probing or other direct atta= ck against the hardware. It's nevertheless an assumption of hardware wallets= that these attacks require loss of the hardware. Physical possession consti= tutes compromise. So the collusion model with a hardware wallet does exist, i= t just requires device possession. Depending on the implementation the extra= ction 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 t= hird party for a second of three signatures, and finally to a second platfor= m 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 t= he third party). This of course implies that keeping both the fist and secon= d platforms in close proximity constitutes collusion from a physical securit= y standpoint. This is probably sufficient justification for not implementing= such a model, especially given the cost and complexity of stealing and crac= king a well-designed device. A device backup would provide comparable time t= o recover with far less complexity (and loss of privacy). Incidentally the hardware wallet idea breaks down once any aspect of the pla= tform 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 exa= mple 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 par= ts 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 par= ty implies loss of privacy to that party, and with weak comsec to the networ= k. Similarly, use of hardware signing devices implies loss of privacy to the= compromised platforms with which they exchange transactions. e= --Apple-Mail-1915308F-CAFA-429B-8C17-BF6283246033 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Feb 2, 20= 15, at 11:53 AM, Mike Hearn <mike@plan= 99.net> wrote:
<= div class=3D"gmail_extra">
In sending the first-signed transaction to another for second signatu= re, how does the first signer authenticate to the second without compromisin= g the  independence of the two factors?

Not sure what you mean. The idea is the second factor displays the transact= ion and the user confirms it matches what they input to the first factor. Id= eally, using BIP70, but I don't know if BA actually uses that currently.

It's the same model as the TREZOR, except with a deskt= op app instead of myTREZOR and a phone instead of a dedicated hardware devic= e. 

Sorry for the slow reply, traveling.
<= br>
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 a= gainst malware.  For example, a user could generate a wallet with 3 key= s and require a transaction that has been signed by 2 of those keys.  O= ne key is placed in cold storage and anther sent to a third-party.

It is now possible to generate and s= ign transactions on the users computer and send this signed transaction to t= he third-party for the second signature.  This now permits the use of o= ut of band transaction verification techniques before the third party signs t= he 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 p= rivate 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 plat= form compromised by malware. It envisions a user signing a 2 of 3 output wit= h a first signature. The precondition that the platform is compromised impli= es that this process results in a loss of integrity of the private key, and a= s such if it were not for the second signature requirement, the malware woul= d be able to spend the output. This may be extended to all of the keys in th= e wallet.

The scenario envisions sending the signed= transaction to an another ("third") party. The objective is for the third p= arty to provide the second signature, thereby spending the output as intende= d by the user, who is not necessarily the first signer. The send must be aut= henticated to the user. Otherwise the third party would have to sign anythin= g it received, obviously rendering the second signature pointless. This impl= ies that the compromised platform must transmit a secret, or proof of a secr= et, to the third party.

The problem is that the two= secrets are not independent if the first platform is compromised. So of cou= rse the malware has the ability to sign, impersonate the user and send to th= e third party. So the third party *must* send the transaction to an *indepen= dent* platform for verification by the user, and obtain consent before addin= g the second signature. The user, upon receiving the transaction details, mu= st be able to verify, on the independent platform, that the details match th= ose of the transaction that user presumably signed. Even for simple transact= ions this must include amount, address and fees.

Th= e central assumptions are that, while the second user platform may be compro= mised, the attack against the second platform is not coordinated with that o= f the first, nor is the third party in collusion with the first platform.

Upon these assumptions rests the actual security bene= fit (increased difficulty of the coordinated attack). The strength of these a= ssumptions is an interesting question, since it is hard to quantify. But wit= hout independence the entire security model is destroyed and there is thus n= o protection whatsoever against malware.

So for exa= mple a web-based or other third-party-provisioned implementation of the firs= t platform breaks the anti-collusion assumption. Also, weak comsec allows an= attack against the second platform to be carried out against its network. S= o for example a simple SMS-based confirmation could be executed by the first= platform alone and thereby also break the the anti-collusion assumption. Th= is is why I asked how independence is maintained.

T= he 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 hard= ware wallet, nothing can collude with that process, with one caveat.

= While a hardware wallet is not subject to onboard malware, it is not inconce= ivable that its keys could be extracted through probing or other direct atta= ck against the hardware. It's nevertheless an assumption of hardware wallets that t= hese attacks require loss of the hardware. Physical possession constitutes c= ompromise. So the collusion model with a hardware wallet does exist, it just= requires device possession. Depending on the implementation the extraction m= ay require a non-trivial amount of time and money.

In a scenario where th= e user signs with HW, then sends the transaction to a third party for a seco= nd of three signatures, and finally to a second platform for user verificati= on, a HW thief needs to collude with the third party or the second platform b= efore 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 p= roximity constitutes collusion from a physical security standpoint. This is p= robably sufficient justification for not implementing such a model, especial= ly given the cost and complexity of stealing and cracking a well-designed de= vice. A device backup would provide comparable time to recover with far less= complexity (and loss of privacy).

Incidenta= lly the hardware wallet idea breaks down once any aspect of the platform or n= etwork to which it connects must be trusted, so for these purposes I do not c= onsider certain hybrid models as hardware wallets at all. For example one su= ch device trusts that the compromised computer does not carry out a MITM att= ack between the signing device and a shared secret entered in parts over tim= e by the user. This reduces to a single factor with no protection against a c= ompromised platform.

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

e
= --Apple-Mail-1915308F-CAFA-429B-8C17-BF6283246033--