Java security evolution and concepts, Part 3: Applet security

Tackle Java applet security with confidence

1 2 3 4 Page 3
Page 3 of 4
Figure 7. Netscape security window: manipulation of certificates Click on thumbnail to view full-size image (37 KB)

After installing the certificate, copy the relevant Netscape .db files to the signtool directory:

C:\signtool> copy c:"\Program Files\netscape\users\rags"\*.db
c:\Program Files\netscape\users\rags\cert7.db
c:\Program Files\netscape\users\rags\key3.db
c:\Program Files\netscape\users\rags\secmod.db

The files contain the keys and certificates needed to sign the code. The -l and -L options on signtool can be used to find certificates that can be used for code signing:

C:\signtool> signtool -l
using certificate directory: .
Object signing certificates
---------------------------------------
Sun Microsystems Inc.'s Thawte Consulting cc ID
    Issued by: Thawte Server CA (Thawte Server CA)
    Expires: Fri Dec 21, 2001
Raghavan N. Srinivas's Thawte Consulting cc ID
    Issued by: Thawte Server CA (Thawte Server CA)
    Expires: Fri Dec 21, 2001
Raghavan N. Srinivas's Sun Microsystems Inc ID
    Issued by: SMI Information Technology Test CA - Sun Microsystems Inc (SMI Information Technology Test CA)
    Expires: Fri Nov 24, 2000
---------------------------------------
For a list including CA's, use "signtool -L"
C:\signtool> signtool -L
using certificate directory: .
S Certificates
- ------------
  Verisign Class 1 Public Primary Certification Authority
  GlobalSign Primary Class 3 CA
  ValiCert OCSP Responder
  Verisign/RSA Commercial CA
  TC TrustCenter, Germany, Class 2 CA
  GlobalSign Primary Class 2 CA
  E-Certify Commerce ID
  Entrust.net Secure Personal CA
  TC TrustCenter, Germany, Class 3 CA
  Digital Signature Trust Co. Global CA 1
  Thawte Personal Freemail CA
  ValiCert Class 1 VA
  TC TrustCenter, Germany, Class 4 CA
  ValiCert Class 2 VA
  Verisign Class 3 Public Primary Certification Authority - G3
  Verisign/RSA Secure Server CA
  Thawte Personal Basic CA
  ValiCert Class 3 VA
  Verisign Class 4 Public Primary Certification Authority - G3
* Sun Microsystems Inc.'s Thawte Consulting cc ID
  GlobalSign Partners CA
  Equifax Secure CA
  Deutsche Telekom AG Root CA
  Sun Microsystems Inc TEST Root CA - GTE Corporation
  Digital Signature Trust Co. Global CA 2
  GTE CyberTrust Global Root
  GTE CyberTrust Root 3
  GTE CyberTrust Japan Secure Server CA
  VeriSign Class 4 Primary CA
  GTE CyberTrust Root 5
  GTE CyberTrust Japan Root CA
  TC TrustCenter, Germany, Class 0 CA
  Verisign Class 2 Public Primary Certification Authority - G2
  Verisign Class 3 Public Primary Certification Authority - G2
  GlobalSign Primary Class 1 CA
  Thawte Universal CA Root
  Entrust.net Premium 2048 Secure Server CA
* Raghavan N. Srinivas's Thawte Consulting cc ID
  GTE CyberTrust Root CA
  GTE CyberTrust Root 4
  American Express CA
  BelSign Object Publishing CA
  Verisign Class 1 Public Primary Certification Authority - G3
  Sun Microsystems Inc Test Root CA - GTE Corporation
  Sun Microsystems Inc TEST CA - Sun Microsystems Inc
  GTE CyberTrust Root 2
  TC TrustCenter, Germany, Class 1 CA
  Verisign Class 3 Public Primary Certification Authority
  Verisign Class 4 Public Primary Certification Authority - G2
  GlobalSign Root CA
  Personal Freemail RSA 1999.9.16 - Thawte Consulting
  Thawte Personal Premium CA
  SMI Information Technology Test CA - Sun Microsystems Inc
