Split Capabilities: Making Capabilities Scale

[Norman Hardy]

At 9:32 -0700 00/07/24, Karp, Alan wrote:
>> -----Original Message-----
>> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
>> Sent: Sunday, July 23, 2000 10:25 AM
>> To: Karp, Alan; 'Mark S. Miller'
>> Cc: e-lang@eros-os.org
>> Subject: Re: Split Capabilities: Making Capabilities Scale
>>
>>
...

>> We need to be careful about this assumption. Clearly,
>> cryptography is the
>> only technique we have right now for security over unsecured
>> wires. It does
>> not follow that cryptographic capabilities are required. A sufficient
>> alternative would be unsecured capabilities transmitted
>> between mutually
>> trusting runtimes over a more generically encrypted link.
>
>Actually, you only need cryptographically secure capabilities if they are
>outside the control of the TCB.  If all the client has is a virtual address
>that points to the capability, for example, you don't need crypto or trust
>between the parties.

I agree with both of the above except that I am unsure of the meaning of
the hypothesis of Alan's last sentence. Is having the address of something
more or less than having the thing in this case? Or is it an address that
the client cannot dereference? If so, I presume that this is what Jonathan
calls partitioned capabilities (citing literature) and that I call
abstracted capabilities.

>>
>> This wouldn't work for E-speak, obviously, because ultimately
>> the capability
>> representation is visible to the end user. It's a fine solution for
>> distributing a system like EROS.  It also raises the
>> possibility that each
>> participant E-speak system could be made responsible for its
>> own encryption
>> locally. Not sure that's a good idea, but sometimes I find
>> that thinking
>> around corners in this way is revealing.
>
>We need to be explicit in how the crypto is being used.  A cryptographically
>secure link prevents tampering and eavesdropping.  A cryptographically
>secure capability prevents forging of access rights by tampering with the
>contents of the capability.  I am only discussing the latter.
>
>In e-speak DR 3.0, the capability is a bag of bits that the clients can pass
>around any way they like.  In this case, the capabilities internals are
>visible to the user and must be cryptographically secure.  In e-speak Beta
>2.2, the capabilities are handles to data structures maintained in the
>engine's address space; there is no need for crypto.
>

In <http://www.mediacity.com/~norm/CapTheory/Dist/Glass.html> I describe a
network discipline based on message authentication codes, that are a bit
cheaper than crypto. I show (sort of) how one can build capability security
on top of that without secrecy. Secrecy can be imposed selectively later
(higher) as required. As in E, an application built at this level is
vulnerable to corruption only in those nodes that it elects to trust.

This may be only a curiosity but the method of third party handoff has a
peculiar solution that I have not seen before and that might have
application elsewhere.

The note is dense and, as usual, I would appriciate any feedback on
inpenatrable parts. If this crowd can't get it then I have a problem!
Norman Hardy  <http://www.mediacity.com/~norm>