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

Marc Stiegler marcs@skyhunter.com
Mon, 22 Jan 2001 10:15:13 -0700

I have replies to Jonathan, David Wagner, Ben Laurie, and Hal Finney
attached here, they all sort of flow together, so I put them together :-)


----- Original Message -----
From: Jonathan S. Shapiro <shap@cs.jhu.edu>
To: Mark S. Miller <markm@caplet.com>
Cc: Tyler Close <tclose@oilspace.com>; Scott Smith <scott@cs.jhu.edu>; Marc
Stiegler <marcs@skyhunter.com>; E Language Discussions
Sent: Sunday, January 21, 2001 12:12 AM
Subject: Re: [E-Lang] Java 2 "Security" (was: Re: Welcome ChrisSkalkaand
ScottSmith of Johns Hopkins)

> I think that Scott has raised a valid view that security is cost-based.
> Actually, I have held this view for a long time and was somewhat bemused
> to be hoist on this issue. I think that as a mental shorthand there are
> some costs that we categorize as "too high to break" and we subsequently
> treat these topics (at least casually) as secure in a black and white
> sense.
> Nonetheless, the personal information test is a terrible security
> mechanism. To explain why I shall need to add a taxonomy for security
> measures, which I am still thinking through.
> Jonathan

Those of us on this list who are free-market philosophers and part-time
economists simply have to agree that security is cost-based. This is a
fundamental principle. However, there is another fundamental issue this
generalization all by itself misses: the economics of creating and breaching
security are dramatically different in physical and virtual worlds.

The bad news for the physical world: In the physical world, walls can only
be made incrementally better. Let us take concrete walls reinforced with
rebar as an example: walls that are thicker and higher are better, but
because of the cube-square laws of physics, the cost of thicker higher walls
grow nonlinearly. Hence there is for any physical technology generally a
most cost efficient wall that is rather low in quality, where "low in
quality" means "penetrable with costs inside the realm of possibility".

The good news for the physical world: 2 walls will generally take nearly
twice as much time and effort to break through as a single wall.

Taking the good news and bad news for the physical world together, we see
that in the physical world, cost effectiveness for defense in the physical
world translates to defense in depth, i.e., defense through quantity.

The bad news for the virtual world: For a given kind of wall, once someone
has broken a wall of that kind, the cost of breaking that kind of wall goes
approximately to zero. For example, it was very expensive for the first
person to figure out how to hack Diablo I. Having figured it out, however,
and having posted the hack on the web, that first break-in has enabled my
mother-in-law to hack Diablo I with little investment.

The good news for the virtual world: mathematics tells us there are walls
you can build that are "near-perfect and perfect", where the cost of
breaking these walls means, "impenetrable for expenditures actually possible
with current World Gross Product". Modern strong encryption systems are
near-perfect,  and Scheme/Java/E object reference mechanisms are indeed

Taking the good news and bad news for the virtual world together, we see
that in the virtual world, cost-effective defense means "defense in
correctness", i.e., defense through quality.

In response to David Wagner: Having spent our lives in a physical world
where defense in depth is king--having spent our entire specie's evolution
in a world where defense in depth is king--it is not surprising that even
people labeled "computer security experts" have trouble recognizing this
change in economic fundamentals. Defense in depth feels right at the deepest
gut level, and has always worked correctly in practice until a handful of
years ago. Moreover, even during all these recent years when defense in
depth has ceased to be cost-effective as a concept, defense in depth has
been the only implementation choice available--there are no capability
systems for experts to recommend to their clients even if they were able to
make the jump intellectually. And finally, defense in depth will still work
a little bit in computer systems as long as the target is not too popular:
Diablo I would not have become free-to-hack if it had not been a big enough
success to invoke the peculiarities of virtual world security economics. But
defense in depth deteriorates at horrific speed in virtual worlds when there
are big financial incentives involved. Digital cash, for example would put
those incentives in place: a whole new class of entrepreneurial attackers
would arise in a world of digital cash. Defense in depth and digital cash
cannot coexist. One of them has to be erased. So far, it is the digital cash
that has been erased. Some of us on this list hope to switch that.

Ben Laurie also made a point that is true: if you grab someone's hardware,
you can probably grab his capabilities. All this perfection we can attain in
the virtual world is only able to achieve the following level of excellence:
it can force the battle back into the physical world, where we wind up
protecting our physical machines, once again with defense in depth :-)

Reply to Hal Finney: 2-factor security is probably still a good idea in the
virtual world because of the risk of user error, though I stick to my claim
that, if credit cards were capabilities, we would be using 1-factor security
for credit card transactions today (1-factor security would be more security
than current credit cards, even with endless checking of public identity
information). Capabilities certainly allow 2-factor security. One example of
2-factor security would use 2 pairs of sealers/unsealers (in E,
BrandMakers). Put the value inside a pair of sealed boxes, each with a
different sealer. In order to acquire the value, one must have both
unsealers. An interesting piece of unexplored (to my knowledge) space is the
development of 2-factor security patterns for applications like credit
cards. Of course, such patterns are of low value until we have capability
infrastructures built out enough to exploit these patterns :-)