[e-lang] VatID + Swiss Number equiv. to Password Capability?

[Toby Murray]

Toby Murray wrote:

> David Hopwood wrote:
>
>> A protocol that specifically takes into account that it is being used in
>> a capability system, rather than just providing authenticated private
>> channels, can provide better forward secrecy properties: it can ensure
>> that the transmitted forms of capabilities are only useful for a limited
>> time.
>
>
> how? is there a paper somewhere that explains this?
>
>>
>> "Capability Myths Demolished" doesn't say that password and object
>> capabilities are equivalent; in fact it points out that enforcing the
>> *-property requires an object capability system. The *-property isn't
>> really very important in itself, but Mark's post pointed out some
>> other differences.
>>
> The Monash system can enforce confinement since Alice can't get an 
> *overt* bitchannel to Bob on which she can pass him a capability, 
> without having a capability to Bob. Therefore, it provides confinement 
> in the same way as a more traditional object-capability system.
> Furthermore, by using their lockwords to seal capability passwords 
> (via XOR encryption) we can ensure that a capability is "good for only 
> the subject I choose to pass it to". Essentially, if Alice wants to 
> give Bob access to Carol but not allow Bob to pass it to anyone else, 
> even with covert and overt channels in existence, Alice "seals" the 
> cap she passes to Bob with a key and sets Bob's "lockword" to this 
> same key. Now when Bob presents this cap to the system, it is 
> automatically unsealed correctly since his lockword matches the key it 
> was sealed with. If Bob passes this cap onto some other subject via a 
> covert or overt channel, it won't be valid since the other subject 
> needs to have their lockword set to the same value as Bob's and Bob 
> can't know his own lockword.
> Therefore, the Monash system appears like it can enforce confinement 
> in the face of covert channels. It can also enforce confinement, even 
> if Bob can communicate via overt channels with another party (ie. even 
> if Bob has a capability to say Dave, he still can't give Dave access 
> to Carol). Therefore, it seems to provide stronger protection than a 
> normal object-capability system since we don't need to limit those 
> parties Bob can communicate with in order to prevent him passing on 
> the caps we give him.

Hmm.. thinking about this a little more I realise that in a "normal 
object-cap" system, we don't need to limit the parties Bob can 
communicate with, only limit the parties he can communicate 
*capabilities* to. Which is usually achieved by partitioning or 
type-enforcement etc. so this perhaps should just be that: the Monash 
system can enforce confinement even in the face of covert channels and 
therefore the *-proeprty too in the face of covert channels.

> BTW the *-proeprty seems perfectly enforcable by this system, meaning 
> that at least this password cap ssytem can enforce it.
>
> Of course the "lockword" scheme doesn't really appear like it would 
> apply very well in a distributed environment, since there is no single 
> trusted "system" that can enforce the lockwords etc.
>
>
>>> As an aside, when developing the ideas of cryptographic 
>>> capabilities, were the ideas of password capabilities considered, or 
>>> was it an independent construction of (what appears to me as) an 
>>> almost identical form of capability?
>>
>>
>>
>> It's likely that there have been many independent reinventions of
>> password capabilities and the need to transmit them over 
>> cryptographically
>> secured links. I reinvented this about 10 years ago.
>>
>
>


-- 
Toby Murray
Software Engineer
Advanced Computer Capabilities Unit
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.