From: Eric Lombrozo <elombrozo@gmail•com>
To: James Hartig <fastest963@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Date: Wed, 5 Mar 2014 14:26:31 -0800 [thread overview]
Message-ID: <C334895E-8AA1-47FC-81B2-9BB487351B92@gmail.com> (raw)
In-Reply-To: <CAM6j61uj9RL0FpOyhQ8U8ucuA=iUJ=ANK7tGAyAeFUZ2fXK5CA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2928 bytes --]
Oh, I absolutely agree that this type of attack is NOT the weakest link in security. There are MANY far easier targets in bitcoind and typical use scenarios of it. If we want to dramatically improve the security of a typical bitcoin wallet, the FLUSH+RELOAD attack is probably not where our efforts would be best rewarded trying to prevent.
However, this thread IS about this particular attack vector - and my suggestion IS specific to this thread.
-Eric Lombrozo
On Mar 5, 2014, at 2:17 PM, James Hartig <fastest963@gmail•com> wrote:
> 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
> ------------------------------------------------------------------------------
> 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 #1.2: Type: text/html, Size: 4000 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2014-03-05 22:26 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 [this message]
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=C334895E-8AA1-47FC-81B2-9BB487351B92@gmail.com \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=fastest963@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