Note: This article first appeared in June 1997 in an issue of JavaUniverse Developer (now defunct). Even though many of its details are dated, the article may still provide a useful overview of the applet signing process. For more current information, please see the following:

Signing Applets for Internet Explorer and Netscape Navigator
by Joseph Bowbeer

Introduction
Breaking Out of the Applet Sandbox
Running from the CLASSPATH
Signed Applets to the Rescue
Certificate Authorities
New Applet Tag
Signing Applets for Internet Explorer
Signing Applets for Netscape Navigator
HotJava, Cold Shoulder?
Netscape's Capabilties API
Signed Applet Example
A Note on Compiling
Conclusion
About the Author

Introduction

Signed applets can bring the power of full-fledged applications to your browser. This article describes how to create signed applets for the latest versions of the two most popular browsers: Microsoft Internet Explorer 3 and Netscape Navigator 4. 

Breaking Out of the Applet Sandbox

Before signed applets were an option, all applets were forced to run in a restrictive sandbox that prevented them from maliciously - or accidentally - causing damage. Simply put, the sandbox prevents an applet from accessing the local hard drive, and it prevents an applet from connecting to any web site except the site from which the applet was loaded. There are a few other restrictions, too, but these are the most important ones. 

See http://java.sun.com/docs/books/tutorial/applet/security for a more complete description of applet capabilities and restrictions. 

Unfortunately, the applet sandbox can be overly restrictive. It can prevent applets from performing many useful functions. For example, it would be impossible for many common applications - such as terminal emulators, text editors, compilers, and network monitors - to run as applets unless they could somehow escape the applet sandbox. 
 
 

Running from the CLASSPATH

One way to escape the sandbox is to put the applet's classes in the CLASSPATH. This is sometimes called running from the class path. For example, before running WriteFileApplet on a PC, you might set the CLASSPATH as follows: 

set CLASSPATH=C:\Java\Projects\WriteFileApplet;%CLASSPATH%

This approach has the drawback that it requires installation (remember AUTOEXEC.BAT?). It may also create conflicts with other applets that are running from the CLASSPATH. More subtly, it may conflict with other applets on the web that happen to require different versions of some of the classes that were installed in the CLASSPATH. I call these shadowing and versioning problems, to give them a name. These problems arise because classes at the beginning of the CLASSPATH take precedence over classes at the end of the CLASSPATH, and classes located in the CLASSPATH take precedence over classes found on the web. 

Another problem with using the CLASSPATH is that it exposes you to attacks from malicious applets. A malicious applet may be able to use the classes you installed in your CLASSPATH to break out of its sandbox and spread its evil throughout the world - or trash your hard drive. 
 
 

Signed Applets to the Rescue

A better way to escape the sandbox is to sign the applet. Your signature is your guarantee to others that the applet is friendly. This adds accountability without the installation hassle - and without creating conflicts with other applets or exposing your applet to attacks from outsiders. By accountability, I mean: if someone else runs the applet you signed and that applet damages their system, the applet's signature can be traced back to you. The signature doesn't prevent damage, but it serves as a stamp of good intention, and it identifies the responsible party if damage does occur. 
 
 

Certificate Authorities

I should point out that not all signatures can be traced back to the individual or corporation that produced them. For example, a signature may bear the name "Bart Simpson", but there may be nothing in the signature that ties this name to a real person. 

One way to guarantee that a signature was produced by who it says it was is to require that the signature be notarized by a Certificate Authority (CA, for short). The Certificate Authority authenticates the identity of the applicant and then issues them a signing certificate. The signing certificate is what is used to sign the applet. Anything signed with the signing certificate will bear the name of the CA in addition to the name of the signer. The signature can be traced, by way of the CA, to the signer. 
 

Note: VeriSign, Inc. is the leading Certificate Authority. Signing certificates for individuals and corporations can be obtained for both Microsoft Internet Explorer and Netscape Navigator at http://digitalid.verisign.com/software_publishers.html. A signing certificate for an individual costs $20 per year. Unfortunately, Microsoft and Netscape each have their own certificate format, so you're looking at $40 per year if you want your applet to work with both browsers. I expect the prices will drop as signed applets become more pervasive.
 
 

New Applet Tag

The applet tag has been extended to support signed applets. Here's a bit of HTML that will run a signed applet in Internet Explorer and Netscape Navigator: 

