Subject: Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

From: James Hartig <[email-masked]>
Date: Wed, 5 Mar 2014 17:17:54 -0500

On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd <[email-masked]> 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