Re: [Bitcoin-development] Safe auto-updating

2013-08-05 Thread Daniel F
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=49501711iu=/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=49501711iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Safe auto-updating

2013-08-05 Thread Alan Reiner
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=49501711iu=/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=49501711iu=/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=49501711iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Safe auto-updating

2013-08-05 Thread Jim
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=49501711iu=/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=49501711iu=/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=49501711iu=/4140/ostg.clktrk