Java security evolution and concepts, Part 5

J2SE 1.4 offers numerous improvements to Java security

Early on, Java security focused on resisting executable content threats -- security risks caused by malicious or poorly designed code. From that beginning, Java security measures evolved to provide security based on where code came from and who signed it. More recently, Java security has improved further to provide user and pluggable authentication, as well as SSL (Secure Socket Layer) and other key management and cryptography support.

Java security evolution and concepts: Read the whole series!

This article, the last of five in the Java security series, follows the examples introduced in Part 3 and briefly revisits the optional packages covered in Part 4. By revisiting the examples from earlier articles, we can reinforce concepts and understand what has changed in the interim.

After an overview of those security features that have changed between J2SE (Java 2 Platform, Standard Edition) 1.3 and the upcoming J2SE 1.4, this article digs deeper into the new packages included in 1.4. The first of the newer packages is the Java Certification Path (CertPath) API, which supports certificate chain manipulation. Second is the Java GSS-API (JGSS), which contains the Java bindings for the Generic Security Services Application Program Interface (GSS-API) for standardized access to a variety of security services and a framework for a single sign-on.

Overview of changes

First, let's quickly look at the changes between J2SE 1.3 and 1.4.

Optional packages move into the 1.4 core

As the most obvious change between J2SE 1.3 security and 1.4, the optional packages (examined in Part 4) will move into 1.4's core security structure:

  • Java Authentication and Authorization Service (JAAS): A framework for performing user-based authentication
  • Java Cryptography Extension (JCE): A framework for using strong ciphers on a global basis
  • Java Secure Socket Extension (JSSE): Support for SSL and TLS (Transport Layer Security)

Each of the aforementioned packages will be available on every J2SE 1.4 installation, obviating the need to install them explicitly.

New 1.4 packages

Besides moving the optional packages into the J2SE core, J2SE 1.4 will also feature two new security packages:

  • Java CertPath API: Classes, methods, and interfaces to build and validate certificate chains
  • JGSS API: Java bindings for the Generic Security Services API

The bulk of this article will be devoted to looking into these two packages.

Other changes

As a result of JAAS becoming an integral part of core security, access control is no longer solely based on code source (i.e., where the code is from and who signed it), but also on who is running the code. As a result, both the Policy files and the graphical Policy tool have been enhanced to accommodate the changes.

Next, strong cipher support is available via JCE and JSSE, albeit with some important control restrictions. In JCE, the cryptographic strengths are limited through the jurisdiction files by default. JSSE, for its part, now restricts the replacement of the default SSLSocketFactory and SSLServerSocketFactory classes.

Moreover, you'll find support for dynamic policies. Prior to J2SE 1.4, the security policy was associated at the time of class loading. In 1.4, the security policy association is deferred until the security check becomes necessary.

In addition, J2SE 1.4 includes some changes to the functionality of the security classes. As an example, the javax.security.cert class is available only for backward compatibility, with its functionality carried forward by the java.security.cert class. Newer applications should use this class.

Finally, applet security as enforced by 1.4 is different, which we'll look into in the next section.

Java Plug-in enhancements

You'll see some changes in security between the J2SE 1.3 Java Plug-in and the 1.4 Java Plug-in (for more, see Sidebar 1: Java Plug-in Primer). Since we are interested in security, I explore the changes by revisiting the signed applets developed in Part 3.

Security in the J2SE 1.3 Java Plug-in

To illustrate how the J2SE 1.3 Plug-in handles applet security, let's first look at the writeFile applet from Part 3 of this series. Execute the writeFile signed applet under the J2SE 1.3 Java Plug-in. Make sure that the policy files do not allow the temp file (/tmp/foo on Unix systems and c:\tmpfoo on Windows) to be modified. If the clock on your system is set correctly, the signed applet's signature should not validate because it has expired; therefore, the applet will not initialize. If you set your system's clock back to a date between December 13, 2000 and December 21, 2001 (that is, to a time when the certificate is valid), the signature validates, and you should see a dialog box asking whether the applet should run or not.

