From a translator: I stumbled upon TheUpdateFramework while searching for libraries that implement automatic software updates on the desktop. On the one hand, the description of the security aspects of software update systems presented below was interesting and detailed to me; on the other - for sure, in addition to academic studies, although under the wing of LinuxFoundation, you can find many suitable solutions. You can suggest options in the comments.

Security

We can consider a software update system “safe” if:

• she will find out about the latest available updates in a timely manner
• any files downloaded by the update system are correct, and
• no harmful consequences from checking or downloading files.

To achieve this, workable preventive strategies are required against many potential attacks.

Attacks and weaknesses

Listed below are some of the known attacks on software update systems, including weaknesses that make these attacks possible. To design a secure software update framework, you need to understand these attacks and develop protection strategies. Some of these shortcomings may be related to each other, depending on the architecture and implementation of a particular software update system.

• Install custom software . An attacker can substitute arbitrary files in response to requests for downloading and install anything he wants into the client system, even without determining the illegality of such actions.
• Attack rollback updates . The attacker provides the software update system with files of an older version than is currently installed on the client. The user installs a version that possibly contains vulnerabilities without the ability to find out that this version is outdated. Later, vulnerabilities can be exploited by an attacker.
• Rewind attacks . The attacker arbitrarily increases the version number, making it much higher than the current value, thus deceiving the software update system and forcing it to believe that any successive updates are actually trying to roll back the software version to the previous, outdated version. In some situations, for example, if there is the maximum possible version number, the offender can use this maximum so that the update system can never install a new update.
• Attacks of unlimited freezing . The attacker continues to return files that the client has already seen to the software update system. As a result, the client remains in the dark about new software versions.
• Attacks of endless data . In response to a request for downloading, the attacker returns an endless stream of data, directly causing harm to the client (for example, filling up a disk or RAM).
• Attacks a slow response . The attacker responds to clients with a very slow data flow, which ultimately leads to the fact that the client can not complete the update process.
• Attacks of excess dependencies . The attacker informs the client that the installation of the required software also requires the installation of third-party software ( hi, mail.ru - approx. Per. ). This third-party software may be from a reliable source, but nevertheless have known vulnerabilities that an attacker could exploit.
• Mixed combination attacks . The attacker returns to the client a snapshot of the repository that contains files that never existed in the same revision at the same time. This can lead to the installation of outdated versions of dependencies and other, more complex consequences.
• Installing other software . The attacker returns a trusted file to the client, which is simply not what the client wanted to install.
• Malicious mirrors that prevent updates . An attacker controls one of the repository mirrors and can use it to prevent clients from receiving updates from other, not infected mirrors.
• Key Compromise Vulnerabilities . An attacker who can compromise a single key in the system (or several keys, with a number of no more than a given threshold) can compromise clients. These attacks can occur both in the case of trusting a single online key (for example, when protecting updates only with SSL encryption), and in the case of a single offline key (for most software update systems that use keys for signing).

Safety principles

In order to make sure that the system is protected from all the attacks described above, the architecture and implementation of the Update Framework (TUF) relies on several basic concepts. Details of how TUF transmits the information described above can be found in the metadata documentation .

The trust

Trusting the downloaded files actually means assuming that the files were provided by a party without vulnerable architectural solutions. The two often elusive aspects of trust in a software update system are:

• Trust should not be granted forever. Trust must be revoked if it is not updated.
• Trust should not be given equally for all participants. This type of shared trust means that you can only trust those member files whose provision by this member is specified by the root role.

Key risk reduction (resistance to compromise)

Cryptographic signatures are an essential component of security in software update systems. The security of keys used in these signatures directly affects the security of clients that the system protects. Instead of naively believing that private keys can never be compromised, secure software update systems should foresee how to protect clients from the possibility of compromising these keys. This is the basic principle of resistance to compromise.

Securing customers when a key is compromised includes:

• Quick and safe key replacement and recall.
• Minimal trust in keys with a high risk of compromise. Keys that are stored online or used in automation systems should not pose an instant threat to customers in case of compromise.
• Using multiple keys and threshold / quorum signatures.

Integrity

Ensuring integrity in the Update Framework (TUF) applies not only to individual files, but also to the repository as a whole. It is pretty obvious that clients should verify that individual files are correct. Already not so obvious, but it is still very important for clients to be sure that the audit of the repository as a whole is correct. For example, if a trusted source provides two files, the software update system should see the latest versions of both files (not just one), and only those versions of these two files that exist in the repository at a time.

Relevance

Since software updates often fix vulnerabilities, it is important for software update systems to obtain the latest available versions. An attacker may try to force the client to install outdated versions of the software, or simply convince the client that there are no new updates.

Ensuring relevance means:

• Never accept files older than those already installed.
• Identify possible problems with receiving updates.

It is worth noting that if the attacker responds to customer requests, it is not always possible to conduct a successful update. However, the client must be able to determine the likelihood of updates that it cannot receive.

Implementation Security

In addition to a secure architecture, TUF also works against implementation vulnerabilities, including vulnerabilities common to software update systems. In some cases, the inclusion of additional information in the update metadata is used for this. For example, knowing the expected size of the downloaded file allows TUF to limit the amount of downloaded data. As a result, TUF is protected against the infinite data attack discussed above.