Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Java security evolution and concepts, Part 5

J2SE 1.4 offers numerous improvements to Java security

By Raghavan N. Srinivas, JavaWorld.com, 12/21/01

  • Print
  • Feedback
.

Page 3 of 6

Figure 2. Signed applet with a certificate signed by an untrusted CA. (Source: Sun Microsystems Inc.)



To summarize the differences between security in the J2SE 1.3 and 1.4 Java Plug-ins: In 1.4, if the signature validates successfully, the dialog box pops up with a message indicating that the certificate is valid, as shown in Figure 3.

Figure 3. Signed applet with a valid certificate



Under the J2SE 1.4 Java Plug-in, if the signature does not validate, the dialog box still pops up under the cases we've seen above. The dialog box clearly warns against potential security holes but leaves the final decision of initializing the applet to the user. With the J2SE 1.3 Java Plug-in, the applet fails to initialize unless the user does something explicitly, such as setting the policies or adjusting the system clock.

Clearly, the J2SE 1.4 Java Plug-in offers the user greater flexibility. Moreover, in an intranet environment, you may no longer be required to sign applets with an external CA; a company-wide CA would suffice. The downside of this flexibility is that some responsibility for validating the signature now shifts to the user. That shift is probably all right, since technology can only so go far to validate a signature. The aspect of trusting a user based on the signature is an interpersonal issue and is left to the user anyway. Technology cannot address this important issue (and I hope it never will).

Now that we have covered some familiar ground, let's move on to J2SE 1.4's new packages. In the examples we looked at above, the Java Plug-in had to validate a certificate or a certificate chain. If, however, we had to build or validate a certificate chain in a program, we would use the Java CertPath API.

Java CertPath API

The Java CertPath API comprises classes and interfaces to manipulate an ordered list of certificates, referred to as certification paths (or certificate chains). Based on the validation results, you can associate a public key with a subject.

As we've seen, certificates serve as digital identities. As such, a certificate associates a public key with an identity. A CA vouches the digital identity by signing the certificate with the CA's private key. To verify a certificate's identity, the relying party should have a trusted copy of the CA's public key. In the absence of such a trusted copy, a certificates chain, the certification path, is needed, with each certificate vouching for the previous one until a certificate the relying party implicitly trusts is found.

The example illustrated in Figure 4 includes a CA hierarchy. Let's look at a case when bob tries to validate the public key of the subject, alice. Since bob does not trust alice's public key directly, a certificates chain is needed to validate alice's key until a public key that bob trusts can be found. This chain is based on alice's key signed by a CA, CA3, which is then signed by CA1. Finally, a CA, referred to as the Root CA or the most-trusted CA, is found. The relying party, in this case bob, trusts this Root CA perched topmost in the certificate chain hierarchy.

  • Print
  • Feedback

Resources
  • Java security resources from java.sun.com:
  • Security-related Java Specification Requests at the Java Community Process:
  • Other important Java security resources:
  • JavaWorld's Java security resources:
  • "Construct Secure Networked Applications with Certificates," Todd Sundsted (JavaWorld):
  • You'll find a wealth of IT-related articles from our sister publications at IDG.net