Updating software is one of the most important ways to keep users and organizations secure. But how can software be updated securely? That’s the challenge that The Update Framework (TUF) aims to solve.
Justin Cappos, assistant professor at New York University, detailed how TUF works and what’s coming to further improve the secure updating approach in a session at last week’s DockerCon 17 conference in Austin, Texas. Simply using HTTPS and Transport Layer Security (TLS) to secure a download isn’t enough as there have been many publicly reported instances of software repositories that have been tampered with, Cappos said.
“If you have the green HTTPS padlock in your browser, it tells you the browser has a secure connection to a server,” he said. “It doesn’t say anything about whether the server has a valid update or know what the correct update is and whether the server itself has been compromised.”
If an attacker has broken into a software repository, all the users who attempt to update from the repository could potentially be compromised, even if HTTPS is being used to secure the data transport, according to Cappos.
“I started a project eight years ago along with my collaborators to try to make a mechanism for doing software updates that are resilient to compromises of the infrastructure,” he said. “Hackers will be able to get into parts of your infrastructure; the goal with TUF is that even if that happens, it doesn’t mean the security of the whole system is compromised.”
A core part of the design of TUF is that it can support multiple types of deployment models and environments, without the need to rip and replace existing infrastructure.
There are several basic design principles behind TUF, the first one being a separation of responsibilities. Cappos said that parties that are trusted to do one set of actions are not trusted for all functions. TUF’s design also integrates a multi-signature trust model, which requires that two or more digital keys for trust and authenticity.
“So if a single key is compromised and you have a threshold of two keys, there isn’t much risk to clients,” Cappos said.
TUF also includes both explicit and implicit trust revocation as part of its design. Cappos explained that one way to do trust revocation in TUF is by explicitly signing new metadata that states that trust should be revoked. With implicit revocation, there is metadata that must be refreshed in a specific amount of time and if that data is not updated, clients will stop trusting it.
“Issues are revoking trust are very central in TUF, since we’re assuming that parts of your infrastructure will become compromised,” he said.
While TUF provides a resilient model for protecting the integrity of updates, it does have limitations. An area that TUF doesn’t help to protect is the extended software supply chain, Cappos said. That is, if a malicious component is injected into a third-party component and the component thereafter is integrated into a project or software repository, TUF doesn’t help.
To help solve the problem of integrity in the distributed software supply chain, there is an effort related to TUF called “in-toto” that uses a similar model to verify authenticity. Cappos said the promise of in-toto is to provide a broader model for software protection that makes sure that all software that ends up in a project is validated.
“Securing software distribution is hard,” Cappos said.