Visa International and the Java 2 Security Model | Face to Face with Dr. Edward W. Felten

by Steven Meloan

November 19, 1999 -- As organizations increasingly offer their vital information across intranets, extranets, and virtual private networks, the traditional boundaries between proprietary business networks and the outside world are rapidly melting away. But such expanded points of contact also bring with them new risks in terms of security -- from viruses to sabotage (both internal and external); from hackers to simple coding errors. And as the definition of computational devices extends to include everything from telephones, to pagers, to smart cards, concerns about security run well beyond the traditional CPU box.

With these considerations in mind, the Java^TM 2 platform was built with a sophisticated model of security as a key design feature. It is a policy-based model that is easily configurable, and provides fine-grained access control. Perhaps the greatest advantage of the model is its flexibility. It gives businesses the ability to access and affect a wide spectrum of functionality, while still protecting themselves from security breaches.

Evolution of the Java^TM Platform Security Model

Version 1: The JDK 1.0 Security Model

The original JDK^TM 1.0 version security model consisted of the simple duality of "trusted" local code and "untrusted" remote code. Any remote code was restricted to the "sandbox" -- an execution area with extremely limited access to system resources (such as the ability to read and write to a local file). This model provided a very high level of security. But because it was so secure, it proved to be too limiting for many uses. For example, with JDK 1.0 software it was impossible to implement simple facilities like an applet-based word processor with the capacity to save a file to the local disk.

This blanket discrimination policy against applets was later relaxed somewhat in the JDK 1.1 version security model. Here the concept of a digitally "signed" applet was introduced. Signed applets, delivered along with their signatures in the Java Archive (JAR) format, were deemed "trusted." And as such they were afforded all of the powers and privileges (and risks) of trusted local code.

Version 2: JDK 1.1 Security Model

While the JDK 1.1 security model opened up whole new functionalities to downloadable code, the signed applet paradigm still left some requirements unmet. There was no "granularity" to the security, no in-between facility to grant partially trusted remote code a partial degree of access to the local system.

But the Java 2 platform security model addresses this issue head-on. It provides a fine-grained and easily configurable security architecture. It delivers the level of security businesses and developers require, while providing the flexibility and functionality needed to create rich enterprise applications.

Java^TM 2 Security API

The Java 2 Security API is core to the Java 2 platform. It applies the same fine-grained security model uniformly across the system -- whether the code in question is local or remote; an applet or an application; a bean or a servlet.

Today's Model: Java 2 Platform Security

The security model is policy-based, meaning it separates out the actual permission specifics from the runtime code. This means that administrators can define the permissions granted to a given executable via an externally configurable policy file. Such a file establishes a fine-grained level of access control -- defining read/write/execute permissions for specific files and directories, as well as allowable network connections.

The Java runtime environment maintains a mapping from code objects to their protection domains (groupings of objects from the same network location and with the same digital signature), and from there, to their respective permissions. At runtime, if a given thread of execution crosses multiple security domains, it is constrained by the intersection of permissions restricting those various domains. As a result, a less powerful domain cannot gain added permissions by calling a more powerful domain.

Elements of the Java^TM 2 Platform Security Model

The Java 2 Platform, Standard Edition includes the fine-grained security model outlined above. In addition, it includes three new tools to augment its security architecture, namely: keytool, jarsigner and policytool.

• Keytool manages the keys and certificates used to digitally sign applications and applets. It creates key pairs and self-signed X.509 v1 certificates, and manages keystores (a protected database that holds keys and certificates). Key pairs are used to encrypt and decrypt, and certificates are used to establish trusted entities.

• Jarsigner signs JAR files, and verifies the signature(s) of signed JAR files. The JAR file is what the model uses to determine whether a file is trusted or untrusted. It accesses the keystore in order to locate a key when signing a JAR file. Keytool and jarsigner replace the previous functionality of the javakey tool.

• Policytool creates and modifies the external policy configuration files that define an installation's security policy.

The Java Security API, combined with keytool, jarsigner and policytool, defines the core Java 2 platform security model for both the Java 2 Platform, Standard Edition and the Java 2 Platform, Enterprise Edition. However, the security story does not end here. There are a number of optional packages that can be added to enhance security. Specifically:

