Java security evolution
and concepts, Part 5
Tutorial Details:
Java security evolution and concepts, Part 5
Java security evolution and concepts, Part 5
By: By Raghavan N. Srinivas
J2SE 1.4 offers numerous improvements to Java security
arly 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!
Part 1: Learn computer security concepts and terms in this introductory overview
Part 2: Discover the ins and outs of Java security
Part 3: Tackle Java applet security with confidence
Part 4: Learn how optional packages extend and enhance Java security
Part 5: J2SE 1.4 offers numerous improvements to Java security
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
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Java security evolution
and concepts, Part 5
View Tutorial: Java security evolution
and concepts, Part 5
Related
Tutorials:
 How to write
a Java Card applet: A developer's
guide
How to write
a Java Card applet: A developer's
guide
|
Understanding Java Card 2.0 - JavaWorld March 1998
Understanding Java Card 2.0 - JavaWorld March 1998
|
The state of Java application middleware,
Part 1 - JavaWorld March 1999
The state of Java application middleware,
Part 1 - JavaWorld March 1999
|
Java security evolution
and concepts, Part 1: Security nuts and bolts - JavaWorld April
2000
Java security evolution
and concepts, Part 1: Security nuts and bolts - JavaWorld April
2000
|
Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
|
Breathe intelligence into Java - JavaWorld April 2001
Breathe intelligence into Java - JavaWorld April 2001
|
Java security evolution
and concepts, Part 2
Java security evolution
and concepts, Part 2
|
Java security evolution
and concepts, Part 4
Java security evolution
and concepts, Part 4
|
Java security evolution
and concepts, Part 5
Java security evolution
and concepts, Part 5
|
I want my AOP!, Part 1
I want my AOP!, Part 1
|
All that JAAS
All that JAAS
|
Good, but
obsolete
Good, but
obsolete
|
Maybe the future UI design of choice
Maybe the future UI design of choice
|
Java and Security, Part 1
Java and Security
WebLogic provides a comprehensive suite of security services that can be used to protect all aspects of a domain and its deployments. These security services affect all aspects of your domain: from the lowest level provided by the Jav
|
Java and Security, Part 2
Java and Security
The Providers
Now we\'ll take a closer look at the different SSPIs that constitute a security realm. We\'ll learn about WebLogic\'s default implementation of these security providers and how to configure them. The default implementat
|
Taming Tiger, Part 3
J2SE 5—code named "Tiger"—is the most significant revision to the Java language since its original inception. Tarak Modi's primary goal with his three-part series on Tiger is to familiarize readers with J2SE 5's most important additions and show how t
|
The ABCs of Synchronization, Part 1
Threads may execute in a manner where their paths of execution are completely independent of each other. Neither thread depends upon the other for assistance. For example, one thread might execute a print job, while a second thread repaints a window. And
|
Using SSL with Non-Blocking IO
Using SSL with Non-Blocking IO
After the initial experiments with Java NIO, most developers start wondering about security; in particular, how to use SSL with Java NIO. With the traditional blocking sockets API, security is a simple issue: just set up an
|
Java Beans, Part 1 Introducing Java Beans
The basic idea of the Beans tutorial is to get you to the point where you can quickly create beans. You may want to write new beans from scratch, or you may want to take existing components, applets, or other classes and turn them into beans.
|
Buy Fedora Core 3 Linux CD's in India.
Buy Fedora Core 3 Linux CD's in India.
Fedora Core 3 Linux
Now Available Fedora Core 3 CD's
We are providing the free downloadable version of Fedora Core 3 Linux CDs, which is distributed under GNU public license.
ABOUT FEDORA Fedora is the
|
|
|
|
