public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jim <jim618@fastmail.co.uk>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Safe auto-updating
Date: Mon, 05 Aug 2013 18:14:00 +0100	[thread overview]
Message-ID: <1375722840.32601.6177639.39D38240@webmail.messagingengine.com> (raw)
In-Reply-To: <51FFD722.5090403@gmail.com>

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



  reply	other threads:[~2013-08-05 17:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 14:39 [Bitcoin-development] Safe auto-updating Wendell
2013-08-05 15:54 ` Daniel F
2013-08-05 16:47   ` Alan Reiner
2013-08-05 17:14     ` Jim [this message]
2013-08-05 17:49     ` Peter Todd
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=1375722840.32601.6177639.39D38240@webmail.messagingengine.com \
    --to=jim618@fastmail.co.uk \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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