The information in this book is based on the Java 2 Standard Edition, version 1.3 (or 1.3, for short). There are slight differences between how Java security operates in 1.2 (that is, the Java 2 Standard Edition, version 1.2) and 1.3. When we refer to a specific release, we’ll use its number; otherwise, we’ll say Java 2 to refer to either platform.
In addition, there are great differences in how Java security operates between the Java 1.1 and the Java 2 platform. While we concentrate on Java 1.3, the end of each chapter contains a section that elucidates the differences between Java 1.3 and previous releases of Java. Some of the very different topics of Java 1.1 are presented in the appendices of this book; it is not generally recommended that you use the facilities and APIs discussed there since they are not compatible with the Java 2 platform.
We present information in this book from three standard Java extensions: the Java Cryptography Extension (JCE) version 1.2.1, the Java Secure Sockets Extension (JSSE) version 1.0.2, and the Java Authentication and Authorization Service (JAAS) version 1.0. Each of these contributes certain technologies to the Java security story. These extensions require 1.3.
Information about the extensions is presented thoughout the book as it makes sense. The JSSE API defines a set of classes that are used to perform SSL operations, and these are discussed in a separate chapter. The JSSE API also defines a set of classes that are used for key management; these are discussed along with the classes in the core API that handle key management. So even though these three packages are standard extensions, we recommend that you install them now along with the SDK so that you can become familiar with their features when they arise. In version 1.4, all these extensions are scheduled to be included in the core SDK, which is another reason why it helps to think of them as an integrated unit.
In the next few pages, we’ll discuss how to obtain and install the platform and extensions. Configuring the extensions may require some steps that you don’t understand right now because they have various security options that apply to them. However, we recommend that you just follow the instructions for now and install the extensions. The extensions use Java’s standard security framework, and as we discuss each aspect of the framework, we detail how the extensions relate to that aspect. Thus, while the core features of each extension is discussed in its own chapter, information about the extensions appears throughout the book.
The core Java 2 platform supplies the basic facilities of Java security:
A configurable security policy that lets you prevent Java programs from reading your files, making network connections to other hosts, accessing your printer without permission, and so on. This policy is based on Java’s access controller, which in turn depends upon Java’s class loaders, security manager, and language protections.
The ability to generate message digests if you want a simple (but not secure) way to determine if data your program reads has been altered.
The ability to generate digital signatures if you want to detect if data your program reads has been altered (or if you want to send data and enable the recipient of that data to detect if the data was altered in transit).
A key management system to manage the keys necessary for digital signatures.
An extensible infrastructure to support all of this.
Java 2 version 1.3 can be obtained for Solaris, Linux, and Windows systems from http://java.sun.com/j2se/1.3/. If you need Java for other platforms, check with your platform vendor or check http://java.sun.com/cgi-bin/java-ports.cgi.
The Java 2 platform contains two flavors: the Software Development Kit (SDK, also known historically as the JDK) and the Java Runtime Environment (JRE). Administration of the security model applies to both the JRE and SDK, but to use the security APIs that we discuss, you’ll need the SDK (which includes the JRE). Throughout this book, we’ll use the environment variable $JDKHOME to refer to the directory in which the Java 2 SDK was installed and the $JREHOME variable to refer to the directory in which the Java 2 JRE was installed. If you installed the SDK into C:\files\jdk1.3 then $JDKHOME would be C:\files\jdk1.3 and $JREHOME would be C:\files\jdk1.3\jre.
JCE leverages the Java 2 core platform’s security architecture to provide a variety of cryptographic operations:
Encryption (Ciphers)
Secure Key Exchange
Secure Message Digests
An alternate key management system
JCE can be downloaded from http://java.sun.com/products/jce/. Version 1.2.1 is an important version because it takes advantage of a change in the policy of the United States regarding export controls of cryptographic engines. Prior to early 2000, the United States government considered cryptographic engines to be a munition and severely restricted the export of such technology. After this policy was changed in early 2000, JCE 1.2.1 was modified to meet the new standards. As a result, although it performs strong encryption, JCE 1.2.1 can be exported from the United States.
JCE consists of some documentation and a lib directory that contains four jar files: US_export_policy.jar, jce1_2_1.jar, local_policy.jar, and sunjce_provider.jar. Like most extensions, you can install JCE as a bundled or unbundled extension.
To use JCE as an installed extension, you must:
To use JCE as an unbundled extension, you must:
Add the four jar files to your classpath.
Add some configuration information to $HOME/.java.policy. The information to be added depends on where you have placed the jar files; if you’ve put JCE into /files/jce1.2.1 then the appropriate lines are:
grant codebase "file:///files/jce1.2.1/lib/US_export_policy.jar" { permission java.security.AllPermission; }; grant codebase "file:///files/jce1.2.1/lib/jce1_2_1.jar" { permission java.security.AllPermission; }; grant codebase "file:///files/jce1.2.1/lib/local_policy.jar" { permission java.security.AllPermission; }; grant codebase "file:///files/jce1.2.1/lib/sunjce_provider.jar" { permission java.security.AllPermission; };You must substitute the appropriate path for /files/jce1.2.1. Note that this is a URL; you use forward slashes no matter what your platform. On Microsoft Windows, the beginning of the appropriate URL is file:/C:/files/jce1.2.1.
In every program that you run, you must insert the following line:
Security.addProvider(new com.sun.crypto.provider.SunJCE( ));
More details about how this works can be found in later chapters. Chapter 8, discusses the addition to the java.security file and its programmatic alternative, and the .java.policy file is discussed in Chapter 2.
JSSE provides Secure Sockets Layer (SSL) encryption facilities. If you need to communicate with an SSL server or SSL client, you can use the APIs in this extension. If you are writing both a client and server and want to do encryption, you can use this extension or you can use the cipher facilities of JCE.
JSSE can be downloaded from http://java.sun.com/products/jsse/. Version 1.0.2 takes advantage of the relaxed export restrictions of the U.S. and is exportable. Unlike JCE, however, there are still two different versions of JSSE: one for domestic use (use within the United States and Canada) and one for global use. The difference between these two versions is that the domestic version allows you to substitute new implementations of the SSL algorithms. Such substitution is still prohibited by export rules, so the global version does not allow it. However, both versions provide exactly the same API and the same key strength for their encryption.
JSSE consists of documentation and a lib directory containing three jar files: jcert.jar, jnet.jar, and jsse.jar. To use JSSE as an installed extension, you must:
JAAS provides for user authentication within the Java platform. It performs a unique function in the Java platform. All of the core facilities of Java’s security design are intended to protect end users from the influences of developers: end users give permissions to developers to access resources on the end user’s machine. JAAS, on the other hand, allows developers to grant (or deny) access to their programs based on the authentication credentials provided by the user.
JAAS can be downloaded from http://java.sun.com/products/jaas/. It comes in two parts: a Java library which defines the interface to the service (the JAAS proper), and platform-specific modules to perform the authorization (the JAAS modules). Sample modules are available to perform authentication based on JNDI directory services, Windows NT login services, and Solaris login services.
JAAS itself contains documentation and a lib directory with a single jar file (jaas.jar). The jar file should either be installed into $JREHOME/lib/ext, or the user must add it to her classpath.
The lib directory of the JAAS modules contains an additional jar file (jaasmod.jar) that must be handled similarly. It also contains platform-specific shared libraries. On Solaris systems, these libraries must be installed into $JREHOME/lib/sparc . If that is not possible, the libraries can be placed into any directory (e.g., /files/jaasmod1_0/lib) and that directory can be added to the user’s LD_LIBRARY_PATH.
On Microsoft Windows systems, these libraries are named
nt.dll, nt.lib, and nt.exp
and they must be installed into $JREHOME\bin. If
that is not possible, then you must set the
java.library.path property on the command line.
For instance, if the libraries are in
\files\jaasmod1_0\lib, you would specify the
following property on the command line:
-Djava.library.path=\files\jaasmod1_0\lib
No modification to the java.security file is required for JAAS.
The U.S. is not the only government that regulates the use of encryption, and encryption software can face import restrictions as well as export restrictions. In France, for example, it is illegal to import many encryption packages without a license. Other countries have regulations for cryptography, but in most cases they are less onerous than those of the United States. However, it is always wise to check your local policies to be sure (see Appendix B, for resources to find more information about these limitations).
Even though the U.S. has relaxed its export rules, some restrictions still apply. You may not export either JCE or JSSE (and, hence, any programs that use them) to the following countries: Afghanistan, Cuba, Iran, Iraq, Libya, North Korea, Serbia/Montenegro (Yugoslavia), Sudan, Syria and parties listed on the Denied and Restricted Parties List (available at http://bxa.fedworld.gov/prohib.html). Additionally, it is Sun company policy not to ship products to Burma.
The encryption extensions, like many aspects of the Java platform, allow for third-party implementations; just like you can buy a third-party JDBC driver, you can buy third-party implementations of JCE. However, many of the popular algorithms that are used by the extensions are patented algorithms, which also restricts their use. RSA Data Security, Inc. holds a patent in the U.S. on several algorithms involving RSA encryption and digital signatures; Ascom System AG in Switzerland holds both U.S. and European patents on the IDEA method of performing encryption. If you live in a country where these patents apply, you can’t use these underlying algorithms without paying a licensing fee to the patent holder. In particular, this means that many of the third-party security providers and third-party implementations of JCE cannot be used within the United States because of patents held by RSA (although some of them have reached a licensing agreement with RSA Data Security, Inc. -- again, it is best to check with the provider to see what restrictions might apply). Sun has an agreement with RSA Data Security to redistribute its implementation of the RSA algorithms.
Note that import and export restrictions apply only to the encryption technology contained within JCE and JSSE. Although the core Java APIs perform important cryptographic operations, those operations are not considered to be munition-grade operations.
Though Java-enabled browsers are very popular, we do not discuss most of the popular ones. This is because their security implementations are very different from the official Java security model. Both Netscape and Microsoft, for example, introduced new (and proprietary) APIs to allow for security extensions. Both companies also developed their own (again proprietary) mechanism to sign applets.
The better way to run Java applets from within a browser is to use the Java Plug-in, which comes standard with every release of the Java 2 platform; when you install Java 2, you install the Java Plug-in. In Netscape 6 and later releases, the Java Plug-in is the only way to run Java applets; there is no Java virtual machine built into Netscape 6. The Plug-in is also compatible with Internet Explorer 4.x and higher, as well as Netscape 4.x versions.
The security model of the Java Plug-in is exactly the same as that of the Java platform that we describe within this book. Where the security model of older browsers is different, we point that out, and we provide directions to the vendor’s web sites that give information on their non-standard systems.
Get Java Security, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
