Java security evolution and concepts, Part 3: Applet security

Tackle Java applet security with confidence

1 2 3 4 Page 2
Page 2 of 4

We will frequently refer to two system properties based on the system used and where the requisite software is installed. They are:

  • ${java.home}: refers to the location where the JRE is installed
  • ${user.home}: refers to the user's home directory

The actual values for these on my windows system, as an example, are C:\Program Files\JavaSoft\JRE\1.3 and C:\WINDOWS, respectively. The corresponding values on a Solaris system might be /files/j2sdk_1_3_0/jre and /home/raghavan, respectively.

All three tools use the keystore, a repository that stores keys and certificates for the installation. Entries are accessed by unique names referred to as aliases.


keytool manages the keystore -- for example, it can:

  • Create public/private key pairs
  • Issue certificate requests (sent to the appropriate Certification Authority)
  • Import certificate replies (obtained from the Certification Authority you contacted)
  • Designate public keys belonging to other parties as trusted

keytool currently handles X.509 certificates, although other formats can be supported by adding the respective providers. The Java Secure Socket Extension (JSSE) 1.0.2, for example, adds limited support to pkcs12. Different formats can be specified via the -storetype option in the command line.

keytool allows users to specify any key-pair generation and signature algorithm supplied by any of the registered cryptographic service providers via the -keyalg and -sigalg command-line options, respectively. The key size can be specified via the -keysize option.

Other useful options for keytool are listed in Table 1.

Table 1. Selected keytool options
-genkey Generates a key pair (a public key and associated private key) 
-import Reads the certificate or certificate chain and stores it in the keystore entry identified by alias 
-certreq Generates a Certificate Signing Request (CSR), using the pkcs10 format 
-export Exports a certificate associated with the alias 
-list Prints the contents of the entire keystore or the specified alias 
-storepasswd Changes the password used to protect the integrity of the keystore contents 
-keypasswd Changes the password under which the key identified by alias is protected 
-delete Deletes entries from the keystore 

The following command, using the RSA algorithm, will generate a key that is valid for 750 days. The command will store the key as an alias rags in the default keystore -- .keystore -- in the home directory (or, more precisely in the directory that is resolved by the system property ${user.home}, as explained earlier):

C:signtool> keytool -genkey -alias rags -keyalg rsa -validity 750
Enter keystore password:  
What is your first and last name?
  [Unknown]:  Raghavan Srinivas
What is the name of your organizational unit?
  [Unknown]:  MDDR
What is the name of your organization?
  [Unknown]:  Sun Microsystems
What is the name of your City or Locality?
  [Unknown]:  Burlington
What is the name of your State or Province?
  [Unknown]:  MA
What is the two-letter country code for this unit?
  [Unknown]:  US
Is >CN=Raghavan Srinivas, OU=MDDR, O=Sun Microsystems, L=Burlington, ST=MA, C=US
> correct?
  [no]:  yes
Enter key password for <rags>
        (RETURN if same as keystore password):  

The following illustrates a X.509 certificate that I got back from the CA.

C:\signtool> type rags.cer

The public key created above can be imported into a keystore to enable trusting code that is signed by the private key corresponding to the public key.

C:\signtool> keytool -v -printcert -file rags.cer
Owner: CN=Raghavan N. Srinivas, OU=Sun Microsystems (MDDR), O=Raghavan N. Srinivas, L=Burlington, ST=MA, C=US
Issuer:, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Serial number: 7c093
Valid from: Wed Dec 13 16:18:38 EST 2000 until: Fri Dec 21 17:20:22 EST 2001
Certificate fingerprints:
         MD5:  34:6C:32:F9:2E:0D:0D:B3:99:13:FC:EC:F3:D9:8B:AF
         SHA1: 77:5D:D9:EC:62:4D:C7:47:D9:58:05:73:B9:34:60:F6:38:A8:36:94

The following command lists the keys in the keystore, which indicates that it's the default type -- Java Key Store (jks). Other formats, such pkcs12, can be used as well; however, they require that JSSE be installed.

C:\signtool> keytool -list -keystore writeFile.keystore
Enter keystore password:  
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry:
rags, Thu Dec 14 12:39:31 EST 2000, trustedCertEntry,
Certificate fingerprint (MD5): 34:6C:32:F9:2E:0D:0D:B3:99:13:FC:EC:F3:D9:8B:AF


The jarsigner tool accesses a keystore created and managed by keytool, when it needs to find the private key and its associated certificate chain to use for signing a jar file. Since passwords protect access to the keystore and to private keys, only people who know the passwords will be able to access the key and use it to sign a jar file. The jarsigner tool prompts for needed passwords.

Some useful options for jarsigner are listed in Table 2.

Table 2. Selected jarsigner options
-storepass Specifies the required password to access the keystore during signing 
-keypass Specifies the password used to protect the private key of the keystore alias entry 
-signedjar Specifies the name to be used for the signed jar file 
-verify Jar file verification 
-verbose Output extra information as to the progress of the jar signing or verification 
-certs Used in conjunction with -verify and -verbose options, the output includes certificate information for each signer of the jar file 

Note: in this article's code examples, I did not use jarsigner to sign the files; instead, I used Netscape's signtool.


