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 1UZe1U-0007B9-KP for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 09:17:24 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.52 as permitted sender) client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f52.google.com; Received: from mail-oa0-f52.google.com ([209.85.219.52]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UZe1S-00019Z-RY for bitcoin-development@lists.sourceforge.net; Tue, 07 May 2013 09:17:24 +0000 Received: by mail-oa0-f52.google.com with SMTP id h1so335793oag.11 for ; Tue, 07 May 2013 02:17:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.84.135 with SMTP id z7mr319266oby.35.1367918237541; Tue, 07 May 2013 02:17:17 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Tue, 7 May 2013 02:17:17 -0700 (PDT) In-Reply-To: References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> <20130506180418.GA3797@netbook.cypherspace.org> <20130506225146.GA6657@netbook.cypherspace.org> Date: Tue, 7 May 2013 11:17:17 +0200 X-Google-Sender-Auth: O48Q-QgePNCcxYjUiVcWrxiac6o Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1UZe1S-00019Z-RY Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) 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: Tue, 07 May 2013 09:17:24 -0000 > Seems like the website redesign managed to hide the signatures pretty > good. They're in the release announcements in any case, but that > should be fixed. Even when they were prominently placed, practically > no one checked them. As a result they are mostly security theater Security theater indeed - even if people check the signatures, where did they get the identities of the signers/developers from? Oh right, the same website that served them the binary. The signatures are useful for verifying the integrity of our mirrors. The verify-bitcoin.sh script does this. Unfortunately it's not good enough. I run it daily and from time to time it fails and says the hashes don't match, which I assume means we may have a corrupted mirror somewhere or the script itself is flaky. But the output is too sparse to investigate. I modified it to print more data and am waiting for it to fail again, unfortunately, I can't make it fail on demand. Anyway. I've been thinking about this problem a fair bit. It's easier to solve on some platforms than on others. On Android, the Bitcoin Wallet app is protected by a few things: 1) Once installed, the device will only accept updates that were signed by the same key as the original. So the auto update mechanism is secure (including I believe against an attack by the store operator, which is usually Google). 2) It appears at the top of the Play Store when you search for "Bitcoin". Unfortunately the Store is somewhat gameable at the moment, but that's getting fixed and more importantly over the long term, app store operators have the right incentives to crack down on gaming of search results. This combined with the reviews, ratings and social recommendations of real users provides a series of signals that are hard for an attacker/phisher to replicate. You can say to someone "Go get the app called Bitcoin Wallet by Andreas Schildbach from the store" and the chances they get the right thing, signed by the right person, are very high. 3) I never got around to trying it, but the threshold RSA library I obtained is theoretically capable of splitting the RSA keys used to protect updates. I've talked to Andreas about this a little bit, and I think he's open to the idea of splitting the Android signing key so it requires a quorum of developers to release an update. This is Shoup threshold RSA, not a Shamir secret share of the key bits. 4) The OS sandboxes apps from each other. That sandbox doesn't have a great track record outside of Google-controlled devices because OEMs and carriers don't have the right incentives to actually ship OS security updates, but it's still a lot better than nothing and hopefully over time these issues will get resolved. All together this means users on phones and tablets have a somewhat convincing security solution that fights against phishing and malware. On MacOS X the binaries are signed under the legal identity of the Bitcoin Foundation. Jim has started signing MultiBit with his legal identity too (this is required to make Gatekeeper happy on recent versions of MacOS). Unsigned binaries will not run by default on 10.8, but anyone with a developer certificate can sign any binary. So whilst a hacked bitcoin.org or a phishing site can distribute malware, at least on OS X 10.8 it will require the user to override the built in security systems, or it will require the malware author to steal a developer certificate - probably not very hard but definitely raises the bar. On Windows antivirus companies operate what is effectively a form of binary whitelisting. The new MultiBit release triggered AV warnings for a few days until it got enough reputation to stop triggering. The goal of these systems is to fight polymorphic viruses and they understand code signing. If you reliably sign your binaries, positive binary reputation accrues to your signing identity and not the binary itself, so you can release updates and not get harassed. On Linux we're actually the most exposed. It has by far the worst situation of all - a culture in which man-in-the-middle attacks by package maintainers are not only common but actively encouraged. The Debian OpenSSL fiasco showed the critical danger this can place people in. I believe we should have a health warning on the website telling people to only get binaries from us unless they are on a distribution that we are verifying doesn't apply any patches. But that's a ton of work and I long ago burned out on the politics of Linux software distribution.