diff options
author | Eric Lombrozo <elombrozo@gmail.com> | 2014-03-05 14:26:31 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-05 22:26:43 +0000 |
commit | 5916f7e9c608a24c43211f866ec7a01f1173f3ec (patch) | |
tree | 5b2950574e6c2764e3eec47b76eb104badfdc96d | |
parent | 216abe65248aa47f3353c3c64113faffaff8ec97 (diff) | |
download | pi-bitcoindev-5916f7e9c608a24c43211f866ec7a01f1173f3ec.tar.gz pi-bitcoindev-5916f7e9c608a24c43211f866ec7a01f1173f3ec.zip |
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
-rw-r--r-- | c9/510a8e38b938bb5d578e0863b704bf331a0383 | 254 |
1 files changed, 254 insertions, 0 deletions
diff --git a/c9/510a8e38b938bb5d578e0863b704bf331a0383 b/c9/510a8e38b938bb5d578e0863b704bf331a0383 new file mode 100644 index 000000000..f8606cd7d --- /dev/null +++ b/c9/510a8e38b938bb5d578e0863b704bf331a0383 @@ -0,0 +1,254 @@ +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-- + + |