<applet code="WriteFile.class" ARCHIVE="signedWriteFile.jar" width=500 height=50> 
<param name="CABBASE" value="signedWriteFile.cab"> 
</applet>

The ARCHIVE parameter (signedWriteFile.jar) is parsed by Netscape Navigator and the CABBASE parameter (signedWriteFile.cab) is parsed by Internet Explorer. The following sections provide more information about the support for signed applets in each of these browsers. 
 
 

Signing Applets for Internet Explorer

Microsoft Internet Explorer 3 supports signed applets in .cab (cabinet) files. The .cab file is created first, and is then signed with an Authenticode signing tool. A signing certificate issued by a Certificate Authority, such as VeriSign, is required. 
 

Note: See http://www.microsoft.com/java for the latest Java news and updates from Microsoft.

Note: Tools for creating a cabinet file are included with the Java SDK. They may also be downloaded separately at http://www.microsoft.com/workshop/prog/cab/cabdl.htm. These tools are only available for Windows.

Note: Authenticode code signing tools are included with the ActiveX SDK. They may also be downloaded separately at http://www.microsoft.com/workshop/prog/sdk/codedl.htm. These tools are only available for Windows.
 
 

Signing Applets for Netscape Navigator

Netscape Navigator 4 supports signed applets in .jar (Java Archive) files. The applet's classes are first signed with a command line tool known as zigbert. A signing certificate issued by a CA, such as VeriSign, is required. Once the classes have been signed, the .jar file is created using a standard ZIP utility such as Info-ZIP - http://www.cdrom.com/pub/infozip. Netscape is also working on a one-stop applet known as Jar Packager, but at the time this article was written, it was too buggy to be useful. 
 

Note: See http://developer.netscape.com/software/signedobj for more information about Netscape’s signed applet implementation.

Note: The zigbert tool is available at ftp://ftp1.netscape.com/private/signtool/zIgshIpme/zigship.zip.

Note: The Jar Packager is available at http://developer.netscape.com/software/signedobj/jarpkgr.zip.
 
 

HotJava, Cold Shoulder?

You might be wondering about JavaSoft's HotJava browser. When HotJava 1 was released in April, 1997 it was the first browser to support JDK 1.1, including the new .jar file format and javakey signatures. Now, three months later, HotJava is still the only browser to be fully JDK 1.1 compliant. The two most popular browsers have not implemented the JDK 1.1 security features. Netscape Navigator now supports the new .jar file format, but it chose to use a different signature encoding, and Microsoft Internet Explorer doesn't yet support the .jar file format. Why? 

I suspect the reason that JDK 1.1 security has not been adopted is because it doesn't support Certificate Authorities. CA's have long been a part of Microsoft's .cab file architecture; any new security model should be at least as powerful. In addition, Netscape didn't believe that the security features introduced in JDK 1.1 went far enough to protect the user, so they introduced their own Capabilities API (see below) to fill the gap. 

As it now stands, both Netscape Navigator and Hot Java support signed .jar files, but they use different signature encodings: a .jar file signed for Navigator will not work with HotJava, and vice versa. I chose to focus on Navigator because it has more users. 

JavaSoft plans to support Certificate Authorities in a future release of the JDK. Probably in JDK 1.2. Then, finally, I hope all browsers will be able to agree on a common archive format and signature encoding. For more information on JavaSoft's security plans, see http://java.sun.com/security. 
 
 

Netscape's Capabilities API

This section describes the new security API introduced in Netscape Navigator 4. 

In Netscape Navigator 4, signing an applet alone is not enough to enable it to escape the sandbox. The applet must also ask for - and be granted by the user - the specific capabilities it requires before it can use them. It does this by calling methods in the netscape.security package. These methods comprise Netscape's Capabilities API. More information is available from the Netscape developer library - http://developer.netscape.com/library/documentation/signedobj/capabilities. 

In a typical case, an applet running in Navigator wishes to connect to an arbitrary host (not permitted in the sandbox), so it must first obtain the capability by calling PrivilegeManager.enablePrivilege("UniversalConnect"). This applies to all applets, including signed applets and applets running in the CLASSPATH. 
 
 

Signed Applet Example

The WriteFile applet, below, is a modified version of an example written by Marianne Mueller - http://java.sun.com/security/signExample. The applet reads the "user.dir" restricted property and writes a file named "tmpfoo" to this directory. 


Figure 1

Figure 2 

