From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLKGx-0002s8-RT for bitcoin-development@lists.sourceforge.net; Wed, 05 Mar 2014 22:26:43 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.174 as permitted sender) client-ip=209.85.192.174; envelope-from=elombrozo@gmail.com; helo=mail-pd0-f174.google.com; Received: from mail-pd0-f174.google.com ([209.85.192.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WLKGw-00085J-BC for bitcoin-development@lists.sourceforge.net; Wed, 05 Mar 2014 22:26:43 +0000 Received: by mail-pd0-f174.google.com with SMTP id y13so1621611pdi.19 for ; Wed, 05 Mar 2014 14:26:36 -0800 (PST) X-Received: by 10.66.146.199 with SMTP id te7mr10205838pab.106.1394058396462; Wed, 05 Mar 2014 14:26:36 -0800 (PST) Received: from [192.168.1.107] (cpe-76-88-33-166.san.res.rr.com. [76.88.33.166]) by mx.google.com with ESMTPSA id ha11sm12356126pbd.17.2014.03.05.14.26.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 14:26:34 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0D940455-5A31-43C1-8D54-471872841CEF"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Eric Lombrozo In-Reply-To: Date: Wed, 5 Mar 2014 14:26:31 -0800 Message-Id: References: <53174F20.10207@gmail.com> <20140305193910.GA24917@tilt> To: James Hartig X-Mailer: Apple Mail (2.1510) X-Spam-Score: -0.6 (/) 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 (elombrozo[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.174 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WLKGw-00085J-BC Cc: Bitcoin Dev Subject: Re: [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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 22:26:44 -0000 --Apple-Mail=_0D940455-5A31-43C1-8D54-471872841CEF Content-Type: multipart/alternative; boundary="Apple-Mail=_F210605E-381A-4C5C-BCEE-578CBD8776E8" --Apple-Mail=_F210605E-381A-4C5C-BCEE-578CBD8776E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 wrote: > On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd 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. >=20 > 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. >=20 > 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. >=20 > 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.=20 > 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=3D122218951&iu=3D/4140/ostg.= clktrk_______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --Apple-Mail=_F210605E-381A-4C5C-BCEE-578CBD8776E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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:
&= gt; 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://p= ubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140/ostg.clkt= rk_______________________________________________
Bitcoin-developme= nt mailing = list
Bitcoin-development@lists.sourceforge.net
https://lists.sourcef= orge.net/lists/listinfo/bitcoin-development

= --Apple-Mail=_F210605E-381A-4C5C-BCEE-578CBD8776E8-- --Apple-Mail=_0D940455-5A31-43C1-8D54-471872841CEF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTF6SXAAoJEAA1EyJsW9n+pPUQANGg+uiCYe7jdpuoHDXrxHAn FzMSgV/Pt6KXu2+ovgcTVBNN8Pt2ZDWMeZMW7Qlcdjx5tRkdHnq5CLZx+KnfVIp6 FjFwG6nO5be6qZ1kqrwhTlxig9K0GpPJuyL+xPnFEWjhHo1fIfezbMpCOew5JM2b KuzaR4NsHPhaQMLOF9COOLfdB2RCbgNwBHBIawgGwjmXfPAq4sIMleskPF021P5E kPnVEP0XyBMkaKLR/O8IZI++b0c66j+OHuadrGdbNq/ubc9UiimvsAinWvaEZLuA b5XwQ9aVUcOEly7E6qUWucwR2pQDId7+IYsKzFmitJ+8zb4p+ADAVnWAVjWC/pVD +KCIL2cgf/H9R4MhmBt3G+4wVPe4ZdR7glGsucLszG0JWgINP6Lbk+pcOCcH9fzH XNSC5yVzpOqhT1LlLqv7ca8I5+t841gvvd86sRUjjNyz6lVQOTLs8mbaO5/FnBkW ofBIVqQxiv+lb07/KSBRsVHnRcdtw77es3J1hcpUpthBEnynUTiB7zyJe/+QQ5+G LVLr4aCOwzTjTRU45KeZmMDP/BWpbH3MELpKdJDEqUQNYgRyPL7B3oPLzX0oOaxi V/1OUdcQ/UxHgTyXcjxwIDwNQhKZyJmYnM6DzFNab1M73Rlkho+WbVhsTLj/RnnV aWsOPIOBI4a3RQAZehoH =fLwF -----END PGP SIGNATURE----- --Apple-Mail=_0D940455-5A31-43C1-8D54-471872841CEF--