Why not RPM and DPKG?

Why not just package your software as an RPM or a DEB file and provide updates using the provided tools? Both of these package formats support signing of the packages themselves, and the repository data can be signed to prevent attacks against the metadata. However, the main failing of both RPM and DPKG is their reliance on very few keys. Typically, only one key is used to sign both the packages and the repository data. Although you can use different keys to sign the repository and the packages, a compromise of either key would still be disastrous, because an attacker could execute rollback attacks and so forth.

TOR Begets TUF

You could also use Thandy. The Tor project [4] was originally funded by the US Naval Research Laboratory who needed, among other things, a way for people overseas to communicate securely without being detected. Since then, Tor has grown and established itself as a healthy open source project with widespread support.

Tor, however, faces some significant challenges when it comes to updates. Basically, people using Tor are trying to protect themselves from state-level attackers (e.g., governments), who can view and intercept Internet traffic either through technical means or by simply getting a court order. Also, Tor users want protection from attackers who create arbitrary web server or code-signing certificates. That means anything Tor uses to support updates must be resistant basically to every possible attack – with no reliance on third-party certificate authorities, DNS, servers, networks, and so on.

Additionally, Tor has to worry about people attacking the Tor project itself. The cost of sending someone in to install a keylogger on a laptop is not that much. There have been confirmed incidents of online poker players' laptops being physically compromised so that malware can be installed, and some of the people who use Tor play for much higher stakes (sorry, but I do love a bad pun). Thus, the Tor Project had to build an update system that would securely handle encryption keys as well as compromises of these keys without putting users at a significant risk. To do this, the Tor project created the "Thandy" updater, which in turn was forked: The Update Framework (TUF) was born [3].

TUF – Security vs. Usability

Users and administrators often have to make a trade-off between security and usability. Longer and more complex passwords are more secure, but people rarely remember them. Keeping encryption keys on a secured offline machine improves security but also makes usability a pain. If you need to sign something like software update metadata daily, or even hourly, it becomes unusable. Additionally, you can use separate keys for various functions; rather than relying on a single key to sign everything, you can use a separate key for each function or duty. Thus, the compromise of a single key will affect only that specific function; however, it also means you have more keys to manage.

You can also prepare for key compromises and make them more survivable [5] by using threshold keys, which are also referred to as quorum keys. TUF supports the use of threshold keys. This approach allows you to specify multiple keys, some or all of which must be used to sign data for it to be considered valid. For example, you can create five root keys and require that three or more be used for the other keys to be valid. In this way, you can survive the compromise of two keys without an adverse effect; the attacker won't be able to sign anything, and you will still be able to sign things properly. You'll also want to be able to revoke your encryption keys explicitly (i.e., if a server where a key is stored is compromised, you should stop using that key and generate a new one), and implicitly (i.e., keys should have a defined life span).

TUF takes a pragmatic and secure approach by splitting the keys into four roles: targets, delegated targets, release, and timestamp (Figure 1).

Figure 1: The overall architecture of TUF update signing.