summaryrefslogtreecommitdiff
path: root/3c/61e4184fd720d88adf77e405a9ed33119dbb0d
blob: f82e4dfe6ae8ad3a82817bc8ac685684120a9eca (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WLBGK-0003Ol-LT
	for bitcoin-development@lists.sourceforge.net;
	Wed, 05 Mar 2014 12:49:28 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.174 as permitted sender)
	client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f174.google.com; 
Received: from mail-ob0-f174.google.com ([209.85.214.174])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WLBGJ-0003cj-Lq
	for bitcoin-development@lists.sourceforge.net;
	Wed, 05 Mar 2014 12:49:28 +0000
Received: by mail-ob0-f174.google.com with SMTP id wo20so937393obc.5
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 05 Mar 2014 04:49:22 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.81.197 with SMTP id c5mr4646588oby.40.1394023762327;
	Wed, 05 Mar 2014 04:49:22 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Wed, 5 Mar 2014 04:49:22 -0800 (PST)
Date: Wed, 5 Mar 2014 13:49:22 +0100
X-Google-Sender-Auth: gfQuQaALxT3kqYeMk61lAQPi47U
Message-ID: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b2e4d58297edb04f3db7340
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1WLBGJ-0003cj-Lq
Subject: [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 12:49:28 -0000

--047d7b2e4d58297edb04f3db7340
Content-Type: text/plain; charset=UTF-8

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.

--047d7b2e4d58297edb04f3db7340
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A new practical technique has been published that can reco=
ver secp256k1 private keys after observing OpenSSL calculate as little as 2=
00 signatures:<div><br></div><div><a href=3D"http://eprint.iacr.org/2014/16=
1.pdf">http://eprint.iacr.org/2014/161.pdf</a><br>
</div><div><br></div><div>This attack is based on the FLUSH+RELOAD techniqu=
e published last year. It works by observing L3 CPU cache timings and forci=
ng cache line flushes using the clflush opcode. As a result, it is applicab=
le 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=
&#39;s secp256k1 implementation completely side channel free in all aspects=
. Also, unfortunately many people have reimplemented ECDSA themselves and e=
ven if OpenSSL gets fixed, the custom implementations probably won&#39;t.=
=C2=A0</div>
<div><br></div><div>So, IMHO this is a sign for hot wallet users to start w=
alking (but not running) towards the exits of these shared cloud services: =
=C2=A0it doesn&#39;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 t=
he cloud. I doubt the researchers will release their code to do the side ch=
annel attack and it&#39;s rather complex to reimplement, so this gives some=
 time for mitigation. Unfortunately the huge sums being held in some &quot;=
bitbank&quot; style hot wallets mean that attackers are well motivated to p=
ull off even quite complex attacks.</div>
</div>

--047d7b2e4d58297edb04f3db7340--