* Raghavan N. Srinivas's Sun Microsystems Inc ID
  BelSign Secure Server CA
  ABAecom (sub., Am. Bankers Assn.) Root CA
  American Express Global CA
  Equifax Premium CA
  E-Certify Internet ID
  Thawte Server CA
  Digital Signature Trust Co. Global CA 4
  Verisign Class 2 Public Primary Certification Authority - G3
  Verisign Class 2 Public Primary Certification Authority
  Digital Signature Trust Co. Global CA 3
  Verisign Class 1 Public Primary Certification Authority - G2
  Thawte Premium Server CA
  Entrust.net Secure Server CA
- ------------
Certificates that can be used to sign objects have *'s to their left.

Notice the *, which indicates a code-signing certificate. Next, sign the file and generate the jar file:

C:\signtool> mkdir writeFileDir
C:\signtool> copy writeFile.class writeFileDir
C:\signtool> signtool -k "Raghavan N. Srinivas's Thawte Consulting cc ID" -Z writeFile.jar writeFileDir
using certificate directory: .
Generating writeFileDir/META-INF/manifest.mf file..
--> writeFile.class
adding writeFileDir/writeFile.class to writeFile.jar...(deflated 44%)
Generating zigbert.sf file..
Enter Password or Pin for "Communicator Certificate DB":
Enter Password or Pin for "Communicator Certificate DB":
adding writeFileDir/META-INF/manifest.mf to writeFile.jar...(deflated 15%)
adding writeFileDir/META-INF/zigbert.sf to writeFile.jar...(deflated 27%)
adding writeFileDir/META-INF/zigbert.rsa to writeFile.jar...(deflated 36%)
tree "writeFileDir" signed successfully

Finally, verify the jar file:

C:\signtool> signtool -w writeFile.jar
using certificate directory: .
Signer information:
nickname: Raghavan N. Srinivas's Thawte Consulting cc ID
subject name: CN=Raghavan N. Srinivas, OU=Sun Microsystems (MDDR), O=Raghavan N. Srinivas, L=Burlington, ST=MA, C=US
issuer name: E=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

This certificate may be imported into the Java .keystore, if needed, using the following steps:

  1. Export the certificate as a pkcs12 format -- default Netscape support
  2. Use the .p12 file as a keystore of storetype pkcs12 -- supported by installing JSSE; alternatively, export out of the pkcs12 keystore and import into the default JKS keystore

The following command lists the keys in the pkcs12 keystore after the certificate was exported from the navigator:

C:\signtool> keytool -list -storetype pkcs12 -keystore rags.p12
Enter keystore password: 
Keystore type: pkcs12
Keystore provider: SunJSSE
Your keystore contains 1 entry:
raghavan n. srinivas's thawte consulting cc id, Thu Dec 14 13:25:44 EST 2000, keyEntry,
Certificate fingerprint (MD5): 

After the jar file has been successfully signed, we are ready to deploy the applet.

Deploy the applet

Having signed the code as highlighted in the previous step, we are now ready to deploy the applet -- almost. The deployment directory must contain the signed jar file and the HTML file for the code to be downloaded and run, as illustrated in the version 1.2 example earlier.

Move writeFile.jar to the deployment directory. The HTML file needs to work with version 1.3 of the Java 2 plug-in. The final writeFile.html in the deployment directory must look something like the code below. Notice that this is only a slight modification of the HTML file we used earlier with changes to incorporate the later version of the plug-in:

<html>
<title> Java Security Example: Writing Files</title>
<h1> Java Security Example: Writing Files </h1>
<hr>
Here's an applet that tries to write to the file <code>/tmp/foo</code>
on a Solaris system (or to the file <code>C:\tmpfoo</code> on a
Windows 95 or Windows NT system.)
<p>
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.0 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 500 HEIGHT = 50  codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = writeFile.class>
<PARAM NAME = ARCHIVE VALUE = "writeFile.jar">
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3" 
java_CODE = writeFile.class java_ARCHIVE = "writeFile.jar" 
WIDTH = 500 HEIGHT = 50   pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>
<!--
<APPLET  CODE = writeFile.class ARCHIVE = "writeFile.jar" WIDTH = 500 HEIGHT = 50 >
</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->
<p>
and here's the <a href=writeFile.java>source</a>. 
<p>
This applet is a signed applet.
</center>
<hr>
</html>

Having deployed the applet, you are now ready to run it. Applets can be tested by deploying them initially on a local system. Eventually, they will need to be deployed in a Web server environment.

