[MUD-Dev] distributed objects

[markm at caplet.com]

--<cut>--
Note: This message was written via the list web archives.  There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2000Q1/msg00378.php

On Wed, 16 Feb 2000 21:42:28 -0800
Kevin Littlejohn <darius at connect.com.au> wrote:
> > ... don't the solutions outlined at www.erights.org for 
> > implementing secure "purses" also fit the bill for combat systems ?  
> 
> For anyone who hasn't read it:
> http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
> 
> Neat system.

Thanks.

> There's still reliance on a bunch of things, that may not be immediately
> evident, though, to achieve this security.  One of them that doesn't apply
> in Moebius (nor, I believe, in any distributed architecture, where the 'bad
> guys' have total control over the objects) 

I'm not sure I understand your security assumptions, or that you understand 
ours.  Please read the "Cypherpunk Reference Scenario" (and variant #3 if you
wish) at http://www.erights.org/elib/capability/conspire.html#revokability .
Briefly, Alice is assumed to have total control over the objects running on
Alice's machine, and Bob is assumed to have total control over objects 
running on Bob's machine, but Alice only has control over objects on Bob's
machine to the extent that objects on Alice's machine have been given such
control.  See also 
http://www.erights.org/elib/capability/ode/ode-protocol.html#subj-aggregate .
In a decentralized mutually suspicious world, beware of statements about 
"*the* bad guys" or "*the* objects".  There are only particular bad guys and
particular objects.

> is a certain non-mutability of objects.  

If the code expresses a non-mutable object, as in our example, then we still
assume that Alice may mutate objects running on Alice's machine, but she
may not mutate objects running on Bob's machine -- unless, of course, Bob
wishes to enable her to do so.

> When you've instantiated an object in E, you can't go back and
> change it's methods - what they bind to, what their source code is, etc.
> If you could do that, you'd instantiate a purse, then change it's decrement
> method.  Presto - you can hand out a decrement that's sealed by the right
> thing, works fine, and does exactly what you want - purse of holding,
> anyone? ;)

The bank, being the owner of the machine the purses run on, can indeed
modify the purses in this way, and by so doing, corrupt the bank logic.  This
is why we explicitly state that the system presented relies on the bank's
customers having mutual trust in the bank.  However, given this trust, the 
bank's customers can use this money to securely transact with each other
without having to trust each other.

All crypto-money protocols that require less than full trust in the bank are 
much more complicated than the protocol presented here.  For money, this
extra complexity is worthwhile.  That's why we explicitly present this protocol
only as an example of protocol definition using capabilities, and not as a
serious proposal for a secure money.


> Ok, so the sealer performs some security checks on the method.  In a
> distributed world, those security checks are going to be _extremely_
> interesting - and valid only until the checks stop being performed (at
> which time, the holder of the object will switch methods on you).

The sealers and unsealers run on the bank's computers along with the purses.
The bank's clients have remote references to some of these objects (in fact,
only to the purses), but are not hosting any of these objects themselves.
Therefore they are not subject to tampering by the bank's clients, though they
are (as stated) subject to tampering by the bank.  I submit that the required
checks in a distributed world are indeed very simple, and are already described
in our paper.


> End result - you drag more and more stuff back to the server for
> verification, until you end up driving the objects data and methods on the
> server from a remote point.

Yup.  That's what we do.  It works.  But it doesn't centralize any more than 
any other working on-line secure money protocol does.  If you know of a way
to do secure money with a less centralized protocol, that'd be worth a paper
at FC01 ;)
 
> Caveat:  I may be wrong, but I can't see where...  As EQ and others have
> demonstrated, people will quite happpily step "out of band" to break these
> systems

Please show me an out of band attack that threatens E.  I'm not saying there
aren't any, but I'd like to understand what kind of attack you have in mind.

> I thought replacing the tiles with transparent ones was good, but
> staggering lag on packets back to the server boggles me.

I haven't read the thread -- only the above message -- so this last comment 
boggles me ;).  If it's relevant to our current discussion, please explain
or point me at something.  Otherwise, feel free to drop.

Hope this clarifies things.




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev