talking tuf: securing software distribution
TRANSCRIPT
Talking TUF: Securing Software Distribution
Justin Cappos, Trishank Kuppusamy, Vladimir Diaz, Santiago Torres, Sebastien Awwad, Lukas Puehringer
New York University
What do these companies have in common?
What do these companies have in common?
They all had a publicly disclosed software update hack!
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.
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?
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
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.
● 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)
Design Principles
9
Responsibility Separation
Multi-signature Trust
Explicit and Implicit
Revocation
Minimize Individual Key and Role Risk
Design Principles
10
Responsibility Separation
Delegate rolesto divide
responsibilities
Responsibility Separation
11
Content Timeliness
Design Principles
12
Minimize Individual Key and Role Risk
Compromise Risk=
Probabilityx
Impact
Minimize Role & Key Risk
13
Root
High-impact role? => Highly-secure keys
Timeliness
Online keys? => Low-impact role
Design Principles
14
Multi-signature Trust
(t, n)signature threshold
required for trust
Multi-signature Trust
15
A
BA
No risk to clients.
Signature threshold:Two signatures
Design Principles
16
Explicit and Implicit
Revocation
Explicit and Implicit Revocation
17
A
C
B
Signature threshold:Two signatures
A
B
B
A
18
Design
19
Root Targets(projects) TimestampSnapshot
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!
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...
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).
Replay attackversion
packagedjango bcrypt flask
4
5
2
version
packagedjango bcrypt flask
32
1
replay!old & vulnerable!
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
developermetadata
snapshot
administratormetadata
hash
hash
hash
version
version
version
1
2
3
5
4
User downloads all package metadata to
verify snapshotmetadata.
Why? To prevent replay attacks, and not blindly
trust administrators.
TUF: snapshot
● Adds a “snapshot” of all metadata/packages.
version
packagedjango bcrypt flask
45
2
packages not installed,but metadata downloaded version
packagedjango bcrypt flask
4
21
packages installed,but with obsolete metadata
replay!
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
developermetadata
snapshot
administratormetadata
version
version
version
version
version
version
1
2
3User downloads only snapshot + desired package
metadata!
Trust administrators to specify accurate
snapshot metadata.
Version checking
● Compact “snapshot” of all metadata/packages.
version
packagedjango bcrypt flask
45
2
packages not installed,but version downloaded version
packagedjango bcrypt flask
4
21
packages installed,but with obsolete metadata
replay!
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.
Fast-forward attack
version
packagedjango bcrypt flask
4
5000
2000
packages not installed,but version downloaded version
packagedjango bcrypt flask
4
5
2
packages not installed,due to version mismatch
denied!
Only a mild, denial-of-service
attack.
Okay, but is it as secure as hash checking?
Yes!● FF DoS (~= dropping requests)
○ Address by resetting version numbers after key revocation.
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
onlinekeys
offlinekeys
signs metadata for
targetpackage
signs root keys for
delegates packages toroot
snapshot targets
A1
BC
A.pkg
C.gz
signs for packages
A.*
B.*, C.*
*.pkgA2
B.tar
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()
Target (Project) Delegation in PyPI (PEP 480)
● 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)
● 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...)
Integrations of TUF (some on-going)
Related effort: Uptane (securing automotive software updates)
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 /
spec...
Uptane: Securely updating automobiles
Current design
Latest downloadedmetadata
Latest downloadedencrypted image
Boot-loader
Previousmetadata
ECUkeys
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
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!
Related effort: Toto (securing the software supply chain)
43
Toto
Toto: OverviewProject owner Functionaries End User
What needs to be done Perform steps, provide evidence
Verify
Layout LinkLink
LinkLink
Link
FinalProduct
Toto: OverviewProject 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
● ...
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
Toto: Overview
End user
Verifies the metadata
LinkLink
LinkLink
Link
FinalProduct
Layout
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 (???)
Wrapping up
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
Thanks!
Questions?
https://theupdateframework.com
https://isis.poly.edu/~jcappos/
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]
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).
Fixing Linux package managers
● Disclosed these security attacks via CERT (VU#230187).● Major vendors have adopted our security architecture.
2009: Mission accomplished!
...or is it???
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?
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 andbound trust window.
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 andbound trust window.
○ ...still not enough.● Still found 8 security problems.● Building your own secure software
updater is not trivial.