JAVA SECURITY: PRESENT AND NEAR FUTURE Li Gong ince the inception of Java,1,2 there has • Usability—To be ubiquitous and been strong and growing interest in accepted in the marketplace, the plat- JavaSoft SJava’s security as well as in new secu- form must be easy to use for building rity issues raised by this technology’s deploy- small- and large-scale systems and ment. These concerns have reached the applications. mainstream—the New York Times, the Wall • Simplicity—To inspire confidence in its Street Journal, and others have run stories correctness, the platform cannot be too on Java security. However, we must exam- complex to analyze (by code inspection ine Java’s trustworthiness comprehensively, or testing, for example) for critical prop- from a broad dependability perspective,3-6 erties. not simply from the journalistic view. • Adequacy—The platform must contain A simplistic statement such as “Java is [or is all essential features and building not] secure” doesn’t come close to capturing blocks for supporting higher-level trust- the complexity of the issues involved. To pass worthiness (security) requirements. judgment on whether Java is a trustworthy • Adaptability—The platform must language or platform, we must precisely evolve with ease, following demand specify requirements of the overall system— and market reality. in this case, computer systems and the glob- al Internet infrastructure. Only then can we Judged by these (perhaps biased) criteria, hope to demonstrate vigorously that the plat- Java scores very favorably compared with form architecture satisfies or contributes to other existing languages and programming the satisfaction of the overall requirements, systems. In particular, Java’s platform inde- and that the platform’s actual implementation pendence greatly reduces the complexity— satisfies the architecture’s design requirement. and thus the probability of design and Unfortunately, neither of these two cru- implementation errors—of dealing with het- cial steps is feasible for security today. The erogeneous environments. The “write once, shape and the characteristics of the nation- run everywhere” philosophy also helps al (or global) system infrastructure are evolv- improve availability. ing rapidly. Consequently, such widely used Moreover, the encouragement to write terms as “Internet security” cannot capture code exclusively in Java (Sun’s “100% pure the essence of the trustworthiness required Java” initiative) is highly desirable because it of such an infrastructure. (Admittedly, such forces all security controls to go through the terms were not very helpful in the past, Java Virtual Machine. This raises the chances either.) Moreover, though formal methods of putting the necessary protection mecha- have been used successfully to verify some nisms in place and getting them (almost) The global system hardware devices, they are not sufficiently right. Other popular platform systems, such advanced to address correctness issues of as MS-DOS/Windows, typically require infrastructure is large-scale software systems. native methods with direct access to raw Given this state of affairs, we must use an system resources and devices. This makes evolving rapidly. alternative (albeit less scientific and idealis- retrofitting nonbypassable protection mech- tic) set of criteria to examine platform trust- anisms with backward compatibility an Java’s security model worthiness. From an industrial point of almost insurmountable task.7,8 view, such criteria must include the follow- This article introduces Java’s existing secu- must keep pace. ing considerations: rity features and the way they contribute to 14 IEEE Micro 0272-1732/97/$10.00 © 1997 IEEE . its overall usability, simplicity, adequacy, and adaptability in Java Web the global computing arena. It also discusses JavaSoft’s plans JavaOS HotJava Server JECF JMAPI to make new features available as the technology evolves. Network Access file control Servlet Gate The sandbox security model system list admin. object The original security model that Java provides is known as clients GUI the sandbox, a very restricted environment in which to run untrusted code (applets) obtained from the open network. Login Authorization/ SSL/ Code SSL/ protocol delegation SKIP signing SKIP The essence of the sandbox model is that a computer entrusts local code with full access to vital system resources (such as JDK Protection Access Signature DES/3DES domain control certification the file system). It does not, however, trust downloaded RSA/D-H remote code, which can access only the limited resources Class loader/manager IDEA, etc. provided inside the sandbox. We have deployed the sandbox model through the Java Nonexportable encryption extension Development Toolkit (JDK, the current version as of May 1997 is 1.1.2), and applications built with JDK generally adopt it. JDK enforces overall security through a number of mech- Figure 1. Overall architecture. JECF: Java Electronic anisms. First, the language is designed to be type safe1 and Commerce Framework; JMAPI: Java Management API. easy to use. The hope is that the burden on programmers is such that they are less likely to make subtle mistakes than they would using other programming languages such as C to accommodate rapidly emerging technologies based on or C++. Java. It must function across a wide range of platforms. These Second, compilers and a bytecode verifier ensure that include JavaOS, which is a Java-based operating system that applications built with JDK execute only legitimate Java code. runs directly on naked hardware, as well as native host sys- Moreover, a class loader defines a local name space and tems such as Microsoft Windows and MacOS. ensures that an untrusted applet cannot interfere with the Figure 1 shows the relationships between various Java operation of other Java programs. components. Finally, the Java Virtual Machine mediates access to cru- It is natural that JDK should serve as the base platform for cial system resources, and a SecurityManager class checks delivering security technologies to Java-based solutions. and restricts untrusted code’s actions to the bare minimum. Future releases of JDK will deliver at least the following secu- The actual implementation of the Java language and the rity features: runtime system is likely to contain bugs, at least for some time, just as any large-scale software system would. This is • Basic language safety features (type safety, bytecode clearly manifested in the discovery of some well-known verifier, class loader); bugs, perhaps most prominently those found by the research • Essential cryptographic primitives (MD5, SHA-1, DSA, team at Princeton University.9 X.509, DES, triple-DES); • Fundamental system security features (protection Evolving the sandbox model domain, access control, authorization and delegation, As Java gains popularity among users and developers, security policy manager); and requests for various security features have been flowing in. • Necessary networking and Web-based security support Among these are support for enabling flexible and config- (user authentication protocols, code signing, secure urable security policies, support for cryptographic capabili- communication protocols such as SSL and SKIP). ties, security protocols for network-based authentication and secure communication, and easy-to-use administration tools. Products built on top of JDK may need additional securi- Starting with JDK 1.1, JavaSoft will provide general Java ty features. For example, the Java Web Server (previously users and developers with a series of security features meet- known as Jeeves) may provide an additional framework for ing customer requirements. securely administering servlets, while the HotJava browser Applet signing. A prominent new security feature in JDK may provide a browser-specific user interface for configur- 1.1 is built-in support for applet signing. Using this feature, ing security policies. applet writers can digitally sign applets using their signature This technical architecture is potentially limited by business keys. The person viewing the applet can use a known public considerations such as licensing and exportability. The stan- key to verify that the applet is correctly signed and then choose dard JDK will be fully exportable under US laws and thus to accept the applet as trusted. This will enable the trusted cannot include strong encryption technology. The Java applet to run as if it were local code. JDK 1.1 contains the nec- Cryptography Extensions will be the vehicle that makes essary tools for code signing, including support for digital sig- unexportable technology available to US domestic users. natures, message digest, and certificate manipulation. JavaSoft will publish the API specification and documenta- New architectural directions. The design of an overall tion and make them available in accordance with the appro- Java security architecture is constrained in a number of ways. priate laws and regulations. It must be backward compatible, but also flexible enough Not shown in Figure 1 is a policy and certification facility May/June 1997 15 . Security Applications Java security/cryptography APIs Per site policy Sun's Reference Native reference implementation code implementation by implementation in Java xyz.com Per user configuration and Certificate per installation configuration authority Figure 3. Cryptographic support allowing alternative providers. Figure 2. Policy configuration. tographic functions. As illustrated in Figure 3, an application that