►
Description
Getting Involved in Sigstore Research Projects - Hayden Blauzvern, Google
Sigstore, an open-source project that provides easy-to-use tooling to simplify signing and verification, is fast-moving and leans into experimentation and research to improve the security and privacy of the project. Sigstore is the perfect-sized project to try out new research techniques, as it has real-world usage but still aims to be agile. In this lightning talk, we will discuss where we'd like to see research applied, to provide privacy-conscious transparency, stronger assurances during verification, and distributed trust with timestamping. We'll end with a call to action for both industry practitioners and academic researchers to contribute to Sigstore.
A
B
Hello:
everyone,
my
name,
is
Hayden
blousfern
I'm,
a
tech
lead
and
manager
at
Google
on
the
open
source,
security
team
and
a
maintainer
on
the
six
store
project
today,
we'll
be
talking
about
some
ways
to
get
involved
with
six
store
with
Recent
research
projects,
you've
probably
heard
of
six
star
before,
but
as
a
really
quick
high
level.
Summary.
It's
a
set
of
services
and
tools
to
simplify
code,
signing
for
artifacts
code,
signing
Is,
Not,
A,
New
Concept.
B
It's
been
done
for
many
many
years,
but
what
sixstore
brings
to
the
table
is
simplification,
an
easy
way
to
bind
identities
that
you
probably
already
have
to
ephemeral
signing
keys.
This
makes
it
so
you
don't
have
to
manage
signing
keys.
It
also
adds
a
layer
of
auditability
where
each
signing
event
is
written
to
a
public
Ledger,
a
transparency
log
so
that
identity
owners
can
monitor
those
logs
to
see
how
their
identities
are
being
used
to
sign.
Artifacts.
B
There's
a
lot
of
reasons.
I
enjoy
working
with
the
state
store,
Community
I've
listed
a
few
up
here,
but
what
I
want
to
call
out
is
we
aim
to
be
agile.
We
aim
to
adopt
a
research
as
it
comes
out
and
to
be
open
to
new
ideas
and
figure
out
how
we
can
evolve,
whether
it's
improving
security
or
privacy
or
a
few
other
areas
we'll
talk
about
in
a
minute
as
researchers.
It's
also
really
nice
to
be
able
to
see
real
world
usage
and
get
data
on
how
your
research
is
being
applied.
B
So
the
first
area
to
touch
on
is
privacy,
preserving
protocols,
as
I
mentioned,
we
use
identities
instead
of
signing
keys
and
those
identities
are
written
to
a
public
Ledger.
This
means
that
identities
could
include
things
like
emails
or
machine
identities,
which
could
include
information
about
private
repositories
or
Cloud
projects.
B
So
some
users
may
not
want
this
information
to
be
public
and
would
instead
want
it
to
be
redacted.
There's
a
few
areas
to
explore
in
this
space.
One
would
be
the
use
of
zero
knowledge
proofs,
which
give
us
a
way
to
redact
information
while
still
making
signing
events
verifiable,
and
it
also
has
the
property
of
being
able
to.
Let
us
see
that
the
ca
fulsio
actually
verified
a
valid
identity
token.
B
Another
interesting
construction
to
explore
would
be
what's
called
a
verifiable
random
function
or
a
vrf.
This
has
actually
been
proposed
for
another
transparency
ecosystem,
key
transparency,
which
is
being
used
for
end-to-end
encrypted
messaging
applications.
They
care
a
lot
about
privacy
because
they're
working
with
sensitive
data
like
phone
numbers
I'm
in
no
way
an
expert
on
this
topic,
but
another
area
that
would
be
interesting
to
explore
is
private
information
retrieval
or
PIR.
B
This
would
give
us
a
way
to
query
logs
such
that
the
log
operator
does
not
learn
about
What
entries.
The
user
is
interested
in.
This
is
particularly
interesting
for
something
like
certificate
transparency,
where
you're
effectively
revealing
every
certificate
that
you're
verifying-
and
this
reveals
your
browser
history
to
a
log
operator.
This
is
also
important
for
binary
transparency
or
Sig
store
because
you're
revealing
what
you
want
to
install,
potentially
or
revealing
details
about
your
development
environment.
So
the
log
operator,
when
you
have
to
query
it.
B
The
role
of
a
witness
is
critical.
What
they
do
is
they
query
the
log
periodically
and
ask
for
what's
called
a
checkpoint,
taking
one
step
back
logs
are
represented
by
a
data
structure
called
a
Merkle
tree,
which
gives
you
two
properties,
one
an
efficient
way
of
computing.
What's
called
an
inclusion
proof
which
is
a
cryptographic
or
set
of
cryptographic,
hashes
that,
let
you
verify
an
entry
is
actually
analog
and
a
consistency
proof
also
a
set
of
hashes
that
let
you
prove
that
between
two
log
sizes,
the
log
remains
append.
B
Only
witnesses
will
periodically
request
the
current
tree
header,
the
checkpoint
from
the
log
and
compute
or
sorry
verify
a
consistency,
proof
between
a
checkpoint
that
they've
saved
and
this
new
checkpoint
and
then
they'll
update
their
current
state.
If
they've
found
that
the
log
remains
consistent,
a
large
scale,
deployment
of
a
witness
network
is
something
that
we've
just
started
exploring,
and
this
would
definitely
be
an
area
that
would
be
very
interesting
to
research.
More
related
to
this
is
what's
called
gossiping.
B
The
next
area
I'd
like
to
touch
on
is
verification
or
authorization
does
a
really
good
job
of
simplifying
signing,
but
we've
kind
of
punted
on
the
problem
of
verification
said
this
is
a
responsibility
of
the
clients
and
I
think
we
can
do
better
and
take
a
bit
more
of
an
opinionated
stance
on
this.
One
area
to
explore
would
be
leveraging
policy
languages
like
Rego
or
q,
and
integrating
those
into
six
store
clients
to
make
it
easier
to
specify
how
you
want
to
verify
an
artifact.
For
example.
B
What's
the
identity
that
should
be
associated
with
an
artifact,
something
else
to
explore
is
binary
authorization.
This
is
thinking
more
about
the
end-to-end
pipeline
of
a
package
as
it
moves
through
a
system
and
at
what
points
should
it
be
verified?
Six
doors
done
some
work
on
this
already.
There's
a
repository
policy
controller.
That's
an
admissions
controller
for
containers
in
a
kubernetes
cluster,
but
I
think
we
can
do
even
more
and
continue
exploring
this
and
coming
up
with
some
sort
of
binary
authorization
approach
for
open
source.
B
Another
thing
to
look
at
would
be
the
contrast
between
user
identity
and
machine
identity.
We
talk
a
lot
about
user
identity
in
our
examples,
thinking
about
emails,
but
many
builds
are
done
on
automation,
on
CI,
like
GitHub
actions
or
gitlab,
or
build
kite,
so
it'd
be
interesting
to
explore
different
ways
to
represent
machine
identity,
for
example.
Thinking
a
bit
more
about
how
we
can
integrate
more
closely
with
something
like
spiffy.
B
The
update
framework
or
tough
is
a
framework
for
securing
software
updates.
It
mitigates
a
number
of
attacks
that
are
common
for
software
updates,
for
example,
things
like
rollback
attacks
where
software
is
rolled
back
to
an
insecure
version
or
freeze
attacks
where
a
client
isn't
able
to
get
updates.
New
versions
of
software
tough
is
very
critical
for
Sig
store.
It
hosts
our
root
of
trust,
which
includes
things
like
our
Cas
root
certificate.
Our
transparency
logs
public
key
there's
a
couple
improvements.
The
tough
I
want
to
call
outs
of
note.
B
One
is
what's
called
identity,
verification
using
folsio,
so
the
way
that
a
tough
metadata
works
is
it's
signed
using
keys
and
one
of
the
goals
of
six
store
is
to
remove
the
need
to
self-manage
keys.
So
we
could
instead
leverage
folsio
and
Associate
identities
that
developers
already
have
with
an
ephemeral
key
and
then
use
that
in
tough
metadata.
B
Another
Improvement
is
on
the
client
side,
thinking
about
multi-repository
search,
and
this
is
particularly
useful
for
deployments
where
there's
both
a
private
deployment
of
sixstore
and
a
verifier
needs
to
trust
the
public
deployment
of
sigstore
right
now.
Six
store,
clients
have
to
be
configured
against
only
one
environment,
and
it
would
be
useful
to
be
able
to
seamlessly
search
across
multiple
there's,
also
a
lot
of
opportunities
for
improvements
on
the
client
side.
Thinking
about
implementing
the
touch
specification
in
other
languages
or
improving
the
existing
apis
for
tough
clients.
B
The
last
area
I
want
to
touch
on
is
verifiable.
Time
is
a
critical
component
of
Sig
store.
We
issue
short-lived
certificates,
and
so
we
have
to
rely
on
timestamps
that
are
trusted
to
verify
certificates
once
they
expire,
and
this
is
kind
of
a
common
pattern
for
code
signing
within
six
store
right
now.
We
have
two
ways
we
get
time.
One
is
by
leveraging
the
transparency
log
and
using
the
entry
upload
time
and
another
is
using
signed
timestamps
that
come
from
timestamp
authorities,
but
in
both
of
these
cases
these
are
single
points
of
failure.