[E-Lang] Confinement Today (was: My financial data)

[Mark S. Miller]

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 
he says.

Alice is the customer, wishing to aggregate her financial data.

Mallet is the provider of proprietary financial aggregation software and 
services.

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,


                                In KeyKOS


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.


                                    In EROS


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 
evaluates to.

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 
authority-providing capabilities.

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 
"auditors".



        Cheers,
        --MarkM