Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of fastmail.co.uk
	designates 66.111.4.25 as permitted sender)
	client-ip=66.111.4.25; envelope-from=jim618@fastmail.co.uk;
	helo=out1-smtp.messagingengine.com; 
Message-Id: <1375722840.32601.6177639.39D38240@webmail.messagingengine.com>
From: Jim <jim618@fastmail.co.uk>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Date: Mon, 05 Aug 2013 18:14:00 +0100
In-Reply-To: <51FFD722.5090403@gmail.com>
References: <EE3869FD-6D83-469A-BF4F-31B79CA9950F@grabhive.com>
	<51FFCA9A.6010208@gmail.com> <51FFD722.5090403@gmail.com>
Subject: Re: [Bitcoin-development] Safe auto-updating
Precedence: list

One approach you could use would be to use bitcoin signing on 
a list of the build artifacts together with their SHA256 hashes.

If you have a look at the MultiBit release notes you get the 
overall idea:
https://multibit.org/releases/multibit-0.5.13/release.txt

Currently these aren't machine readable but you can imagine
having a machine readable statement with:
+ a list of the files in the build
+ their SHA256 hashes
+ the above bitcoin signed by multiple signatures e.g. 2 of 3

The client can then download the file, check the signature,
check the hashes and knows which files to download.
The acceptable Bitcoin addresses for signatures would
be a whitelist in the client code.


On Mon, Aug 5, 2013, at 05:47 PM, Alan Reiner 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


-- 
https://multibit.org    Money, reinvented