Article development led by
Difficult technical problems and
tough business challenges.
By Li GoNG
the JAVA PLAtform JDK 1.0 was released in 1995 with a
simplistic all-or-nothing “sandbox” security model. Li
Gong joined the JavaSoft division of Sun Microsystems
in 1996 and led the redesign of the security architecture
that was first released in 1998 as JDK 1. 2 and is now
deployed on numerous systems and devices from the
desktop to enterprise and mobile versions of Java.
This article looks back at a few of the most difficult
technical problems from a design and engineering
perspective, as well as some tough business
challenges for which research scientists are rarely
trained. Li offers a retrospective here culled from
four previous occasions when he had the opportunity
to dig into old notes and refresh his memory: 2002
Workshop on the Economics of Information Security,
Berkeley, CA; 2003 UW/MSR/CMU Summer Institute,
Stevenson, Washington; ACM’s 2009 Computer
Security Applications Conference, Honolulu; and
a seminar last May at the University of Cambridge
Computer Laboratory, england.
Although security architects are not
“in business,” it is important that they
are clear about who their customers are.
They rarely build directly for individual
end users, who do not directly use the
operating system, although they are often the eventual beneficiaries.
Most of the work of a security architect is targeted at application programmers, and Java is no exception. Here
the design goal is to help programmers
get what is intended out of their code—
more specifically, to make the most
common cases the easiest to write and
get right, and to reduce the risk of coding mistakes or bugs. As such, the four
attributes of the Java security architecture1 should generally apply:
˲ ˲ Usability. To be ubiquitous and
accepted in the marketplace, the architecture must be easy to use and
suitable for writing a wide variety of applications.
˲ ˲ Simplicity. To inspire confidence
in the correctness of the architecture, it
must be easy to understand the critical
design properties and to analyze the
˲ ˲ Adequacy. The architecture must
contain all essential features and
building blocks for supporting higher-level security requirements.
˲ ˲ Adaptability. The design must
evolve with ease, following demand
and market reality. In particular, it
should avoid overprescribing that restricts programmability.
In hindsight, having these guiding principles in place was crucial.
In the original JDK 1.0, the security
mechanism was all about special casing—code being inside versus outside
the sandbox. That seemingly simple
architecture paradoxically resulted in
complicated design, fragile code, and
numerous security bugs. In JDK 1. 2,
security was designed to be general, systematic, and simple-minded, and this
resulted in a more robust and usable
platform. We fought off a competing design from Netscape that was specialized
for browser usage. Our design is not
only broad in scope, covering desktops,
servers, and embedded and mobile de-