The policytool command creates and modifies the external policy configuration files that define the installation's security policy. This tool has a graphical user interface, with which you select buttons and other options rather than type in commands as you would with the other tools. The tool modifies a regular text policy file. For default policy implementation and policy file syntax, see Resources.

Figure 4 below shows the top-level window used to specify the location of the policy file and the keystore. If the policy file does not exist, an empty file may need to be created before using this tool. The window also displays the different entries.

Figure 4. policytool: modify the locations of the keystore and the policy file Click on thumbnail to view full-size image (14 KB)

Figure 5 below shows the next step of adding or modifying a policy entry. You may set the CodeBase and the SignedBy properties in this window.

Figure 5. policytool: CodeBase and SignedBy properties Click on thumbnail to view full-size image (15 KB)

Finally, Figure 6 illustrates how permissions can be added or modified.

Figure 6. policytool: setting permissions

The file {java.home}/lib/security/ by default contains two policy files -- {java.home}/lib/security/java.policy and {user.home}/.java.policy. policytool typically modifies the latter file.

Later, we will see several examples of how to modify policy files; this can be accomplished either with the policytool or a text editor. policytool does the validation (enforces the syntax, checks for keys in the keystore, and so on), a considerable advantage.

Netscape's signtool for object signing

Like jarsigner, Netscape's signtool is a stand-alone command-line tool that creates digital signatures and uses the Java Archive (JAR) format to associate them with files in a directory. Some useful options for signtool are listed in Table 3.

Table 3. Selected signtool options
-d certdir Specifies your certificate database directory containing key3.db and cert7.db files  
-G nickname Generates a new private-public key pair and corresponding object-signing certificate with the given nickname 
-k key Specifies the nickname (key) of the certificate you want to sign with 
-l Lists signing certificates, including issuing CAs; specifies invalid or expired certificates 
-L Lists the certificates in your database. An asterisk appears to the left of the nickname for any certificate that can be used to sign objects with signtool 
-v archive Verifies the cryptographic integrity of the archive 
-w archive Displays the names of signers of any files in the archive 
-Z jarfile Creates a jar file with the specified name 

Several examples of signtool commands are illustrated later.

Applet Deployment under Java 2 version 1.2

Instructions for running a Java 2, version 1.2 applet, including source code, is available from

Without repeating Sun's instructions here, let's summarize what happened when we followed them:

  • We discovered that applets can be deployed for plug-in support by using the Java plug-in HTML converter (see Resources).
  • By default, the applet generated a security exception due to the restrictions placed on downloaded code.
  • We imported the public key corresponding to the key used to sign the code.
  • To overcome the restrictions placed, we provided permissions based on the URL and the signer.
  • Finally, we were able to run the code without generating an exception. In fact, the code runs identically on Netscape Navigator and Internet Explorer without any changes.

Be aware that to run applet code that is signed, we had to import the public key of the signer into the keystore before we could run the code. This may not always be feasible. Worse yet, the process of importing signatures to a number of client machines does not scale well. Both these issues have been fixed in version 1.3 of the Java plug-in.

Evolution to Java 2 version 1.3

To utilize a variety of security enhancements in the platform and the Java plug-in, we will try to upgrade the applet that we studied in the 1.2 environment to the 1.3 environment using the plug-in. Some of the enhancements in the platform include:

  • Full support for RSA signatures.
  • Full interoperation with Verisign's code-signing certificates. As such, keytool is now able to import Verisign certificates.

Some of the enhancements to the Java plug-in v1.3 include:

  • New support for RSA-signed applets, thus removing the need to distribute an identitydb.obj file to client machines.
  • Support for the standard Java 2 SDK, Standard Edition version 1.3 security model.

In the earlier example, we simply used signed code. However, it's more interesting to sign and deploy our own applet. With the armory of tools and the knowledge we have now obtained, we are more or less ready for the undertaking.

It's recommended that you delete earlier versions of the plug-in before installing a more recent version. However, I have not seen any major ill effects myself of not doing so. To be reasonably sure that you are running the right version of the plug-in, you may want to use the plug-in panel available via the Control Panel (in Windows).

Generate an RSA-signed applet

The first step in the process will be to sign the code; for this task, I used Netscape's signtool. To sign the code, we need an object- or code-signing certificate, specifically for Netscape. This procedure can vary depending on what Certifying Authority (CA) you use. An important distinction between 1.3 and 1.2: self-certified signatures that worked in 1.2 do not work in 1.3. Signatures must be certified by a standard CA in 1.3. The turnaround times are different, as they involve some form of physical checks. Also, there are different certificate classes. Finally, the process involves some form of payment -- typically in the hundreds of dollars. Typically, this process starts off by generating a key pair. The private key will be stored safely on a local disk or a smart card. The public key is then sent to the CA for certification. Most CAs will follow a manual procedure at this point to ascertain the identity of the signer before issuing a certificate. (For a list of CAs, see Resources.)

Eventually, you will receive a public key encapsulated as a certificate. The public key certificate needs to be imported into Netscape's database. This process can be done in a variety of ways depending on the format used to receive the certificate. You may use the Import A Certificate option in Certificates/Yours in the security window as seen in Figure 7 below. Or you may paste the certificate into a text file and then import it.

1 2 3 4 Page 2
Page 2 of 4