Implement privacy-minded designs and policies.

As someone who develops or supplies software, you and your organization have an obligation to consider the risk that your software update channel presents to your users. As a responsible software distributor, you should take steps to defend your users against misuse of this channel. Similarly, users should prefer software distributors like you—ones that offer these defenses.

The First Line of Defense: Cryptographic Signatures

The most basic protection that every software distributor should offer is strong cryptographic signatures over the updates. As a software distributor, you should have a secret key, and your users should know about the corresponding public key. They protect their systems during the update process by verifying that the proposed update is signed by your public key. The security depends on your retaining exclusive control over the corresponding secret key so that malicious updates will not verify.

However, your secret key can be compromised (i.e. used to sign malicious updates) by legal compulsion, technical attack, or economic coercion. So more accountability is needed for a trustworthy update system than signatures alone.

Defense Against Targeted Attack

One possible attack on a user via software updates is the targeted distribution of malware. That is, an attacker who gains control of a distributor’s secret key can sign a malicious update and ship it only to the targeted user. Other users will continue to see the typical, non-malicious update channel.

Mirrorable Distribution

To bolster user defense against targeted attack, you should adopt “mirrorable distribution.” This means enabling users to pass information about available updates between one another, or allowing any number of intermediaries to copy and re-distribute (“mirror”) that information. If the attacker cannot predict where the user will pull their update from and cannot identify the user when they do an update, it is significantly harder to target a specific user. Letting a user fetch software updates anonymously from a range of sources concretely demonstrates that it is likely to be difficult to subject them to targeted attack.

In contrast, it is problematic to cryptographically sign software updates that are specific to a particular user or group of users. Targeted software updates facilitate targeted malware. For example, Apple’s iOS will not update unless it verifies a signature over the specific identifier for an individual phone or other device. This is dangerous both because it facilitates and incentivizes targeted malware and because it means Apple can “fingerprint” devices. You should ensure there is no tradeoff between end-user privacy and secure software updates.

Binary Transparency

An additional form of defense against targeted attack is an accountability mechanism known as binary transparency.

A mechanism protected by binary transparency will refuse to install an update unless the software has been verifiably logged in a global, irrevocable, auditable log. Website certificates — the mathematical objects behind the lock symbol in your web browser’s address bar — are already logged in a similar way. There are many ways to do this technically, but the tools are still relatively new and not widely tested. Mozilla is leading the way on this, but more work is needed, including tools for auditors to review binary transparency logs to highlight unusual behavior.

Auditability and Verifiability

If you take software update safety seriously, you will want to hold yourself accountable to your users. Accountability starts with auditability and verifiability. Even when individual users do not do their own audits or verification, the fact that others can do so provides a level of "herd immunity” — flawed updates can be detected and corrected even if your company is prevented from doing so.

Free/Libre and Open Source Software, also known as “FLOSS,” has the benefit of being readily auditable. FLOSS is a contract between the software distributor and the software user — it says that the human-readable source code that corresponds to the software update will be available to the user for inspection and improvement. With inspectable source code, it becomes much harder to hide malware inside software updates and patches. And with modifiable source, it becomes easier to fix problems that may have been introduced by the initial supplier. While some vendors will continue to sell proprietary software, visible and independently fixable code brings important security advantages.

You can also offer additional reassurance against malware with reproducible builds (a.k.a. deterministic compilation). Reproducible builds focus on how a developer translates software from code written by software engineers (source code) to machine code that computers can read and run (binaries). If the build is reproducible, the set of tools that do that translation (compiler, assembler, etc., sometimes referred to collectively as the “toolchain”) can not be modified to inject malware into those binaries. A compromised toolchain is not a theoretical attack.

If an uncompromised toolchain acting on the same source code produces a binary completely identical, down to the last bit, to all the other binary versions compiled by the vendor, then we can be confident that the vendor’s toolchain was not compromised. If not, it suggests that something may be, but is not necessarily, wrong. Toolchains sometimes produce minor differences between binaries because the compiled version includes trivial varying elements such as timestamps, tags indicating the name of the compiling computer, or more esoteric harmless changes. But serious security flaws can also be tiny, which makes them difficult to distinguish from inconsequential variation. With a reproducible toolchain, anyone who compiles the source code themselves can verify that it exactly matches a binary offered by a vendor (which is what the vast majority of software users are going to download).

Reproducible builds provide the most meaningful protection for users of Free/Libre and Open Source Software, because FLOSS vendors have already committed to having meaningful, visible source code that other people can review, modify and, double-check for themselves. But even if you are a vendor of completely proprietary software, you can take advantage of reproducible builds internally, as a way of ensuring that an order can’t be placed on one part of the organization (e.g., the build/release team) without other parts (e.g., the team that verifies reproducibility) knowing about it. If you have contractual agreements to provide copies of source code to auditors (even if you supply prorietary, non-FLOSS software), you can make reproducibility a part of their audits. And if you make a public commitment to reproducible builds, you will let your users know that a compromised toolchain can’t be used as an excuse for shipping malware.

Among other things, reproducible builds can protect individual software developers from extortion or personal attack because any malware slipped into a build through compromise of their build systems will be discovered as soon as someone else compiles the source code independently and discovers the mismatch. If you employ software developers, you can simultaneously reduce your organization’s attack surface, and reduce potential threats to your employees with this improvement.

Build reproducibility has in recent years become much more of a focus within the developer community, and non-reproducibility is increasingly considered a bug. Thanks to years of effort, the majority of widely used free and open source software packages, including the Apache webserver, the Linux kernel, and the Tor Browser are now reproducible, and work is ongoing across the ecosystem to establish this as a new norm in software development.

Providing Responsible Software Updates

Your users depend on you to provide them with updates that are concrete improvements and are not designed to harm them. While all software developers will make mistakes, you can provide your users with concrete defenses against potential malware and put in place systems that provide deterrence against attempts to use your update channels for stealthy injection of malware.

As a software user, if your preferred software distributor doesn’t apply the mechanisms and principles described above, consider encouraging them to adopt these approaches, or consider other software distributors that can offer you comparable functionality with better protections.

The technical protections above should of course be combined with legal and policy guidelines that make it clear that the software update channels should be inviolable as a critical piece of public infrastructure. But even if we get legal and policy constraints that keep some governments from trying to abuse these channels, less principled governments and non-governmental actors (organized crime, industrial espionage, etc.) may attempt to ship malware by these channels, so the technical guards described here are a necessary part of any healthy software ecosystem.