4 ms·
For free software, I wonder if reproducible builds plus a "certificate transparency"-style check in the updater (only allow an update once several build servers
by cesarb 8y ago
For free software, I wonder if reproducible builds plus a "certificate transparency"-style check in the updater (only allow an update once several build servers, preferentially located in separate jurisdictions, have validated the build and published the corresponding source code) could help. That is, make it impossible to push a backdoor to a single user without making it public to everyone. Making updates anonymous (that is, never sending any ID which could be used to target an update to a specific user) might also help.
- cyphar 8y agoI don't think that's sufficient. We need devices that only allow software to run that has been signed by TPM-resident keys on the device. Updates are only attempted to be installed if the binary has been signed by multiple keys (by people in different jurisdictions) and then the device prompts the user to sign the update (which requires entering the TPM passphrase). Even if you managed to compromise all of the developers you couldn't run signed code on the device -- you'd need the user to install it. And for bonus brownie points we could have reproducible build checking (a-la certificate transparency) against the source repo, to see whether the binary is different to the official one. However, I think the threat model might have to be reconsidered (if all the developers are compromised, couldn't they upload a bad hash to the certificate transparency trail with a dummy version that only one user is given?). I might write a blog post about this actually, though I'd need better experts than myself in IMA (which is what you'd use on Linux for this) and other secure-boot work.