• The Java Cryptography Extension (JCE) 1.2 API is an optional package to the Java Cryptography Architecture (JCA) API. The JCA API makes it possible for developers to use any cryptographic algorithm they choose. As such, developers are neither tied to a specific cryptographic algorithm (such as RSA), nor a particular vendor's implementation of that algorithm. This is particularly important because different countries restrict different cryptographic technologies (i.e. one developer may not have legal access to the same libraries used by another). The Java Cryptography Extension API expands the JCA API to include additional APIs for encryption, key exchange and Message Authentication Code (checksums), and upgrades the JDK software's certificate management infrastructure to support X.509 v3 certificates. The JCE API is released separately as an optional package. Due to U.S. export control laws, the Java Secure Socket Extension (JSSE) API is not exportable outside the U.S. and Canada.

• The Java Authentication and Authorization Service (JAAS) API is currently available as part of Sun's Early Access program for the Java 2 Platform, Standard Edition. It is a framework that supplements the Java 2 platform with user-based authentication and access control capabilities. While the Java 2 SDK software offered the means to enforce access controls based upon where code came from, and who signed it, until now it hadn't offered any means to control who ran the code. The JAAS API includes a Java technology implementation of the standard Pluggable Authentication Module architecture, and provides support for user-based, group-based, or role-based access controls. JAAS also offers the facility to map a single username and password entry to authenticate to multiple services, each with its own specific username and password requirements.

• The Java Secure Socket Extension, currently in beta, is an optional package that provides Secure Socket Layer (SSL) v3 and Transport Layer Security (TLS) 1.0 support to the Java 2 platform. Where the JCE API provides for encryption directly within an application, the JSSE API operates at a higher level, offering secure network communication -- including encryption, server authentication, message integrity, and optional client authentication. By abstracting the complex underlying security algorithms and "handshaking" mechanisms of SSL and TLS, the Java Secure Socket Extension minimizes the risk of creating subtle, but still dangerous, security holes. Using JSSE, developers can provide for the secure passage of data between a client and a server running any application protocol, including HTTP, Telnet, NNTP, and FTP, over TCP/IP. Due to U.S. export control laws, the JSSE package is not exportable outside the U.S. and Canada.

True Innovation -- Standing on Shoulders

The Java 2 platform security model, like the rest of the Java platform, was developed through a community participative methodology called the Java Community Process.

The Java security model has evolved with the help of countless developers, along with noted security experts from IBM, Hewlett-Packard, Intel, Digital, Netscape, Microsoft and Oracle, and others. The model has also been the beneficiary of significant contributions from such respected security experts as Ed Felten of Princeton University, Peter Newman of the Stanford Research Institute, Jerome Salzer of MIT, and Fred Schneider of Cornell University.

The resulting specifications offer both open and highly interoperable solutions. They are designed to be platform independent, scalable and interoperable with other technologies, and they offer fine-grained and easily configurable security. And through the Java Community Process, the Java security model has a clearly defined mechanism for rapidly evolving and responding to the growing and ever-changing needs of the business community.

Technologies offered by other vendors consist of a collection of end-to-end Web development products that are inextricably tied to the environment for which they are developed, making the resulting technologies interoperable with other platforms.

The Java platform, with its characteristic cross-platform compatibility and its superior security model, is the cornerstone of enterprise critical applications being used by such organizations as Visa International, Charles Schwab, the US Postal Service, The UCLA Medical Center, Banco Brasil, and Hong Kong Telecom.

See Also

Visa International and the Java 2 Security Model:
(http://java.sun.com/features/1999/11/security.visa.html)

Face to face with with Dr. Edward W. Felten:
(http://java.sun.com/features/1999/11/security.qa.html)

Java^TM 2 Platform Security Features Overview:
(http://java.sun.com/docs/books/tutorial/security1.2/overview/index.html)

Java 2 Software Security:
(http://java.sun.com/products/jdk/1.2/docs/guide/security/index.html)

Java^TM Security API Home Page:
(http://java.sun.com/security)

Security-Specific Glossary:
(http://java.sun.com/docs/books/tutorial/security1.2/summary/glossary.html)

[ This page was updated: 21-Nov-99 ]