►
From YouTube: Beyond signatures: Using TUF and Notary to Secure Software Distribution - Marina Moore, NYU
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.
Beyond signatures: Using TUF and Notary to Secure Software Distribution - Marina Moore, New York University
The Update Framework (TUF) provides a unique level of protection against attacks on software distribution and updates. Marina Moore will discuss how TUF can ensure secure distribution for registries. She will present an adaption of TUF for use with the Notary v2 project that addresses diverse secure distribution use cases unique to the registry ecosystem.
A
So
why
do
we
care
about
secure
software
distribution?
This
is
an
attack
factor,
that's
being
used
a
lot,
especially
recently,
to
distribute
malware
to
large
numbers
of
systems
all
at
once.
This
includes
the
recent
solar
wind
attack,
which
relied
on
software
updates,
as
well
as
a
wider
software
supply
chain
attack
to
distribute
that
malware.
A
In
addition,
the
mall,
sorry,
let's
flame
malware,
was
distributed
through
microsoft.
Windows
update,
not
pettya,
which
caused
all
kinds
of
outages
in
hospitals
and
major
companies
also
spread
through
software
updates.
More
close
to
this
community,
the
docker
hub
password
database
compromised
was
part
of
you
know
a
docker
hub
compromise
and
many
images
were
compromised
there.
Although
this
was
very
much
mitigated
by
an
earlier
version
of
this
work.
A
So
what
are
we
going
to
do
about
this?
So
in
the
cloud
in
this
space,
I've
been
working
on
the
node
v2
effort,
which
is
an
effort
to
create
a
more
broadly
used,
secure
distribution
system
for
registries
by
building
onto
the
work
done
in
notary
and
addressing
some
of
the
limitations
of
that
system.
These
include
avoiding
trust
on
first
use
for
keys
and
really
consolidating
the
key
management
to
make
it
much
easier
to
use
and
use
securely
hosting
metadata
directly
on
repositories
to
avoid
users
having
to
run
additional
services
in
order
to
use
secure
distribution.
A
This
space
is
especially
interesting
from
this
perspective
in,
in
the
way
that
it's
different
from
traditional
software
repository
systems,
in
that
we
also
have
to
secure
ephemeral
clients
which
don't
have
any
state
on
them
that
we
can
use
to
store
information
to
be
used.
As
part
of
this
update
process
update
or
distribution
process.
Sorry,
we
also
have
shared
repositories
with
private
data,
and
you
don't
want
this
private
data
to
leak
to
other
users
through
the
use
of
metadata.
A
So
to
do
so,
we
have
a
threat
model.
This
is
the
place
to
start
with
how
to
design
a
security
solution
so
in
our
threat
model.
We
looking
at
these
previous
compromises
that
I've
talked
about.
We
kind
of
make
this
assumption
that
it's
not
a
question
of
you
know
if
your
repository
or
your
registry
will
be
compromised,
it's
a
question
of
what
will
you
do
when
that
happens,
and
and
how
protected
will
you
be
when
that
happens,
because
even
these
companies
with
huge
huge
security
budgets
and
people
focusing
on
this?
A
A
So
the
first
approach
that
I'll
talk
about
for
how
to
secure
software
distribution
in
general
is
using
cryptographic
signatures,
and
these
are
a
piece
of
probably
any
system
for
secure
distribution
that
you'll
see.
But
this
is
kind
of
looking
at
looking
at
systems
that
kind
of
focus
on
the
cryptographic,
signature
aspect,
and
so
what
these
signatures
do.
Is
they
attest
that
the
person
with
the
private
key
who
signs
an
image,
has
access
to
this
private
key
and
they
attest
to
the
contents
of
the
image
in
tls?
A
A
The
downside
with
just
this
approach
is
that
whoever
has
control
of
the
keys
in
the
system
has
full
control
over
the
system
and
can
consign
arbitrary
software
or
arbitrary
malware,
as
the
case
may
be,
and
convince
users
to
install
it.
So,
if
the,
if
these
keys
are
on
a
repository
or
a
registry,
I'm
using
those
terms
a
little
bit
interchangeably,
but
it's
basically
whatever
server
you're
hosting
your
code
for
the
purpose
of
this
talk,
that's
what
I
mean
by
either
of
those
terms
but
yeah.
A
If
the
developer
controls
these
signatures
an
attacker
and
an
attacker
compromises,
a
developer
key
they're
also
able
to
sign
arbitrary
images,
and
this
is
in
part,
because
users
don't
have
a
good
way
to
know
which
signatures
to
trust
and
which
signatures
to
trust
for
which
particular
images,
and
so
they
often
have
a
key
ring,
and
if
any
key
in
that
ring
is
compromised,
it
can
be
used
just
to
sign
arbitrary
malware
and
they'll.
Then
trust
and
install
it,
and
in
this
system
there's
often
no
good
ability
to
rebuild
keys
and
ensure
timely,
revocation
of
keys.
A
There's
a
quick
summary
of
those
attacks
that
I
just
talked
about.
If
a
developer
key
is
compromised,
the
malicious
developer
key
can
be
trusted
by
all
users,
even
if
you
know
to
sign
malware,
if
a
repository
or
registry
is
compromised,
the
attacker
can
alter
content
and
show
older
versions
of
images
that
were
previously
signed
by
developers.
Even
if
those
developer
signatures
are
no
longer
valid.
A
If
a
mirror
is
compromised,
it
has
pretty
much
the
same
abilities
as
a
registry
to
alter
content
or
share
old
versions,
and
then,
if
the
attacker
is
acting
as
like
a
machine
in
the
middle
or
on
the
network,
they
can
save
and
replay
old
signatures.
Even
after
a
vulnerability
is
discovered
or
the
software
is
otherwise
no
longer
signed.
A
We
also
just
we
also
in
in
tough
focus
on
this
idea
of
invisible
usability,
which
means
that,
even
though
there's
a
lot
of
security
going
on
behind
the
scenes,
the
users
don't
need
to
know
exactly
what's
happening
unless
something
goes
wrong.
So
for
the
most
part
they
all
they
know
is
that
they're
downloading
software
and
it's
being
verified
they're
like
they
don't
they
would
they
don't
have
to
specifically
do
a
lot
of
steps.
A
A
The
mirrors
actually
don't
have
any
trust
in
a
system
using
trust
using
tough,
and
so
the
mirrors
aren't
able
to
change
any
content
without
detection
and
then
somewhat.
Similarly,
a
machine
in
the
middle
or
attacker
on
the
network
is
not
able
to
alter
any
anything
and
any
old
signatures
will
be
detected
by
the
clients,
and
so
they
can't
be
used
to
install
old
versions
of
the
software.
A
So
how
does
stuff
do
this,
so
it
uses
a
few
principles
in
order
to
achieve
kind
of
this
level
of
security.
The
first
principle
is
this
idea
of
separation
of
duties,
where
any
one
person
or
anyone
signing
key
is
only
trusted
to
do
a
certain
set
of
things
within
the
system
and
the
way
this
works
is.
It
starts
with
a
root
of
trust
or
root
role,
which
serves
as
the
root
of
trust
for
the
system,
and
this
role
then
delegates
or
provides
the
public
keys
for
some
other
top
level
roles.
A
Next
we
have
threshold
signatures.
The
idea
here
is
that,
especially
for
more
high
security
roles,
the
role
isn't
trusted
unless
a
threshold
of
signatures
all
signs
the
same
piece
of
metadata
for
that
role.
So
in
this
example
here
the
target's
metadata
isn't
trusted
unless
three
out
of
the
four
keys
for
that
role
have
all
signed
the
same
metadata,
and
this
just
makes
sure
that
if
there
are
different
people
trusted
for
the
role
they
all
sign
it
and
it
takes
a
it-
would
take.
A
Next
we
have
explicit
and
implicit
relocation
of
keys.
So
the
implicit
relocation
of
keys
is
just
that
all
keys
in
the
system
have
a
a
time,
a
time
stamp
and
they
all
they
expire
after
a
certain
period
of
time,
and
the
explicit
revocation
means
that
any
higher
level
role
in
the
system
can
explicitly
sign
new
metadata.
That
removes
a
signature
that
removes
a
public
key
for
a
lower
level
role.
A
Once
you
get
back
control
of
your
registry
and
without
any
manual
intervention
on
decline,
systems
to
kind
of
re-establish
trust,
it's
all
kind
of
automatically
done
after
the
attack
and
then,
if
any
single
developer
key
is
compromised
only
that
one
package
or
that
one
thing
that
the
developer
was
trusted
to
sign
would
be
compromised
and
again
that
can
be
revoked
by
any
of
the
higher
level
targets
keys
all
the
way
up
to
the
boot
roll,
which
could
just
revoke
all
of
them.
If
need
be,
although
probably
a
lower
level,
one
should
be
broken.
A
First,
just
prevent
the
overhead
there
and,
in
addition
to
all
of
these
kind
of
existing
features
of
tough
and
kind
of
this
whole
kind
of
philosophy
around
secure
software
distribution
in
order
to
kind
of
adapt.
This
more
for
the
nodeov2
effort
and
the
container
registry
specific
scenarios,
we
have
a
couple
of
new
features
that
I'm
going
to
talk
about
here
today,
so
the
first
of
these
is
client
pinning
of
targets
keys.
A
This
means
that
the
even
the
root
role
on
the
registry
or
repository
itself
doesn't
have
won't
be
able
to
override
this
without
the
client
knowing
about
it.
So
the
client
will
know
you
know
whenever
this
key
is
changed
whenever
a
new
developer
is
signing
it
whenever
something
changes
like
that-
and
this
can
be
especially
useful
in
open
source
projects
where
you
want
to
keep
track
of,
who
is
currently
signing
for
this
release,
and
also
just
you
want
more
control
over
over
the
process.
A
So
if
you'd
like
to
learn
more
about
tough,
we
have
our
our
website,
as
well
as
the
specification
which
goes
into
a
lot
more
detail
about
how
the
all
of
the
aspects
of
the
system
work,
there's
also
a
reference
implementation
for
tuff,
which
you
can
find
from
the
website,
or
you
can
contact
me,
and
I
can
get
that
to
you-
we're
also
available
on
the
the
cncf
slack.
We
have
a
couple
of
channels.
One
got
the
tough
channel
as
well
as
the
python
tuff
channel.
Where
we
talk
about.
A
You
know
the
reference
invitation
specifically
for
the
nodejs
v2.
This
is
an
ongoing
design
process.
So,
if
you
have
any
interest
in
secure
distribution,
this
is
kind
of,
I
think,
a
good
great
place
to
get
involved.
We
are
we're
on
the
cncf
slack
and
a
lot
of
the
work
that
I've
presented
here
is
included
in
a
tough
prototype
design.
A
Piece
which
is,
is
there's
a
link
to
here
and
yeah
we'd
love
to
work
more
with
with
folks
and
see
how
we
can
solve
all
of
our
use
cases
and
get
everyone's
packages
signed
on
registries
and
so
feel
free
to
email
me
or
contact
me
on
the
cncf
slack
and
I
will
be
available
live
for
questions.
Thank
you.