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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1V6Ouq-0002jo-Gv
for bitcoin-development@lists.sourceforge.net;
Mon, 05 Aug 2013 17:49:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.110 as permitted sender)
client-ip=62.13.148.110; envelope-from=pete@petertodd.org;
helo=outmail148110.authsmtp.com;
Received: from outmail148110.authsmtp.com ([62.13.148.110])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V6Ouo-0001L0-GS for bitcoin-development@lists.sourceforge.net;
Mon, 05 Aug 2013 17:49:56 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r75HnkP1037388; Mon, 5 Aug 2013 18:49:46 +0100 (BST)
Received: from [25.13.141.185] ([24.114.68.193]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r75Hnfl8023210;
Mon, 5 Aug 2013 18:49:42 +0100 (BST)
User-Agent: K-9 Mail for Android
In-Reply-To: <51FFD722.5090403@gmail.com>
References: <EE3869FD-6D83-469A-BF4F-31B79CA9950F@grabhive.com>
<51FFCA9A.6010208@gmail.com> <51FFD722.5090403@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Peter Todd <pete@petertodd.org>
Date: Mon, 05 Aug 2013 13:49:36 -0400
To: Alan Reiner <etotheipi@gmail.com>,
bitcoin-development@lists.sourceforge.net
Message-ID: <09169cb2-cc59-4261-84e9-0769ec72af6b@email.android.com>
X-Server-Quench: 6907546a-fdf7-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgcUGUATAgsB AmUbWlxeVFR7XWA7 aQ5PbARZfExGQQRj
U1dMSlVNFEsqBhl5 WEhCWhlwdAdHeDBx Zk9hWj5dVUR9cEJ7
E1MCQTsBeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4wFzAx DxkfATJqAFUJTjky KRNO
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 24.114.68.193/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1V6Ouo-0001L0-GS
Subject: Re: [Bitcoin-development] Safe auto-updating
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: Mon, 05 Aug 2013 17:49:56 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Gregory Maxwell had some good ideas along these lines at the san jose conference. Extending gitian with these kinds of features would be a good approach.
But I think its worth thinking about attack models. A huge danger with auto-updating is that it is easy to target individuals; if I leave auto-updates on I am essentially trusting the developers capable of signing an update not to specifically try to attack me in the future, a much more risky thing to do than simply trusting them not to release a malicious release.
Sure you can try to implement anonymous downloads and similar mechanisms, but they all tend to be fragile with regard to deanonymization attacks.
A better way is to ensure that the act of making a release available for download must be public, even if you can control what binaries are made available to a particular target. You can do this by putting a commitment in the blockchain itself. Each person on the signing list creates a transaction with a special form from a specific pubkey that commits to the digest of the binaries, and the auto-update code refuses to update unless it sees that special transaction with a sufficient number of confirmations. The developers now can't make a special release for a specific target without letting the world know they did so, even under coercion.
They developers could of course still make a release with code inside targeting a specific individual, but in theory at least the public can check if their builds are reproducible, and start asking questions why not?
Alan Reiner <etotheipi@gmail.com> wrote:
>Indeed. You can hardcode a "distributor" public key in the software,
>and client software will only trust signed data from that key. Of
>course, the private key for that data is not kept on the server
>distributing the signed checksums. Ideally it would be kept offline,
>and the couple-times-per-year that you actually execute an upgrade, you
>sign the new checksums offline and upload the signed checksum to the
>distribution server. Then even if the server is compromised, the
>client-side software will not accept a bogus checksum because it won't
>bear the right signature.
>
>If you do this, it would be good to also have some kind of revocation
>process that can be used in the event of the offline key being
>compromised. You won't be able to "switch" keys, as that would defeat
>the purpose (the attacker who compromises the offline key could just
>issue a replacement with his own). Instead, it would be an
>irreversible
>broadcast that would force clients to start rejecting updates from that
>key. If the key is compromised (and find out), you broadcast the
>revocation and the users will stop auto-updating, and be given a
>warning
>that they should manually upgrade the software through trusted
>channels. It's not failproof, but it's a decent way to minimize damage
>if you discover compromise early enough.
>
>-Alan
>
>
>
>
>
>
>On 08/05/2013 11:54 AM, Daniel F wrote:
>> If you want package authentication, you should at least throw in some
>> digital signing, not just a checksum. With a compromised host, both
>the
>> checksum and binaries can be changed undetectably, but if there's a
>> signature made by a key that is not kept on the host, there's no way
>to
>> fake a valid binary.
>>
>> There may be other issues people would want to bring up, but surely
>just
>> a checksum is not sufficient.
>>
>> on 08/05/2013 10:39 AM Wendell said the following:
>>> For usability purposes, we at Hive would like to have an
>>> auto-updater
>> in our wallet app.
>>> What is a safe way to do this? I understand that Bitcoin-QT lacks
>>> such
>> an updater for security reasons... Has been thought out in more
>detail
>> since that decision was made?
>>> We have been toying around with the idea of placing one server
>>> behind
>> a Tor hidden service, whose only function is to output a checksum of
>the
>> update package. The theory is that if it is well-secured, it will at
>> least be immune to tampering at the physical hosting level.
>>> Any thoughts or advice about any of this?
>>> -wendell
>>>
>>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>>>
>>>
>>>
>>>
>------------------------------------------------------------------------------
>>> Get your SQL database under version control now!
>>> Version control is standard for application code, but databases
>havent
>>> caught up. So what steps can you take to put your SQL databases
>under
>>> version control? Why should you start doing it? Read more to find
>out.
>>>
>http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases
>havent
>> caught up. So what steps can you take to put your SQL databases under
>
>> version control? Why should you start doing it? Read more to find
>out.
>>
>http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>------------------------------------------------------------------------------
>Get your SQL database under version control now!
>Version control is standard for application code, but databases havent
>caught up. So what steps can you take to put your SQL databases under
>version control? Why should you start doing it? Read more to find out.
>http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8
iHkEAREIADkFAlH/5a8yHFBldGVyIFRvZGQgKGxvdyBzZWN1cml0eSBrZXkpIDxw
ZXRlQHBldGVydG9kZC5jYT4ACgkQpEFN739thozkAACeIu7GINlJqPObyZ+87vA+
2hMphHYAoI3CyuGuSr7xYm0pus0DVgnQc/vD
=nVJA
-----END PGP SIGNATURE-----
|
