Nowadays, users expect their applications to remain up-to-date. Outside the walled gardens, vendors use a multitude of update systems with different security properties – an average desktop computer contains over 20 separate update mechanisms from as many vendors.
We here analyze a number of ways to deliver updates and show why, as a developer, your next update system should be based on The Update Framework, and, as an end user, you should demand it from your vendor.
Update identification and delivery mechanisms
Single path/executable delivery over HTTP
This is the most basic of transport mechanisms and still surprising- and unpardonably used nowadays. Even some government and banking sites inexcusably require you to download certificates or “configuration programs”, typically used to alter the operating system or browser’s security settings to accept insecure modes of operation in order for legacy applications to work. Manual operation, while inconvenient, at least lets you know what is about to happen (and when you have a choice, desist altogether). Automated update systems do not, though, and that adds insult to injury.
Needless to say, this delivery mechanism is absolutely insecure, as it is open to several kinds of attacks:
man-in-the-middle (MITM) attacks where the file is altered in transport to inject malware or viruses. This attach is particularly simple in public wifi networks.
attacks against the update repository, where the server holding the updates is broken into and the file is replaced
MITM attacks when the list of updates is retrieved
Delivery over HTTPS
Just one level above insecure HTTP delivery, HTTPS prevents MITM attacks (most of the time) by leveraging the global certificate authority (CA) public key infrastructure (PKI). The certificate used by the update server authenticates the accessed website and protects the integrity of the data in transfer (privacy is usually of no concern for updates delivered to the public at large). Several points of attack remain, though:
the global PKI relies on hundreds of CAs throughout the globe, and it is known that there are several rogue ones. In particular, state-sponsored groups have the ability to forge certificates either directly, by bypassing the CA identity checks, or via old-school coercion. A forged certificate allows such actors to redirect traffic directed to the update server to a machine of their control which will serve malicious updates.
while MITM attacks are prevented, successful attacks on the content delivery server allow to replace the update with a malicious one, which will alas be served securely
To sum up, HTTPS secures delivery, but does not by itself help identify the update and prove that it is legitimate.
Signed updates
In order to make sure the update is legitimate regardless of the delivery mechanism, it is necessary to authenticate the contents of the update, which is done by providing a trusted list of updates along with their cryptographic digests. The problem becomes how to establish trust in that list.
it can come from a trusted party via a secure delivery mechanism – for instance a list of updates delivered via HTTPS (kicking the bucket forward)
it can be signed digitally with a vendor-supplied private certificate
The second solution avoids the security issues related to the global PKI, as the private certificate can be generated by the vendor.
This update identification/delivery system is the minimum admissible with present-day technology. It is adequate when timeliness of update delivery is not critical (more on this below) and the release process does not involve many people, thus making it possible to keep tight control over the certificate used to sign the updates.
The Update Framework
The Update Framework (TUF) is the “OSI model” of update frameworks. Unless the OSI model, though, it is entirely practical and readily implemented. Sync Appliance updates are delivered using an embodiment of TUF.
TUF is designed to be flexible and usable in diverse scenarios, with well-defined roles for different participants in update creation and delivery, who each use different keys. It moreover protects against a multitude of attacks in all stages of the update process (creation, addition to update repository, delivery), and is resilient again key compromises at each level.
TUF defines the following roles, each with an associated key:
- root role: signs the certificates of other roles and is the ultimate source of trust
- targets role: signs the update artifacts
- snapshot role: signs the repository metadata and prevents attacks where different versions of these files are combined and presented to the user by the attacker
- timestamp role: signs a file used to guarantee freshness of the updates
Conclusion
In few words, TUF is the most fleshed-out update framework out there.
As a user, when you see a vendor used it, you know it had some concern for security.
As a developer, this is the one you should be using barring a good reason. Even if you do not require a specific role right now, it might become necessary in the future. Unlike functionality, security is inherently averse to backwards-compatibility: you usually cannot allow seamless interoperation with earlier, insecure mechanisms, as this would render newly introduced security mechanisms moot (this is the gist of downgrade attacks). So using the TUF makes your update system future-proof.