►
From YouTube: Securing Content Distribution with The Update Framework (TUF) - Lukas Puehringer & Joshua Lock
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Securing Content Distribution with The Update Framework (TUF) - Lukas Puehringer, NYU, Tandon School of Engineering & Joshua Lock, VMware
Time and again we see insecure content delivery systems – such as software updaters, and configuration management systems – being compromised to deliver malicious content. The Update Framework (TUF) was designed not only to prevent and detect attacks, but also with risk mitigation (reducing the damage from a successful attack) as a core principle. Being the first security-focused project to graduate in the CNCF, TUF is widely used both inside and outside of the cloud ecosystem. It is in use today in places including CNAB, AWS Labs BottleRocket OS, and Datadog. With several ongoing integrations being actively developed including the Python Package Index (PyPI), Drupal, TYPO3 and Joomla. We will introduce TUF by describing the basic architecture, including how TUF protects against a variety of real-world attacks on any content distribution infrastructure. Then we look forward to discussion with the audience as we deep dive on a current technical issue.
A
B
A
Okay,
let's
see
what
we're
gonna
talk
about
today,
so
first
we
will
talk
very
briefly
about
content
distribution.
What
we
actually
mean
by
that
and
what
challenges
exist
then
we'll
give
a
tough
primer,
tough
being
short
for
the
update
framework
and
talk
about
the
pillar
stuff
is
based
on
and
the
principles.
A
It
it
uses
and
yeah
and
how
it
all
faces,
the
challenges
of
content
and,
last
but
not
least,
we'll
talk
about
how
to
get
involved
in
the
project,
because
this
is
a
maintainer
track
talk
of
a
of
an
open
source
project.
So
we
want
you
to
get
excited
and
help
us
out,
but
first
things.
First,
content,
distribution.
A
A
The
content
distribution
is
part
of
the
software
supply
chain
and
a
very
crucial
part
too,
because
it's
at
the
user
boundary
in
this
software
supply
chain
graph
by
software
supply
chain.
I
mean
all
the
steps
that
are
carried
out
in
order
to
write
software
to
test
it,
build
it
package
it
and
to
finally
ship
it
out
so
being
at
the
edge
of
this
graph
content.
Distribution
needs
to
be
done
carefully
because
whatever
gets
distributed
is
what
should
be.
A
What
the
well,
let's,
let's
put
it
differently
so
once
software
leaves
the
premises
of
the
software
producers
there
is,
they
will
have
a
hard
time
to
enforce
any
quality
assurance
on
the
software.
So
it
should
make
sure
that
the
software
they
intend
the
user
to
have
is
actually
the
software
that
they
get.
A
B
But
remote
update
systems
are
regularly
compromised
to
deliver
to
deliver
malicious
content
to
users,
and
you
can
see
kind
of
a
logo
soup
of
systems
that
have
been
compromised
effectively
to
deliver
malicious
content,
and
this
continues
to
happen.
You
know
to
this
day
as
more
software
is
produced
that
leverages
new
and
different
software.
Update
systems
continue
to
be
deployed
with
flaws
that
are
susceptible
to
the
kinds
of
compromise
that
enable
someone
to
deliver
malicious
content.
B
So,
relatively
recently,
a
large
computer
systems
vendor
had
the
piece
of
software
on
their
devices
that
they
sold.
That
was
used
to
update
the
firmware
and
drivers
and
whatnot
on
those
devices,
and
that
software
update
system
was
compromised
to
deliver
malicious
content.
That
was
targeting
specific
users.
So
the
current
malicious
content
was
delivered
to
huge
swathes
of
users
and
a
subset
of
those
users
were
targeted
to
kind
of
activate
that
religious
content
and
do
unkind
things,
and
that
continues
to
be
the
case.
B
You
know
we
continue
to
see
these
kinds
of
attacks
happen
against
multiple
types
of
software
play
systems,
and
so
you
might
think,
surely
there's
an
easy
solution
to
that.
And
could
you
just
switch
the
next
slide?
Please,
and
so
a
couple
of
things
might
come
to
mind
when
you're
thinking
of
this
being
a
relatively
easy
problem
or
solved
problem.
B
One
solution
that
might
come
to
mind
is
that
we
all
became
so
used
to
seeing
the
little
padlock
in
our
browser.
Url
bars
that
the
browsers
don't
even
show
it
anymore,
so
that
uses
to
indicate
the
presence
of
certificates,
hd
https
certificates,
so
ssl
tls
certificates,
protecting
your
connection
and
that
kind
of
is
like
a
very
low
amount
of
security
for
a
software
update
system.
It
does
improve
on
pure
http's
kind
of
status
square
volt,
but
it's
still
a
single
point
of
failure.
B
There's
a
single
p,
which
is
kept
online
in
the
system's
memory,
which
is
printer
compromise
and
even
then,
all
the
the
only
kind
of
guarantee
that
an
ssl
tls
certificate
gives
is
that
you
have
received
content
from
the
server
that
you
intended
to
connect
to.
It
doesn't
provide
any
additional
guarantees
about
the
integrity
of
that
content
or
that
the
server
that
you
did
connect
to
was
even
the
one
you
intended
to,
because
you
know
your
software
update
system
is
really
indicating
which
servers
it's
actually
connecting
to.
B
B
This
is
a
positive
step
because
it
gives
you
offline
keys
and
that's
good.
The
keys
are
not
kept
consistently
in
memory,
so
that's
an
extra
level
of
protection,
but
as
soon
as
you
start
to
introduce
offline
keys,
you
have
to
worry
about
things
like
key
distribution
and
revocation.
So
key
management
is
known
to
be
a
difficult
problem,
as
is
knowing
which
keys
to
trust
the
gpg
or
any
kind
of
signing
system.
B
B
B
And
so
companies
were
just
blindly
installing
software
from
the
public
repository
that
was
malicious
thinking.
They
were
installing
the
packages
they
intended
from
their
internal
systems,
and
I
think
this
is
interesting
for
two
reasons:
one.
We
actually
have
an
enhancement
to
the
tough
specification
which
would
help
protect
against
an
attack
like
this.
B
But
I
think
it's
also
just
indicative
of
how
content
delivery
is
a
very
attractive
target
for
military
software
and
tuff
provides
a
very
solid
foundation
for
for
protecting
against
known
attacks
and
for
building
protections
against
future
attacks.
On
top
of
so
with
that
kind
of
introduction
I'll
hand
back
to
lucas
to
talk
us
through
some
of
the
principles
of
tough.
B
A
A
A
So
tough
has
mechanism
mechanisms
to
reduce
the
impact
of
such
a
key
loss
or
compromise,
and
speaking
of
recovery,
tough
was
built
with
recovery
from
wait.
Yeah
stuff
was
built
with
recovery
of
keys
in
mind,
so
that's
built
into
the
core
design
of
tough.
Let's
see
how
tough
can
do
all
those
things
regarding
the
content.
Protection
tough
employs
cryptographic
signatures
for
that
uses
is
asynchronous
asymmetric,
cryptography
and
science,
both
the
content,
but
also
the
entire
repository
so
signing
one
software
package,
for
instance,
or
one
container
image,
is
pretty
good.
A
It
gives
you
a
guarantee
about
the
integrity
of
that
file
and
that's
what
many
or
most
software
updaters
maybe
do.
It's
not
nothing
out
of
the
ordinary,
but
it's
also
important
to
ensure
that
the
entire
repository
is
consistent,
because
an
attacker
who
can
control
which
files
are
served
might
be
able
to
serve
files
that
are
benign
by
themselves
each
of
them,
but
not
if
they're
served
together.
A
That
means
that
if
a
an
attacker
can
intercept
traffic
and
tell
the
client
that
there
are
no
new
updates,
the
client
will
detect
this
at
some
point
because
the
local
signatures
will
expire
and
the
client
will
ask
for
new
new
signatures
so
much
to
protect
in
the
content.
What
about
reducing
impact
of
kilos.
A
A
For
all
of
these,
a
separate
role
exists
in
the
tough
design
and
the
separate
signing
keys
separation
of
responsibilities
allows
you
to
still
continue
operation
if
one
key
is
lost.
Same
goes
for
threshold
signing,
that's
like
separation
of
responsibilities
within
one
responsibility,
so,
for
instance,
for
the
role
that
deals
with
the
integrity
of
the
contents.
A
A
A
And
if
a
compromise
happened,
then
the
repository
content
repository
needs
to
make
sure
that
the
client
gets
some
keys
and
taf
allows
to
do
this
in
band
in
band
mechanisms
by
creating
a
hierarchical
trust
delegation
tree
where
you
have
a
root
role:
that's
the
route
of
trust
and
that
delegates
thrust
to
all
the
other
roles
that
we
already
talked
about.
So
there's
the
timestamp.
B
A
A
Secure
pipi
downloads
with
signed
repository
metadata
pep
stands
for
python
enhancement
proposal,
and
this
is
basically
a
design
document
that
describes
how
tough
can
be
used
to
secure
the
python
package
index,
and
these
are
the
roles
on
the
top
of
this
diagram.
You
can
see
the
root
role,
then
you
can
see
below
it.
A
You
can
see
the
other
roles
I
talked
about,
and
the
spins
role
roles
are
basically
also
targets,
roles
that
are
responsible
for
subsets
of
the
content,
integrity
and
the
arrows
show
the
trust
delegation
relationships
so
root
signs
for
time,
snapshot,
targets
and
for
itself
and
targets
can
sign
for
delegated
targets.
I'm.
A
But
it
is
also
not
as
hard
as
it
looks
and
and
this
lets
him
transition
to
our
next
part
of
the
talk.
Tafe
is
a
very
friendly
community
and
there
are
a
lot
of
people
who
will
love
to
help
you
to
get
started
with
tough,
to
better
understand
it,
to
integrate
it
with
your
package
manager
or
to
help
you
start
contributing.
If
you
are
interested
to
do.
A
B
So
yeah,
if
you
have
seen
this
brief
introduction
to
secure
content,
delivery
and
attacks
on
those
systems
and
how
tough
helps
protect
against
them,
maybe
you'd
like
to
know
how
to
get
involved
with
tough.
This
is
a
maintainer
track
talk
after
all,
so
if
you
could
switch
to
the
next
slide,
lucas
tough
is
effectively
three
main
projects.
The
primary
project
is
actually
the
specification.
B
That
was
mentioned
for
the
pipe
I
work
and
this
process
is
for
documenting
information
about
the
tough
system
or
proposing
new
features
to
the
tough
system
and
I'm
going
to
talk
about
each
of
those
three
projects
in
a
lot
more
detail.
So
the
specification,
if
you
were
interested
in
the
specification
itself
and
how
you
might
contribute
to
that
project,
probably
the
easiest
way
that
anyone
can
contribute
to
tough,
is
to
review
the
specification
and
suggest
any
clarifications
we
have.
B
B
I
think
it
would
be
really
beneficial
if
some
aspects
of
the
specification,
specifically
the
detailed
client
workflow,
had
more
anchors
so
that
you
could
refer
to
specific
points
in
the
workflow,
for
example,
from
a
code
comment
or
when
discussing
with
a
specification,
and
everyone
would
be
able
to
follow
that
link
and
understand
exactly
which
part
of
this
package
talking
about
another
ease
of
use.
Change
we
would
like
to
make
to
the
specification
is
that
today,
it's
all
written
as
prose
and
various
parts
of
the
prose
are
repetitive.
B
B
The
other
way
you
might
get
involved
if
you're
code
minded
is
contributing
to
the
reference
implementation
and
we're
currently
undertaking
a
refactoring
effort
to
provide
a
really
exemplary
implementation
of
tough
with
the
python
reference
implementation,
and
this
is
motivated
in
part
by
lesbian
software
engineers,
but
also
in
part
by
the
integration
into
the
price
and
packaging
index.
Where
we've
been
extending
the
reference
implementation
to
be
a
little
bit
more
modular.
So
you
can
now
plug
in
kind
of
storage,
back
ends
used
to
assume
that
you're
writing
files
to
disk.
B
Now,
that
might
be
cloud
storage,
and
it
could
be
a
number
of
other
things
with
the
modularity
that
we've
implemented.
We've
also
recently
extracted
out
networking
operations
so
pip,
which
is
the
the
python
packaging
installer,
has
a
very
mature
code,
codebase
for
interacting
or
performing
network
operations,
and
we
wanted
the
tough
implementation
to
be
able
to
take
advantage
of
that.
B
So
we
very
much
welcome
contributors
to
come
and
help
us
with
our
ongoing
refactoring
efforts.
We're
really
looking
to
make
this
a
very
good
pythonic.
Our
project
looking
to
be
very
clearly
mapped
to
the
specification
very
easy
to
understand
so
that
it
could
become
kind
of
supplementary
to
the
specification
as
a
way
to
understand
what
is
happening
in
tough.
B
And
then,
if
python
and
specification
writing
is
not
your
thing,
there
are
multiple
other
implementations
of
stuff
that
I
think
it
would
be
great
if
you
were
interested
in
contributing
to.
We
have
a
largely
dormant
go
implementation
as
part
of
the
update
framework
organization
on
github
would
very
much
welcome.
B
And
then
there
are
two
implementations
of
tough
and
rust.
One
is
rustuf
which
is
kind
of
automotive
focused
and
is
used
in
various
automotive
systems
today,
and
then
there's
tough
to
ughh,
which
is
the
system
that
adds
secure,
updates
to
aws's
bottle
rocket
os,
which
is
their
linux
container,
host
operating
system,
and
then
another
way
that
you
might
care
to
get
involved
is
to
participate
in.
Some
of
the
integrations,
so
integrations
are
how
we
describe
taking
tough
and
integrating
it
into
an
existing
software.
B
A
big
system,
if
you
have
a
software
update
system,
you
work
on
that,
you
think,
would
benefit
from
tough
we'd,
be
happy
to
discuss
how
to
approach
these
integrations
with
you.
But
there
are
also
some
ongoing
integration.
Efforts
that
you
might
wish
to
contribute
to.
The
python
package
index
is
adopting
the
reference,
implementation
and
adding
tough
to
warehouse,
which
is
the
open
source
project
that
backs
pipei.
B
So
any
contributions
to
the
reference
implementation
are
going
to
benefit
that
project,
but
you
might
also
want
to
contribute
to
warehouse
directly,
and
there
are
various
tasks
left
to
to
enable
that
effort,
and
I
also
mentioned
the
php
cms-
is
collaborating
on
a
php
implementation
of
tough.
They
have
the
peer
computer
for
implementation,
as
well
as
various
plugins
for
the
composer
system
to
enable
tough
and
other
security
related
features,
and
I'm
sure
they
will
welcome
contributions
from
excited
participants
and
then,
with
that,
before
we
just
switch
over
to
questions.
B
If
you're
interested
in
learning
by
you
can
go
to
our
website
the
update
framework
dot
io,
you
can
join
the
tough
channel
on
the
cncf
slack
workspace
or,
if
you're,
into
email
like
I
am,
you
can
send
an
email
to
the
update
framework
at
googlegroups.com
and
I've
added
some
references.
If
you'd
like
to
go
and
read
a
bit
more
about
tough
and
some
of
the
ongoing
integrations
and
implementations,
you
can
follow
these
links
and
learn
some
more
that
way
so
with
that
yeah.