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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@signal11.com>) id 1YIjZq-0001pj-NX
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Feb 2015 19:56:02 +0000
X-ACL-Warn:
Received: from mail-ob0-f172.google.com ([209.85.214.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YIjZl-0003es-UO
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Feb 2015 19:56:02 +0000
Received: by mail-ob0-f172.google.com with SMTP id nt9so20813583obb.3
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Feb 2015 11:55:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=6njhhL/G9uy4bDkoutdxS+MRJAwkoH+hDRon1Izw8Ls=;
b=YnF0Om7m5QPMkI/Xy64Q6r4J5yGVaG9eZteSPJGU4K8lfxU2w7QF0ivdUHdOqHtftZ
92gOJ9l/BsZxvAnBvwpnq5YVxiRL4I/+kuxpJyc5N6CVMOO2EeftUR1cALja7Y4HNS+M
txSxfvSnhwblpzFfxVmmLRqTw4gV+zxUhzmKaBC50Xw8jUw7ao5KA8lNTVOCmcSYrl0S
Up/TUD4P1R8k38ndeE8vrQDFpsSvAVm+aPFFp3ZtIKeeCo2dzufV3KHlrnMLQvO2C4gR
xAm8S5ydFGPB5WTwLEqQOqMMbdCfkHC/0meuCyrjHM2D4go3fCDdyomcVK8MoJe7FzmB
Hp+Q==
X-Gm-Message-State: ALoCoQmP8Ll18yYyt6SpqHdoOLeV5KpEphRV63eUDjK7apwA6uuOmCsVm2vfGhpv3N27rqWaGX7h
MIME-Version: 1.0
X-Received: by 10.60.15.198 with SMTP id z6mr2164211oec.84.1422991519848; Tue,
03 Feb 2015 11:25:19 -0800 (PST)
Received: by 10.202.102.216 with HTTP; Tue, 3 Feb 2015 11:25:19 -0800 (PST)
In-Reply-To: <etPan.54d0b945.46e87ccd.7f23@Williams-MBP>
References: <etPan.54d0b945.46e87ccd.7f23@Williams-MBP>
Date: Tue, 3 Feb 2015 14:25:19 -0500
Message-ID: <CAFVoEQQHVcY0Ad-4c2wnH+WF_7M-o5SNwVr-nce_9bQ794cwDQ@mail.gmail.com>
From: Adam Weiss <adam@signal11.com>
To: Will <will.madden@novauri.com>
Content-Type: multipart/alternative; boundary=089e0149d0940f2d89050e3408d5
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
X-Headers-End: 1YIjZl-0003es-UO
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Subject: Re: 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: Tue, 03 Feb 2015 19:56:02 -0000
--089e0149d0940f2d89050e3408d5
Content-Type: text/plain; charset=UTF-8
>
>
> Using a desktop website and mobile device for 2/3 multisig in lieu of a
> hardware device (trezor) and desktop website (mytrezor) works, but the key
> is that the device used to input the two signatures cannot be in the same
> band. What you are protecting against are MITM attacks. The issue is that
> if a single device or network is compromised by malware, or if a party is
> connecting to a counterparty through a channel with compromised security,
> inputing 2 signatures through the same device/band defeats the purpose of
> 2/3 multisig.
>
Maybe I'm not following the conversation very well, but if you have a small
hardware device that first displays a signed payment request (BIP70) and
then only will sign what is displayed, how can a MITM attacker do anything
other than deny service? They'd have to get malware onto the signing
device, which is the vector that a simplified signing device is
specifically designed to mitigate.
TREZOR like devices with BIP70 support and third party cosigning services
are a solution I really like the sound of. I suppose though that adding
BIP70 request signature validation and adding certificate revocation
support starts to balloon the scope of what is supposed to be a very simple
device though.
Regardless, I think a standard for passing partially signed transactions
around might make sense (maybe a future extension to BIP70), with attention
to both PC <-> small hardware devices and pushing stuff around on the
Internet. It would be great if users had a choice of hardware signing
devices, local software and third-party cosigning services that would all
interoperate out of the box to enable easy multisig security, which in the
BTC world subsumes the goals of 2FA.
--adam
--089e0149d0940f2d89050e3408d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div style=
=3D"font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin=
:0px;line-height:auto"><span style=3D"font-family:'helvetica Neue',=
helvetica;line-height:19.5px"><br></span></div><div style=3D"margin:0px"><f=
ont face=3D"helvetica Neue, helvetica"><span style=3D"line-height:19.5px">U=
sing a desktop website and mobile device for 2/3 multisig in lieu of a hard=
ware device (trezor) and desktop website (mytrezor) works, but the key is t=
hat the device used to input the two signatures=C2=A0cannot be in the same =
band.=C2=A0 What you are protecting against are MITM attacks.=C2=A0 The iss=
ue is that if a single=C2=A0device or network is compromised by malware, or=
if a party is connecting to a counterparty through a channel with compromi=
sed security, inputing 2 signatures through the=C2=A0same device/band defea=
ts=C2=A0the purpose of 2/3 multisig. =C2=A0</span></font></div></div></bloc=
kquote><div><br></div><div>Maybe I'm not following the conversation ver=
y well, but if you have a small hardware device that first displays a signe=
d payment request (BIP70) and then only will sign what is displayed, how ca=
n a MITM attacker do anything other than deny service?=C2=A0 They'd hav=
e to get malware onto the signing device, which is the vector that a simpli=
fied signing device is specifically designed to mitigate.</div><div><br></d=
iv><div>TREZOR like devices with BIP70 support and third party cosigning se=
rvices are a solution I really like the sound of.=C2=A0 I suppose though th=
at adding BIP70 request signature validation and adding certificate revocat=
ion support starts to balloon the scope of what is supposed to be a very si=
mple device though.</div><div><br></div><div>Regardless, I think a standard=
for passing partially signed transactions around might make sense (maybe a=
future extension to BIP70), with attention to both PC <-> small hard=
ware devices and pushing stuff around on the Internet.=C2=A0 It would be gr=
eat if users had a choice of hardware signing devices, local software and t=
hird-party cosigning services that would all interoperate out of the box to=
enable easy multisig security, which in the BTC world subsumes the goals o=
f 2FA.</div><div><br></div><div>--adam<br></div><div><br></div></div></div>=
</div>
--089e0149d0940f2d89050e3408d5--
|
