Talking TUF - Securing Software Distribution by Justin Cappos (New York University)

Written by GemmaG (Gemma Gordon)
Published: 2016-10-06 (last updated: 2016-10-07)

Background

The Update Framework (TUF) secures new or existing software update systems by providing a specification and library that can be flexibly and universally integrated or natively implemented. The update procedure is notoriously susceptible to malicious attacks and TUF is designed to prevent these and other updater weaknesses.

Docker's Notary project integrates the Go implementation of TUF with Docker Content Trust to verify the publisher of Docker images.


Justin loves software update systems!

Collective work by full-time developers and PhD students at New York University

All major tech companies that produce software use software updates, and many have publicly disclosed software update hacks that have affected them.

Repository compromise impact

  • nation-state level actor attacks
  • one of the most damaging attacks was in 2013 with three quarters of a billion dollars of damage.
  • Flame malware: impersonated Microsoft Windows Update

Commonly used (bad) techniques

  • TLS: good: easy; nice icon that users are trained to trust bad: lots of design and implementation issues; compromise possible

  • GPG: good: signature of packages with offline keys bad: have to manually verify public keys; trust for anything implies trust for everything; only 4% of software projects provide GPG's signatures

2010-now: TUF

  • secure software update framework
  • build on ideas discussed with Tor
  • plug and play (like TLS) but compromise resilient

GOAL: support a wide array of different configurations and workflows

Design Principles

  • responsibility separation: rather than a trusted key, we want to have different people with different roles - different keys that do different things. Delegate roles to divide responsibilities where signatures are only trusted based on their agreed roles.
  • minimise individual key and role risk: compromise risk = probability x impact. Keys that have a lot of responsibility need to be able to be used as online tokens, and those that need to be used in an online manner should allow only a small amount of damage. High-impact role -> highly-secure keys; online keys -> low-impact
  • multi-signature trust: signature threshold required for trust.
  • explicit and implicit revocation: ability to designate a key as compromised (explicit). Expiration date allows implicit revocation

Design

1: root role: root of trust which tells you about other roles. Commonly used in key revocation and top level role revocation 2: top level target (projects): this is the correct key for this package 3: snapshot role: these are versions of projects 4: timestamp role: information on last update

Snapshot role is important based on the type of malware. Can take old metadata/old version and target that with malware (replay attack) and tell users to install that version. The snapshot role stops this by telling you about the correct version to use. Found that some of the mirrors for the linux distribution were serving very out of date versions.

  • Eager verification in TUF 0.1 User downloads all package metadata to verify snapshop data - to prevent replay attacks and not blindly trust administrators.

  • Secure lazy verification in TUF 1.1 Distribute version numbers only - user downloads only snapshot and desired package metadata allowing you to trust administrators. Prevents replay attacks more efficiently than eager verification, BUT is more open to a fast-forward attack SO need to handle this by resetting version numbers after key revocation.

Example setup for TUF

1: responsibility separation (roles) 2: multitrust signatures 3: selected delgations

Selected delegations in Python (PyPI) mix of delegations to online and offline keys so if someone breaks into the repo they can only mess around with very new projects. 90% people only download packages that are >1 month old so most users are still safe.

Standardisation Process (TAPs)

  • lots of good suggestions for changes
  • formal TUF augmentation proposal process (TAP): lots of TAPS online and on the way to being added and standardised. e.g. version numbers in root metadata; pinning repository keys; multi-role signatures etc.

Integrations of TUF

  • Docker
  • CoreOS
  • Flynn
  • OCaml
  • Python
  • Ruby

Related Efforts

  • Uptane Securing automotive software updates. Funded by Homeland Security.

  • working closely with vendors (US manufacturers), 80% of US cars

  • upcoming demo on Oct 18th

  • Do have a version working that is passing through standardisation.

  • Likely to be in your car in 5 years - help us discover problems!

  • healthcare and infrastructure

  • elevators

  • pacemakers

  • Toto Securing the software supply chain. TUF only solves part of the problem. Once you are ready to send your package to clients, that is where TUF operates. What about before that in the supply chain? Can we secure the entire chain so that if people break into different parts we can protect people?

Secure the individual components and the links between them in the process so that when you go to download some software you can see it has passed through a variety of secure steps.

e.g.

  • project owner: propose the layout, defines the steps that are required in the project's software supply chain.
  • functionaries: people who perform the steps - sign individual pieces of link metadata
  • end user: verify the metadata and validate that the layout was followed and it went through the correct steps

DEMO

  • blank directory
  • run a scrip to set up some data to get started and apply rules that dictate how the software is created.
  • functionary: packages it up which creates a new link metadata file.
  • generate keys for functionaries Alice and Bob: Alice will do the "write code" step and sign everything with Alice's key. Now Bob will package everything up and will create file and sign metadata using his key.
  • Now can copy those link files, go into the project owner directory, copy the link layout and if there are no bugs or malware then the output will pass.

If tampered, an exception would show and the system would error out.

Timeline for toto

  • high level spec coming in ~1 week
  • reference implementation ~1-2 weeks

Upcoming:

  • internal use ~2-3 weeks
  • compliance test cases ~3 weeks
  • external beta testing ~1-2 months
  • broad public release....

Conclusion

  • Securing software is difficult
  • Notary provides strong guarantees for Docker
  • Use TAPs to get changes into TUF
  • Look at uptane, toto and TUF on GH


Q&A

Q: In the example Alice was also the project owner which you normally wouldn't do - just for ease of use. This layout was set up saying it was ok for a single dev to produce the software, the process is correct and will pass. The layout could say that there are multiple devs and they need to review eachothers changes. Most companies have these measures in place usually - there is a checking process before committing to master. We are trying to get you to add signatures and then crytographically checking the signatures to ensure the process is correct.

Q: What guarantees do you have that VI is not already tampered with? I'll take this to the BOF session tomorrow! You can have an env or platform that you have a reason to have more trust in, which provides better guarantees. We are not saying it isn't possible for someone to get in and trick, but having this does provide better guarantees than not having it.