Run the applet

Having deployed the applet on the server, we are now ready to run it from the client. It's not necessary to have a Web server to test the deployment. It can be run from a filesystem using the file: protocol instead of http:.

Before running the applet, make sure that the policy files, ${java.home}/lib/security/java.policy and ${user.home}/.java.policy, do not accord any special permissions besides the default.

Point the browser at writeFile.html in the publicly available URL. If you do not have the latest version of the plug-in installed, you may have to go through the additional step of installing it. When users of the Java plug-in encounter an RSA-signed applet, the plug-in will verify that the applet is correctly signed, and that the RSA certificate chain and the root CA are valid. If these are all valid, the plug-in will pop up a security dialog explaining who signed the applet and providing four options, as shown in Figure 8. Depending on whether you trust the signer of the code, you could do one of the following:

  • Grant this session: If selected, the applet will be granted AllPermission. Any signed applet signed using the same certificate will be trusted automatically within the same browser session.
  • Deny: If selected, the applet will be treated as an untrusted applet.
  • Grant always: If selected, the applet will be granted AllPermission. Any signed applet signed using the same certificate will be trusted automatically in the future, and no security dialog will pop up when this certificate is encountered again. This decision can be changed from the Java plug-in control panel.
  • More Info: If selected, users can examine the attributes of each certificate in the certificate chain in the jar file.
Figure 8. Plug-in warning pop-up window Click on thumbnail to view full-size image (16 KB)

Once the user selects the options from the security dialog, the applet will run in the corresponding security context. All of these decisions are determined on the fly, and no preconfiguration is required.

All certificates trusted by the plug-in can be viewed from the plug-in panel, illustrated in Figure 9.

Figure 9. Plug-in trusted certificates Click on thumbnail to view full-size image (12 KB)

At this point you may ask, "If trusting the certificate grants complete access to the signed applet, where does the fine-grained security professed in Java 2 come in?"

In fact, the model does not seem a whole lot different from version 1.1. However, the plug-in default behavior can be overridden by specifying a new permission named usePolicy under RuntimePermission in the policy file. The pop-up dialog box serves a useful role for unsophisticated users and for temporary exceptions to the installed policy, but only at the sole discretion of the user.

Figures 10 and 11 show the applet running in Netscape Navigator on Solaris and Internet Explorer on Windows, respectively.

Figure 10. Applet in Netscape Navigator Click on thumbnail to view full-size image (63 KB)
Figure 11. Applet in Internet Explorer Click on thumbnail to view full-size image (26 KB)

The applet may be run from http://www.javaworld.com/javaworld/jw-12-2000/security/writeFile.html.

The policy file's role

Let's remove the trusted certificate from the Java plug-in control panel to understand the role of the policy file. Select the certificate in the plug-in control panel and hit Remove. Close the control panel and bring it up again to ensure that the certificate has indeed been deleted.

We will look at several policy instances to understand the interaction of the plug-in and the policy file in making access-control decisions. We saw an instance where the user selected the security context since the policy file did not contain any relevant entries.

Let's modify the policy file to contain the entry below:

grant {
  permission java.lang.RuntimePermission "usePolicy";
};

Now, run the applet as before. Notice that the pop-up dialog box does not appear due to the permission usePolicy in the policy file. The applet generated a security exception since there was nothing specified in the policy file to permit that operation. To explicitly provide that permission, add an entry to the policy file:

grant {
  permission java.lang.RuntimePermission "usePolicy";
  permission java.io.FilePermission "C:${/}tmpfoo", "write";
};

As you might expect, rerunning the applet will create and modify the file without popping up the dialog box.

Finally, let's remove the usePolicy entry in the policy file:

grant {
  permission java.io.FilePermission "C:${/}tmpfoo", "write";
};

The dialog box pops up again as expected and, regardless of what security context is chosen in the dialog box, the file will be modified. In other words, it does not matter if access was granted or denied. Why? The installation's policy is ultimately governed by the policy file. The pop-up dialog box should be used very selectively, especially in situations where it might be unreasonable to expect the user to modify the policy file. My mom would be a good example of such a user. Hopefully, she will trust me enough to provide access to an applet that I have signed and let me out of the sandbox.

1 2 3 4 Page 3
Page 3 of 4