[cap-talk] membrane challenge - an Attack!
david.nospam.hopwood at blueyonder.co.uk
Thu Nov 18 17:29:31 EST 2004
Jed at Webstart wrote:
> At 10:59 PM 11/17/2004, Jed Donnelley wrote:
>> At 02:19 PM 11/17/2004, David Hopwood wrote:
>>> Mark Miller wrote:
>>>> Jed Donnelley wrote:
>>>>> At 02:27 PM 11/16/2004, Stiegler, Marc D wrote:
>>>>>> With the simple membrane, he would indeed end up with N different
>>>>>> With the EQ membrane, he would wind up with 2: the original bare key,
>>>>>> and the one instance of a membrane for that key. With the fantasy
>>>>>> membrane that unseals an object when it comes back to the side of the
>>>>>> membrane where the object resides, there would be only one.
>>>> I would argue this is a good design for a capability-stretching comm
>>>> system (such as DCCS and CapTP), but one might argue otherwise
>>>> (Alan's CU Proxy).
>>>> However, it is a broken design for a membrane, for exactly the
>>>> reasons you raise. If a membrane around Bob gives Bob only
>>>> revocable-Foo, i.e., FMCFoo, then, when Bob passed FMCFoo as an
>>>> argument in a message to FMCSN, SN must get FMCFoo, not Foo. To give
>>>> irrevocable-Foo to SN is to give to SN something more powerful than
>>>> what Bob has.
>>> Oops, some of my previous comments were not applicable to the fantasy
>>> membrane, only the actual membrane implementations at
>>> <http://www.skyhunter.com/marcs/membranesNotaries/>. The fantasy
>>> membrane is indeed broken. However, the main reason why it's broken
>>> has nothing in particular to do with the Swiss Number server; there
>>> are much simpler attacks against it. For instance suppose that "SN"
>>> in the above paragraph is not a Swiss Number server but is an
>>> arbitrary object colluding with Bob.
>>> The problem is that the fantasy membrane design assumes,
>>> that the world can be partitioned into "Bob and all objects with
>>> in common with Bob" on one side, and "objects that have no interests in
>>> common with Bob" on the other.
> That's right. For example, the two capabilities sent to Bob
> via the membrane could be Foo and BobD, a directory that Bob
> has direct access to. In that case the fantasy membrane server
> could be induced to insert Foo into BobD through the membrane
> for later retrieval by Bob outside the membrane.
> However, I don't believe there's any sense in which the Swiss Number
> server is "colluding" with Bob.
I didn't say there was; just that replacing SN by an object that
colludes with Bob gives another attack, that I think more clearly shows
what is wrong with the fantasy membrane design.
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the cap-talk