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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kevinsisco61784@gmail.com>) id 1WLEa4-0004KY-FZ
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 16:22:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.42 as permitted sender)
client-ip=209.85.192.42; envelope-from=kevinsisco61784@gmail.com;
helo=mail-qg0-f42.google.com;
Received: from mail-qg0-f42.google.com ([209.85.192.42])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WLEa3-0001Ve-Bh
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 16:22:04 +0000
Received: by mail-qg0-f42.google.com with SMTP id q107so3517641qgd.1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 05 Mar 2014 08:21:58 -0800 (PST)
X-Received: by 10.140.93.130 with SMTP id d2mr7263073qge.41.1394036517878;
Wed, 05 Mar 2014 08:21:57 -0800 (PST)
Received: from [192.168.1.115] (ool-457b2cb7.dyn.optonline.net.
[69.123.44.183])
by mx.google.com with ESMTPSA id a10sm9141011qas.6.2014.03.05.08.21.56
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 05 Mar 2014 08:21:56 -0800 (PST)
Message-ID: <53174F20.10207@gmail.com>
Date: Wed, 05 Mar 2014 11:21:52 -0500
From: Kevin <kevinsisco61784@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
In-Reply-To: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------050502050209020300080500"
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.42 listed in list.dnswl.org]
-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
(kevinsisco61784[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 (kevinsisco61784[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: 1WLEa3-0001Ve-Bh
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 16:22:04 -0000
This is a multi-part message in MIME format.
--------------050502050209020300080500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 3/5/2014 7:49 AM, Mike Hearn wrote:
> A new practical technique has been published that can recover
> secp256k1 private keys after observing OpenSSL calculate as little as
> 200 signatures:
>
> http://eprint.iacr.org/2014/161.pdf
>
> This attack is based on the FLUSH+RELOAD technique published last
> year. It works by observing L3 CPU cache timings and forcing cache
> line flushes using the clflush opcode. As a result, it is applicable
> to any x86 environment where an attacker may be able to run on the
> same hardware i.e. virtualised hosting environments where keys are
> being reused.
>
> I am not currently aware of any efforts to make OpenSSL's secp256k1
> implementation completely side channel free in all aspects. Also,
> unfortunately many people have reimplemented ECDSA themselves and even
> if OpenSSL gets fixed, the custom implementations probably won't.
>
> So, IMHO this is a sign for hot wallet users to start walking (but not
> running) towards the exits of these shared cloud services: it doesn't
> feel safe to sign transactions on these platforms, so hot wallets
> should be managed by dedicated hardware. Of course other parts of the
> service, like the website, are less sensitive and can still run in the
> cloud. I doubt the researchers will release their code to do the side
> channel attack and it's rather complex to reimplement, so this gives
> some time for mitigation. Unfortunately the huge sums being held in
> some "bitbank" style hot wallets mean that attackers are well
> motivated to pull off even quite complex attacks.
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
How can we patch this issue?
--
Kevin
--------------050502050209020300080500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/5/2014 7:49 AM, Mike Hearn wrote:<br>
</div>
<blockquote
cite="mid:CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com"
type="cite">
<div dir="ltr">A new practical technique has been published that
can recover secp256k1 private keys after observing OpenSSL
calculate as little as 200 signatures:
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://eprint.iacr.org/2014/161.pdf">http://eprint.iacr.org/2014/161.pdf</a><br>
</div>
<div><br>
</div>
<div>This attack is based on the FLUSH+RELOAD technique
published last year. It works by observing L3 CPU cache
timings and forcing cache line flushes using the clflush
opcode. As a result, it is applicable to any x86 environment
where an attacker may be able to run on the same hardware i.e.
virtualised hosting environments where keys are being reused.</div>
<div><br>
</div>
<div>I am not currently aware of any efforts to make OpenSSL's
secp256k1 implementation completely side channel free in all
aspects. Also, unfortunately many people have reimplemented
ECDSA themselves and even if OpenSSL gets fixed, the custom
implementations probably won't. </div>
<div><br>
</div>
<div>So, IMHO this is a sign for hot wallet users to start
walking (but not running) towards the exits of these shared
cloud services: it doesn't feel safe to sign transactions on
these platforms, so hot wallets should be managed by dedicated
hardware. Of course other parts of the service, like the
website, are less sensitive and can still run in the cloud. I
doubt the researchers will release their code to do the side
channel attack and it's rather complex to reimplement, so this
gives some time for mitigation. Unfortunately the huge sums
being held in some "bitbank" style hot wallets mean that
attackers are well motivated to pull off even quite complex
attacks.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
How can we patch this issue?<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Kevin
</pre>
</body>
</html>
--------------050502050209020300080500--
|
