Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Talking TUF: Securing Software Distribution

1,285 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Talking TUF: Securing Software Distribution

  1. 1. Talking TUF: Securing Software Distribution Justin Cappos, Trishank Kuppusamy, Vladimir Diaz, Santiago Torres, Sebastien Awwad, Lukas Puehringer New York University
  2. 2. What do these companies have in common?
  3. 3. What do these companies have in common? They all had a publicly disclosed software update hack!
  4. 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. 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. 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. 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. 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. 9. Design Principles 9 Responsibility Separation Multi-signature Trust Explicit and Implicit Revocation Minimize Individual Key and Role Risk
  10. 10. Design Principles 10 Responsibility Separation Delegate roles to divide responsibilities
  11. 11. Responsibility Separation 11 Content Timeliness
  12. 12. Design Principles 12 Minimize Individual Key and Role Risk Compromise Risk = Probability x Impact
  13. 13. Minimize Role & Key Risk 13 Root High-impact role? => Highly-secure keys Timeliness Online keys? => Low-impact role
  14. 14. Design Principles 14 Multi-signature Trust (t, n) signature threshold required for trust
  15. 15. Multi-signature Trust 15 A B A No risk to clients. Signature threshold: Two signatures
  16. 16. Design Principles 16 Explicit and Implicit Revocation
  17. 17. Explicit and Implicit Revocation 17 A C B Signature threshold: Two signatures A B B A
  18. 18. 18 Design
  19. 19. 19 Root Targets (projects) TimestampSnapshot
  20. 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. 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. 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. 23. Replay attack version package django bcrypt flask 4 5 2 version package django bcrypt flask 3 2 1 replay! old & vulnerable!
  24. 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. 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. 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. 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. 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. 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. 30. Okay, but is it as secure as hash checking? Yes! ● FF DoS (~= dropping requests) ○ Address by resetting version numbers after key revocation.
  31. 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. 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. 33. Target (Project) Delegation in PyPI (PEP 480)
  34. 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. 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. 36. Integrations of TUF (some on-going)
  37. 37. Related effort: Uptane (securing automotive software updates)
  38. 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. 39. Uptane: Securely updating automobiles Current design Latest downloaded metadata Latest downloaded encrypted image Boot- loader Previous metadata ECU keys
  40. 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. 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. 42. Related effort: Toto (securing the software supply chain)
  43. 43. 43
  44. 44. Toto
  45. 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. 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. 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. 48. Toto: Overview End user Verifies the metadata Link Link Link Link Link Final Product Layout
  49. 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. 50. Wrapping up
  51. 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. 52. Thanks! Questions? https://theupdateframework.com https://isis.poly.edu/~jcappos/ jcappos@nyu.edu
  53. 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. 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. 55. Fixing Linux package managers ● Disclosed these security attacks via CERT (VU#230187). ● Major vendors have adopted our security architecture.
  56. 56. 2009: Mission accomplished! ...or is it???
  57. 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. 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. 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.

×