and then regenerate the digital signature without access to the private key. It is, however, possible to replace one message that was signed by a private key with another message that was signed by that same private key.
7.3.4 Encryption Engines
The final engines well discuss handle actual encryption. These engines are part of the Java Cryptography Extension JCE and the Java Secure Socket Extension JSSE rather than the core security package.
Encryption engines handle the encryption and decryption of arbitrary data, just as we would expect. An important thing to note is that the encryption engines that are part of JCE are not used in the generation and
verification of digital signatures −− digital signatures use their own algorithms to encrypt and decrypt the message digest that are suitable only for manipulating data the size of a message digest. This difference allows
the digital signature engine to be exportable, where the encryption engines may not be.
7.4 Summary
Much of the Java security package is made up of a collection of engines, the basic properties of which weve outlined in this chapter. As a unit, these engines allow us primarily to create digital signatures −− a useful
notion that authenticates a particular piece of data. One thing that a digital signature can authenticate is a Java class file, which provides the basis for a security manager to consider a class to be trusted as least to some
degree, even though the class was loaded from the network.
The security package, like many Java APIs, is actually a fairly abstract interface that several implementations may be plugged into. Hence, another feature of the security package is its infrastructure to support these
differing implementations. In the next chapter, well explore the structure of the security package and how it supports these differing implementations; well then proceed into how to use the engines of the security
package. 122
Chapter 8. Security Providers
The cryptographic engines in Java that provide for digital signatures, message digests, and the like are provided as a set of abstract classes in the Java security package. Concrete implementations of these classes
are provided by Sun in the SDK, and you have the option of obtaining third−party implementations of these engines. All of this is made possible through the security provider infrastructure. The provider infrastructure
allows concrete implementations of various classes in the security package to be found at runtime, without any changes to the code. This provides a consistent API that can be used by all programs, regardless of who
provides the actual implementation.
Java 2, version 1.3 comes with two security providers: one performs operations that implement DSA−based algorithms plus some other default operations and one performs operations that implement RSA−based
algorithms. Sun supplies two additional security providers: one with JCE and one with JSSE. Well discuss how to install those additional providers in this chapter and then look at the Java classes that comprise the
security provider architecture.
In terms of actual programming, the classes were going to examine in this chapter are rarely used −− hence, we will not delve much into programming. To meet the needs of most developers, end users, and
administrators, this chapter focuses on the architecture of the security provider since that gives us the ability to substitute new implementations of the cryptographic engines well use in the rest of the book. Following that
discussion, well move into the implementation of the architecture for those readers who are interested in the details.
8.1 The Architecture of Security Providers
The security provider abstracts two ideas: engines and algorithms. In this context, engine is just another word for operation; there are certain operations the security provider knows about, and in Java, these
operations are known as engines. An algorithm defines how a particular operation should be executed. An algorithm can be thought of as an implementation of an engine, but that can lead to confusion because there
may be several implementations of an algorithm.
As a simple example, the Java security package knows about message digests. A message digest is an engine: it is an operation a programmer can perform. The idea behind a message digest is independent of how any
particular message digest may be calculated. All message digests share certain features, and the class that abstracts these common features into a single interface is termed an engine. Engines are generally abstract and
are always independent of any particular algorithm.
A message digest may be implemented by a particular algorithm, such as MD5 or SHA. An algorithm is generally provided as a concrete class that extends an abstract engine class, completing the definition of the
class. However, there may be many classes that provide a particular algorithm; you may have an SHA class that came with your Java platform and you may also have obtained an SHA class from a third party. Both
classes should provide the same results, but their internal implementations may be vastly different.
Security providers are the glue that manages the mapping between the engines used by the rest of the security package such as a message digest, the specific algorithms that are valid for those engines such as an SHA
digest, and the specific implementations of that algorithmengine pair that might be available to any particular Java virtual machine. The goal of the security provider interface is to allow an easy mechanism
where the specific algorithms and their implementations can be easily changed or substituted. The security provider allows us to change the implementation of the SHA digest algorithm that is in use and to introduce a
new algorithm to generate a digest.
Hence, a typical programmer only uses the engine classes to perform particular operations. You dont need to worry about the classes that actually perform the computation. The engine classes provide the primary
interface to the security package. An administrator, meanwhile, needs to know only the name of the provider class so that she can ensure that the correct provider class is used.
8.1.1 Components of the Architecture
The architecture surrounding all of this has these components: Engine classes
These classes come with the Java virtual machine as part of the core API. Algorithm classes
At the basic level, there is a set of classes that implement particular algorithms for particular engines. A default set of these classes is provided by the supplier of the Java platform; other third−party
organizations including your own can supply additional sets of algorithm classes. These classes may implement one or more algorithms for one or more engines; it is not necessary for a set of classes
from a particular vendor to implement all possible algorithms or all possible engines. A single algorithm class provides a particular algorithm for a particular engine.
The Provider class Each set of algorithm classes from a particular vendor is managed by an instance of the class
Provider . A provider knows how to map particular algorithms to the actual class that implements
the operation. The Security class
The Security
class maintains a list of the provider classes and consults each in turn to see which operations it supports.
In later chapters, well look at the individual algorithms and engines of this architecture; for now, well discuss the
Provider and
Security classes. These two classes together make up the idea of a security provider.
The security providers rely on cooperation between themselves and the rest of the Java security package in order to fulfill their purpose. The details of this cooperation are handled for us −− when we use the
MessageDigest class to generate a digest, for example, its the responsibility of the
MessageDigest class to ask the
Security class which particular class to use to generate the digest. The
Security class in
turn asks each of the providers whether or not they can supply the desired digest. So a typical program that wants to use the security package does not interact directly with the security
provider. Instead, the security provider is transparently useful to the programmer and to the end user. An end user, a system administrator, or a developer can configure the security provider; this is a result of the security
provider being based on a set of provider classes. While there is a default provider class, the end user or system administrator can replace the default provider with another class. In addition, a user or programmer
can augment the default provider class by adding additional provider classes.
When the security package needs to perform an operation, it constructs a string representing that operation and asks the
Security class for an object that can perform the operation with the given algorithm. For
example, the idea of generating a message digest is represented by a particular engine; its name i.e., 124
