Chapter 10: Signed Applets

Print-friendly Version

[<<BACK] [CONTENTS] [NEXT>>]

A policy file can be defined to require a signature on all applets or applications that attempt to run with the policy file. The signature is a way to verify that the applet or applicationis from a reliable source and can be trusted to run with the permissions granted in the policy file.

If a policy file requires a signature, an applet or application can get the access granted by the policy file only if it has the correct signature. If the applet or application has the wrong signature or no signature, it will not get access to the file.

This section walks through an example of signing an applet, verifying the signature, and running the applet with a policy file.

• Signed Applet Example
• Intranet Developer
• End User
• Running an Application with a Policy File
• Signed Applets in JDK 1.1

Signed Applet Example

The policy file granting access can be set up to require or not require a signature. If a signature is required, the applet has to be bundled into a Java ARchive (JAR) file before it can be signed. This example shows you how to sign and grant permission to an applet so it can create demo.ini in the user's home directory when it executes in Applet Viewer.

These files are used for the example. You can copy them to or create them in your working directory.

• SignedAppletDemo.java file containing the applet code
• Write.jp policy file granting access to the user's home directory
• Applet tag embedded in the SignedApplet.html file:

  <applet code="/developer/onlineTraining/Programming/JDCBook/SignedAppletDemo.class" archive="SSignedApplet.jar" width=400 height=400> <param name=file value="/etc/inet/hosts"> </applet>

  
  

Usually an applet is bundled and signed by an intranet developer and handed off to the end user who verifies the signature and runs the applet. In this example, the intranet developer performs Steps 1 through 5 and Ray, the end user, performs Steps 6 through 8. But, to keep things simple, all steps occur in the same working directory.

1. Compile the applet
2. Create a JAR file
3. Generate Keys
4. Sign the JAR file
5. Export the Public Key Certificate
6. Import the Certificate as a Trusted Certificate
7. Create the policy file
8. Run the applet

Intranet Developer

Susan, the intranet developer, bundles the applet executable in a JAR file, signs the JAR file, and exports the public key certificate.

1: Compile the Applet

In her working directory, Susan uses the javac command to compile the SignedAppletDemo.java class. The output from the javac command is the SignedAppletDemo.class.

javac SignedAppletDemo.java

2: Make a JAR File

Susan then stores the compiled SignedAppletDemo.class file into a JAR file. The -cvf option to the jar command creates a new archive (c), using verbose mode (v), and specifies the archive file name (f). The archive file name is SignedApplet.jar.

jar cvf SignedApplet.jar SignedAppletDemo.class

3: Generate Keys

A JAR file is signed with the private key of the creator of the JAR file and the signature is verified by the recipient of the JAR file with the public key in the pair. The certificate is a statement from the owner of the private key that the public key in the pair has a particular value so the person using the public key can be assured the public key is authentic. Public and private keys must already exist in the keystore database before jarsigner can be used to sign or verify the signature on a JAR file.

Susan creates a keystore database named compstore that has an entry for a newly generated public and private key pair with the public key in a certificate using the keytool command.

In her working directory, Susan creates a keystore database and generates the keys:

keytool -genkey -alias signFiles -keystore compstore 
	-keypass kpi135 -dname "cn=jones" 
	-storepass ab987c

This keytool -genkey command invocation generates a key pair that is identified by the alias signFiles. Subsequent keytool command invocations use this alias and the key password (-keypass kpi135) to access the private key in the generated pair.

The generated key pair is stored in a keystore database called compstore (-keystore compstore) in the current directory, and accessed with the compstore password (-storepass ab987c).

The -dname "cn=jones" option specifies an X.500 Distinguished Name with a commonName (cn) value. X.500 Distinguished Names identify entities for X.509 certificates. In this example, Susan uses her last name, Jones, for the common name. She could use any common name that suits her purposes.

You can view all keytool options and parameters by typing:

keytool -help

4: Sign the JAR File

JAR Signer is a command line tool for signing and verifying the signature on JAR files. In her working directory, Susan uses jarsigner to make a signed copy of the SignedApplet.jar file.

jarsigner -keystore compstore -storepass ab987c 
        -keypass kpi135 
	-signedjar 
	SSignedApplet.jar SignedApplet.jar signFiles

The -storepass ab987c and -keystore compstore options specify the keystore database and password where the private key for signing the JAR file is stored. The -keypass kpi135 option is the password to the private key, SSignedApplet.jar is the name of the signed JAR file, and signFiles is the alias to the private key. jarsigner extracts the certificate from the keystore whose entry is signFiles and attaches it to the generated signature of the signed JAR file.

5: Export the Public Key Certificate

The public key certificate is sent with the JAR file to the end user who will be using the applet. That person uses the certificate to authenticate the signature on the JAR file. A certificate is sent by exporting it from the compstore database.

In her working directory, Susan uses keytool to copy the certificate from compstore to a file named CompanyCer.cer as follows:

keytool -export -keystore compstore -storepass ab987c  
	-alias signFiles -file CompanyCer.cer

As the last step, Susan posts the JAR and certificate files to a distribution directory on a web page.

End User

Ray, the end user, downloads the JAR file from the distribution directory, imports the certificate, creates a policy file granting the applet access, and runs the applet.

6: Import Certificate as a Trusted Certificate

Ray downloads SSignedApplet.jar and CompanyCer.cer to his home directory. Ray must now create a keystore database (raystore) and import the certificate into it using the alias company. Ray uses keytool in his home directory to do this:

keytool -import -alias company -file 
        CompanyCer.cer -keystore 
	raystore -storepass abcdefgh

7: Create the Policy File

The policy file grants the SSignedApplet.jar file signed by the alias company permission to create demo.ini (and no other file) in the user's home directory.

Ray creates the policy file in his home directory using either policytool or an ASCII editor.

keystore "/home/ray/raystore";

// A sample policy file that lets a program 
// create demo.ini in user's home directory
// Satya N Dodda

grant SignedBy "company" {
  permission java.util.PropertyPermission 
    "user.home", "read";
  permission java.io.FilePermission 
    "${user.home}/demo.ini", "write";
};

8: Run the Applet in Applet Viewer

Applet Viewer connects to the HTML documents and resources specified in the call to appletviewer, and displays the applet in its own window. To run the example, Ray copies the signed JAR file and HTML file to /home/aURL/public_html and invokes Applet viewer from his home directory as follows:

appletviewer -J-Djava.security.policy=Write.jp 
	http://aURL.com/SignedApplet.html

Note: Type everything on one line and put a space after Write.jp

Note: The Policy file can be stored on a server and specified in the appletviewer invocation as a URL.

Running an Application with a Policy File

This application invocation restricts MyProgram to a sandbox-like environment the same way applets are restricted, but allows access as specified in the polfile policy file.

java -Djava.security.manager
        -Djava.security.policy=polfile MyProgram

Signed Applets in JDK 1.1

JDK 1.1 signed applets can access local system resources if the local system is properly set up to allow it. See the JDK 1.1 Signed Applet Example page for details.

[TOP]