alternate location for that library, which offers a slight security advantage. Note that if the user can write to the hardwired directory where the library lives, this advantage no longer exists: the user can simply overwrite
the existing library instead of changing an environment variable to point to another library; the end result is the same.
6.5 Comparison with Previous Releases
In Java 2, version 1.3, no class loader can define a class that is in the java package i.e., whose class name begins with
java . In 1.2 and earlier releases, that restriction is not present unless you code it into your own
class loader. Thats one reason why there is no class loader that uses the checkPackageDefinition
method although that method was not used in 1.2 either. In Java 1.1, class loading was significantly different. To begin, there are no code source or protection domain
objects in 1.1, and classes do not carry associated permissions with them. Security in 1.1 is solely up to the security manager, and the class loader simply loads classes.
That means that the loadClass
method in 1.1 is very different. In particular, there is only one defineClass
method that it can call the one without a protection domain argument, and it does not call the
findClass method. In order to write a class loader in 1.1, you must override the
loadClass method and perform all your work in that method. We show an example of this in
Appendix D. The secure class loader and URL class loader were introduced in Java 2, version 1.2. In 1.1, the primordial
class loader is used to load all classes on the classpath in addition to the classes in the core API. Delegation was also introduced in Java 2, version 1.2. In 1.1, a custom class loader can make a special method
call to load classes from the classpath, but there is no general hierarchy of class loaders. In 1.1, the default behavior of the methods that retrieve resources is to return
null .
The RMI class loader does not exist in Java 1.0.
6.6 Summary
The class loading mechanism is integral to Javas security features. Typically this integration is considered in light of the relationship between the class loader, the access controller, and the security manager. However,
the class loader is important in its own right. The class loader must enforce the namespace separation between classes that are loaded from different sites especially when these different sites are untrusted; this helps to
enforce the security mechanisms of the Java language.
For sites that need a more flexible security policy, a custom class loader may be desirable. Custom class loaders allow the security policy to be modified as classes are defined; this is similar to and compatible with
providing a new implementation of the Policy
class. However, custom class loaders can bypass the policy class altogether, which means that they can define immutable security policies though, of course, installing
the class loader in the first place still requires that applications have the appropriate policy−based permissions. In certain circumstances, this is easier than modifying and installing a new
Policy class.
Chapter 7. Introduction to Cryptography
So far, weve examined the basic level of Javas security paradigm −− essentially, those features that make up the Java sandbox. Were now going to shift gears somewhat and begin our examination of the cryptographic
features in the Java security package itself. The Java security package is a set of classes that were added to Java 1.1 and expanded in Java 2, version 1.2; these classes provide additional layers of security beyond the
layers weve examined so far. Although these classes do play a role in the Java sandbox −− they are the basis on which Java classes may be signed, and expanding the sandbox based on signed classes is a key goal of Java
security −− they may play other roles in secure applications.
A digital signature, for example, can authenticate a Java class so that the security policy can allow that class greater latitude in the operations it can perform, but a digital signature is a useful thing in its own right. An
HR department may want to use a digital signature to verify requests to change payroll data, an online subscription service might require a digital signature to process a change order, and so on. Thus, while well
examine the classes of the Java security package from the perspective of what well be able to do with a signed class, the techniques well show will have broader applicability.
In order to use the classes of the security package, you dont need a deep understanding of cryptographic theory. This chapter will explain the basic concepts of the operations involved, which should be sufficient to
understand how to use the APIs involved. On the other hand, one feature of the security package is that different implementations of different algorithms may be provided by third−party vendors. Well explain how
to go about providing such implementations, but it is assumed that readers who are interested in writing such an implementation already understand the mechanics of cryptography. Hence, we wont give any
cryptographically valid examples in those sections. If youre interested in this type of information, a good reference is Jonathan Knudsens Java Cryptography OReilly Associates.
If you already have an understanding of the basics of digital signatures, encryption, and the need for authentication, you can skip this chapter, which provides mainly background information.
7.1 The Need for Authentication
We are primarily concerned with one goal of the security package: the ability to authenticate classes that have been loaded from the network. The components of the Java API that provide authentication may have other
uses in other contexts including within your own Java applications, but their primary goal is to allow a Java application and the Java Plug−in to load a class from the network and be assured of two things:
The identity of the site from which the class was loaded can be verified author authentication. •
The class was not modified in transit over the network data authentication. •
As weve seen, Java applications typically assume that all classes loaded over the network are untrusted classes, and these untrusted classes are generally given permissions consistent with that assumption. Classes
that meet the above two criteria, however, need not necessarily be so constrained. If you walk into your local software store and buy a shrink−wrapped piece of software, youre generally confident that the software will
not contain viruses or anything else thats harmful. This is part of the implied contract between a commercial software producer and a commercial software buyer. If you download code from that same software
producers web site, youre probably just as confident that the code youre downloading is not harmful; perhaps it should be given the same access rights as the software you obtained from that company through a
more traditional channel.
Theres a small irony here because many computer viruses are spread through commercial software. Thats one reason why the fact that a class has been authenticated does not necessarily mean it should be able to
