* [Bitcoin-development] Safe auto-updating @ 2013-08-05 14:39 Wendell 2013-08-05 15:54 ` Daniel F 0 siblings, 1 reply; 7+ messages in thread From: Wendell @ 2013-08-05 14:39 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 654 bytes --] 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 [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 841 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Safe auto-updating 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 0 siblings, 1 reply; 7+ messages in thread From: Daniel F @ 2013-08-05 15:54 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Safe auto-updating 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 0 siblings, 2 replies; 7+ messages in thread From: Alan Reiner @ 2013-08-05 16:47 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Safe auto-updating 2013-08-05 16:47 ` Alan Reiner @ 2013-08-05 17:14 ` Jim 2013-08-05 17:49 ` Peter Todd 1 sibling, 0 replies; 7+ messages in thread From: Jim @ 2013-08-05 17:14 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Safe auto-updating 2013-08-05 16:47 ` Alan Reiner 2013-08-05 17:14 ` Jim @ 2013-08-05 17:49 ` Peter Todd 2013-08-07 4:32 ` Wendell 1 sibling, 1 reply; 7+ messages in thread From: Peter Todd @ 2013-08-05 17:49 UTC (permalink / raw) To: Alan Reiner, bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Safe auto-updating 2013-08-05 17:49 ` Peter Todd @ 2013-08-07 4:32 ` Wendell 2013-08-07 8:41 ` Mike Hearn 0 siblings, 1 reply; 7+ messages in thread From: Wendell @ 2013-08-07 4:32 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2317 bytes --] That multisignature/blockchain commitment idea seems really solid, Peter. Thanks very much indeed everyone, this is all very helpful. Much to research and think about. Interestingly, a thread is presently raging on liberationtech about Tor Browser Bundle, and the subject of automatic updates has come up. Gregory Maxwell responded thusly (cross-posting for completeness): > _please_ don't deploy automatic updates in a sensitive environment > like this without at least quorum signatures (like gitian downloader) > and timed quarantine with negative signatures (harder to make strong > absent a jamming proof network). -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 5, 2013, at 7:49 PM, Peter Todd wrote: > 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? [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 841 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Safe auto-updating 2013-08-07 4:32 ` Wendell @ 2013-08-07 8:41 ` Mike Hearn 0 siblings, 0 replies; 7+ messages in thread From: Mike Hearn @ 2013-08-07 8:41 UTC (permalink / raw) To: Wendell; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3502 bytes --] As you're Mac specific you could just use a modified Sparkle or something like that. Even if you want to use a stock Sparkle, I have some code that does threshold RSA. My intention was to use it for the Android wallet but I never found the time. I can send you a copy if you want. But it's easier and more robust to modify the update framework. Threshold RSA would only be interesting if you wanted to use the Mac app store, for example. On Wed, Aug 7, 2013 at 6:32 AM, Wendell <w@grabhive•com> wrote: > That multisignature/blockchain commitment idea seems really solid, Peter. > > Thanks very much indeed everyone, this is all very helpful. Much to > research and think about. > > Interestingly, a thread is presently raging on liberationtech about Tor > Browser Bundle, and the subject of automatic updates has come up. Gregory > Maxwell responded thusly (cross-posting for completeness): > > > _please_ don't deploy automatic updates in a sensitive environment > > like this without at least quorum signatures (like gitian downloader) > > and timed quarantine with negative signatures (harder to make strong > > absent a jamming proof network). > > -wendell > > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 > > On Aug 5, 2013, at 7:49 PM, Peter Todd wrote: > > > 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? > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 4413 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-08-07 8:42 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2013-08-05 17:49 ` Peter Todd 2013-08-07 4:32 ` Wendell 2013-08-07 8:41 ` Mike Hearn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox