►
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.
Cryptographic Signatures: A Building Block Not A Panacea- Marina Moore, NYU
Cryptographic signatures are a key piece of securing the software supply chain. They allow developers to attest that a piece of software is valid, and an end user to ensure that the software was not tampered with. In this talk, Marina Moore will talk about what cryptographic signatures do and don’t provide for a security ecosystem with examples of their effective use as a building block for existing cloud native supply chain security applications. She will also address some common pitfalls in the implementation of cryptographic signature systems.
A
Hey
hi
so
like
they
mentioned,
I'm
marina
moore,
I'm
a
phd
student
at
nyu.
I
work
with
dr
justin
capos
in
the
seeker
systems
lab
there,
and
I
contribute
to
tough
and
various
other
open
source
projects,
and
they
talk
a
little
bit
today
about
some
of
the
lessons
I've
learned
through
working
in
the
secure
software
supply
chain,
space
about
cryptographic,
signatures
and
what
they
like
do
and
don't
provide
for
your
systems.
A
So
yeah.
If
you
know,
if
you're
here
today
at
cloud
native
security
conference,
you've
probably
heard
a
little
bit
about
these
cryptographic.
Signature
things.
You
know
it's
a
bunch
of
math
that
does
that
provides
a
cryptographic
guarantee
that
a
particular
private
key
signed
a
data,
and
you
can
verify
this
using
a
public
key
associated
with
that
private
key.
A
That's
kind
of
attached
to
that
artifact
is
then
sent
to
a
verifier
or
really
to
anyone
who
then
can
use
a
public
key.
That's
you
know
cryptographically
linked
to
this
private
key.
They
can
use
that
key
to
then
verify
the
artifact
and
really
ensure
that
the
signature
came
from
the
private
key
like
it
was
supposed
to,
but
okay.
So
what
does
this
actually
mean?
For
you
know
for
us
making
secure
systems
the
main
guarantee
that
is
this
still
working
good.
A
But
if
you
put
these
signatures
in
context
with
a
lot
of
other
policies
and
rules
and
kind
of
you
know
formulations,
you
can
really
get
a
lot
out
of
the
system,
so
some
of
the
things
to
kind
of
think
about
and
we're
going
to
go
into
a
lot
more
detail
about.
Some
of
these
is
who
should
sign
like
who
controls
this
private
key.
That
is
then
signing
information.
How
do
you
know
that
they
actually
control
this
private
key?
What
what?
What
is
each
key
allowed
to
sign?
A
A
So
the
first
step
in
answering
a
lot
of
these
questions
is
looking
at
why
you
actually
want
to
use
cryptographic
signatures?
I
think
a
lot
of
people
look
at
like
you
know,
distribution
of
artifacts
or
messages
and
say
you
know
we
need
to
sign
them
so
that
they're
secure
when
they're
you
know
sent
across,
but
I
think
it's
important
to
think
about
what
meaning
you're
hoping
to
get
from
that
signature.
Does
the
signature
just
mean
that
the
correct
person
wrote
the
software
that
you're
then
receiving?
A
Or
does
it
mean
that,
like
you
know,
a
security
team
reviewed
this
software
and
really
you
know
ensure
that
that
was
also
done
or
you
can
do.
You
can
make
very
various
other
guarantees
around
it,
but
you
have
to
really
like
decide
upfront
what
it
is
you
want
to
get
from
the
signature
on
a
piece
of
data
and
another
kind
of
general
principle
that
I'm
going
to
talk
a
lot
about
later
on.
A
Is
this
idea
of
compromise
resilience,
or
what
do
you
do
when
something
goes
wrong
so
especially
for
the
more
critical
assets
that
you
find
when
you,
when
you
look
at
a
threat
model
of
your
system,
it's
important
to
think
of
like
if
any
one
piece
of
the
system
is
compromised.
If
any
one
key
is
lost,
if
any
one
server
is
compromised
or
any
other
like
piece
of
whatever
system
is
being
secured,
what
can
you
do
to
make
sure
that
you
can
both
recover
from
that
compromise
and
maybe
prevent
the
compromise
from
really
like?
A
Are
you
using
for
verification?
And
how
do
you
know
this
is
the
public
key?
That
is
correct.
How
did
you
get
that,
and
what
are
you
gonna
do
when
this
verification
fails?
Are
you
gonna?
You
know,
fail,
open
and
download
the
software
anyway
or
feel
closed
and,
potentially
you
know,
leave
the
attack
an
attacker
away
to
generalize
sort
of
denial
of
service,
your
application
by
just
issuing
really
bad
signatures
for
a
lot
of
different
content.
There
are
definitely
pros
and
cons
to
both
of
those
approaches,
but
something
that
you
need
to
think
about.
A
However,
because
the
keys
are
on
you
know
some
server
on
the
internet,
they
are
more
vulnerable
to
compromise
than
a
key.
That's
stored
offline
on
something
like
a
you
know,
uvic
hsm
or
something
that's
that
requires
some
kind
of
human
interaction
to
then
connect
it
to
another
device,
use
it
to
create
that
signature.
A
So
these
keys
are
harder
to
compromise,
but
they
do
require.
You
know
that
actual
human
step
of
of
connecting
them,
which
might
make
it
so
that
these
signatures
are
used
a
little
bit
less
often,
and
whether
using
online
or
offline
keys,
it's
important
to
manage,
who
has
access
to
these
keys
for
online
keys,
managing
like
credentials
to
access
the
the
servers
where
these
keys
are
stored
and
for
offline
he's.
A
The
next
issue
is
establishing
trust.
So
how
do
you
once
you
have
these
pub,
these
private
keys
that
are
signing
the
data
you
have
these
associated
public
keys,
which
you
know
you
can
distribute
these
widely
because
they're
public
keys,
they
don't
need
to
be
kept
secret,
but
you
do
want
to
ensure
that
you
know
you
know
what
public
key
you
have,
and
you
know
that
this
public
key
is
associated
with
an
identity
that
you
trust
for
a
particular
operation.
A
There
are
various
ways
to
do
this.
I
think
there's
a
lot
of
very
cool
technologies
out
there
that
can
establish
kind
of
a
trusted
channel
to
to
communicate
this.
I
think
the
you
know
the
classical
fashion
method
would
just
be
to
meet
up
in
person
and
say
you
know
this.
This
is
the
key
that
that
I
control
this
is
the
public
key.
A
You
know
you
know,
I'm
you
know
it's
mine,
because
I'm
giving
it
to
you
in
person,
and
you
can
kind
of
fake
these
online
to
use
a
variety
of
different
methods
and
then
there's
another
method
that
gets
it
it's
a
lot
of.
You
know
bad
press,
but
it's
a
surprisingly
useful
one
which
can
be
trust
on
first
use.
A
You
know
the
correct
key
and
then
using
that
key
over
and
over
again
can
actually
be
a
reasonable
method
to
ensure
this
as
well,
and
it's
actually
very
commonly
used
when
connecting
to
servers
over
it
would
like
authenticating
to
servers
on
the
internet
because
often
says
gives
you
a
fingerprint.
You
know
the
first
time
you
connect,
like
you
know.
A
A
Instead
of
giving
this
intern
the
power
to
also
assign
anything
in
the
boot
to
project,
you
can
just
give
them
a
specific
key
that
can
be
used
for
the
documentation
or
for
whatever
project
or
subset
of
this
project
that
they're
actually
using
the
next
kind
of
big
way.
To
prevent
or
to
add
this,
this
sense
of
limiting
trust
is
through
the
use
of
multi-signatures
or
threshold
signature
signing,
and
the
idea
here
is
that
you
require
multiple
different
keys,
just
multiple
different
private
keys
to
sign
the
same
artifact
and
then
as
a
verifier.
A
A
Another
signing
solution
in
kind
of
a
similar
vein
is
cosine,
which
I
think,
which
is
sig
star,
signing
solution,
which
is,
and
in
many
ways
similar
to
notation.
It
adds
signatures
to
artifacts
on
oci
registries
using
slightly
different
apis,
and
it
really
focuses
on
this
idea
of
usability
and
one
of
the
big
pieces
of
context
that
cosine
kind
of
adds
in
is
this
integration
with
another
sigster
project
called
recore,
which
is
a
transparency
log.
A
So
any
artifact
that
is
signed
with
cosine
that
signature
is
automatically
uploaded
to
record,
which
means
that
it
is
fully
auditable
and
on
the
immutable
log.
So
anyone
in
the
future
can
go
through
and
see.
You
know
when
this
artifact
was
signed
and
you
know
make
sure
there
was
no
no
tampering
going
on
in
that
situation.
A
There's
actually
ongoing,
integrations
of
tough,
both
into
into
both
notation
and
cosine
just
to
to
be
clear
for
those
who's
watching,
and
so
these
things
aren't
mutually
exclusive.
This
is
just
some
additional
policy.
That's
added
on
here
there's
also
some
flexibility
in
in
tough,
which
includes
how
developers
actually
manage
the
keys
so
like
that
kind
of
online
versus
offline
decision,
tough
mandates
that
the
root
keys
of
the
system
are
stored
offline,
because
this
is
kind
of
the
root
of
trust
for
the
system
and
so
the
most
critical
piece.
A
But
developers
can
decide
whether
it
makes
more
sense
for
them
at
the
developer
level,
to
store
these
keys
online
or
offline
and
and
how
to
manage
them
themselves.
Another
piece
of
context
that
tough
adds
in
that
chef
leaves
to
individual
users
is
how
to
do
root.
Key
distribution,
so
tuf
actually
handles
the
distribution
of
all
non-root
keys
through
the
framework
itself.
It
has
policies
and
mechanisms,
they
basically
use
delegations
in
order
to
distribute
keys,
but
these
all
train
back
up
to
these
root
keys,
which
which
then
still
need
to
be
distributed.
A
A
lot
of
systems
using
tough
do
use
trust
on
first
use,
but
there
it.
It
also
supports
any
other
kind
of
key
distribution
mechanism.
You
know,
depending
on
what
can
be
set
up
in
a
particular
context,
and
this
kind
of
depends
on
the
kind
of
closeness
between
the
person
downloading
the
software
and
the
person
like
uploading,
the
the
the
software
to
be
downloaded
and
how
much
they're
able
to
communicate
in
order
to
do
this.
A
It
entoto
allows
users
to
set
policies
for
all
the
different
stages
of
the
software
supply
chain
and
what
they
expect
to
happen
at
these
different
stages
and
then
allows
the
users
to
verify
that
all
these
different
steps
happened
and
one
of
the
really
interesting
kind
of
pieces
of
context
that
ntoto
adds
is
really
about
this
identity,
because,
because
entourage
goes
across
the
entire
supply
chain,
it
needs
to
keep
track
of
the
public
keys.
That
should
be
used
to
verify
each
step
in
the
supply
chain,
and
it
really
it
does
a
great
job.
A
I
think,
of
tying
the
identity,
to
the
specific
step
that
that
identity
should
be
used
to
sign,
to
really
ensure
that
each
key
is
used
for
the
thing
that
it's
supposed
to
be
used
for.
It's
similar
to
tough.
It
supports
thresholds
for
each
of
these
stages
as
well.
So
in
certain
cases,
for
example,
you
may
want
the
code
to
be.
You
know
signed
off
by
more
than
one
different
developer
to
ensure
that
you
know
you've
had
more
than
one
set
of
eyes
on
the
code
and
you
can
enforce
that
using
thresholds
in
nintendo.
A
B
C
A
I
did
go
through
that
little
fast,
so
yeah,
the
basically
what
it
means
is
looking
at
how
your
software
goes
from
the
developer
to
the
end
user.
Looking
at
all
the
different
stages,
it
usually
involves
some
kind
of
you
know:
code
being
uploaded
some
kind
of
ci
cd
system,
some
kind
of
build
system,
some
kind
of
distribution
system,
plus
maybe
some
other
steps,
depending
on
what
you
do.
So
the
first
step
is
really
defining
what
those
steps
are
for
you.
What
systems
are
you
using?
A
What
machines
or
people
are
responsible
for
each
of
those
different
steps,
and
then
I
don't
have
pictures
of
it
or
anything.
But
entoto
has
you
know
specific
formats,
basically
that
you
just
put
all
that
information
into
and
then
it
can
and
then,
if
you
actually
follow
those
steps
of
the
supply
chain,
you
can
then
use
into
verify
that
each
of
these
steps
happened.