►
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.
Whose Sign Is It Anyway? - Marina Moore, NYU & Matthew Riley, Google
Code signing is the security foundation of the software supply chains we rely on every day. But if you let yourself think about it for too long -- like we have -- it starts to seem weird that we’re so sure a random download won’t steal our credentials or ransom our data just because someone, somewhere happened to choose a very special point on an elliptic curve.
In this talk, we will explore what a digital signature really means -- and what it doesn’t. We’ll look at the implications of policy choices around key handling, what gets signed, and when we call a signature "valid". And we’ll dive so deeply into the very idea of identity that you may begin to question the nature of your reality.
A
A
A
A
I
mean
okay,
there's
one
law
of
physics,
thing
that
signatures
mean
a
valid
signature
means
that
the
private
key
and
the
signed
data
were
in
the
same
place
at
the
same
time
once,
but
that's
it.
That's
as
far
as
the
math
can
take
us
if
we
want
to
make
decisions
based
on
valid
signatures.
If
we
want
to
use
signatures
to
improve
the
security
of
an
ecosystem,
we
need
to
rely
on
policy
to
answer
questions
like
whose
key
was
used.
A
So
that's
what
we're
hoping
to
spend
our
time
talking
about
today.
First,
I'm
going
to
t
up
the
problem
by
looking
at
how
policy
defines
an
ecosystem
and
what
sort
of
questions
a
policy
might
address,
then
marina
will
look
at
how
this
applies
to
real
systems
that
chose
policies
based
on
their
specific
use
cases.
A
So
we
said
policy
is
the
set
of
rules
that
make
signatures
mean
anything
to
put
it
a
different
way.
Policy
allows
signers
to
predict
how
verifiers
will
behave,
and
vice
versa,
and
to
grossly
oversimplify
every
policy
decision
that
we're
going
to
make
falls
on
a
spectrum
or
on
the
one
end
we
make
signatures
easier
to
create
and
on
the
other
end,
we
make
signatures
more
meaningful
at
either
end
of
that
spectrum
lies
peril.
A
A
What
we're
looking
for
instead
is
a
trade-off,
a
spot
somewhere
in
the
middle,
where
we
can
meaningfully
improve
security
for
everyone
all
right,
so
we've
talked
about
how
to
think
about
policies
and
trade-offs
at
a
high
level.
Now,
let's
get
into
the
nitty-gritty
of
some
specifics
of
what
a
policy
needs
to
answer
and
we'll
start
with
one
of
the
most
foundational
questions.
If
I
have
something
that's
signed
who
signed
it,
how
do
I
match
a
signing
key
to
some
real
world
identity?
A
Now
again,
there's
a
real
trade-off
here.
If
I
make
this
too
hard,
if
I
require
id
cards
and
lawyers
and
contracts,
then
only
big
well-resourced
companies
are
going
to
bother
signing
anything
and
the
long
tail
of
software.
The
left
pads
of
the
world
are
going
to
remain
unsigned,
but
if
I
make
it
too
easy
to
get
a
code
signing
signature,
if
I
don't
require
any
proof
of
anything,
then
we
end
up
with
spoofed
identities
and
a
lot
of
signatures
that
don't
really
tell
us
much.
A
A
Some
systems
rely
on
a
central
directory
or
arbiter
of
identity,
which
is
trusted
to
make
statements.
Like
this
key
belongs
to
this
name,
this
is
sort
of
like
the
dns
approach,
other
systems
ship
with
a
hard-coded
set
of
keys,
which
are
either
used
to
sign
things
directly
or
delegate
authority
to
other
keys.
This
is
like
the
web
pki
model
of
certificate
authorities
and
root
cas
that
ship
in
an
os
store.
A
Finally,
some
systems
choose
to
provide
a
weaker
guarantee,
rather
than
check
that
things
are
signed
with
the
right
key.
They
assume
the
first
key
they
see
is
correct
and
they
just
make
sure
that
the
key
stays
the
same
over
time.
This
works
as
long
as
your
first
request
wasn't
tampered
with
and
as
long
as
the
entity
does
not
change
keys
over
time.
A
Okay,
so
let's
say
that
we
have
a
way
to
map
keys
to
real
world
identities
like
people
or
companies.
Now
we
have
a
new
problem:
a
company
doesn't
sign
code,
some
computer
at
a
company
signs
code.
Wherever
that
signing
happens,
we
need
to
keep
the
key
protected,
so
it
is
still
meaningfully
the
company's
key.
A
A
A
These
examples
also
demonstrate
another
policy
decision.
Do
we
want
to
keep
our
signing
key
somewhere
that
can
be
accessed
and
used
by
automation,
or
do
we
want
it
locked
away
where
we
need
to
run
some
sort
of
ceremony
to
get
to
it?
We
can
trust
those
offline
keys
more.
We
can't
use
them
as
easily,
which
might
lead
us
not
to
sign
every
build
or
every
commit.
A
I've
spent
a
lot
of
time
talking
so
far
about
how
to
get
signatures
right,
but
no
matter
how
hard
we
try.
Something
will
go
wrong.
Your
signing
key
will
accidentally
end
up
on
github.
A
developer's
yubikey
will
walk
off
the
desk
over
a
holiday,
or
maybe
you
kept
control
of
your
key,
but
you
signed
a
bad
build
because
your
source
repository
was
compromised
or
your
build
server
had
malware
and
you
didn't
know,
our
policy
needs
to
have
a
story
for
how
we
find
out
about
mistakes
and
how
we
fix
them
in
practice.
A
The
most
common
way
to
find
out
that
your
key
was
used
to
sign
something
bad
is
for
a
user
to
find
that
something
bad
on
their
machine
and
send
it
to
security
yourcompany.com
in
some
more
elaborate
setups.
That
key
might
be
on
a
protected
server
that
generates
audit
logs
or
we
might
have
a
binary
transparency
log
set
up
where
we
list
all
the
artifacts
that
we've
signed.
That
validators
should
trust
and
we
can
go
through
that
list
to
see
if
anything
is
out
of
place.
A
A
A
Do
we
show
a
reasonable
error
message,
or
do
we
just
prompt
the
user
and
say
press
y
to
make
this
your
fault
dealing
with
mistakes
is
by
far
one
of
the
hardest
things
to
get
right
in
a
code
signing
ecosystem
and
that's
because
by
definition,
you're
starting
from
a
bad
state,
and
you
somehow
need
to
get
back
to
normal
without
creating
any
or
at
least
many
new
surprises
all
right.
We've
talked
about
policies
and
the
questions
they
need
to
answer
before
we
get
into
covering
some
real
systems.
A
We
saw
that
a
signature
only
proves
that
the
private
key
and
the
data
were
together
once
and
that
everything
else
all
the
meaning
we
hope
to
imbue
into
that
signature
comes
from
policy
surrounding
how
we
map
keys
to
identities,
how
those
signatures
should
be
validated
and
how
we
heal
the
ecosystem.
If
things
go
wrong,
that
policy
needs
to
be
universal,
agreed
on
and
relied
on
by
all
the
agents
in
the
system,
and
it
needs
to
find
the
right
trade-off,
the
right
equilibrium,
where
it's
easy
enough
to
deploy
and
strong
enough
to
be
valuable.
A
A
B
Thank
you
matt,
so
as
you've
heard
as
you've
heard
so
far
in
this
talk,
signatures
are
just
one
piece
of
the
puzzle
in
this
section.
I'm
going
to
discuss
some
of
the
policy
trade-offs
that
really
complete
this
picture.
Each
of
these
policies
is
based
on
a
threat
model
for
a
specific
project
and
the
examples
I'm
going
to
use
are
from
software
distribution
and
I've
seen
these
through
a
lot
of
the
work
I've
done
on
tough,
so
first,
a
little
bit
of
background
tough
or
the
update
framework
is
a
framework
for
secure
software
updates.
B
So,
as
our
first
case
study,
I'd
like
to
talk
about
optane,
which
is
the
automotive
variant
of
tough,
this
is
pretty
unique,
because
automotives
are
very
automobiles.
Sorry
are
very
controlled
and
safety,
critical
environment,
and
this
really
affects
the
policy
trade-offs
that
are
made
in
this
implementation
of
taf,
because
cars
are
physically
in
a
factory
before
being
sent
out
onto
roads.
Uptake
can
do
key
distribution
just
in
the
factory
in
person,
which
is
a
pretty
unique
in
in
the
in
the
world
of
software.
B
B
So
the
next
case
study
I'd
like
to
talk
about
is
pep
480,
which
is
a
proposal
for
end
to
end
signing
of
python
packages
with
tuff
the
first
half
of
this
proposal,
something
called
pep
458
is
in
the
process
of
being
implemented
and
in
warehouse
and
by
the
time
you
are
watching
this.
It
will
likely
be
in
use
by
in
practice
in
warehouse,
which
is
the
pi
pi
server.
B
So
for
key
distribution,
pi
pi
hosted
a
public
key
distribution,
sorry
key
generation
and
signing
ceremony,
which
was
live
streamed
and
also
recorded
to
establish
kind
of
public
trust
in
this.
In
this
generation
process,
the
key
generation
process,
these
public
keys,
are
posted
online,
publicly
available
in
as
many
places
as
as
possible
and
they'll
also
be
distributed
in
pip
in
other
and
other
warehouse
consumers.
So
they
can
automatically
be
used
as
well,
but
you
can
verify
using
the
online
sources,
so
warehouse
controls
these
root
keys
and
then
uses
them
to
delegate
some
intermediaries.
B
B
B
Trust
on
every
use
is
the
first
use,
so
if
you're
using
trust
on
first
use,
it's
kind
of
an
infeasible
way
to
to
manage
your
key
distribution.
So
instead
for
this
key
distribution,
piece,
tef
notary,
suggests
distribution
during
container
provisioning
or
using
existing
secret
distribution
mechanisms
like
spiffy
inspire
also
in
notary
v2.
Real-Time
use
requires
the
use
of
online
keys,
but
security
risk
of
online
keys
can
be
mitigated
through
delegations
from
offline
keys.
B
That's
kind
of
the
way
that
this
this
works
in
in
in
many
of
the
cases
of
people
using
this,
and
so
this
works
by
having
an
offline
key
that
lists.
The
online
keys
they'll
be
used
for
your
day-to-day
signing
and,
if
anything
goes
wrong
with
this
online
key,
if
it's
lost,
if
it's
stolen,
if
something
happens
to
your
server,
this
online
key
can
then
be
revoked
by
using
the
offline
key.