The CERT Coordination Center recommends automated software updates, at least for security updates. With the emergence of IoT, we see more and more devices running out-of-date software even when they roll out fresh off the assembly line. It is important that devices integrate some method of automated patching to ensure that devices remain protected through their lifespan. Out-of-date and unpatched systems are one of the most common risks seen in field studies. With the emergence of the Internet of Things, patching is no longer limited to traditional computers and mobile devices, but also control systems, building automation, vehicles, and other critical systems.

However, there have also been numerous instances of security vulnerabilities in the update mechanisms themselves. If an update solution is not properly designed, it can introduce vulnerabilities into a system rather than mitigate them. Although there are some emerging standards for software updates, it would be useful to publicize some best practices that developers, architects and security analysts can refer to. Below, several emerging standards and "drop-in" update frameworks are listed.

First, a definition of "automated software updates". This guidance refers to the ability of an application, operating system, or device to download new data from the Internet which replaces and/or augments existing data. This data can consist of software, firmware, bitstreams, configuration information, or reference data (e.g., updated maps). "Automated" refers to the fact that the original application or device checks for new versions on a regular basis and, if any are available, downloads and installs them without user intervention.

One overarching principle is that you, as a developer or product owner, cannot trust the underlying network that is used to transfer software updates to your application or device. Your data may transit multiple countries, multiple carriers and ISPs, cellular systems, unencrypted WiFi, or other networks. Even if you are designing an application that is only intended to communicate across a single corporate network, you should assume that this will not always be true. A variety of technologies can cause a corporate network to intentionally or unintentionally bridge untrusted networks: BYOD, mesh networks, virtualization, cloud computing, etc.

With those basic assumptions covered, we can roughly divide the security controls for software updates into four categories:

1. Integrity of Update
2. Transport Security
3. Client Security
4. Server Security

For the rest of this article, the new information being transferred is referred to as the "update", the device or app being updated as the "client", and the origin of the update as the "server". Note that in some cases, there may be some sort of intermediate "staging" server. In fact, it is often desirable to allow updates to be staged in some way so that customers can perform regression testing before deploying the updates.

Integrity of Update

The single most important step in securing the update process is assuring the integrity of the update itself. The two components of this are ensuring that the update comes from a trusted source, and ensuring that the update has not been modified while in transit. There are several key points to consider to achieve these goals.

1. The only secure way to do this is to use public key cryptography to digitally sign the update. That is, the server signs the update with a private key and the client validates the update with the matching public key. This confirms both that the update comes from a trusted source (or at least a source with access to the private key) and that it has not been modified (or the signature would not match.)
2. A hash or cyclic redundancy check (CRC) is not considered secure because the hash or CRC must be sent with the update. Therefore, anyone who modified the code would modify the hash / CRC to match the modified code. A hash might be a reasonable security measure if the hash can be transferred out-of-band and securely.
3. If a hash is used, it should be SHA-2 or SHA-3, not SHA-1 or MD-5. The latter two are not considered cryptographically secure. A CRC is never considered cryptographically secure.
4. Symmetric key cryptography can provide proof of integrity and authentication, but not non-repudiation.
5. Symmetric key cryptography requires a unique key to be shared between the server and each individual client (device or copy of an application.) This is a huge number of keys which are stored on user-owned systems. Given the ease with which digital information can be copied and transmitted, these keys are highly vulnerable to compromise.
6. Digital signatures using public key cryptography can mitigate these issues, if they are properly implemented. The server signs the update with its private key. The client verifies the update with the server's public key. The public key must be signed by a Certificate Authority that the client trusts. There must be a way to remove and/or expire both public keys and Certificate Authorities, as well as a way to provision new ones, on the client. It is more likely that the keying material will be compromised or stolen than that the cryptography itself will be broken (cracked.)
7. Optionally, public key or symmetric key encryption may also be used to encrypt the update for confidentiality. This can be to protect intellectual property, credentials, personally identifiable information, or other sensitive data. However, it should be assumed that a determined attacker can defeat this cryptography, since the data eventually needs to be processed on a user-owned device.

Transport Security

In order to achieve defense-in-depth, an update solution should also secure the communication channel over which the update is transferred. As one of our assumptions is that the underlying communications infrastructure cannot be trusted, it is necessary to add security mechanisms on top of that infrastructure. This is usually accomplished by implementing Transport Layer Security (TLS) between the client and the server, including any staging server. All of the guidelines for public key cryptography listed under "Integrity of Update", above, still apply to the TLS implementation. There are also a few additional precautions that should be taken.

1. Ensure that the client does "hostname verification" to ensure that it is connecting to the correct server. This is particularly important if you use public Certificate Authorities, as anyone can acquire a valid public key certificate from them.
2. If there are any intermediary or staging servers, make sure that the communications are properly secured to and from those servers.
3. Of particular concern is the case where an update for a device is delivered from the server to an app running on an intermediary such as a laptop or mobile device, and then delivered via USB, Bluetooth, WiFi, etc., to the device. The security posture of this "last hop" will typically be different than a transfer over a public Internet connection, so the risks should be considered separately.
4. Depending on your business model, you may also want to authenticate the client to the server, via client certificates, password, or other mechanism. Like encryption, this shouldn't be assumed to be sufficient protection to stop a determined attacker from reverse engineering the update, but there may be other business reasons to authenticate clients.
5. It's recommended to use encryption for all network communications to prevent eavesdropping or Man-in-the-Middle attacks.

Client Security

For purposes of these guidelines, we only consider security on the client which affects the update process. Several features are recommended.

1. The client should store any credentials as securely as possible.
2. The client should log all updates and any errors in the update process.
3. Any dependencies should be secured to the same level of confidence as the update itself. The client should defend against an attacker trying to force the install of a malicious dependency.
4. The client should be resistant to downgrade attacks, where an attacker forces the install of an earlier, and potentially less secure, version.
5. The update be should be able to be uninstalled (that is, a rollback without data loss) if necessary. It should be able to be installed manually if the automatic update fails.
6. The client should attempt to detect and/or prevent Denial-of-Service attacks. Specifically, this means an attack that prevents the update from occurring.

Server Security

Again, this only considers security controls relevant to the update process.

1. The server should follow best practices for an Internet-facing computer.
2. The server should log all updates and any errors in the update process.
3. Clients should not be able to perform a Denial-of-Service attack where they prevent other clients from updating.
4. The server should resist a Man-in-the-Middle attack that provides fake information about the client (such as a very high version number) which would cause the server not to send the update.
5. The server should perform version control, code signing, and other software development and distribution tasks correctly.

References / Conclusion

The CERT Coordination Center recommends automated software updates, at least for security updates. In supporting the user base, ensure that your update process supports these key categories: verification of the integrity of the update; encryption and/or authentication of the communication channel for the update transfer; and the security requirements of the client and server.

There are several ongoing efforts to standardize the update process:

1. ITU X.1373, Secure software update capability for intelligent transportation system communication devices. https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=13548. Proprietary standard.
2. The Update Framework (TUF). Methodology and implementations in various programming languages.
3. Open Mobile Alliance (OMA) Software Component Management Object (SCOMO). http://www.openmobilealliance.org/release/SCOMO/V1_1-20130521-A/OMA-ER-SCOMO-V1_1-20130521-A.pdf. Publicly available standard.

Hopefully these "Quick Reference" guidelines will help you standardize your own update processes or evaluate those of vendors you use. If you would like to suggest other best practices or have comments or questions, please contact us.