►
Description
Mark S. Miller invited mystery talk, December 10, 2020
https://www.youtube.com/watch?v=g28yRvHKIgc&list=PLzDw4TTug5O0ywHrOz4VevVTYr6Kj_KtW is an extended form of this talk presented at UC Santa Cruz.
Our civilization today rests on infrastructure that is not only insecure, but insecurable.We cannot eliminate risk, but we can be vastly safer. Qualitative arguments have been made for various security architectures, but without any overall framework for comparing them as alternatives or as complements. We present a visualization of the attack surface as a way to reason about aggregate risk, and show how the composition of several techniques --- blockchains, object-capability languages, patterns, protocols, user interfaces, and smart contracts --- can produce a multiplicative decrease in risk without loss of functionality.
A
A
Of
course,
security
is
about
reducing
risk.
Expected
risk
is
just
the
flip
side
of
expected
value
for
each
potentially
exploitable
vulnerability.
The
vertical
axis
is
the
likelihood
that
the
vulnerability
is
actually
exploitable
and
the
horizontal
axis
is
the
value
at
risk
to
the
exploitation
of
that
vulnerability.
A
The
red
surface
area
is,
then
the
overall
expected
risk
of
the
system,
and
our
goal
is
to
reduce
that
red
surface
area
in
order
to
reduce
overall
expected
risk.
However,
likelihood
and
value
are
difficult
to
measure,
so
we
start
off
with
proxy
measures.
The
rows
are
the
various
fallible
agents.
The
fallible
agents
might
be
malicious
or
might
simply
have
a
flaw
that
enables
them
to
be
subverted
by
an
attacker,
and
the
columns
are
the
resources
they
have
access
to
and
therefore
might
damage
if
they
misbehave.
A
A
The
first
row
is
the
operating
system
kernel
or
the
tcb
for
all
of
the
resources
managed
by
the
operating
system.
The
operating
system
itself
is
the
mechanism
that
controls
the
access
that
the
other
accounts
have
to
those
resources
and
therefore
a
flaw
in
the
operating
system
is
one
that
places
all
of
those
resources
at
risk.
All
those
resources
are
vulnerable
to
operating
system
flaws.
A
A
If
doug
is
running
a
conventional
operating
system
and
running
installed,
applications
conventionally
installed
under
that
operating
system,
then
each
of
doug's
applications
runs
as
doug
and
therefore
anything
that
doug
is
allowed
to
do
any
of
those
applications
can
do
so.
All
of
doug's
resources
are
vulnerable
to
any
of
doug's
applications
within
the
dove
box.
A
The
attack
surface
is
again
complete
in
order
to
continue
to
reduce
risk.
Let's
turn
to
a
research
system
that
I
did
in
the
early
2000s
named
capdesk
a
capdesk,
a
capability
oriented
desktop
built
on
top
of
my
e-language,
which
was
a
object
capability,
secure,
distributed
language
cap
capdesk
brings
the
capability
concepts
out
through
the
user
interface.
A
A
A
Capital,
the
capmail
caplet
being
written
in
an
object
capability
language.
Unsurprisingly,
the
different
modules
in
it
have
access
to
different
subsets
of
the
authority
granted
to
capmail
as
a
whole,
but
I
should
emphasize
that
all
of
these
diagrams
are
not
are
not
drawn
to
scale
they're,
not
the
way
you
would
normally
represent
them.
I'm
representing
it
this
way
to
fit
into
the
attack
surface
analysis,
but
this,
for
example,
is
a
real
import
graph
of
a
realistic
javascript
application,
in
this
case
the
metamask
wallet
when
run
in
normal
javascript.
A
All
of
these
dots
are
colored
red,
because
any
of
the
modules
can
completely
destroy
the
integrity
of
any
other
module.
Everything
is
vulnerable
to
anything
when
run
under
ses
the
same
graph.
Most
of
these
modules
are
colored
green,
because
we
can
tell
that
they're
granted
very
little
dangerous
authority.
A
Some
of
them
are
still
colored,
yellow
or
red,
meaning
that
they're
that,
in
order
to
do
their
job,
they
need
to
be
granted
substantial,
dangerous
authority.
So
any
security
review
can
start
off
by
focusing
in
on
the
modules
granted
dangerous
authority
and
what
that
dangerous
authority
is,
but
returning
again
to
our
historical
system
for
the
authority,
the
cap
desk
grants
to
cap
mail
cap
capmail
consists
of
multiple
modules.
One
of
those
modules
is
the
main
module
that
receives
all
of
that
authority.
A
A
That
address
book
in
turn
being
written
in
an
object
capability.
Language
internally
consists
of
a
sparse
graph
of
encapsulated
objects
that
those
objects
start
off
isolated
from
the
world
outside
the
module,
except
for
the
imports
and
exploits
so
the
decision
about
in
the
module
design
about
what
it
imports
and
exports
is.
The
decision
of
how
authority
come
from
the
outside
world
comes
to
be
threaded
into
the
module,
and,
once
again
you
would
not
normally
draw
it
this
way.
Normally,
you
would
draw
object
graphs.
A
A
So,
by
zooming,
in
through
all
of
these
levels
and
applying
the
same
technique
of
hollowing
out
authority
at
each
level,
we're
getting
a
multiplicative
benefit
to
understand
it.
We
can
understand
it
by
analogy
with
fractals
like
the
menger
sponge,
if
in
a
fractal,
let's
say:
okay,
if
in
a
fractal
you
remove
half
of
the
surface
area
at
every
level,
then
as
you
proceed
through
the
levels,
you've
removed
half
times
a
half
times
a
half
asymptotically
approaching
zero.
A
This
is
the
picture
we
get
by
applying
the
techniques
we've
explained
so
far
everywhere
we
can
and
there
still
remain
some
solid
red
areas
of
undiminished
risk.
The
first
of
them
is
what
we'll
call
tcb
risk,
which
is
the
components
at
each
level
of
composition,
which
subdivide
the
authority
and
therefore,
by
the
nature
of
the
job
they're
doing
their
width
cannot
be
reduced.
However,
we
can
reduce
their
height.
A
A
The
next
large
source
of
solid
red
risk
is
legacy.
Boxes
say
that
alan
and
doug
have
been
convinced
to
run
capdesk,
but
barb
is
still
running
a
legacy
desktop
with
a
legacy
operating
system
running
legacy
applications,
but
even
barb
could
reduce
her
risk
further
by
running
different
portions
of
her
world
in
different
virtual
machines.
A
Partitioning
it
that
way,
in
which
case
there's
no
one
component,
that
all
of
barb's
stuff
is
vulnerable
to
other
than
the
virtual
machine
monitor
itself.
This.
This
technique
applies
again
down
our
levels
of
composition,
polaris
system.
We
did
at
hp
running
each
app
in
a
separate
user
account
and
even
down
at
for
the
individual
modules
in
our
memory
safe
languages,
there
is
always
some
modules
written
in
c,
linked
into
a
foreign
function.
A
Interface
robert
watson's
cherry
hardware
shows
how
you
can
use
that
hardware
to
isolate
the
bad
effects
of
those
c
codes,
so
that,
even
if
the
c
code
is
buggy,
it
does
not
endanger
the
integrity
of
your
memory,
safe
language,
so
we've
applied
four
different
techniques.
Here:
we've
reduced
with
initially
with
principal
least
authority,
we
reduced
height
by
minimizing
and
formal
methods.
A
We
reduced
the
width
of
legacy
by
placing
legacy
into
separate
virtual
boxes
and
most
of
all,
by
applying
this
to
these
techniques,
recursively
we've
reduced
the
density
by
this.
Getting
this
fractal
benefit,
however,
there's
still
one
big
hidden
source
of
risk,
which
is
hidden
in
the
assumption
universal
to
software
security,
which
is
given
uncorrupted
hardware.
All
software
security
effectively
starts
with
that
hidden
assumption
and
there's
nothing
that
justifies
that
hidden
assumption,
in
fact,
the
supply
chain.
That's
delivering
our
hardware
to
us.
A
A
A
Over
here,
each
rectangle
is
a
separate
physical
machine,
but
each
power
is
a
logical
machine.
The
tower
on
the
left
is
a
public
blockchain
such
as
the
gorika's
building
that
synthesizes
a
simple
single
logical
machine
by
the
massive
multi-way
agreement
of
many
physical
machines
that
cross-check
each
other.
On
top
of
this
agoric
builds
an
os
like
distributed
system
of
communicating
vent
loops.
That's
where
each
vat
is
a
process-like
unit,
communicating
through
ipc
within
a
platform
or
a
cryptographic
protocols
between
platforms
at
the
next
next
smaller
scale.
We
build
on
top
of
that.
A
It's
the
system
of
distributed,
secure,
object,
capabilities
of
where
an
object
on
a
that
on
one
platform
can
send
a
message
to
an
object
on
about
another
platform.
On
top
of
that,
we
build
the
world
of
secure
smart
contracts,
and
a
smart
contract
is
a
great
example
of
a
program
whose
integrity
needs
to
be
simultaneously
credible
to
a
massive
audience.
All
of
those
that
potentially
participate
in
the
smart
contract
and
because
of
these
supply
chain
risks
that
simultaneous
widespread
credibility
is
not
something
that
can
be
solved
by
a
single
hardware
machine.