[E-Lang] Java 2 "Security" (was: Re: Welcome Chris Skalkaand ScottSmith of Johns Hopkins)
Fri, 19 Jan 2001 17:13:18 -0700
The reason the world is moving so ferociously towards cross checking the
credit cards is that the credit card data is so ludicrously forgeable.
Forgeability is as profoundly non-capability-like as you can get. Indeed, it
is the antithesis of capabilities. It is why both the concepts of
capabilities and ACLs were invented, as an alternative to this situation.
It strikes me as inconceivable that such cross checking would be a growth
industry if indeed the credit cards really were capabilities. Especially if
they were capabilities run on capability secure platforms, in which case the
unforgeability of the capability would be superior to any other form of
authentication ever developed by human society.
PS: I comfortably use the very strong term "inconceivable" here because, as
your own experience has pointed out, it is a hassle for the customer to
support all this cross checking, and if there is one eternal truth about
marketplaces, it is that sellers are fanatical in their effort to eliminate
hassle from the process of buying. Only forgery on a grand scale could push
them into this step.
PPS: Though human society has never developed a form of authentication as
powerful as correctly implemented capabilities, human evolution did indeed
create something comparable. Students of human neurology will note that
there is a big chunk of the human brain custom-hardwired for the sole
purpose of doing facial and gesture recognition. This brain function is so
highly evolved that even identical twins have trouble beating the
authentication mechanism. Off-topic, but amusing.
----- Original Message -----
From: Scott Smith <email@example.com>
To: Mark S. Miller <firstname.lastname@example.org>
Cc: Christian Skalka <email@example.com>; Marc Stiegler
Sent: Friday, January 19, 2001 3:07 PM
Subject: Re: [E-Lang] Java 2 "Security" (was: Re: Welcome Chris Skalkaand
ScottSmith of Johns Hopkins)
> 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.
> But they don't work that way. Signatures/photo ID/... are needed as
> non-capability cross-checks. This is my entire point: cross-checks to
> capabilities are needed. More interesting is how credit-card
> transactions have been evolving in the on-line world. There they
> started as pretty much pure capabilities in that no signature is
> required, only the number. But, you now must give a billing address.
> Still, there has recently been a wave of fraud through on-line credit
> cards, and further controls are being added. Just yesterday a company
> wouldn't ship me something I ordered on-line because I wasn't in their
> phone book (I moved about a year ago). So they required me to fax my
> driver's licence with my address on it to them. Its interesting that
> when I called the company it was to the "department of order
> verification", so now they have a whole department engaged in capability
> verification! Also I have had webpages require me to enter some control
> codes on the card, which are not part of the number (thats a stupid idea
> in the long run because eventually thieves will capture those too).
> Anyway the war being fought as we speak shows how the credit-card
> capability needs to be supplemented to be secure (n.b. it is already
> revocable). Capability systems are certainly stronger than on-line
> credit cards, but they are not much stronger than a physical credit card
> which requires no extra authentication to use. There are similar
> cross-checks on other capability systems in the real world. Passcard
> computer access devices can require both the card plus a password or
> fingerID. The fact that the real world has not embraced the idea of
> pure capabilities gives some evidence that it is an insufficient model.
> Certainly capabilities are the core of much real-world security, but
> they are not the only aspect. Even if capability code is itself
> well-written, in a complete system there will be some users indirectly
> controlling some capabilities who are bound to screw up. If you think
> users will not be able to control capabilities, then you have users who
> hate you because they can't do anything useful with their computer.
> One other thing: I don't equate ACL's and stack inspection by any
> means. It should be possible to define a capability-based notion of
> stack inspection on top of a standard capability model. Just replace
> privilege with capability (this was in fact the Java-folk's original
> terminology: search for "capability" in
> http://home.netscape.com/columns/techvision/java.html). So, every
> object has a fixed capability set associated with it (say initialized at
> load time) which is added to its method's stack frame. What
> checkprivilege(cap) does is scan back on the stack to make sure every
> call on the stack also has capability cap in the frame. Ignoring
> network issues for now, in the communicating conspirators example Mallet
> can get a capability at run-time, but if he tries to do something with
> it that raises a checkpriv(cap), his code doesn't have cap and the
> checkpriv will fail. ... This is super-vague but I hope you at least
> see there is no necessary relation between ACL's and stack inspection.
> The general approach needed in my (not completely well-formed) opinion
> is a broad family of techniques for modulating capabilities. The bigger
> the basket of tricks, the greater the security possible. Some are
> easily encoded in capabilities themselves, such as restricted feature
> capabilities (subset of a full capability via a wrapper), timed
> capabilities, revokable capabilities, coordinated capabilities (requires
> two parts to get the real capability), etc (is there a good listing of
> these things somewhere??). But some modulating dimensions are not
> easily encoded in capabilities, and stack inspection is one such
> (I'm leaving for a week so expect slow/no email response shortly)
> (forwarding to elist fine)