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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1V6Nwi-0008Qx-U0
for bitcoin-development@lists.sourceforge.net;
Mon, 05 Aug 2013 16:47:48 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.44 as permitted sender)
client-ip=209.85.213.44; envelope-from=etotheipi@gmail.com;
helo=mail-yh0-f44.google.com;
Received: from mail-yh0-f44.google.com ([209.85.213.44])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V6Nwh-0000FI-Q3
for bitcoin-development@lists.sourceforge.net;
Mon, 05 Aug 2013 16:47:48 +0000
Received: by mail-yh0-f44.google.com with SMTP id c41so1554719yho.17
for <bitcoin-development@lists.sourceforge.net>;
Mon, 05 Aug 2013 09:47:42 -0700 (PDT)
X-Received: by 10.236.142.105 with SMTP id h69mr11684588yhj.174.1375721262344;
Mon, 05 Aug 2013 09:47:42 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126]) by mx.google.com with ESMTPSA id
v61sm37615229yhp.24.2013.08.05.09.47.40
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 05 Aug 2013 09:47:41 -0700 (PDT)
Message-ID: <51FFD722.5090403@gmail.com>
Date: Mon, 05 Aug 2013 12:47:30 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <EE3869FD-6D83-469A-BF4F-31B79CA9950F@grabhive.com>
<51FFCA9A.6010208@gmail.com>
In-Reply-To: <51FFCA9A.6010208@gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1V6Nwh-0000FI-Q3
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 16:47:49 -0000
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
|
