►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
TUF-En Up Your Signatures - Marina Moore & Justin Cappos, NYU
Speakers: Justin Cappos, Marina Moore
Description: As supply chain security has garnered a lot of attention recently, software signing and verification has emerged as a vital step in the process of distributing software. However, a signature alone is insufficient for ensuring the security of a software artifact. Come learn about The Update Framework (TUF), the technology used by sigstore, Notary, Google Fuchsia, and more to not only sign software, but determine which keys should be used and prevent known attacks on software update systems. We will give an overview of TUF that describes its security features and how it has been integrated into fields as diverse as container registries and automobiles. We will also discuss new features we are working on to better support secure software distribution at scale, usability, and some emerging uses of TUF.
B
A
A
A
A
So
the
the
thing
that
we're
worried
about
in
the
tough
project
the
threat
we're
worried
about
is
for
attackers
who
can
compromise
a
repository
and
do
other
attacks
like
this.
So
we
assume
that
attackers
can
perform
men
in
the
middle
attacks
on
the
network
that
an
attacker
can
compromise
keys
that
might
be
used
to
sign,
updates
and
an
attacker
can
compromise
the
repository
or
server
itself
and
anything
stored
on
that
server.
So
if
you
have
things
inside
of
an
HSM
or
something
like
that,
that
will
not
necessarily
save
you.
A
In
fact,
it
will
likely
not
save
you,
as
some
of
the
companies
on
the
previous
slides,
have
found
out
so
ways
that
people
have
tried
to
solve.
This
is
they've
tried
to
solve
it,
with
hey
we're,
just
going
to
use
TLS
and
so
on
and
put
things
on
the
server,
and
if
you
connect
to
our
server,
then
you
must
be
good
and
our
server
must
be,
you
know,
is
never
going
to
get
hacked
or
whatever,
but
the
problem
is
is
that
it
doesn't
say
anything
that
what
the
server
is
giving.
A
You
is
actually
accurate
or
correct
packages,
and
your
server
now
becomes
a
single
point
of
failure,
and
so,
when
the
server
it
gets
using
as
a
repository
gets
compromised,
then
all
of
your
users
are
in
a
world
of
hurt.
So
that's
how,
roughly
you
know,
half
to
two-thirds
of
the
companies
on
that
list
got
their
names
on.
There
was
using
this
as
a
security
design,
and
the
other
way
to
do
it
was
that
they
would
just
go
and
just
sign
something
they
would
have
a
key
that
they
might
keep
in.
A
Like
you
know,
an
HSM
like
your
iot
Hub,
or
something
like
this
and
sign
an
update
package
with
this
key,
and
this
key
can
often
be
in
like
your
build
Farm.
It
can
be.
You
know
somewhere
like
that,
and
your
updater
would
ship
with
this
with
the
corresponding
public
key
and
the
client
would
need
to
trust
this
key,
and
this
key
would
get
used
repeatedly.
A
A
Attacks
back
in
2009
and
the
folks
at
Tor
read
some
papers
that
I
wrote
about
this
talking
about
the
right
way
to
do
things
and
pointing
out
all
these
problems,
and
they
said:
hey,
can
you
help
us
fix
it,
and
actually
several
people
from
the
tour
project
came
and
visited
me
at
my
lab
and
spent
a
couple
days
with
me
working
on
a
design
and
at
first
they
were
like
Security's.
Not
that
hard
for
this.
How
hard
can
it
be?
A
It's
a
very
hard
problem.
Okay
and
I.
Don't
you
know,
and
the
solution
to
this
isn't
to
say,
like
trust
me,
I'm,
smart,
it's
like!
Let's
get
a
group
of
people
together
to
actually
think
really
hard
about.
This
problem
spend
a
lot
of
time
doing
open
design,
get
a
lot
of
review
and
build
something
out
there.
That
you
know
can
resist
a
lot
of
these
problems
and
attacks,
so
that
led
us
to
develop
tough,
where
this
is
a
comp.
A
You
know
a
compromise
resilient
effectively
like
a
library
or
framework
or
mechanism
you
use
to
do
updates.
You
know
and
distribute,
and
do
your
updates
and
things
like
this
in
a
secure
way,
and
it
assumes
that
repositories,
keys
and
developer
accounts
can
all
be
compromised,
and
the
goal
of
tough
is
to
reduce
the
impact
of
a
compromise
so
that,
if
you
have
things
that
do
get
hacked
the
damage
that
the
attacker
can
do
is
extraordinarily
minimal
and
I'm
going
to
talk
some
examples
of
that.
A
So
you
understand,
and
also-
and
this
is
really
fundamental-
is
to
be
able
to
securely
recover
from
a
compromise
if
you've
used
any
of
you
know,
certificate,
revocation
lists
or
online
certificate
status
protocol,
you've
done
any
of
that
or
you've
done
anything
with
like
pgp
key,
revocation
trust
replication
stuff.
Like
this,
you
realize
these
systems
are
really
messy
and
really
difficult,
and
you
know
it
was
definitely
something
added.
After
the
fact
onto
an
existing
system
and
tough.
A
We
had
this
as
a
design
goal
from
the
very
beginning,
and
so
people
are
actually
amazed
how
well
and
seamlessly
revocation
Works
in
our
system,
because
it
was
such
a
first
class
concern
from
the
very
beginning.
Okay,
so
tough
is
based
on
a
few
different
principles
and
I'm
just
going
to
talk
through
them
here.
So
you
get
some
understanding
of
the
kinds
of
things
we
use
to
build
it.
A
One
is
and
I'll
go
through
each
one,
a
little
bit
of
detail,
so
the
first
is
responsibility
separation,
and
this
is
an
idea
that
you
can
have
different
roles
that
do
different
things
in
a
system.
So,
if
you're
familiar
with
rollback,
role-based
access
control,
as
you
probably
are
from
all
the
mini
systems
that
use
them-
you
know
this
concept
so,
for
instance,
a
key
that
might
be
trusted
to
say
this
is
a
valid
version
of
package.
A
X
is
a
different
key
that
might
be
trusted
to
say
there
has
been
a
new
valid
version
of
package
X
in
the
last
10
minutes.
Right
and
I'll
you'll
see
in
a
moment
about
why
that
matters.
Okay,
another
thing
you
can
do
is
you
can
delegate
trust
that
you
get
in
the
system.
So
if
Alice
is
responsible
for
the
food
project
Alice
you
know,
and
the
food
project
builds
different
versions.
Alice
can
let
Bob
and
Charlie
decide
to
build,
possibly
all
those
versions
or
some
subset.
A
A
Also
tough
uses
a
principled
to
minimize
the
individual
key
and
role
risk
so
that
keys
that
need
to
be
used.
Frequently
are
sorry,
so
let
me
explain
this
formula
here.
A
second
you
know:
I'm,
a
professor
I
have
to
have
at
least
one
formula
on
my
slides,
so
the
expected
damage
is
roughly
equal
to
the
probability
of
the
thing
happening
times.
The
impact
okay
and
we
won't
expect
a
damage
to
be
very
low.
So
it
means
that
one
of
these
two
terms
has
to
be
very
low
right.
A
A
Tough
also
allows
you
to
do
multi-signature
trust
as
I
kind
of
alluded
to
with
my
other
examples.
So
you
can
say
you
know
we
want.
There
are
seven
people
in
a
certain
role
and
four
of
them
have
to
come
together
to
do
something
or
whatever
you
can
say,
a
person
from
the
QA
team
and
two
of
our
developers
have
to
approve
a
release
before
it
goes
out.
A
So
you
can
say
this
thing
expires
after
this
amount
of
time,
so
you
have
both
explicit
ways
to
revoke
trust
independent
of
time,
and
you
have
implicit
ways
to
say
this
should
only
be
considered
for
the
next
six
months
or
something
and
we've
had
a
a
lot
of
different
security
audits
with
them
with
tough
that
are
all
available.
Here
we
published
a
lot
of
peer
review
papers
that
have
also
had
a
lot
of
screw
security
scrutiny.
A
We
have
many
more
Audits,
and
things
like
this-
that
we
can't
talk
about
because
they're
not
necessarily
public
for
some
of
the
less
widely
used
implementations
and
in
fact
we
just
yesterday
are
able
to
publicly
release
information
about
the
python.
Tough
implementation,
which
is
our
reference
implementation,
which
VMware,
especially
Joshua
Locke,
and
everyone
in
his
team
did
such
an
amazing
job
with
hardening,
and
we
are
very
proud
of
how
our
audit
turned
out.
We
encourage
you
to
go,
read
the
blog
post,
because
yeah
we're
very
happy
with
it.
A
So
if
you
do
think
you
know,
hey
I,
you
know
think
I
can
do
something
better
than
what
these
guys.
You
know
and
the
tour
guys-
and
you
know
all
the
folks
from
all
the
big
companies
that
have
worked
with
us
and
all
the
security
Auditors
have
done.
You
know,
feel
free
to
make
it
public
or
send
it
to
us
and
ask
us
to
look
at
it,
because
we,
we
think,
we've.
B
B
We
are
one
of
the
12
projects
to
have
achieved
the
open,
ssf
gold,
best
practices
badge,
which
is
the
highest
badge
that
they
they
offer
there's
an
automotive
variant
of
tough
called
uptane,
which
has
been
standardized
initially
in
IEEE
as
part
of
their
isto
group,
and
now
it's
under
the
auspices
of
the
jdf,
and
so
that's
still
on
this
ongoing
yeah
outgoing
issues
there
to
get
that
going.
And
finally,
the
the
tough
project
itself
is
a
graduated
cncf
project.
B
B
I'll
highlight
a
few
of
them
here.
Python
tough
is
our
reference
implementation,
which
we
use
for
some
experimentation
with
new
features
in
the
specification.
It's
also
used
in
production
by
various
folks
and
it's
maintained
by
the
groups
here,
as
well
as
additional
contributors
who
aren't
named
on
this
slide.
With
all
of
these
implementations,
we
have
lots
of
amazing
contributors.
Go
tough.
Also,
you
also
very
popular
implementation.
B
Some
similar
overlap,
two
implementations
in
rest,
maintained
by
different
groups
for
different
purposes,
a
new
PHP
implementation
and
then
an
actualizer
which
is
a
c
plus
implementation
used
specifically
for
update
in
the
embedded
space,
so
that
one
is
maintained
by
Horizon,
so
yeah
five
different
languages,
lots
of
different
work
going
on
in
this
space
and
all
these
implementations
have
been
deployed
in
a
variety
of
different
places.
So
as
we're
at
cncf,
Cloud
native,
you
know
conference
we'll
talk
about
some
of
our
Cloud
deployments,
which
are
the
highlighted
here
as
well.
B
So
here's
some
other
updates
about
our
different
implementations.
As
Justin
mentioned,
the
python
talk
project
had
recently
had
a
really
big
refactor,
where
we
created
this
whole
new
embed,
metadata,
API
abstraction
to
make
the
code
a
lot
more
maintainable,
a
lot
more
mutable
and
hopefully
a
better
reference
implementation
for
other
folks
who
want
to
to
use
it
as
such,
and
this
ongoing
work
on
a
repository
tool
that
then
uses
that
new
metadata
API.
But
the
client
work
is
all
done
there
there's
some
exciting
new
maintainers
and
new
users
in
that
space.
B
B
This
tap
process,
the
tough
augmentation
proposal
process
and
the
idea
here
is
that
you,
you
know
anyone
can
submit
a
proposal
to
change
or
add
something
to
the
tough
specification
and
we
go
through
a
whole
process
to
make
sure
that
you
know
the
security
properties
of
tough
will
be
maintained
and
that
this
is,
you
know
a
good
idea
that
has
real
world
use
cases.
That
will
be
helpful
for
the
specification.
B
So
a
couple
of
these
that
have
some
recent
updates.
We
have
top
15,
which
is
it's
the
you
know.
The
title
is
succinct
hash
bin
delegations.
The
idea
here
is
that
tough
has
this
format
for
doing
delegations
to
a
a
huge
group
of
Targets
in
this
succinct
format,
and
this
even
further
reduces
the
metadata
duplication
to
reduce
the
metadata
overhead
of
using
this
feature
in
tough
and
an
implementation
of
this
tap
was
recently
merged
into
python.
B
Tough
and
we're
really
excited
about
the
use
for
for
really
large
repository
implementations
that
can
take
advantage
of
this,
and,
as
I
mentioned
here,
it
reduces
the
tough
metadata
overhead
versus
through
hashmin
delegations
by
a
factor
of
eight,
which
is
very
full
top
14
is
another
very
exciting
one.
This
this
tap
is
all
about
managing
tough
versions
and
managing
breaking
changes
to
the
tough
specification
and
what's
exciting.
B
B
I'll
talk
a
little
bit
too
about
kind
of
where
tough
fits
into
this
ecosystem
and
other
related
projects.
I
think
I
want
to
highlight
here
is
the
six
door
project
which
we
are
also
active
members
of,
but
here
I'm
just
going
to
compare
what
we
do,
what
they
do,
how
we're
hoping
to
collaborate
more
so
tough,
especially
historically,
has
really
had
a
focus
on
developers,
managing
keys
and
a
lot
of
the
different
properties
of
tough
to
like
discourage
key
sharing,
and
all
of
these
things
require.
B
You
know:
lots
of
different
Keys,
properly
managed
in
the
system,
and
sixster
has
a
really
great
way
to
have.
The
sixer
itself
manage
the
keys
to
improve
usability
in
that
way,
and
so
I
think
you
know.
The
short
version
of
this
is
that
I
think
Tufts
has
a
lot
more
security
guarantees
and
sigster
has
a
bigger
focus
on
kind
of
the
usability
first
and
then
also
the
security
pieces
as
well.
B
As
we
mentioned
earlier,
revocation
into
office,
essential
property
and
in
sixster,
is
a
much
bigger
focus
on
auditability
and
detection
of
attacks,
rather
than
the
reverification
and
prevention
pieces
and
there's
also
yeah
and
tough,
has
been
used
in
production
for
over
10
years
in
various
different
systems.
But
of
course,
there's
also
like
Integrations
between
these
projects.
I
think
both
projects
have
good
ideas
right,
and
so
we
have
the
sixth
year
project
actually
uses
tough
as
its
root
of
trust.
B
So
tough
is
used
in
the
sixth
story
to
distribute
the
root
keys
for
record
and
full
Co,
and
we
have
a
lot
more
ideas
about
how
to
do
more
cross
integration,
including
using
the
six
door
key
management
in
tough
to
improve
usability
for
developers
and
and
adding
more
support
for
tough
metadata
files
in
six
store,
so
yeah.
So
so
far
in
this
talk,
we've
really
talked
about
this
last
mile
of
the
software
supply
chain,
so
tough
and
sixture,
and
all
these
pieces
really
focus
on
okay.
B
B
We
have
a
couple
of
really
good
Integrations
of
these
two
technologies
and
they
really
complement
each
other,
because
Tufts
can
provide
the
root
of
trust
and
the
key
management
and
expert
and
all
these
properties
we've
talked
about
and
in
addition
to
actually
Distributing
artifacts,
it
can
be
used
to
distribute
other
metadata
like
the
intodo,
layouts
and
attestations.
So
not
only
so
you
can.
You
know
you
have
all
one
system
that
distributes
all
of
these
different
pieces
to
secure
your
whole
supply
chain.
B
The
chef
project
also
is
you
know,
always
looking
to
the
future.
I
think
one
of
the
advantages
of
coming
to
this
project
from
a
research
lab
is
that
we're
always
looking
at
the
next
things.
What
else
is
out
there
and
so,
of
course,
a
couple
of
Technologies.
You
may
have
heard
of
blockchain
post
Quantum
crypto.
B
We
have
some
pilot
support
for
Quantum
crypto
support
in
the
secure
systems
lib,
which
is
the
cryptographic
library
that
both
tough
and
internet
are
used,
so
we're
hoping
to
get
some
of
that,
especially
in
the
automotive
variants,
which
are
really
long-term
Integrations
of
tough
yeah
another.
You
know
ongoing
Integrations,
I,
think
key
lime
and
Toto,
some
of
the
more
Integrations
going
on,
and
you
know
we're
really
into
experimentation
with
future
technology
to
make
sure
that
we
always
look
in
the
future
things
that
are
happening
and
yeah
so
yeah.
B
But
these
are
not
yet
part
of
the
specification.
I
think
they'll
have
to
go
through
the
whole
tap
approval
process.
We
want
to
make
sure
that
Technologies
are
mature
before
we
actually,
you
know,
require
use
for
everybody,
but
we
are
looking
ahead
to
things
like
post
quantum
and
finally,
we
want
to
encourage
everybody
here
to
contribute
to
tough.
We
I
think
we're
a
very
welcoming
Community.
We
love
new
people,
you
can
talk
to
us
on
slack.
We
have
a
tough
Channel
as
well
as
various
other
channels
for
individual
implementations.
B
On
the
cncf
slack,
we
have
a
mailing
list,
which
is
mostly
quiet,
but
it's
definitely
a
great
place
to
have
more
in-depth
conversations,
a
website
which
has
links
to
very
previous
talks
papers
on
the
project
and
lots
of
other
information
and
I
think
the
best
way
to
get
involved
really
is
GitHub.
We
are
everything
we
do
is
open
source
and
so
easy
way
to
get
involved
is
to
look
at
our
issue,
our
open
issues,
on
the
specification
on
the
Taps
repository
and
on
all
of
our
implementations,
I
linked
to
a
bunch
of
the
implementations.
B
B
A
Yeah
so
there's
a
there's,
an
IEEE
is
the
standard
and
a
we're
under
the
jdf.
Now,
where
there's
like
a
path
to
OSI
and
stuff
like
this,
and
the
reason
why
we
went
that
way
with,
optane
is
because
the
automakers
are
adopters
had
that
as
like
a
question
like
hey,
could
you
do
this
and
we
looked
into
it
and
said
sure?
No
problem
we'd
be
very
happy
to
do
the
same
with
tough.
A
We
were
actually
have
been
approached
a
couple
times
to
to
push
it
through
processes
with
different
organizations,
and
we
kind
of
one
of
the
really
important
things
to
us
is
that
we
still
maintain
control
of
the
spec
and
control
of
the
way
it
gets
edited
and
control
of
what
happens
over
it.
So
we
may
do
that
in
the
future,
if
there's
a
real
desire
for
it,
but
it
hasn't
been
a
pressing
need
yet
so.