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, as described below.

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. A security manager is responsible (in this and subsequent platforms) for determining which resource accesses are allowed.

The 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 (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 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 by the runtime system 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. The arrow on the left end refers to a domain whose code is granted full access to resources, while the one 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 mostly of interest to developers already familiar with cryptography concepts. If you're not such a person, you may want to skip ahead to Security-Related Tools.. Note: Some of the cryptography terminology is defined in the Glossary(in the Java Security 1.2 trail) . For more information about cryptography, see books such as "Applied Cryptography" by Bruce Schneier.

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 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 additional types of services:

JDK 1.2 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. The SPI (Service Provider Interface) layer, representing methods that must be implemented by cryptographic service providers, is described in the following section.


Cryptographic Services

A number of new classes referred to as "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, for each engine class, there is a corresponding abstract SPI class, which defines the Service Provider Interface methods that Cryptographic Service Providers must implement.

As an example, an API client may request and utilize 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 SHA1 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.

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 (person, company, etc.), 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 keystore type defines the storage and data format of the keystore information.

  • 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. The key material for a key may, for example, consist of the key itself and the algorithm parameters used to calculate the key value. A transparent representation of keys means that you can access each key material value individually.

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

Security-Related 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, to 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 policy configuration files that define your installation's security policy.

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