talking tuf: securing software distribution

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/

jcappos@nyu.edu

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.