From: Peter Todd <pete@petertodd•org>
To: Alan Reiner <etotheipi@gmail•com>,
bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Safe auto-updating
Date: Mon, 05 Aug 2013 13:49:36 -0400 [thread overview]
Message-ID: <09169cb2-cc59-4261-84e9-0769ec72af6b@email.android.com> (raw)
In-Reply-To: <51FFD722.5090403@gmail.com>
-----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-----
next prev parent reply other threads:[~2013-08-05 17:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 14:39 Wendell
2013-08-05 15:54 ` Daniel F
2013-08-05 16:47 ` Alan Reiner
2013-08-05 17:14 ` Jim
2013-08-05 17:49 ` Peter Todd [this message]
2013-08-07 4:32 ` Wendell
2013-08-07 8:41 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09169cb2-cc59-4261-84e9-0769ec72af6b@email.android.com \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox