Scalable Distributed Security with Bearer Certificates

[Mark S. Miller]

At 03:23 PM 2/10/99 , Frank O'Dwyer wrote:
>Obscuring both ends of a connection is possible but more complex. I
>think this would require two parties to initiate a connection to a 3rd
>party, and splice those connections together.

What trust, if any, would need to be invested in such a third party?  Our
protocol already assumes a third party called a Vat Location Service (VLS),
and the E source distribution contains slightly stale code for such a
service that we hope to resurrect soon.  We had always hoped that the
Vat-locating part of the protocol might eventually grow to enable a mixing
network.  Might our VLS serve the role of the unobscured 3rd party in your
protocol, allowing Alice, Bob, and Carol to remain obscured?

VLS protocol description:

A Vat has a long-lived identity, denoted by its VatID (fingerprint of its
public key).  A Vat incarnation is a process running on some machine and
listening at a particular TCP/IP.  A Vat may have no more than one
incarnation at a time, but overall a Vat lives through a series of
incarnations, each of which may listen on a different TCP/IP port.

A Vat exports references to objects it hosts (but only according to
capability discipline).  An exported reference must provide the ability to
send messages to the object they designate, and therefore to the Vat
hosting this object.  But what if this Vat has been reincarnated in the
meantime?  It would have the same VatID, but be listening on a different
TCP/IP port?  How can it be found?

We intend to run a set of well known Vat Location Servers at well known
stable TCP/IP addresses.  (And we already have several volunteers sites.)
A Vat is configured to know a set of these as its "Search Path".  When a
Vat is [re]incarnated, it registers itself with all the VLSs on its Search
Path that it can contact.  (And it re-registers once an hour)  Note: The
VLS currently accepts unauthenticated registration.  This will be fixed.

When a Vat exports a reference to an object it hosts, such as Carol, this
reference contains this Search Path.  When the receiver of a reference,
such as Bob, wishes to contact Carol, Bob's Vat does a breath-first search
for Carol starting with all the TCP/IP addresses in Carol's reference's
Search Path.  The search is breadth-first so malicious VLSs cannot prevent
Bob from finding Carol as long as any of the paths starting from one of
Carol's VLSs successfully leads to Carol.


>I don't think a
>transparent socket interface to that would be easy, but something like
>sockets but requiring a few extra method calls might be possible.

We don't require transparent operation through the existing socket
interface, but might one define an interface through which one could use
either the existing socket library or your library?  In any case, I don't
think this is a big deal.


>It
>might be easier in your case to have well-known (or discovered?) proxy
>objects which existed to provide the rendezvous point and the forwarding
>functionality, using half-anonymous connections as a basis. The 3rd
>party would be in a position to inspect content, though, so if that's a
>problem another layer of encryption is needed, and some higher level
>means of authenticating the endpoints.

Pluribus requires and supplies an end-to-end encrypted and authenticated
data pipe.  If intermediate data-forwarding proxies are in the way, as in
http://www.erights.org/to-be-sorted/DataCommThruFirewalls.html they cannot
see or disrupt any of the content.  Mixing would seem to require hop-to-hop
encryption as well, resulting in a doubly encrypted stream.  Any system
would seem to require this -- the security resulting from the end-to-end
encryption is far more important than that resulting from the hop-to-hop
encryption.


>In the half-anonymous case, initiators would need to know the location
>of responders--so depending on how your introduction is done, somebody
>needs to reveal their location. In the fully anonymous case, the
>location of the 3rd party needs to be known, but the other partipants
>locations remain hidden.

This would seem to fit the role of VLSs.


>Yes, it would be interesting from my angle too. I think I could use E
>for my project if it hid location.

TCQ by any chance?  That'd be great!

You may be interested in a project Marc Stiegler is currently working on,
SecureIt-EChat --  no mixing, blinding, buddy list, or multi-way chat
rooms; but a secure (secrecy, authenticated, integrity) point-to-point chat
built in a *tiny* amount of E code.  In its current form it's intended, not
so much as a serious app (though it's quite usable), but as a demonstration
of how easily you can build secure distributed apps on a distributed
capability language.  He's about to use it in a course he's teaching, and
expects to open source it at his site fairly soon.

	Cheers,
	--MarkM