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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <fastest963@gmail.com>) id 1WLK9C-0006NB-3I
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 22:18:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.176 as permitted sender)
client-ip=209.85.216.176; envelope-from=fastest963@gmail.com;
helo=mail-qc0-f176.google.com;
Received: from mail-qc0-f176.google.com ([209.85.216.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WLK9A-0007qY-Hs
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 22:18:42 +0000
Received: by mail-qc0-f176.google.com with SMTP id m20so1945127qcx.7
for <bitcoin-development@lists.sourceforge.net>;
Wed, 05 Mar 2014 14:18:35 -0800 (PST)
X-Received: by 10.224.25.73 with SMTP id y9mr5192136qab.101.1394057914913;
Wed, 05 Mar 2014 14:18:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.47.170 with HTTP; Wed, 5 Mar 2014 14:17:54 -0800 (PST)
In-Reply-To: <20140305193910.GA24917@tilt>
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
<53174F20.10207@gmail.com> <20140305193910.GA24917@tilt>
From: James Hartig <fastest963@gmail.com>
Date: Wed, 5 Mar 2014 17:17:54 -0500
Message-ID: <CAM6j61uj9RL0FpOyhQ8U8ucuA=iUJ=ANK7tGAyAeFUZ2fXK5CA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bdc177cd099cb04f3e366cd
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(fastest963[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (fastest963[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WLK9A-0007qY-Hs
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New side channel attack that can recover
Bitcoin keys
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: Wed, 05 Mar 2014 22:18:42 -0000
--047d7bdc177cd099cb04f3e366cd
Content-Type: text/plain; charset=UTF-8
On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd <pete@petertodd.org> wrote:
> More important though is you shouldn't be using single factor Bitcoin
> addresses. Use n-of-m multisig instead and architect your system such
> that that every transaction that happens in your service has to be
> authorized by both the "online" server(s) that host your website as well
> as a second "hardened" server with an extremely limited interface
> between it and the online server.
This adds a very minor amount of security, if any, if someone manages to
hack into your "hot wallet" server they can just initiate a non-multisig
transaction and still steal all your bitcoins in that wallet. You can't
give the argument that the RPC API is password protected because the
password is stored in plain-text in the config so all someone has to do is
first grep for the file. There doesn't appear to be a way to force ALL
outgoing transactions to be multisig and even if there was one, would you
be able to force one of the addresses to be the "hardened" server? That
still wouldn't prevent anyone from just stopping bitcoind, changing the
config, then restarting it.
Unless you're using your own custom wallet software there doesn't seem to
be any sufficient way to prevent someone from stealing all your money once
they have access to your server. Other software, like MySQL has access
controls so I can prevent ALTERs, DROPs, DELETEs, etc for all "live"
accounts limiting the scope of any attack if they manage to get into the
server. Maybe this is beyond the scope of bitcoind, not sure.
Thanks,
--
James Hartig
Software Engineer @ Grooveshark.com
http://twitter.com/jameshartig
--047d7bdc177cd099cb04f3e366cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd=C2=A0<span dir=
=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@p=
etertodd.org</a>></span>=C2=A0wrote:<div><div>> More important though=
is you shouldn't be using single factor Bitcoin</div>
<div>> addresses. Use n-of-m multisig instead and architect your system =
such</div><div>> that that every transaction that happens in your servic=
e has to be</div><div>> authorized by both the "online" server=
(s) that host your website as well</div>
<div>> as a second "hardened" server with an extremely limited=
interface</div><div>> between it and the online server.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This adds a very mino=
r amount of security, if any, if someone manages to hack into your "ho=
t wallet" server they can just initiate a non-multisig transaction and=
still steal all your bitcoins in that wallet. You can't give the argum=
ent that the RPC API is password protected because the password is stored i=
n plain-text in the config so all someone has to do is first grep for the f=
ile. There doesn't appear to be a way to force ALL outgoing transaction=
s to be multisig and even if there was one, would you be able to force one =
of the addresses to be the "hardened" server? That still wouldn&#=
39;t prevent anyone from just stopping bitcoind, changing the config, then =
restarting it.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Unless you&=
#39;re using your own custom wallet software there doesn't seem to be a=
ny sufficient way to prevent someone from stealing all your money once they=
have access to your server. Other software, like MySQL has access controls=
so I can prevent ALTERs, DROPs, DELETEs, etc for all "live" acco=
unts limiting the scope of any attack if they manage to get into the server=
. Maybe this is beyond the scope of bitcoind, not sure.</div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr">Thanks,<=
br>--<br>James Hartig<br>Software Engineer @ Grooveshark.com<br><a href=3D"=
http://twitter.com/jameshartig" target=3D"_blank">http://twitter.com/jamesh=
artig</a></div>
</div></div></div></div>
--047d7bdc177cd099cb04f3e366cd--
|
