Peter Todd [ARCHIVE] on Nostr: š Original date posted:2013-08-05 š Original message:-----BEGIN PGP SIGNED ...
š
Original date posted:2013-08-05
š Original message:-----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 at 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 at 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 at 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 at 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-----
š Original message:-----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 at 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 at 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 at 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 at 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-----