From: Mike Hearn <mike@plan99•net>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Date: Thu, 6 Mar 2014 09:38:40 +0100 [thread overview]
Message-ID: <CANEZrP1+=JY0RGEMvm9iL09L-tZAWqsSOOwFaroYUKkWumx+xg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgScLKgq8_V0oVpvP1gYAKxiyVNGVWA86XfecSmPqsMKUg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]
I'm wondering about whether (don't laugh) moving signing into the kernel
and then using the MTRRs to disable caching entirely for a small scratch
region of memory would also work. You could then disable pre-emption and
prevent anything on the same core from interrupting or timing the signing
operation.
However I suspect just making a hardened secp256k1 signer implementation in
userspace would be of similar difficulty, in which case it would naturally
be preferable.
On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
> > Everything you say is true.
> >
> > However, branchless does reduce the attack surface considerably - if
> nothing else, it significantly ups the difficulty of an attack for a
> relatively low cost in program complexity, and that might still make it
> worth doing.
>
> Absolutely. I believe these things are worth doing.
>
> My comment on it being insufficient was only that "my signer is
> branchless" doesn't make other defense measures (avoiding reuse,
> multsig with multiple devices, not sharing hardware, etc.)
> unimportant.
>
> > As for uniform memory access, if we avoided any kind of heap allocation,
> wouldn't we avoid such issues?
>
> No. At a minimum to hide a memory timing side-channel you must perform
> no data dependent loads (e.g. no operation where an offset into memory
> is calculated). A strategy for this is to always load the same values,
> but then mask out the ones you didn't intend to read... even that I'd
> worry about on sufficiently advanced hardware, since I would very much
> not be surprised if the processor was able to determine that the load
> had no effect and eliminate it! :) )
>
> Maybe in practice if your data dependencies end up only picking around
> in the same cache-line it doesn't actually matter... but it's hard to
> be sure, and unclear when a future optimization in the rest of the
> system might leave it exposed again.
>
> (In particular, you can't generally write timing sign-channel immune
> code in C (or other high level language) because the compiler is
> freely permitted to optimize things in a way that break the property.
> ... It may be _unlikely_ for it to do this, but its permitted— and
> will actually do so in some cases—, so you cannot be completely sure
> unless you check and freeze the toolchain)
>
> > Anyhow, without having gone into the full details of this particular
> attack, it seems the main attack point is differences in how squaring and
> multiplication (in the case of field exponentiation) or doubling and point
> addition (in the case of ECDSA) are performed. I believe using a branchless
> implementation where each phase of the operation executes the exact same
> code and accesses the exact same stack frames would not be vulnerable to
> FLUSH+RELOAD.
>
> I wouldn't be surprised.
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: Type: text/html, Size: 4534 bytes --]
next prev parent reply other threads:[~2014-03-06 8:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 12:49 Mike Hearn
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 [this message]
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='CANEZrP1+=JY0RGEMvm9iL09L-tZAWqsSOOwFaroYUKkWumx+xg@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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