Talking TUF: Securing Software Distribution
2 likes2,381 views
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.
![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]](https://image.slidesharecdn.com/tufdockersummit2016-161010203221/85/Talking-TUF-Securing-Software-Distribution-53-320.jpg)
Talking TUF: Securing Software Distribution
- 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
- 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
- 17. Explicit and Implicit Revocation 17 A C B Signature threshold: Two signatures A B B A
- 18. 18 Design
- 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
- 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.