public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Date: Wed, 5 Mar 2014 13:49:22 +0100	[thread overview]
Message-ID: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1686 bytes --]

             reply	other threads:[~2014-03-05 12:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 12:49 Mike Hearn [this message]
2014-03-05 12:56 ` Pieter Wuille
2014-03-05 13:18   ` Jean-Paul Kogelman
2014-03-05 14:04     ` Pieter Wuille
2014-03-05 16:21 ` Kevin
2014-03-05 19:39   ` Peter Todd
2014-03-05 19:51     ` Gregory Maxwell
2014-03-05 20:32       ` Peter Todd
2014-03-05 20:54         ` Gregory Maxwell
2014-03-12  9:44           ` Peter Todd
2014-03-05 22:17     ` James Hartig
2014-03-05 22:26       ` Eric Lombrozo
2014-03-06  7:02     ` Odinn Cyberguerrilla
2014-03-08 19:34   ` Luke-Jr
2014-03-09  1:57     ` Gregory Maxwell
2014-03-05 21:31 ` Eric Lombrozo
2014-03-05 21:44   ` Gregory Maxwell
2014-03-05 22:14     ` Eric Lombrozo
2014-03-05 22:25       ` Gregory Maxwell
2014-03-06  8:38         ` Mike Hearn
2014-03-06 10:00           ` Natanael
2014-03-25 13:39             ` Troy Benjegerdes
2014-03-25 13:50               ` Gavin Andresen
2014-03-08 19:29           ` Gustav Simonsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com \
    --to=mike@plan99$(echo .)net \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox