►
From YouTube: Securing Content Repositories with the Update Framework (TUF) - Marina Moore, NYU & Joshua Lock
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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 Repositories with the Update Framework (TUF) - Marina Moore, NYU & Joshua Lock, VMware
The Update Framework (TUF) is a framework for secure content delivery and updates that protects against many known attacks on software update systems. In this talk, Joshua Lock and Marina Moore will describe how TUF works, why content delivery systems need the protections offered by TUF, and share some recent developments in TUF and related projects. Following this introductory content, we will deep dive into proposed new features for TUF by reviewing a TUF Augmentation Proposal (TAP). Come to this talk to learn about how many organizations, including Docker, Amazon, and Google secure software updates and how you can get involved.
A
Say:
hello:
everyone,
I'm
marina
moore,
I'm
a
phd
student
at
nyu
in
the
secure
systems
lab
working
with
justin
capos
and
many
others
on
tough
and
other
projects.
My
co-presenter
joshua
lock,
unfortunately,
was
not
able
to
make
it
here
today,
but
I
want
to
give
them
credit
for
help
with
the
slides
and
and
everything
else.
So.
A
A
When
you
want
to
download
this
this
piece
of
content,
another
thing
that
can
go
wrong
is
you
can
be
redirected
to
a
whole
other
place
to
to
download
the
package,
and
that
can
also
be
a
bad
way
to
go
and,
in
addition,
the
entire
content
repository
itself
can
be
compromised
in
any
of
these
different
pieces
of
content.
On
this,
repository
can
be
replaced
with
malicious
versions
of
of
these
packages,
image,
artifacts
or
whatever
it
is
that's
being
stored,
and
this
has
happened
in
practice.
There
have
been
these
are.
A
A
This
is
just
a
very
tempting
vector
for
attractors,
because
it's
a
place
where
you
know
you're
installing
a
piece
of
software
and
then
going
to
run
it
on
your
machine,
and
so
if
the
attacker
can
can
mess
with
what
you're,
installing
it's
a
very
tempting
thing
for
them
to
do.
So.
What
can
we
do
to
prevent
this
from
happening
to
you?
A
This
is
where
the
update
framework
or
taf
comes
in.
It's
a
framework
for
secure
software
updates,
that's
designed
to
protect
the
the
freshness,
consistency
and
integrity
of
packages,
and
it
does
this
at
the
same
time
as
reducing
the
impact
of
a
compromise
and
allowing
for
recovery.
When
a
compromise
does
happen,
so
in
a
bit
more
detail,
so
protects
content
by
using
cryptographic
signatures
in
a
couple
of
different
places.
It
has
signatures
that
go
over
the
content
itself
in
order
to
protect
the
integrity
of
the
content
that
you're
downloading.
A
A
So
if
any
one
of
these
keys
is
compromised,
it
only
protects
it
only
compromises
that
one
responsibility
which
in
most
cases,
isn't
enough
to
convince
someone
to
install
malware
and
in
order
to
you
know
additional
protection
have
additional
protection.
Each
of
these
roles
can
also
have
a
threshold
of
keys,
so
you
don't
just
have
one
key
signing
for
a
single,
for
example,
piece
of
content.
You
could
have
multiple
different
keys
that
are
required
to
sign
the
same
piece
of
content,
and
they
should
agree
on.
A
What's
in
that
content,
so
and
then,
when
they're
all
verified,
you
can
see
that
okay,
it's
not
just
this
one
entity
which
may
be
compromised.
That
thinks
that
this
is
true.
It's
also
various
other
entities
as
well,
and
this
can
also
be
nice
for
ensuring
some
processes
followed.
So,
for
example,
if
there's
a
code
review
process
that
you
want
to
ensure
a
certain
number
of
people
have
reviewed
the
code
before
it
goes
on
to
the
next
step.
A
A
It
does
this
in
a
few
ways,
primarily
through
hierarchical
trust
delegations
and
the
main
goal
of
this
hierarchical
trust
delegation
is
that
if
anything
lower
in
this
in
this
hierarchy
is
compromised,
anything
above
it
in
this
hierarchy
is
able
to
revoke
those
keys
or
replace
them,
so
that
users
no
longer
use
them.
And
what
this
looks
like
in
tough,
is
you
start
with
a
root
roll
at
the
top,
which
is
obviously
you
know
it's
the
root
of
trust
for
the
system,
so
it
can
be
protected
using
all
those
mechanisms.
A
It
also
delegates
to
the
root
role
itself
to
allow
for
some
inband
key
rotation
of
the
root
role,
so
that
even
those
root
keys
don't
have
to
be
stick
around
forever.
They
can
be
replaced
using
this
inband
rotation,
so
the
tough
project
has
a
bunch
of
different
pieces,
not
just
one
thing.
The
tough
specification
is
one
of
the
the
big
things
that
we
do,
and
this
describes
the
framework,
including
all
those
things
I
talked
about
with
more
specific
metadata
formats
and
workflows
that
explain
how
these
things
work
in
practice.
A
Toughness
also
includes
this,
these
tough
augmentation
proposals,
which
are
a
process
for
proposing
bigger
changes
to
the
specification
or
new
features
that
that
we
want
to
add.
And
finally,
we
have
a
reference
implementation
of
tuff,
which
is
written
in
python
and
shows
how
the
specification
can
be
used
in
practice.
What
it
looks
like
in
the
code-
and
we
always
aim
to
have
the
reference
implementation
in
line
with
the
current
version
of
the
specification.
A
A
In
addition
to
the
pieces
that,
like
the
core
pieces
of
the
tuff
project,
there
are
also
many
different
deployments
and
adoptions
of
tough.
These
include
both
adoptions
that
directly
use
the
tough
specification,
as
well
as
adaptions
that
use
pieces
of
the
tough
specification,
but
are
adapted
for
slightly
different
threat
models
with
slightly
different
systems.
A
Addition
there's
some
work
in
progress,
adoptions
and
adaptions,
as
well
as
optane,
which
is
a
derivation
of
tough
for
auto
automobiles,
which
allows
for
repository
controlled
repository,
directed
updates.
Sorry-
and
this
is
used
in
a
variety
of
automobiles,
as
well
as
in
some
iot
systems
that
require
that
kind
of
repository
direction
of
updates,
rather
than
the
user
asking
for
the
packages
that
they
want.
A
So
that's
that's!
That's
where,
where
the
tough
project
is-
and
so
I'm
going
to
talk
a
bit
now
about
some
some
of
the
new
changes
to
tough
some
of
the
things
that
we're
working
on
and
some
of
the
kind
of
the
new
pieces,
I'm
going
to
go
into
more
detail
about
various
of
these.
This
is
just
kind
of
a
quick
overview.
A
So
some
of
the
things
we're
working
on
is
clarifying
the
tough
documentation
and
the
specification
to
make
sure
that
that
all
this
documentation
is
clear
and
that
new
users
coming
into
into
this
ecosystem,
can
understand.
What's
going
on
with
the
tough
specification
how
it
can
be
used
in
their
system,
we've
also
been
collaborating
with
the
notary
v2
project
to
in
order
to
facilitate
uploading,
tough
metadata
directly
to
registries,
and
I'm
going
to
go
into
a
lot
more
detail
about
that
in
a
minute.
That's
one
of
our
big
projects.
A
In
addition,
we
have
a
couple
of
different
collaborations
with
the
sigstor
project,
both
integrating
full
shio
into
tuff,
using
that
tap
process
to
improve
developer
key
management
again
I'll
have
more
details
in
a
minute
and,
in
addition,
using
tough
as
the
root
of
trust
in
the
sigster
project.
So
it's
kind
of
a
multi-directional
integration,
we're
also
working
on
an
ongoing
integration
of
tuff
into
pipi,
which
is
the
python
packaging
index,
which
is
the
repository
used
by
pip
and
various
other
python
package.
A
And
finally,
we
are
working
with
members
of
the
entota
project
and
others
on
a
new
signature
wrapper
for
tough.
This
thing
called
dizzy
or
the
dead,
simple
signing
envelope
which
improves
the
assigned
rapper
for
tough
and
removes
just
kind
of
reliance
on
canonicalization,
which
has
been
you
know,
kind
of
a
known
issue
with
the
spec,
and
so
this
is
us
working
to
improve
that
talk
too
long.
The
slides
went
dark
here.
B
A
So
and
I'm
going
to
go
a
bit
into
detail
about
some
of
these
things.
So
first
of
all,
this
is
the
integration
of
the
full
ceo
six
stores
full
seo
project
into
tough.
So
tough
today
requires
that
for
end-to-end
developer
signing
that
developers
manage
and
keep
safe
a
private
key
that
they
then
use
to
sign,
metadata
and
upload
it
etc,
and
the
idea
of
this
tap
and
this
project
is
to
ensure
that
is
to
make
this
a
lot
easier.
A
So
the
developers
don't
have
to
keep
this
key
safe
over
time,
because
we've
heard
feedback
that
for
many
developers
this
is
like
one
of
the
biggest
barriers
to
entry,
and
so
folso
does
this
through
the
use
of
short-lived
certificates
that
don't
need
to
be
saved
over
time
and
they're,
backed
by
oicd
systems,
so
credentials
that
the
developers
already
maintain
for
things
like
email,
github
or
anything
else
that
they
they
already
have.
And
so
what
happens
here
is
that
tuff
delegates,
instead
of
to
a
public
key
it
delegates
to
a
full
co
identity.
A
And
then
the
verification
happens
using
the
foster
process,
backed
by
oidc.
There's
more
and
there's
more
details.
I've
brought
a
link
on
this
slide,
but
there
is
the
tap
is
available
on
on
github,
oh
and
and
in
general,
there's
a
lot
of
links
included
in
these
slides
and
they
are
available
online.
If
anyone
wants
to
to
follow
any
of
these
links
for
more
details,
just
as
a
quick
aside,
so
the
next
kind
of
thing
I
wanted
to
cover
is
the
work
that
the
tough
project's
been
doing
with
node
v2.
A
A
A
So
they
have
a
lot
of.
We
have
a
lot
of
ongoing
integrations
of
tough
into
various
different
projects.
The
pipeline
integration,
which
I
mentioned
earlier.
We
are
almost
done
with
the
part
one
of
this
implementation,
which
involves
registry
signing
of
images
and
then
part
two
involves
developer
signings,
so
just
kind
of
extending
the
process
back
one
step
at
a
time,
so
there's
also
an
integration
into
condo,
forge
and
bomb
and
there's
a
very,
very
exciting,
there's
a
new
implementation
of
tough
being
written
in
php
for
use
in
drupal
and
typo3.
A
So
there's
a
great
group
of
people
working
on
that.
In
addition,
there
is
some
more
kathy
on
six
store
which
I'm
going
to
talk
a
bit
about
now,
so
in
the
six
star
project
we've
worked
with,
we
sorry
we've
worked
with
the
sigtro
project
in
order
to
back
both
the
record
transparency,
log
and
the
full
coca
with
a
tough
route
of
trust.
A
A
It
so
there
we
have
a
lot
of
different
implementations
of
tough,
and
so
these
are
here's
a
couple
of
quick
updates
about
the
different
implementations
that
are
going
on.
It's
kind
of
a
quick
overview
if
you're
interested
in
getting
involved
in
any
of
these.
So,
as
I
mentioned
before,
the
python
reference
implementation
is
undergoing
a
refactor.
The
refractor
of
the
client
side
of
the
system
is
almost
complete
and
we're
looking
at
getting
started
on
the
repository
side
of
this
refactor
to
kind
of
use.
A
Google's
fuchsia
implementation
of
tough
has
been
shipped
on
next-gen
nest.
Hubs,
which
we
believe
is
the
first
use
of
tough
in
you
know,
real-life
iot
devices,
which
is
pretty
exciting,
and
in
addition,
as
I
mentioned,
the
php
test
is
having
its
initial
implementation.
Lots
of
great
for
folks.
Working
on
that.
A
few
implementations
also
didn't
make
the
list
they're
just
still
ongoing,
including
the
rusttuff
implementation
and
an
invitation
called
tough
t-o-u-g-h,
which
is
also
in
rest.
A
So,
finally,
all
of
the
all
of
this
is
open
source
software
or
almost
all
of
it
is
open
source
software
and
we
would
love
any
participation
in
in
this
project,
and
so
this
includes
both
participation
in
the
implementations
and
integrations
of
tough.
So
if
you
have
a
favorite
programming
language,
you
can
work
on
either
the
existing
implementation
in
that
language
or
you
can
make
a
new
one
and
it's
just
in
addition.
If
there's
any
projects
interested
in
using
taft
to
secure
software
distribution
or
updating,
we
would
love
to
love
to
chat.
A
We
encourage
contribute
contributions
directly
back
to
the
specification.
If
there's
anything,
that's
unclear,
anything
that
you
know
even
anything
that
doesn't
make
sense
on
a
first
read:
that's
great
feedback
for
us
to
hear,
so
we
can
improve
continue
to
improve
the
specification
and,
of
course
it
is
any
new
feature.
That's
not
currently
included
and
tough
feel
free
to
submit
a
tap
and
we
can
discuss.
A
You
know
how
and
whether
we
can
make
that
happen
and
feel
free
to
chat
with
us.
So
we
have
a
mailing
list
again
linked
from
these
slides,
also
available
on
the
cncf
slack
there
are
we
have.
I
think
we
have
three
different
channels
there,
an
overall,
tough
channel
so
for
general
questions,
anything
about
the
specification
and
then
specific
channels
for
development
of
go
tough
and
python.
Tough
and,
of
course,
we're
also
on
github.
A
All
this
is
open
source
feel
free
to
to
take
a
look
around,
and
I
don't
think
I've
included
a
link
to
the
rendered
version
of
the
specification
here,
but
that's
also
a
great
way
to
get
involved
just
to
read
through
that.
Let
us
know
about
that,
and
I
want
to
conclude
with
thank
you
to
all
of
the
wonderful,
tough
maintainers
that
make
all
this
work
possible
and
also
to
the
maintainers
and
contributors
of
all
of
the
sub
projects.
Implementations,
everyone
else
who
works
with
us
lots
of
great
people.
A
C
A
B
B
A
I
don't
know
that
we
have
any
ongoing
work
there.
I
think
there's
other
projects,
including,
I
think,
entodo
and
others
that
work
more
on
the
so
the
code
side
of
you
know
a
part
of
the
software
supply
chain.
I
think
there's
definitely
ideas
from
tough
that
could
work
there
as
well.
We
just
haven't
you
know
not
specifically.