[E-Lang] Java 2 "Security" (was: Re: Welcome Chris Skalkaand ScottSmith of Johns Hopkins)

Tyler Close tclose@oilspace.com
Sat, 20 Jan 2001 15:33:35 -0000

Ben Laurie wrote:
> It is unclear to me that this is a sustainable view: I can
> forge (i.e.
> copy) the capabilities, even in a capability secure
> platform, if I have
> access to the platform, surely? Furthermore, in a
> distributed capability
> system, then capabilities are inherently forgeable, aren't they, by
> virtue of the fact that I can transmit them from A to B.

The verb "forge" should be reserved for unauthorized copying.
Authorized copying is just plain copying. Capabilities are (and must
be) easily copied; however, they are impossible to forge. A credit
card is easily copied and possible to forge.

Both of the scenarios you describe are authorized copying and not
forgery. When I voluntarily pass a capability to someone else, I am
sharing that capability with them. The receiving party is authorized
to copy that capability.

> Clearly we try
> to reduce that by using stuff like crypto between A and B,

The crypto is there only to ensure that the intent of a given copy
operation is precisely implemented and that it does not result in
unintended copies. The crypto is not there to in any way restrict the
copying abilities of either A or B.

> but A has to
> assume it can rely on B in order to make the capabilities
> unforgeable.
> This assumption may not be correct.

And therefore should not be made. In a well designed capability
application, A should assume that B will use any capabilities that it
has to its maximum benefit. A must not rely on B depriving itself of
advantage for the sake of A's security.

Scott Smith wrote:
> Lets map capabilities on to some real-world scenarios.
> Credit cards.
> Taken as a pure capability all you need to do is present
> the card, you
> can pass the card around if you want, presenting it buys
> anything, etc.

The problem with credit cards is not that they are imperfectly
implemented capabilities. The problem with credit cards is that they
are a very poorly designed capability application. Does it seem
bizarre to you that Dan Bornstein handed over the capability to his
entire credit line to the movie ticket kiosk at the Metreon in order
to purchase a $10 ticket? (I assume Dan's worth more than $10 ;)

Every credit card purchase involves giving the merchant unrestricted
access to your entire line of credit. The authentication procedure is
not the problem. The problem is that *many* parties are given *much*
more authority than they require. This results in certain parties
(criminals) collecting that authority and utilizing it to their
maximum benefit (credit card fraud). This should not be surprising. It
should be expected. In a well designed capability based credit card
application, a merchant would only be given the authority to charge my
credit line once for the exact purchase price of the item sold.

Scott Smith also wrote:
> The fact that the real world has not embraced the idea of
> pure capabilities gives some evidence that it is an
> insufficient model.

The "real world" does lots of really stupid stuff. History seems to be
mostly about learning about "stupid stuff done in the past". The "real
world" mostly teaches us what didn't work, not what will work. Taken
in this light, it is promising that the "real world" doesn't have much
to say on the topic of capabilities.

The other major thing to consider here is that pretty much all of
history's knowledge of security is limited to security in the physical
world, not security in the software world. Software is subject to a
completely different "law of physics" than the physical world is.
There should not be any expectation that knowledge gained from one
realm will port to the other, in fact, quite the opposite, we should
expect something completely different.