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.
https://github.com/theupdateframework/tuf
1. Talking TUF: Securing
Software Distribution
Justin Cappos, Trishank Kuppusamy, Vladimir Diaz,
Santiago Torres, Sebastien Awwad, Lukas Puehringer
New York University
3. What do these companies have in common?
They all had a publicly disclosed software update hack!
4. Repository compromise impact
● SourceForge mirror distributed malware.
● Attackers impersonate Microsoft Windows Update
to spread Flame malware.
● RubyGems compromised with RCE.
● Opera users automatically installed malware
signed by compromised key.
● Node Packaged Modules compromised.
● Attacks on software updaters have massive impact
○ E.g. South Korea faced 765 million dollars in damages.
5. Commonly used (bad) techniques
● Why not sign all the software on a community repository?
● This way, we know whether or not attackers have tampered with software after a
repository compromise.
● Couldn’t we already use previous systems --- GPG or TLS --- to do this?
6. The Problem with TLS
● Good
○ easy to set up
○ has nice lock icon users are trained to trust
● Bad
○ Lots of design / impl issues
○ Compromise repository -> game over
7. The Problem with GPG
● Good
○ Provides signature of software packages with offline
keys (private keys kept off repository) so that
attackers cannot tamper with packages after a
repository compromise.
● Bad
○ have to manually verify public keys
○ trust for anything usually implies trust for everything
○ Furthermore, only 4% of software projects provide
GPG signatures on PyPI, and 0.07% of users
downloaded GPG signatures between March and
April 2014.
8. ● TUF is a secure software update framework.
● Built on ideas discussed with some folks from Tor.
● Plug-and-play (like TLS), but compromise resilient.
● Goal: support a wide array of different configurations
○ Support, don’t judge!
“Survivable Key Compromise in Software Update
Systems” (CCS 2010).
2010-Present: The Update Framework (TUF)
22. Versions of metadata
django-1.7.1.tar.gz
django django-1.8.tar.gz
metadata
version
developers packages
● packages
○ django-1.8.tar.gz
■ hash: Y
○ django-1.7.1.tar.gz
■ hash: X
● version: 2
...there are different
versions of metadata
corresponding to
different versions of
packages.
The version number
of a metadata file (e.g.
2) does not
correspond with the
version number of
packages (e.g. 1.7.1).
25. TUF: snapshot
● Adds a “snapshot” of all metadata/packages.
version
package
django bcrypt flask
4
5
2
packages not installed,
but metadata downloaded version
package
django bcrypt flask
4
2
1
packages installed,
but with obsolete metadata
replay!
27. Version checking
● Compact “snapshot” of all metadata/packages.
version
package
django bcrypt flask
4
5
2
packages not installed,
but version downloaded version
package
django bcrypt flask
4
2
1
packages installed,
but with obsolete metadata
replay!
28. Is this as secure as hash checking?
● So what security attacks have we given up?
○ Not malware attacks, because package metadata
still signed with offline developer keys.
○ Not replay attacks, because snapshot metadata
cannot specify older version numbers.
29. Fast-forward attack
version
package
django bcrypt flask
4
5000
2000
packages not installed,
but version downloaded version
package
django bcrypt flask
4
5
2
packages not installed,
due to version mismatch
denied!
Only a mild,
denial-of-service
attack.
30. Okay, but is it as secure as hash
checking?
Yes!
● FF DoS (~= dropping requests)
○ Address by resetting version numbers after key
revocation.
31. Example setup for TUF
1. Responsibility separation (roles)
2. Multitrust signatures (a.k.a. two-man rule).
a. some roles like root may need multiple signatures from keys
3. Explicit and implicit revocation of keys.
a. individual roles / keys timeout
4. Minimizing risk (with offline keys).
5. Further selective delegation from targets role.
a. Gives trust without sharing keys, etc.
ε
timestamp
metadata packages
online
keys
offline
keys
signs metadata for
target
package
signs root keys for
delegates packages to
root
snapshot targets
A1
BC
A.pkg
C.gz
signs for packages
A.*B.*,C.*
*.pkg
A2
B.tar
32. Multi-trust signatures
● Can require multiple signatures for a role
○ Some keys can be lost / compromised and things work
>>> repository = create_new_repository("repository/")
>>> public_root_key = import_rsa_publickey_from_file("keystore/root_key.pub")
>>> repository.root.add_verification_key(public_root_key)
>>> public_root_key2 = import_rsa_publickey_from_file("keystore/root_key2.pub")
>>> repository.root.add_verification_key(public_root_key2)
# Threshold of each role defaults to 1.
>>> repository.root.threshold
1
# Set threshold then need to write / sign the new root file.
>>> repository.root.threshold = 2
>>> repository.root.load_signing_key(private_root_key)
>>> repository.root.load_signing_key(private_root_key2)
>>> repository.writeall()
34. ● Lots of good suggestions for changes to TUF
● Formal TUF Augmentation Proposal (TAP) process
○ Discuss ideas, when ‘close’ send TAP
○ We review closely
○ Test implementation
○ Approve
○ (Read TAPs 1 and 2 for details)
https://github.com/theupdateframework/taps/blob/master/tap1.md
Standardization process (TAPs)
35. ● TAP 3 -- multi-role signatures (Evan / Jake)
○ Alice AND Bob must both sign package A
○ Lets one have ‘unequal’ quorums
● TAP 4 -- pinning repository keys (Evan / Jake)
○ The user can control the root of trust for parts of the
namespace
■ Root role compromise !-> game over!
● TAP 5 -- specify URLs in root files
○ Makes it easy to change the repo location
● TAP 6 -- version numbers in root metadata (David)
● TAP ? -- hash chaining of timestamp metadata (???)
○ Coming soon?
https://github.com/theupdateframework/taps/blob/master/tap1.md
Standardization process (TAPs cont...)
38. Uptane: Securely updating automobiles
Work closely with vendors, OEMs, etc.
● Security reps from 79% of US cars
● Many top suppliers / vendors
Account for deployment concerns
● Solutions are only useful if deployed
● Accommodate existing infrastructure,
business relationships, etc.
Standardize and harden
● Working toward SAE certification
● Professional security audit
● Free / open source, detailed tests /
40. Uptane Timeline
40
● Current tasks:
○ High level spec (complete!)
○ Multi-group security analysis (complete!)
○ Detailed impl specification (RFC-style) (?complete??)
○ Reference implementation (in progress)
○ Compliance test cases (in progress)
○ Deployment recommendations document (in progress)
● Upcoming:
○ Technology demonstration (Oct 18)
○ Public security review
○ SAE Standardization
41. Future work: healthcare, infrastructure too
Healthcare systems:
● Often antiquated OSes / systems
● Only certified in a specific configurations
● Increasingly targeted
Infrastructure:
● Often antiquated OSes / systems
● Reliability is the focus, not security
○ Remote access needed
Security issues can have catastrophic impact!
45. Toto: Overview
Project owner Functionaries End User
What needs to be done Perform steps, provide
evidence
Verify
Layout
Link
Link
Link
Link
Link
Final
Product
46. Toto: Overview
Project owner
Defines the steps that are required in this project’s software
supply chain
Layout
● Only Alice and Bob can commit to
this VCS
● The build will be made using the
company’s Gradle buildserver
● The project will be added to a
docker recipe by Carl
● ...
47. Toto: OverviewFunctionaries
Perform steps and provide evidence as link metadata
Link
Link
Link
● Alice: I committed to the VCS
● Gradle buildserver: I compiled
alice’s commit
● Carl: I pulled and made a docker
image of all of this
51. Conclusion
51
● Securing software distribution, etc. is hard
● Notary provides strong guarantees for Docker containers
● Use TAPs to get changes into TUF (let’s discuss first)
● Let’s work together!
○ https://github.com/theupdateframework/
○ https://github.com/uptane
○ https://github.com/toto-framework
53. My background... (2003-2008)
● Built the first package manager designed specifically for OSVMs (Stork)
○ Deployed on the research infrastructure “PlanetLab”
■ Practical experience: thousands of VM instances over 8 years of use
○ Packages are cached in a special VM and shared
■ Disk, memory, and bandwidth savings
■ Additional security risks [USENIX ATC 2005], [LISA 2007]
54. 2008: Attacks on Linux package managers
● By changing unsigned metadata, we can compromise users.
● No protection against:
○ Arbitrary package attacks
○ Extraneous dependencies
○ Replay attacks
○ Mix-and-match attacks
“A Look in the Mirror: Attacks on Package Managers”
(CCS 2008).
55. Fixing Linux package managers
● Disclosed these security attacks via CERT (VU#230187).
● Major vendors have adopted our security architecture.
57. 2009: Tor
● Tor: “We heard about your work. Can you help us fix our software
updater?”
● Security is simple, right?
● How hard can this be anyway?
58. Thandy (Tor)
● The Thandy software updater for
Tor
○ A quorum of keys for root of trust.
○ Signing by different
compartmentalized key types.
○ Use online keys only to prevent freeze
attacks and
bound trust window.
59. Thandy (Tor)
● The Thandy software updater for
Tor
○ A quorum of keys for root of trust.
○ Signing by different
compartmentalized key types.
○ Use online keys only to prevent freeze
attacks and
bound trust window.
○ ...still not enough.
● Still found 8 security problems.
● Building your own secure software
updater is not trivial.