Figure 1 shows what happens if WriteFile is not signed: the security manager throws an exception when the applet tries to read the "user.dir" property. Figure 2 shows successful output from a signed WriteFile applet. 

I modified the applet to add support for Netscape's Capabilities API. The "UniversalFileAccess" capability enables access to restricted properties in addition to files. The applet also uses the SecurityContext class, which I'll describe shortly.  

// To compile, add java40.jar to the class path. 
import netscape.security.PrivilegeManager;

public class WriteFile extends Applet {

    public void paint(Graphics g) {

        String slash = System.getProperty("file.separator");

        try {
            // Support added for Netscape's Capabilities API. 
            if (SecurityContext.isCapableOf("UniversalFileAccess")) {
                PrivilegeManager.enablePrivilege("UniversalFileAccess");
            }

            String userdir = System.getProperty("user.dir");
            g.drawString("Successfully read user.dir ..." + userdir, 10, 10);

            String fileName = userdir + slash + "tmpfoo";

            DataOutputStream dos;
            dos = new DataOutputStream(new FileOutputStream(fileName));
            dos.writeChars("This was written by a trusted applet.\n");
            dos.close();
            g.drawString("Successfully wrote to file " + fileName, 10, 30);
        }

        catch (Exception e) {
            g.drawString("WriteFile: caught " + e, 10, 10);
        }
    }
}

The WriteFile applet calls the isCapableOf method in SecurityContext to decide if it should try to obtain a capability from Netscape's security manager. Here's the code for the isCapableOf method:  

    private static Hashtable hash = new Hashtable();

    public static synchronized boolean isCapableOf(String s) {

        if (!isCommunicator()) return false;

        Boolean granted = (Boolean) hash.get(s);

        if (granted == null) {
            granted = Boolean.FALSE;
            try {
                // Ask for the capability. 
                PrivilegeManager.enablePrivilege(s);
                granted = Boolean.TRUE;
            }
            catch (Exception e) {
                // Capability not granted. 
            }
            hash.put(s, granted);
        }

        return granted.booleanValue();
    }

isCapableOf first determines if Netscape's security manager is present by calling the isCommunicator method (also in SecurityContext). If present, it checks the capability by calling enablePrivilege, which may pop-up a dialog window to ask the user. The result is stored in a hash table for efficiency - and to avoid deluging the user with the same question over and over again. 

It is important to realize that capabilities are implemented using stack frame annotation. This means that any capabilities obtained by a method are lost as soon as the method returns. (So much for modularization...) 

 The isCommunicator method, below, determines if Netscape's security manager is present. It does this by trying to load one of the classes in the netscape.security package.  

    private static Boolean communicator;

    public static synchronized boolean isCommunicator() {

        if (communicator == null) {
            communicator = Boolean.FALSE;
            try {
                // Try to find one of the netscape.security classes. 
                Class t = Class.forName("netscape.security.UserDialogHelper");
                communicator = Boolean.TRUE;
            }
            catch (Exception e) {
                // Can't find netscape.security package.
            }
        }

        return communicator.booleanValue();
    }

 
 

A Note on Compiling

The netscape.security package (Capabilities API) is contained in java40.jar, which is part of the Navigator 4 installation. You'll need to add this file to your CLASSPATH before compiling. Your compiler may require you to use the .zip extension, in which case you’ll need to copy and rename. 

There's a trick that will make your life easier if you're developing in an IDE: Create a stripped-down version of java40.jar that contains only the classes in the netscape.security package. And - here’s the trick - remove the UserDialogHelper.class (unless you need it, of course!). This way, the netscape.security classes that are used by your applet will exist in the CLASSPATH when the applet is compiled, but isCommunicator will return false as it should when your applet is run in the IDE. 
 
 

Conclusion

Signed applets are now a reality. Applets with the power of full-fledged applications can now run in the most popular browsers. Developing signed applets is currently a bit complicated, though, requiring platform-specific tools and two different archive file formats and signature encodings. And it ain't free. This article won’t make it any cheaper, but I hope it will help you through the maze. 

Source to WriteFile.java. 
Source to SecurityContext.java. 
 
 

About the Author

Joseph Bowbeer is a Java consultant living in Seattle. He learned about signing applets while working on AAC Manager, an applet created by ADC Kentrox to manage their line of ATM network concentrators. Joe can be reached by email at jozart@alum.mit.edu.