1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAAS2fgQU5yHFEUfzVwco=L2YKU=Ci0Od+4w59o1wx5UUf1w3VQ@mail.gmail.com>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
<20130506161216.GA5193@petertodd.org>
<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
<20130506163732.GB5193@petertodd.org>
<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
<20130506180418.GA3797@netbook.cypherspace.org>
<CAAS2fgSh+dYxSak8HvE0Sr4=zxzRc=3dMQ6X_nD_a+OdacUBZQ@mail.gmail.com>
<20130506225146.GA6657@netbook.cypherspace.org>
<CAAS2fgQU5yHFEUfzVwco=L2YKU=Ci0Od+4w59o1wx5UUf1w3VQ@mail.gmail.com>
Date: Tue, 7 May 2013 11:17:17 +0200
X-Google-Sender-Auth: O48Q-QgePNCcxYjUiVcWrxiac6o
Message-ID: <CANEZrP1unq_36p0_VJ6CnHof2Sxb4B8go3BK6tPzEMbSLQBBtg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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.
|
