summaryrefslogtreecommitdiff
path: root/93/b9a19b57ff06b237753661a9b76e6d80bcf484
blob: e644ebbca57627a3e4e0546400e4d01f80743d1a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
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--