User:Gmaxwell/update checking requirements

Currently users of Bitcoin software seldom check the cryptographic signatures of their downloads, defeating their effectiveness. While some might say that it's the users own responsibility and thus fault if they do not, we know that the vast majority do not and this constitutes a systemic risk which we can and should correct.

Traditional approaches of simply imposing automated updates that verify signatures are ill-suited to a decenteralized system and potentially create risks for anyone with the signing keys as well as the system at large. Getting this kind of tool right requires addressing some subtle requirements.

You can imagine a tool that automatically downloads, verifies, and stages an upgrade for a user

Here are the properties which I think a good update tool must provide:

• Supports widespread platforms.
• Avoids thundering upgrades. Some problems have been avoided by having early adopters deploy first and then sound alarms before large numbers of users are impacted. This can be avoided by first staging the update and then waiting a random amount of time before notifying the user that an update is available. Users could express preferences ("I want to be an early adopter") and signers could express preferences ("This update is less important, slow roll it") to modulate this random time. Of course, a "I heard there is an update, give me it now" button can be provided so that users who want an update right away aren't forced to use a less secure update process.
• Utilize offline signing keys. Experience has shown that it is too difficult to maintain the security for keys kept on continually networked hosts, there is no reason updates can't be signed via offline devices, so they should be.
• Utilize multi-party signing (multisignature or threshold signature). Trusting any single party creates too much exposure both for the public and for the person themselves. (These last two properties also follow from the principle that the Bitcoin software itself should be secured by no process weaker than recommended strong processes people are using to secure their Bitcoins).
• Provide traceability of binaries to source code. Deterministic build processes like gitian allow signers to (somewhat) independently verify that the source and binaries agree. Blindly signing a binary someone else created adds little value, signing a verified deterministic build helps convert source integrity confidence to binary integrity confidence.
• Provide traceability of binaries to passing a test suite. Some tests are light enough that they should just be performed at install time on all systems, which makes them able to catch host interaction. But for more extensive tests the process which makes sure binaries agree with source could also attest that the implementation passes an extensive systems integration test.
• Support negative acknowledgement. The primary method we believe that many-eyes-make-(issues)-shallow is because it takes only one party to sound the alarm if an update is bad. But this isn't helpful if the communication doesn't reach people in time, if we make positive acknowledgement faster we must also make negative acknowledgement faster, otherwise we undermine our assumptions about the public sounding the alarm for bad updates. Keys which can only sign for negative acknowledgement are strictly less risky, so negative only keys could be included in the default list more liberally, since abuse of them could only yield an overridable dos attack against the update system. A perfectly reasonable NACK is "release has some major change which doesn't match the release notes" e.g. changes the supply of bitcoins.
• Support anti-jamming for NACKs. One problem with NACKs is that an attacker might just attempt to prevent users from learning about NACKs. One way to address this is to require a quorum and allow signatures to abstain. NACK anti-jamming could also be strengthened by having each ACK/NACK/Abstain commit to the ACK/NACK/Abstains the signing party knows about, creating an all or nothing property.
• Provides for release transparency. It should be infeasible for a special release to be issued just for some subset of users while everyone else gets something else. (We could potentially make use of Bitcoin itself, e.g. movement of a coin) to ensure there are no hidden releases, though this might encourage spammy use of Bitcoin and is probably not required. Requiring a quorum of signers also sets a minimum bar for how visible an update is.
• Provides for use-privacy. No party should be able to make use of the update process to easily enumerate the users running the software. This can be facilitated by fetching the updates and signatures via Tor. As a side effect it also reduces the ability to target updates at particular users.
• Support user configuration of requirements: Users should be able to single out particular parties whos signatures they will require or negative acknowledgements they'll automatically accept. In practice few users will do this, but hopefully higher value ones will and it will reduce the incentives to subvert the default configuration (and also provide pressure relief for people who are unhappy with the default configuration).
• Can provide self-contained artifacts. It should be possible to move some .sig file from a semi-trusted online system along with the release to some locked down system in order to have it verify an update without having direct access to the general Internet (e.g. it could be completely offline or only able to access the Bitcoin network via a gateway).
• Though the primary security here is "The same process that produced the version you're currently running produced the new version", it should be possible for keys to provide additional data like PGP signatures so that people auditing the default signing lists can easily independently verify the identities of the signers.
• Interact as well as possible with existing popular update systems: Some users expect to use things like pgp to verify downloads, so there should exist some thresholded RSA key whos signers only sign when the above process passes for a binary from their perspective, giving users without the fancy verifying tool an approximation of the same security. Some things like windows code signing must be signed up-front but at the very least should be thresholded as some users will pay attention to it at the exclusion of these other security mechanisms.

Beyond these things there are a number of additional mechanisms which could be employed to further increase confidence. For example, the main signing keys should be Bitcoin keys which could have coins assigned to them, and they could be considered only valid if at least that amount of coins was still assigned to them, creating an integrated bounty for revealing that a key has been compromised.

(Some of these things had previously been list at http://www.reddit.com/r/Bitcoin/comments/22jtxg/bitcoin_core_version_091_released/cgnww5o as well as many IRC and meat space conversations)