As another example, run the signed applet discussed in "JDK 1.2 -- Signed Applet Example" under the J2SE 1.3 Java Plug-in. The applet has been signed by a key -- Duke -- whose public key has been self-certified. That means the Certification Authority (CA) used to sign the certificate is not trusted by default in the environment. As a result, the signature validation fails again, and the dialog box again fails to pop up.

Security in the J2SE 1.4 Java Plug-in

Now, let's run the same applet examples under the J2SE 1.4 Java Plug-in.

When executing the example from Part 3, the signed applet with the expired certificate, the user sees a dialog box clearly indicating that the certificate is expired, as shown in Figure 1. Here, the ultimate decision to execute the applet is left to the user's discretion.

Figure 1. Signed applet with an expired certificate

Likewise, in the second example of the signed applet with the untrusted certificate, the user sees a dialog box, this time indicating that the CA cannot be trusted. The applet can still be executed if the user so chooses, as seen in Figure 2.

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.

Likewise, if alice were to validate bob's key, the certificate path bob-CA4-CA2-Root CA would be required, assuming alice trusts the Root CA's public key.

Figure 4. Hierarchy of CAs

To make such certificate-chain validation possible in programs, signatures must be verified, certification revocation and validity must be checked, and so on. Further, a certificate chain from the most-trusted CA to the subject may have to be found by other means, such as with access to LDAP (Lightweight Directory Access Protocol).

Building and validating certification paths is routinely carried out in security protocols such as SSL/TLS, S/MIME, IPSec, and so on. We saw how the Java Plug-in validated a certificate (or a chain). The Java CertPath API proves useful in all such cases.

I briefly examined X.509 in earlier articles of this series. The X.509 certificate standard in part provides confidence for doing business online. The Public-Key Infrastructure X.509 (PKIX) working group develops Internet standards needed to support X.509 PKI.

The Java CertPath API is based on the provider architecture introduced in the Java Connector Architecture (JCA). The provider architecture allows user programs to use the same API, but different providers can be plugged in via a Service Provider Interface (SPI). The Sun provider supports the PKIX standard.

Java CertPath API classes and interfaces

Now that we've seen Java CertPath's function, let's examine its classes for building and validating certification paths. Each class below exists in the java.security.cert package:

  • Core classes:
    • The abstract CertPath captures the functionality shared by all certification path objects. For example, its getCertificates() abstract method returns the certificates list in the path.
    • In J2SE 1.4 the CertificateFactory now supports certification path objects.
    • The interface CertPathParameters specifies parameters to the Certification Path algorithms. For example, the class PKIXParameters that implements the interface can set PKIX parameters such as time of validity, policy constraints, target certificate constraints, and user-defined checks, among others.
  • Validation classes:
    • CertPathValidator validates a certification path.
    • The CertPathValidatorResult interface captures the results from the CertPathValidator certification path validation.
  • Building classes:
    • The CertPathBuilder class, like CertPathValidator, builds certification paths.
    • CertPathBuilderResult captures the results of CertPathBuilder's path building.
  • Storage classes:
    • CertStore provides the functionality of a certificate and certificate revocation list (CRL) repository, such as LDAP. The methods getCertifcates() and getCRLs() retrieve certificates and CRLs, respectively.
    • CertStoreParameters specifies all CertStore parameters. In conjunction with the CertStore.getInstance()method, the CertStoreParameters class obtains a CertStore with the appropriate properties.
    • The CertSelector interface serves as an argument to the respective methods, allowing them to specify a set of criteria for the respective selection.
    • The CRLSelector interface also serves as an argument to the respective methods.

Having briefly looked at the classes and some methods, in the next section we see how to use them.

Java Certification Path programming model

Next, we see an example of validating a Certification Path of X.509 certificates. The following steps illustrate how to accomplish that task:

1 2 3 4 Page 1
Page 1 of 4