Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

KeyGuard, JAR Signing Utility

0.00/5 (No votes)
25 Feb 2005 1  
A small utility to automate and simplify the process of JAR signing
KeyGuard GUI in action.

Disclaimer

Please be advised that KeyGuard is suitable only for the purpose of maintaining a Key-Store of personal Certificates that are created by the user and are therefore vouched by the user.  KeyGuard currently re-writes the Key-Store file every time you save your changes to the Key-Store, this means that any Certificates bought and installed or created before working with KeyGuard, will be removed! Any changes you make to the Key-Store through the command-line program "keytool" are not maintained in KeyGuard and will be lost when KeyGuard saves its information back to the Key-Store. I will not be responsible for loss of any information from your Key-Store and urge you to back up your ".keystore" file before using KeyGuard. Also note that this approach covers signing JARs to be used with Sun's JRE Plug-In and not with other JVMs.

Introduction

In your work with Java and the Web, you may have had to sign a JAR.  Most likely, it was a JAR containing an Applet. There are several ways to sign JAR files, especially those that contain Applets. However, for some bizarre reason, most ways involve command-line tools, or scripts.  Since I'm currently developing a Web Project which requires me to deploy at least two signed Applets, each with its own tasks, I realized I would be doing a lot of signing and re-signing of my JAR files. Since software projects are usually quite dynamic, I decided to create a GUI that will not only let me sign a JAR file, but also manage the Java Key-Store used for signing the JAR files in my project. 

Background

Before I begin to describe how KeyGuard helps in creating Key-Store Aliases and signing JAR files, a brief review of the process is in order. The process of signing a JAR file starts with first creating a Certificate that contains your credentials (if you don't already have one). This process involves the command-line program "keytool" which requires you to provide information about yourself as the provider of the Certificate. Once you have specified the necessary information, a Certificate is stored in the Key-Store under an Alias you specified. This Alias can then be given as a parameter to another command-line program "jarsigner" along with the JAR file you wish to sign. Both "keytool" and "jarsigner" should be easily accessible from your shell-prompt for KeyGuard to work properly. As you can see from the image above, KeyGuard maintains the passwords for each of the stored Certificates as well as the global password for the Key-Store itself. One particular requirement for working with the command-line programs is that you remember the passwords and Aliases of each Certificate you wish to use, a problem which KeyGuard solves very well.

Using KeyGuard

You can use KeyGuard in one of the following ways:

  1. Use KeyGuard as an Applet directly from the article page.
  2. Download the KeyGuard ZIP file, rename it to JAR and use it on your machine.

If you choose to download KeyGuard and use it locally, you should be able to create a File-Association to let you right-click on any JAR file and sign it using KeyGuard as demonstrated in the image below:

If you choose however to work with KeyGuard as an Applet from this article, please be advised that you must authorize the Applet to access your local file-system or it will not function properly.

KeyGuard has two modes of operations. The first is a simple editor of the Certificate, and their information, that are stored in the Key-Store, this mode uses the "keytool" command-line program and feeds it the information required to create the Certificates you use. The second mode is activated to sign a JAR file. If you run KeyGuard.jar without any parameters, it will display the Certificate editing GUI. If you supply a JAR file (complete path and file-name is required), the JAR signing dialog will be displayed instead.  If you do not have a .keystore file in your disk, you will have to first create one by adding at least one Certificate through KeyGuard before you will be able to sign any JAR files.

No Source Code

KeyGuard uses another component I have presented in an earlier article, this component enables KeyGuard to interact with the command-line programs it uses. KeyGuard itself is contained in the KeyGuard.jar file. The Applet's JAR file is not required for KeyGuard to run as a stand-alone version, however, as you have noticed, there is no source-code to download from this article.

Applets Under the Hood

This section discusses how Applets are expected to utilize their freedom once the Applet's JAR can be signed.

First, an Applet must use its own SecurityManager in order to bypass certain permission-checks otherwise performed by the default SecurityManager. The following code displays a simple Applet that already includes its own SecurityManager as an inner-class:

import java.awt.*;
import java.security.*;

public class SignedApplet extends Applet {
  final class MySecurityManager extends SecurityManager {
    // Permission overriding methods..
    public void checkPermission(Permission perm) {}
    public void checkPermission(Permission perm, Object context) {}
  }
  // Rest of Applet goes here..
}

Sometimes, as I have found when testing the Applet version of KeyGuard, simply having a SecurityManager present as an inner class is not enough. I am not sure why, but apparently, even a signed Applet may not create its own ClassLoaders even if it is signed and has a SecurityManager present as an inner class. Therefore, I needed to create a SecurityManager class that actually replaces the default SecurityManager, as the following code shows: 

import java.security.*;

public final class KgSecurityManager extends SecurityManager {
  public static boolean init() {
    try {
      SecurityManager sm = System.getSecurityManager();
      if (!(sm instanceof KgSecurityManager)) {
        System.setSecurityManager(new KgSecurityManager());
      }
      return true;
    } catch (AccessControlException ex) {
      // Here's a little trick, if we get an AccessControlException here,
      // this means the user has refused to trust the Applet's Certificate!
      return false;
    }
  }
  // Same permission overriding methods as before..
  public void checkPermission(Permission perm) {}
  public void checkPermission(Permission perm, Object context) {}
}

Now, my KeyGuard Applet can use the KgSecurityManager class like this:

public class KgApplet extends JApplet {
  private static boolean appletAuthorized;
  
  // ...Rest of Applet code goes here...
  
  static {
    // This code will run only once, when the KgApplet class is 
    // first loaded in the Browser's JVM..
    try {
      // Try to initialize the KgSecurityManager class..
      appletAuthorized = KgSecurityManager.init();
      // Initialize the look & feel setting..
      UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}

The Applet can now check the appletAuthorized boolean-flag to know if it is allowed to attempt any operations that will otherwise result in another AccessControlException if the default SecurityManager is still in place.

Points of Interest

I procrastinated writing KeyGuard mostly for fear that it may become a project of its own.  However, this little utility is worth its weight in bytes. I can now change my Key-Store on a whim, remove and add Certificates with ease and the simplicity of a double-click on the KeyGuard.jar file. After integrating KeyGuard.jar into my XP system, I can safely say that I see no need to manually use "keytool" or "jarsigner" ever again. Writing this utility and bridging the world of command-line/interactive programs and a modern GUI system was also illuminating as at one point I found that the External Process created for "keytool" was already sending input to my program while my program wasn't sure the Process was properly started! I was amused to see that the problem was with Thread synchronization of access to the Process instance.  Indeed, one must be careful combining procedural-programming and event-driven/multi-threading programs. If you like this utility and can think of future improvements, please leave me a message or email.

History

  • Feb 26th, 2005 - KeyGuard Applet now hosted on GeoCities
  • Feb 25th, 2005 - Created article

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here