path: root/93/b9a19b57ff06b237753661a9b76e6d80bcf484

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 <eric@voskuil.org>) 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 <bitcoin-development@lists.sourceforge.net>;
	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>
	<CANEZrP1QgtJ2urNTVqbscrXaJ=wefUO16GQ=THaSBnLq9QBmeQ@mail.gmail.com>
In-Reply-To: <CANEZrP1QgtJ2urNTVqbscrXaJ=wefUO16GQ=THaSBnLq9QBmeQ@mail.gmail.com>
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 <eric@voskuil.org>
Date: Mon, 2 Feb 2015 14:54:25 -0800
To: Mike Hearn <mike@plan99.net>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <mike@plan99.net> 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 <brian.erdelyi@gmail.com> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span></span></div><div><meta http-equ=
iv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div>On Feb 2, 20=
15, at 11:53 AM, Mike Hearn &lt;<a href=3D"mailto:mike@plan99.net">mike@plan=
99.net</a>&gt; wrote:</div><blockquote type=3D"cite"><div><div dir=3D"ltr"><=
div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">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&nbsp; independence of the two factors?</blockquote><div><br></div><div=
>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.</di=
v><div><br></div><div>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.&nbsp;</div></div></div></div>
</div></blockquote><br><div>Sorry for the slow reply, traveling.</div><div><=
br></div><div>My comments were made in reference to this proposal:</div><div=
><br></div><div><blockquote type=3D"cite"><font color=3D"#000000"><span styl=
e=3D"background-color: rgba(255, 255, 255, 0);">On Feb 2, 2015, at 10:40 AM,=
 Brian Erdelyi &lt;<a href=3D"mailto:brian.erdelyi@gmail.com" x-apple-data-d=
etectors=3D"true" x-apple-data-detectors-type=3D"link" x-apple-data-detector=
s-result=3D"1">brian.erdelyi@gmail.com</a>&gt; wrote:<br></span></font></blo=
ckquote><blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"bac=
kground-color: rgba(255, 255, 255, 0);"><br></span></font></blockquote><bloc=
kquote type=3D"cite"><font color=3D"#000000"><span style=3D"background-color=
: rgba(255, 255, 255, 0);">Another concept...<br></span></font></blockquote>=
<blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"background-=
color: rgba(255, 255, 255, 0);"><br></span></font></blockquote><blockquote t=
ype=3D"cite"><font color=3D"#000000"><span style=3D"background-color: rgba(2=
55, 255, 255, 0);">It should be possible to use multisig wallets to protect a=
gainst malware. &nbsp;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. &nbsp;O=
ne key is placed in cold storage and anther sent to a third-party.<br></span=
></font></blockquote><blockquote type=3D"cite"><font color=3D"#000000"><span=
 style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></font></blo=
ckquote><blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"bac=
kground-color: rgba(255, 255, 255, 0);">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. &nbsp;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.<br></span></font></blockquote><b=
lockquote type=3D"cite"><font color=3D"#000000"><span style=3D"background-co=
lor: rgba(255, 255, 255, 0);"><br></span></font></blockquote><blockquote typ=
e=3D"cite"><font color=3D"#000000"><span style=3D"background-color: rgba(255=
, 255, 255, 0);">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. &nbsp;If the third-party disappeared, the user could use the key=
 in cold storage to sign transactions and send funds to a new wallet.<br></s=
pan></font></blockquote><blockquote type=3D"cite"><font color=3D"#000000"><s=
pan style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></font></=
blockquote><blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"=
background-color: rgba(255, 255, 255, 0);">Thoughts?</span></font></blockquo=
te><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</d=
iv><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><d=
iv><br></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">=
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.&nbsp;</span><span style=3D"background-color: rgba(2=
55, 255, 255, 0);">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.</span></div><div><span st=
yle=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><spa=
n style=3D"background-color: rgba(255, 255, 255, 0);">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).</span></div><div><br></div><div>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.</div><div><br></div><div><span style=3D"background-colo=
r: rgba(255, 255, 255, 0);">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.</span></div></div><div><span style=3D"background-color: rgba(25=
5, 255, 255, 0);"><br></span></div><div><span style=3D"background-color: rgb=
a(255, 255, 255, 0);">e</span></div></body></html>=

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