[e-lang] VatID + Swiss Number equiv. to Password Capability?
toby.murray at dsto.defence.gov.au
Thu Aug 12 21:41:23 EDT 2004
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
> 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
>> secured links. I reinvented this about 10 years ago.
Advanced Computer Capabilities Unit
Information Networks Division
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.
More information about the e-lang