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; 
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>
Subject: Re: [Bitcoin-development] Safe auto-updating
Precedence: list

-----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-----