ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Java Application Security
Pages: 1, 2, 3, 4, 5

The Java 2 Platform

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.

Installed or Bundled Extensions?

When you work with the extensions that we use in this book, you have the option of treating them as installed or bundled extensions.

Installed extensions are much easier to work with: they require no special configuration once they are installed. However, they must be installed into special directories within $JREHOME, and they may require files in $JREHOME to be modified. Depending on your setup, this may require special operating system privileges.

A bundled extension requires no special installation privileges, but it does require you to set up things within your environment: you must modify your classpath, and you must set up special policy files. In addition, some of this configuration must be done programatically, so this option will not work for third-party applications. We assume in our examples that you've set up the extensions as installed extensions.

The Java Cryptography Extension

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:

  • Copy the four jar files to $JREHOME/lib/ext
  • Add the following line to $JREHOME/lib/security/java.security:
    security.provider.3=com.sun.crypto.provider.SunJCE
    This line should immediately follow the line that reads:
    security.provider.2=com.sun.rsajca.Provider

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, Security Providers, discusses the addition to the java.security file and its programmatic alternative, and the .java.policy file is discussed in Chapter 2, The Default Sandbox.

The Java Secure Sockets Extension

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:

  • Copy the three jar files to $JREHOME/lib/ext.
  • Add the following line to $JREHOME/lib/security/java.security:
    security.provider.4=com.sun.net.ssl.internal.ssl.Provider
    This line should immediately follow the line you inserted for JCE.

To use JSSE as an unbundled extension, you must:

  • Add the three jar files to your classpath.
  • In every program that you run, you must insert the following line:
    Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider( ));

The Java Authentication and Authorization Service

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.

More About Export Controls

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, Security Resources, 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.

Other Software Versions

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.

Pages: 1, 2, 3, 4, 5

Next Pagearrow