The Essence of Pluribus

Mark S. Miller
Thu, 04 Feb 1999 10:35:10 -0800

[Something I recently posted to a private discussion.  Perhaps this is
something I should revise and post in the Pluribus section of the ELib page
of our website?  Maybe something along these lines should go into the book?

Consult the documents posted at the erights site for the details,
especially , but here's a simplified
version of the Pluribus protocol, identical from a security point of view,
but less efficient:

Objects are aggregated together into units called Vats.  Each E object
exists in exactly one Vat -- we speak of an object being hosted by its Vat,
A Vat typically hosts many objects.  Each Vat exists on one machine at a
time, but a machine may host many Vats.  A good first approximation is to
think of a Vat as a process (or address space) full of objects, except that
it persists.  Rather, think of a process as an incarnation of a Vat, but
the Vat maintains its identity (and state) as it passes serially thru a
sequence of incarnations.

On creation, each Vat generates a public/private key pair.  (We're avoiding
RSA for patent reasons.  We're currently using DSS.  Anyone like to
contribute an Elliptic Curve implementation?)  The fingerprint of the Vat's
public key is the Vat IDentity, or VatID.  What does the VatID identify?
The VatID can only be said to designate any Vat that knows and uses the
corresponding private key.

Within one Vat, an object reference (capability) is implemented by a
traditional memory address.  Capability security within as address space is
built out of safe language techniques (made popular by Java, but having a
history going back to Lisp 1.5 and Algol 60).  An object reference can also
go between Vats.  On the fundamental diagram , if Alice,
Bob, and Carol are in three separate Vats, then Alice can talk to Carol
only because Alice's Vat can talk to Carol's Vat.  An inter-vat data
connection is secure and authenticated (+ integrity, defense from replay
attacks, etc...  Bill Frantz and Eric Messick did great work here).  We
care about inductive correctness -- assuming a pre-existing secure
connection between Alice and Bob, and separately between Alice and Carol,
can we establish a similarly secure connection between Bob and Carol?

When Carol's Vat first exported a pointer to Carol across the Vat boundary,
Carol's Vat assigned an unguessable randomly chosen number to Carol.  We
call this a "swiss number", since it has the "knowledge is authority" logic
of swiss bank accounts.  When Alice's Vat first received the tail of this
pointer, Alice's Vat thereby came to know Carol's swiss number and Carol's
Vat's VatID.

When Alice gives Bob access to Carol, Alice's Vat tell's Bob's Vat Carol's
swiss number and Carol's Vat's VatID.  Bob's Vat now wishes to obtain the
tail of a Vat-crossing pointer directly to Carol, so that it may deliver
this tail to Bob.  Bob's Vat first contacts an alleged Carol's Vat (using
location routing/hint info beyond this description) and asks it for its
public key.  It verifies that it matches the fingerprint, ..., you can
image the logic from here, through Diffee Hellman, to a shared encryption
single-key, Mac, and IVs.  *Only* once a secure data pipe is set up does
Bob's Vat reveal Carol's swiss number to Carol's Vat.

A capability is an arrow, and an arrow has two sides.  There is an imposter
problem in both directions.  The VatID ensures that the entity Bob is
speaking to is the one Alice meant to introduce him to.  The swiss number
ensures that the entity allowed to speak to Carol is one Alice chose to
enable to do so.

Notice how separate this part of the description is from how locations are
identified and how data packets are actually conveyed.