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 <elombrozo@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; 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 <multiple recipients> (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 <elombrozo@gmail.com> In-Reply-To: <CAM6j61uj9RL0FpOyhQ8U8ucuA=iUJ=ANK7tGAyAeFUZ2fXK5CA@mail.gmail.com> Date: Wed, 5 Mar 2014 14:26:31 -0800 Message-Id: <C334895E-8AA1-47FC-81B2-9BB487351B92@gmail.com> References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com> <53174F20.10207@gmail.com> <20140305193910.GA24917@tilt> <CAM6j61uj9RL0FpOyhQ8U8ucuA=iUJ=ANK7tGAyAeFUZ2fXK5CA@mail.gmail.com> To: James Hartig <fastest963@gmail.com> 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 <bitcoin-development@lists.sourceforge.net> 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: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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. >=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 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>However, this thread IS about this = particular attack vector - and my suggestion IS specific to this = thread.</div><div><br></div><div>-Eric = Lombrozo</div><div><div><br></div><div><br><div><div>On Mar 5, 2014, at = 2:17 PM, James Hartig <<a = href=3D"mailto:fastest963@gmail.com">fastest963@gmail.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div dir=3D"ltr">On Wed, Mar 5, 2014 at 2:39 PM, Peter = Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" = target=3D"_blank">pete@petertodd.org</a>></span> wrote:<div><div>&= gt; More important though is you shouldn't be using single factor = Bitcoin</div> <div>> addresses. Use n-of-m multisig instead and architect your = system such</div><div>> that that every transaction that happens in = your service has to be</div><div>> authorized by both the "online" = server(s) that host your website as well</div> <div>> as a second "hardened" server with an extremely limited = interface</div><div>> between it and the online server.</div><div = class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">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.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">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.</div> <div class=3D"gmail_extra"><br clear=3D"all"><div><div = dir=3D"ltr">Thanks,<br>--<br>James Hartig<br>Software Engineer @ <a = href=3D"http://Grooveshark.com">Grooveshark.com</a><br><a = href=3D"http://twitter.com/jameshartig" = target=3D"_blank">http://twitter.com/jameshartig</a></div> </div></div></div></div> = --------------------------------------------------------------------------= ----<br>Subversion Kills Productivity. Get off Subversion & Make the = Move to Perforce.<br>With Perforce, you get hassle-free workflows. Merge = that actually works. <br>Faster operations. Version large binaries. = Built-in WAN optimization and the<br>freedom to use Git, Perforce = or both. Make the move to Perforce.<br><a = href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D= /4140/ostg.clktrk_______________________________________________">http://p= ubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140/ostg.clkt= rk_______________________________________________</a><br>Bitcoin-developme= nt mailing = list<br>Bitcoin-development@lists.sourceforge.net<br>https://lists.sourcef= orge.net/lists/listinfo/bitcoin-development<br></blockquote></div><br></di= v></div></body></html>= --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--