[E-Lang] Confinement Today (was: My financial data)
Mark S. Miller
Sun, 28 Jan 2001 15:04:06 -0800
Hi Vijay, glad to have you aboard!
Regarding your question, I'm unsure which of two possibilities you're
asking about. The first possibility is the one I take Tyler and Zane to be
answering, in which case I would give the same answer.
(Though note that there techniques for blinded computation more practical,
but more specialized than, multi-party secure computation. Some of these
might be adapted to better answering this first possibility, such as Eric
Hughes' encrypted open books (URL anyone?) and "Practical Techniques for
Searches on Encrypted Data"
http://paris.cs.berkeley.edu/~dawnsong/papers/se.ps by Dawn Song, David
Wagner, and Adrian Perrig. In any case, capability technologies such as E
and EROS make no significant contribution to such solutions, so I'll ignore
them for the remainder of this message.)
At 09:11 AM Sunday 1/28/01, Vijay Saraswat wrote:
>My question is about neither -- its about how this can be accomplished on
>a networked computer, run by a *third party*.
>... my real question is: how do we think of computation, how do we
>organize it such that it even becomes possible for system designers to
>provide such guarantees?
This "*third party*" suggests a second possibility. Does your question
correspond to the following scenario?
Third party computation host Harold is running a computation service (eg, a
timesharing service) based on hardware that he alleges only he has physical
access to and the ability to tamper with. On this hardware, he allegedly
runs an untampered capability platform capable of confinement (KeyKOS, EROS,
or E). Harold knows nothing of financial data or financial computation --
he's just providing a general purpose secure computational service. Or so
Alice is the customer, wishing to aggregate her financial data.
Mallet is the provider of proprietary financial aggregation software and
Alice trusts Mallet to the extent that she is willing to pay to see what
Mallet's software would say about her finances, but she does not want her
financial data to be revealed to Mallet. Alice would like to steal Mallet's
analysis program (so she can avoid paying next time), but is willing to
proceed with the transaction even if she can't.
Mallet is willing to let his software be run on Alice's data in exchange for
Alice's money, but does not want his program to be revealed to Alice (not
even the binary executable -- decompilation is a rather trivial form of
cryptanalysis). Mallet would like to steal Alice's data, but is willing to
proceed with the transaction even if he can't.
Without introducing a mutually trusted third party (or the kind of fancy
crypto mentioned above), Alice and Mallet are stuck. They cannot find a
mutually acceptable arrangement. Fortunately, for purposes of this
transaction, they are both willing to rely on Harold to run his hosting
service in the way he alleges. Note that this reliance is unverifiable,
either before or after the transaction.
This is exactly the standard scenario motivating capability confinement.
See http://www.erights.org/elib/capability/confinement.html , and please
look at least at the top diagram before proceeding.
Abstractly, Mallet arranges for Alice to be able to instantiate Bob on
Harold's hosting service in such a way that Alice can be assured Bob is
confined, contingent on her reliance on Harold. Concretely,
If Harold's service is running KeyKOS, then Mallet would create a
BobFactory, and give Alice access to that. Alice would first verify that
BobFactory is indeed a Factory, and then do a "hole check" (see
http://www.erights.org/elib/capability/factory.html ) to see if the initial
set of communications channels a factory instance (a Bob) would be endowed
with are acceptable, as far as the assurance she is seeking is concerned.
I haven't really followed the EROS Constructor (EROS's confinement
mechanism) , so I'll let Jonathan speak for it.
The Simple Story Supported by stl-E-0.8.9k
(At the time of this writing, stl-E-0.8.9k is the latest release of E, which
supports the confinement part of the following story, but not the
distribution. The previous release, tl-otc-E-0.8.9, supports the secure
distribution but not the confinement.)
If Harold's service is running E, then Mallet would upload a BobMaker.emaker
file to Harold's machine, to be installed by Harold on his CLASSPATH. Alice
would remotely <import:...> this using Harold's E's importing service
(technically, the object known by the name "import__uriGetter" in the
universalScope of a Vat run on Harold's machine), obtaining the object it
The E import mechanism guarantees (given that Harold is running an
untampered implementation of E) that the resulting object graph contains no
capabilities that would let it effect the world outside of itself. Further,
although this object graph is stateful, all mutable state in this graph is
reachable only from the object resulting from the import action. Each
separate <import:...> ing of the same name results in a fresh instantiation
of this graph and all its internal state.
To map the concepts to KeyKOS, the E importing service is like
a hole-less factory whose instantiation message does not allow its client to
provide instantiation-time arguments. Therefore, it's yield (the object
graph it instantiates) can have new internal state, but no further
Because this object is authority-less, the typical E style is to treat this
object in a Factory-like way, and use it to instantiate other objects. In
this case, Alice might remotely say on Harold's machine:
define BobMaker := <import:com.mallet.finance.BobMaker>
which looks up "com/mallet/finance/BobMaker.emaker" in Harold's CLASSPATH,
and evaluates the E expression in this file in the (non-authority-granting)
universalScope. The result of this evaluation is assigned to BobMaker.
define Bob := BobMaker new(/*...access to Alice's data...*/)
Endowing Bob with data and powers not to be leaked to Mallet
... (Bob getBalance) ...
Asking Bob to use those powers and data to answer Alice's question.
Note: to actually do this remotely in E, Alice must first obtain from Harold
the "import__uriGetter" from Harold's vat, which she might call "farImporter"
(using the naming conventions from E in a Walnut
http://www.skyhunter.com/marcs/ewalnut.html#SEC46 ). The above remote
computation would then be expressed by her as:
define FarBobMaker := farImporter <- get("com.mallet.finance.BobMaker")
define FarBob := FarBobMaker <- new(/*...access to Alice's data...*/)
... (FarBob <- getBalance) ...
Of course, Alice has no assurance that Bob will give her good answers, and
it's well beyond the scope of capability mechanisms by themselves to enable
her to have such assurance. (Although proof carrying code (PCC)
http://www.cs.berkeley.edu/~necula/pcc.html combined with E's auditors (see
next message), could provide Alice such assurance while not revealing
Mallet's code to her. We have no current plans to support PCC, so I won't
mention it further.)
This story has a probably fatal weakness: The need for Mallet to occupy a
name in Harold's CLASSPATH's namespace, which Alice then needs to access by
name. Though this problem can be avoided even in current E, I won't explain
how (unless someone's interested). Rather, in the next message I'll explain
E's not yet implemented plans to provide better confinement support via