The document discusses the challenges of securing software distribution, highlighting various past software update hacks and their impacts. It introduces The Update Framework (TUF) as a solution, emphasizing principles like responsibility separation, multi-signature trust, and minimizing key compromise risks. The framework aims to provide a robust and resilient system for software updates amidst evolving security threats.

1. Talking TUF: Securing
Software Distribution
Justin Cappos, Trishank Kuppusamy, Vladimir Diaz,
Santiago Torres, Sebastien Awwad, Lukas Puehringer
New York University

2. What do these companies have in common?

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)

9. Design Principles
9
Responsibility
Separation
Multi-signature
Trust
Explicit and
Implicit
Revocation
Minimize
Individual Key
and Role Risk

10. Design Principles
10
Responsibility
Separation
Delegate roles
to divide
responsibilities

11. Responsibility Separation
11
Content Timeliness

12. Design Principles
12
Minimize
Individual Key
and Role Risk
Compromise Risk
=
Probability
x
Impact

13. Minimize Role & Key Risk
13
Root
High-impact role? => Highly-secure keys
Timeliness
Online keys? => Low-impact role

14. Design Principles
14
Multi-signature
Trust
(t, n)
signature threshold
required for trust

15. Multi-signature Trust
15
A
B
A
No risk to clients.
Signature threshold:
Two signatures

16. Design Principles
16
Explicit and
Implicit
Revocation

17. Explicit and Implicit Revocation
17
A
C
B
Signature threshold:
Two signatures
A
B
B
A

18. 18
Design

19. 19
Root
Targets
(projects) TimestampSnapshot

20. Malware attack
django-1.7.1.tar.gz
bcrypt-1.1.1.tar.gz
flask-0.10.tar.gz
django
bcrypt
flask
django-1.8.tar.gz
repository (compromised)
user
malware!

21. Versions of metadata
django-1.7.1.tar.gzdjango
metadata
version
developers packages
● packages
○ django-1.7.1.tar.gz
■ hash: X
● version: 1
Just as there as different
versions of packages...

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).

23. Replay attack
version
package
django bcrypt flask
4
5
2
version
package
django bcrypt flask
3
2
1
replay!
old & vulnerable!

24. TUF: eager verification
django-1.7.1.tar.gz
bcrypt-1.1.1.tar.gz
flask-0.10.tar.gz
django
bcrypt
flask
django-1.8.tar.gz
repository
user
developer
metadata
snapshot
administrator
metadata
hash
hash
hash
version
version
version
1
2
3
5
4
User downloads
all package
metadata to
verify snapshot
metadata.
Why? To prevent
replay attacks,
and not blindly
trust
administrators.

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!

26. Secure lazy verification
django-1.7.1.tar.gz
bcrypt-1.1.1.tar.gz
flask-0.10.tar.gz
django
bcrypt
flask
django-1.8.tar.gz
repository
user
developer
metadata
snapshot
administrator
metadata
version
version
version
version
version
version
1
2
3
User downloads
only snapshot +
desired package
metadata!
Trust
administrators to
specify accurate
snapshot
metadata.

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()

33. Target (Project) Delegation in PyPI (PEP 480)

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...)

36. Integrations of TUF (some on-going)

37. Related effort: Uptane (securing
automotive software updates)

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 /

39. Uptane: Securely updating automobiles
Current design
Latest downloaded
metadata
Latest downloaded
encrypted image
Boot-
loader
Previous
metadata
ECU
keys

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!

42. Related effort: Toto (securing the
software supply chain)

43. 43

44. Toto

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

48. Toto: Overview
End user
Verifies the metadata
Link
Link
Link
Link
Link
Final
Product
Layout

49. Timeline
49
● Currently:
○ High level spec (release coming ~1 week)
○ Reference implementation (“complete” ~1-2 weeks)
● Upcoming:
○ Internal use (~2-3 weeks)
○ Compliance test cases (~3 weeks)
○ External beta testing (~1-2 mo)
○ Broad public release (???)

50. Wrapping up

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

52. Thanks!
Questions?
https://theupdateframework.com
https://isis.poly.edu/~jcappos/
jcappos@nyu.edu

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.

56. 2009: Mission accomplished!
...or is it???

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.