solution. If the applet needs to open a connection back to www.xyz.com, it must use SSL for this communication as well. And we still have other, non−web−related traffic that is not authenticated.
It would be better still to solve this problem at the network level itself. There are many products from various vendors that allow you to authenticate and encrypt all data between your site and a remote site on the
network. Using such a product is really the ideal from a design point of view; in that way, all data is protected, no matter what the source of the traffic. Either of these solutions makes authentication and fingerprinting of
Java classes redundant and may offer the benefit that the data is actually encrypted when it passes through the network.
Unfortunately, these solutions lead us back to practical considerations: if its hard for Java environments to share digital keys and to manage cryptographic technology, its harder still to depend on the network software
to manage this process. So while it might be ideal for this problem to be solved for the network as a whole, its impractical to expect such a solution. Hence, the Java security package offers a reasonable compromise: it
allows you to deploy and use trusted i.e., authenticated classes, but their use is not mandated in case you prefer to employ a broader solution to this problem.
7.2 The Role of Authentication
In the preceding discussion, we assumed that you want to load classes from www.xyz.com and that you want those classes to be trusted so that they might have some special permission when they execute on your
machine. For example, the spellchecking class might need to open up a local dictionary file to learn how to spellcheck names and other data you customized for the spell checker.
Do not, however, make the assumption that all classes that are authenticated are therefore to be trusted, or even that all trusted classes should necessarily have the same set of permissions. Theres nothing that prevents
me from obtaining the necessary information and tools so that I can sign and encrypt all of my classes. When you download those classes, you know with certainty that the classes came from me −− they carry my digital
signature and theyve been fingerprinted to ensure that they havent been tampered with.
But thats all the information that you know about these classes. In particular, just because the classes were authenticated does not mean that I didnt put a virus into them thats going to erase all the files on your hard
disk. And just because you know that a particular Java applet came from me does not mean that you can necessarily track me down when something goes wrong. If you surf to my home page and run my
authenticated applet, then surf to www.sun.com and run their authenticated applet, then surf to www.EvilSite.org and run their authenticated applet, and then two weeks later your hard disk is erased, how
will you know which site planted the delayed virus onto your machine? How will you even remember which sites you had visited in the last two weeks or longer? If you have an adequate set of backups and other logs,
it is conceivable that you might be able to recreate what happened and know at whom to point your finger and whom to sue, but such a task would be arduous indeed. And if the virus affected your logs, the finger of
suspicion might point to the incorrect site.
Hence, the role of authentication of Java classes is not to validate that those classes are trusted or to automatically give those classes special permissions. The role of authentication is to give the user or, for a
corporate network, the system or network administrator more information on which to base a security policy. A reasonable policy might be that classes that are known to come from www.SpellChecker.com can read the
users personal dictionary file −− but that doesnt mean they should necessarily be able to read anything else. A reasonable policy would also grant this type of exception to the general rule about permissions given to
network classes only in very specific cases to a few well−known sites, and consider unknown but authenticated sites as still untrusted.
The moral of the story is that authentication does not magically solve any problem; it is merely a tool that can be used in the pursuit of solutions.
7.3 Cryptographic Engines
In the next few chapters of this book, were going to see how Java provides an interface to the algorithms required to perform the sort of authentications weve just talked about. Well also explore the architecture Java
provides for general implementation of these algorithms, including ones such as encryption that are not strictly required for authentication. If youre not familiar with the various cryptographic algorithms weve been
alluding to so far in this chapter, the next section should sort that all out for you.
Essentially, all cryptographic operations are structured like the diagram in Figure 7−2. Central to this idea is the cryptographic algorithm itself, which is called an engine; the term algorithm is reserved to refer to
particular implementations of the cryptographic operation. The engine takes some set of input data and optionally some sort of key and produces a set of output data. A few points are relevant to this diagram.
There are engines that do not require a key as part of their input. In addition, not all cryptographic engines produce symmetric output −− that is, its not always the case that the original text can be reconstructed from
the output data. Also, the size of the output is typically not the same as the size of the input. In the case of message digests and digital signatures, the output size is a small, fixed−size number of bytes; in the case of
encryption engines, the output size is typically somewhat larger than the input size.
Figure 7−2. A cryptographic engine for encryption
In the Java security package, there are two standard cryptographic engines: a message digest engine and a digital signature engine. In addition, for some users, an optional engine is available to perform encryption.
Finally, because keys are central to the use of most of these engines, there is a wide set of classes that operate on keys, including engines that can be used to generate certain types of keys. The term engine is also used
within the security package to refer to other classes that support these operations.
7.3.1 Cryptographic Keys
The first engines well look at generate cryptographic keys. Keys are the basis for many cryptographic operations. In its simplest sense, a key is a long string of numbers −− not just any string of numbers, but a
string of numbers that has very strict mathematical properties. The mathematical properties a key must have vary based on the cryptographic algorithms it is going to be used for, but theres an abstract logical set of
properties all keys must have. Its this abstract set of properties that well see in the Java security package.
In the realm of cryptography, keys can either come alone in which case they are called secret keys or in pairs. A key pair has two keys, a public key and a private key. So all together there are three types of keys −−
secret, public, and private.
When an algorithm requires a secret key, both parties using the algorithm will use the same key. Both parties must agree to keep the key secret, lest the security of the cryptography between the parties be compromised.
