If you want to compromise millions of machines and users, software distribution and software updates are an excellent attack vector. Using public cryptography to sign your packages is a good starting point, but as we will see, it still leaves you open to a variety of attacks. This is why we designed TUF, a secure software update framework. TUF helps to handle key revocation securely, limits the impact a man-in-the-middle attacker may have, and reduces the impact of repository compromise. We will discuss TUF's protections and integration into Docker's Notary software, and demonstrate new techniques that could be added to verify other parts of the software supply chain, including the development, build, and quality assurance processes.

1. Securing the Software Supply Chain
with TUF and Docker
Santiago Torres
Ph.D student, NYU
Justin Cappos
Professor, NYU

2. There exists an attack vector that...

3. Many Victims...

4. Does crypto just work?
Easy?

5. Does a simple solution
work?
Easy?

6. Does a simple solution
work?
Easy?

7. Easy?

8. Easy?

9. Easy?
Possible?

10. Goals:
● compromise
resilience
Enter TUF!

11. Goals:
● compromise
resilience
● support, don’t
judge!
Enter TUF!

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

13. TUF Design Principles
Responsibility
Separation
Delegate roles
to divide
responsibilities

14. Responsibility Separation
Content Timeliness

15. TUF Design Principles
Minimize
Individual Key
and Role Risk
Expected Damage
~=
Probability×Impact

16. Minimize Expected Damage
Root
High-impact role? → Highly-secure keys
Timeliness
Online keys? → Low-impact role

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

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

19. TUF Design Principles
Explicit and
Implicit
Revocation

20. Root TimestampSnapshot
Targets
(projects)

21. Standardized / Used

22. Is docker vulnerable to
these kinds of attacks?
What about
Docker?

23. A long time ago
(in technology terms)...

24. Docker content trust
integrates TUF in order
to sign and protect
Docker manifests.
Signing Docker
images

25. ● Root: user
● Targets: user
● Snapshot: content-trust*
● Timestamp: content-trust
The TUF specific roles
are as follows
Role
breakdown

26. In order to sign the
metadata, the docker
cli tool will talk to the
content trust server
before pushing to the
registry.
How to sign

27. Docker Today

28. Key compromise
Key compromised Malicious content Rollback, freeze,
mix and match
Denial of service
Timestamp (online) No No Limited
Snapshot (online*) No No Limited
Targets (offline) No (*) No (*) Limited
Root (offline) Yes Yes Yes

29. Key compromise
Key compromised Malicious content Rollback, freeze,
mix and match
Denial of service
Timestamp (online) No No Limited
Snapshot (online*) No No Limited
Targets (offline) No (*) No (*) Limited
Root (offline) Yes Yes Yes

30. Things TUF does not
protect against
Beyond TUF

32. Supply chain compromises

34. Final
Product
much like TUF, in-toto uses roles
in-toto: overview
Project owner Functionaries End User
Defines what needs to be
done
Perform steps, provide
evidence
Verify
Layout
Link
Link
Link
Link
Link

35. ✔ ✔
Introducing in-toto
✔
✔

36. Conclusion
● Securing software distribution, etc. is hard
○ Use TUF -- standardized, widely used, security audited...
● Docker Content Trust provides strong guarantees for
Docker images
● in-toto will further improve security

37. TUF
• TAP 3 -- multi-role signatures
○ Lets one have ‘unequal’ quorums
• TAP 4 -- pinning repository keys
○ 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
• TAP 7 -- TUF conformance testing
Discuss with us, then submit (TAP 1/2)
Standardization process (TAPs)

38. Thank You!
Let’s work together!
https://theupdateframework.com
https://in-toto.io
@docker #dockercon