Previous | Next | Trail Map | Security in JDK 1.2 | Contents

Security Features Overview

JDK 1.2 contains substantial security features enhancements. This release introduces:


Security Architecture Extensions

Policy-based, easily-configurable, fine-grained access control

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 is known as the "sandbox" model, which existed in order to provide a very restricted environment in which to run untrusted code obtained from the open network. The essence of the sandbox model is that local code is trusted to have full access to vital system resources (such as the file system), while downloaded remote code (an applet) is not trusted and can access only the limited resources provided inside the sandbox. This sandbox model is illustrated in the figure below:

JDK 1.0 Security Model:

JDK 1.1 introduced the concept of a "signed applet", as illustrated by the figure below. A digitally signed applet is treated like local code (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 of all, 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 system administrator. Each permission specifies a permitted acccess to a particular resource (such as "read" and "write" access to a specified file or directory, "connect" access to a given host and port, etc.).

Code is organized into individual domains. Each domain 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 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 figure below.

JDK 1.2 Security Model:

Cryptography Architecture Extensions

Note: This section is mostly of interest to developers already familiar with cryptography concepts. For more information about cryptography terminology, see the Glossary(in the Java Security 1.2 trail) .

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 "provider" for short, refers to a package (or a set of packages) that supply 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 additional types of services:

It also enables a provider to supply a random number generation (RNG) algorithm.

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 by this trail.

The following figure illustrates the various JCA modules:


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. 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, for each engine class, there is a corresponding abstract SPI class, which defines the Service Provider Interface methods that cryptographic service providers must implement.

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

The "SUN" Provider

JDK 1.2 comes standard with a default provider, named "SUN". The "SUN" provider package includes:

  • An implementation of the Digital Signature Algorithm (DSA), described in NIST FIPS 186.

  • An implementation of the MD5 (RFC 1321) and SHA-1 (NIST FIPS 180-1) message digest algorithms.

  • A DSA key pair generator for generating a pair of public and private keys suitable for the DSA algorithm.

  • A DSA algorithm parameter generator.

  • A DSA algorithm parameter manager.

  • A DSA "key factory" providing bi-directional conversions between (opaque) DSA private and public key objects and their underlying key material.

  • An implementation of the proprietary "SHA1PRNG" pseudo-random number generation algorithm.

  • A "certificate factory" for X.509 certificates and Certificate Revocation Lists (CRLs).

  • A keystore implementation for the proprietary keystore type named "JKS".

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, saying that the public key of some other entity has some particular value.

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

  • Certificate - This class is an abstraction for certificates that have different formats but important common uses. For example, different types of certificates, such as X.509 and PGP, share general certificate functionality (like encoding and verifying) and some types of information (like a public key). X.509, PGP, and SDSI certificates can all be implemented by subclassing the Certificate class, even though they contain different sets of information, and they store and retrieve the information in different ways.

  • CertificateFactory - This class defines the functionality of a certificate factory, which is used to generate certificate and certificate revocation list (CRL) objects from their encodings.

  • X509Certificate - This is an abstract class for X.509 certificates. It provides a standard way to access all the attributes of an X.509 certificate.

Key Management Classes and Interfaces

JDK 1.1 introduced abstract Key interfaces. JDK 1.2 adds
  • a KeyStore class (an engine class) that supplies well-defined interfaces to access and modify the information in a keystore, which is a repository of keys and certificates. It is possible for there to be multiple different concrete implementations, where each implementation is that for a particular type of keystore.

  • a default KeyStore implementation, which implements the keystore as a file, utilizing a proprietary keystore type (format) named "JKS". The keystore implementation protects each private key with its individual password, and also protects the integrity of the entire keystore with a (possibly different) password.

  • Key Specification Interfaces. Key specifications are "transparent" representations of the key material that constitutes a key. A transparent representation of keys means that you can access each key material value individually.

  • a tool (keytool) for managing keys and certificates.

New Tools

JDK 1.2 introduces three new tools:
  • keytool is used to create pairs of public and private keys; to import and display certificate chains, and export certificates; and to generate X.509 v1 self-signed certificates and certificate requests that can be sent to a Certification Authority.

  • jarsigner signs JAR (Java Archive Format) files, and verifies the authenticity of the signature(s) of signed JAR files.

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

Previous | Next | Trail Map | Security in JDK 1.2 | Contents