The JavaTM Tutorial
Previous Page Lesson Contents Next Page Start of Tutorial > Start of Trail Search
Feedback Form

Trail: Security in Java 2 SDK 1.2

Lesson: Security Features Overview

JDK 1.2 contains substantial security features enhancements: policy-based, easily-configurable, fine-grained access control; new cryptographic services and certificate and key management classes and interfaces; and three new tools. These topics are discussed in the following sections:


Security Architecture Extensions

Access control has evolved to be far more fine-grained than in previous versions of the Java platform.

The original security model provided by the Java platform, known as the "sandbox" model, existed in order to provide a very restricted environment in which to run untrusted code obtained from the open network. In the sandbox model, shown in the following diagram, local code is trusted to have full access to vital system resources, such as the file system, but downloaded remote code (an applet) is not trusted and can access only the limited resources provided inside the sandbox. A security manager is responsible in this and subsequent platforms for determining which resource accesses are allowed.

JDK 1.0 Security Model:


JDK 1.1 introduced the concept of a "signed applet," as illustrated in the next figure. A digitally signed applet is treated like local code, with full access to resources, if the public key used to verify the signature is trusted. Unsigned applets are still run in the sandbox. Signed applets are delivered, with their respective signatures, in signed JAR (Java ARchive) files.

JDK 1.1 Security Model:


JDK 1.2 introduces a number of improvements over JDK 1.1. First, all code, regardless of whether it is local or remote, can now be subject to a security policy. The security policy defines the set of permissions available for code from various signers or locations and can be configured by a user or a system administrator. Each permission specifies a permitted access to a particular resource, such as read and write access to a specified file or directory or connect access to a given host and port..

The runtime system organizes code into individual domains, each of which encloses a set of classes whose instances are granted the same set of permissions. A domain can be configured to be equivalent to the sandbox, so applets can still be run in a restricted environment if the user or the administrator so chooses. Applications run unrestricted, as before, by default but can optionally be subject to a security policy.

The new security architecture in JDK 1.2 is illustrated in the following figure. The arrow on the left end refers to a domain whose code is granted full access to resources; the arrow on the right refers to the opposite extreme: a domain restricted exactly the same as the original sandbox. The domains in between have more accesses allowed than the sandbox but less than full access.

JDK 1.2 Security Model:


Cryptography Architecture Extensions

Note: This section is of interest mostly to developers already familiar with cryptography concepts. If you're not such a person, you may want to skip ahead to the section Security-Related Tools. Note: Some of the cryptography terminology is defined in the Glossary (in the Security in Java 2 SDK 1.2 trail) . For more information about cryptography, we recommend the book Applied Cryptography by Bruce Schneier, published by John Wiley & Sons, Inc., New York, NY, 1996.

The first release of the JDK Security API in JDK 1.1 introduced the Java cryptography architecture (JCA), which refers to a framework for accessing and developing cryptographic functionality for the Java platform. The JCA includes a provider architecture that allows for multiple and interoperable cryptography implementations. The term cryptographic service provider (CSP), or simply provider, refers to a package (or a set of packages) that supplies a concrete implementation of a subset of the cryptography aspects of the JDK Security API.

In JDK 1.1 a provider could, for example, contain an implementation of one or more digital signature algorithms, message digest algorithms, and key-generation algorithms. JDK 1.2 adds five more types of services:

JDK 1.2 also enables a provider to supply a random-number generation (RNG) algorithm.

Sun's version of the Java Runtime Environment comes standard with a default provider, named SUN. The SUN provider package includes implementations of a number of DSA (Digital Signature Algorithm) services, implementations of the MD5 (RFC 1321) and SHA-1 (NIST FIPS 180-1) message digest algorithms, a certificate factory for X.509 certificates and certificate revocation lists, a pseudo-random-number generation algorithm, and a keystore implementation.

The Java Cryptography Extension (JCE) extends the JDK to include APIs for encryption, key exchange, and message authentication code (MAC). Together the JCE and the cryptography aspects of the JDK provide a complete, platform-independent cryptography API. The JCE is released separately as an extension to the JDK, in accordance with U.S. export control regulations, and is not covered in this trail.

The following figure illustrates the various JCA modules. The SPI (service provider interface) layer, representing methods that must be implemented by cryptographic service providers, is described in the following section.


This figure has been reduced to fit on the page.
Click the image to view it at its natural size.


Cryptographic Services

A number of new "engine" classes have been added in JDK 1.2 to the Signature, MessageDigest, and KeyPairGenerator classes available in JDK 1.1. An engine class defines a cryptographic service in an abstract fashion (without a concrete implementation). An engine class defines API methods that allow applications to access the specific type of cryptographic service it provides, such as a digital signature algorithm. The actual implementations, from one or more providers, are those for specific algorithms.

The application interfaces supplied by an engine class are implemented in terms of a service provider interface (SPI). That is, each engine class has a corresponding abstract SPI class that defines the service provider interface methods that cryptographic service providers must implement.

For example, an API client may request and use an instance of the Signature engine class to access the functionality of a digital signature algorithm to digitally sign a file. The actual implementation supplied in a SignatureSpi subclass would be that for a specific kind of signature algorithm, such as SHA-1 with DSA or MD5 with RSA.

Each instance of an engine class encapsulates an instance of the corresponding SPI class as implemented by a cryptographic service provider. Each API method of an engine class invokes the corresponding SPI method of the encapsulated SPI object.

Certificate Interfaces and Classes

JDK 1.2 introduces certificate interfaces and classes for parsing and managing certificates and provides an X.509 v3 implementation of the certificate interfaces. A certificate is basically a digitally signed statement from one entity (person, company, etc.), saying that the public key of another entity has some particular value.

Some of the certificate-related classes (all in the java.security.cert package) are as follows.

Key Management Classes and Interfaces

JDK 1.1 introduced abstract Key interfaces. JDK 1.2 adds

Security-Related Tools

JDK 1.2 introduces three new tools:

Previous Page Lesson Contents Next Page Start of Tutorial > Start of Trail Search
Feedback Form

Copyright 1995-2004 Sun Microsystems, Inc. All rights reserved.