email article printer friendly get the code more resources

Building Trust for Applets
With only one security model to worry about, the Java 2 standard security model, security for applets is now easier than ever
by Kevin Jones

Posted February 11, 2004

Editor's Note: This is the second of two installments on creating and using secure applets. In the first part, "Employ Secure Applets in Browsers" (Java Pro Online, February 4, 2004), author Kevin Jones discussed why applets are back in vogue after falling out of favor for a while, using applets in browsers, and managing applets' security. Here, Jones walks you through the process of creating and using a security certificate and changing the policy file.

Turning to matters of security, let's walk through a process of creating a certificate, using that certificate to sign code, and then changing the policy file so that only code with that signature is trusted. Be aware that the certificate we create here will be self-signing, that is, there will be no verification that we are who we say we are. I could say I was Microsoft and the certificate would contain that information. In a normal business environment you would get a certificate from a certifying authority such as Thawte or VeriSign (see Resources), but we'll forgo that step here. Note that the code examples you see here were run and tested on Windows Server 2003 running J2SDK 1.4.2 and J2SDK 1.5alpha.

Java comes with tools that allow us to create certificates and to sign code. To create a certificate, you use keytool. This tool has many uses. You create a certificate like this:

keytool -genkey -alias signer

The flag genkey tells keytool that you want to create a key pair, and alias is the name by which this key pair will be referenced. When you run this command you will be asked for some naming information; fill in these details (by default the password for the JDK keystore is changeit). Once these keys have been generated, they are in your keystore. You will use these keys to sign the code.

To sign code, it must first be packaged as a JAR file. Use your favorite tool to do this. You can then run jarsigner:

jarsigner -verbose -signedjar 
  sdirlisting.jar dirlisting.jar 
  signer

Again you will be asked for passwords. Note that dirlisting.jar is the input JAR, signer is the alias used when creating the key pair, and sdirlisting.jar is the signed output JAR. You now need to deploy the JAR to the Web server and browse to the page. Remember that the applet tag looked like this:

<applet code=
  "com.develop.kevinj.
  DirectoryList.class"
  archive="sdirlisting.jar"
  width=460 height=160>
</applet>

That is, we are specifying an archive to load, and it is this archive that is signed. Before browsing to the page, change your policy file to look like this:

keystore ".keystore", "jks";
grant signedBy "signer" 
codeBase "http://localhost/*" {
  permission java.lang.
    RuntimePermission "usePolicy";
  permission java.io.
    FilePermission 
    "<<ALL FILES>>", "read";
};