Code Signing | Building an On Demand Computing Environment with IBM: How to Optimize Your Current Infrastructure for Today and Tomorrow (MaxFacts Guidebook series)

One of the most important uses of authentication technology is signing executable programs. If you download a program, you are naturally concerned about damage that a program can do. For example, the program could have been infected by a virus. If you know where the code comes from and that it has not been tampered with since it left its origin, then your comfort level will be a lot higher than without this knowledge. In fact, if the program was also written in the Java programming language, you can then use this information to make a rational decision about what privileges you will allow that program to have. You might want it to run just in a sandbox as a regular applet, or you might want to grant it a different set of rights and restrictions. For example, if you download a word processing program, you might want to grant it access to your printer and to files in a certain subdirectory. However, you may not want to give it the right to make network connections, so that the program can't try to send your files to a third party without your knowledge.

You now know how to implement this sophisticated scheme.

1.	First, use authentication to verify where the code came from.
2.	Then, run the code with a security policy that enforces the permissions that you want to grant the program, depending on its origin.

JAR File Signing

In this section, we show you how to sign applets and web start applications for use with the Java Plug-in software. There are two scenarios:

Delivery in an intranet
Delivery over the public Internet

In the first scenario, a system administrator installs certificates and policy files on local machines. Whenever the Java Plug-in tool loads signed code, it consults the keystore for signatures and the policy file for the permissions. Installing the certificates and policies is straightforward and can be done once per desktop. End users can then run signed corporate code outside the sandbox. Whenever a new program is created or an existing one is updated, it must be signed and deployed on the web server. However, no desktops need to be touched as the programs evolve. We think this is a reasonable scenario that can be an attractive alternative to deploying corporate applications on every desktop.

In the second scenario, software vendors obtain certificates that are signed by certificate authorities such as VeriSign. When an end user visits a web site that contains a signed applet, a pop-up dialog box identifies the software vendor and gives the end user two choices: to run the applet with full privileges or to confine it to the sandbox. We discuss this scenario in detail on page 770.

For the remainder of this section, we describe how you can build policy files that grant specific permissions to code from known sources. Building and deploying these policy files is not for casual end users. However, system administrators can carry out these tasks in preparation for distributing intranet programs.

Suppose ACME Software wants its users to run certain programs that require local file access, and it wants to deploy the program through a browser, as applets or web start applications. Because these programs cannot run inside the sandbox, ACME Software needs to install policy files on employee machines. As you saw earlier in this chapter, ACME could identify the applets by their code base. But that means that ACME would need to update the policy files each time the applet code is moved to a different web server. Instead, ACME decides to sign the JAR files that contain the applet code.

To make a signed JAR file, first add your class files to a JAR file. For example,

 javac FileReadApplet.java jar cvf FileReadApplet.jar *.class

Then run the jarsigner tool and specify the JAR file and the alias of the private key:

 keytool -genkey -keystore acmesoft.store -alias acmeroot jarsigner -keystore acmesoft.store FileReadApplet.jar acmeroot

In this example, the JAR file is signed with the self-signed root key. Alternatively, ACME could issue keys to its programmers and sign them with the root key.

Of course, the keystore containing the private root key must be kept at a safe place. Let's make a second keystore certs.store for certificates and add the acmeroot certificate into it.

 keytool -export -keystore acmesoft.store -alias acmeroot -file acmeroot.cert keytool -import -keystore certs.store -alias acmeroot -file acmeroot.cert

Next, create a policy file that gives the permission for all applets that are signed with signatures in that keystore.

Include the location of your keystore in the policy file. Add a line

keystore "keystoreURL", "keystoreType";

to the top of the policy file. The type is JKS if the keystore was generated by keytool.

 keystore "file:certs.store", "JKS";

Then add signedBy "alias" to one or more grant clauses in the policy file. For example,

 grant signedBy "acmeroot" {    . . . };

Any signed code that can be verified with the public key associated with the alias is now granted the permissions inside the grant clause.

NOTE

Because the Java platform combines authentication and control over code permissions, it offers vastly superior security than Microsoft's ActiveX technology. ActiveX code is authenticated, but once it gains permission to run, it cannot be controlled at all. Microsoft has introduced a more comprehensive security model in the .NET platform.

You can try out the code signing process with the applet in Example 9-20. The applet tries to read from a local file. The default security policy only lets the applet read files from its code base and any subdirectories. Use appletviewer to run the applet and verify that you can view files from the code base directory, but not from other directories.

Now place the applet in a JAR file and sign it with the acmeroot key. Then create a policy file applet.policy with the contents:

 keystore "file:///home/mydir/certs.store", "JKS"; grant signedBy "acmeroot" {    permission java.io.FilePermission "<<ALL FILES>>", "read"; };

Finally, tell the applet viewer to use the policy file:

 appletviewer -J-Djava.security.policy=applet.policy FileReadApplet.html

Now the applet can read all files, thus demonstrating that the signing mechanism works.

As a final test, you can run your applet inside the browser (see Figure 9-15). Modify the deployment.properties file. If you run UNIX or Linux, the file is contained inside the .java/deployment subdirectory of your home directory. In Windows, the file is located inside the C:\Documents and Settings\yourLoginName\Application Data\Sun\Java\Deployment directory.

Figure 9-15. A signed applet can read local files

Add a line with a file URL for the policy file, such as

 deployment.user.security.policy=file:///home/mydir/applet.policy

Load the FileReadApplet.html file into the browser. Do not accept the signature of the JAR file. (Doing so would automatically give the applet all permissions.) Nevertheless, you should be able to load any local file, proving that the security manager has given the applet additional rights.

When you are done, remember to clean up your deployment.properties file and remove the policy file setting. If you load the applet again after cleaning up, you should no longer be able to read files from the local file system.

CAUTION

When you test your applet in the browser instead of the applet viewer, be aware that the plug-in reads the deployment.properties file only once, when it is loaded for the first time. If you made a mistake, then close down the browser, fix your mistake, and restart the browser. Simply reloading the web page containing the applet does not work.

TIP

If you decide to roll out signed applets or web start applications in an intranet, you should configure the deployment.properties files of your users' machines. The sections on "Deployment Configuration File and Properties" and "Java Control Panel" in the deployment guide at http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/contents.html contain detailed instructions.

Example 9-20. FileReadApplet.java

  1. import java.awt.*;  2. import java.awt.event.*;  3. import java.io.*;  4. import java.util.*;  5. import javax.swing.*;  6.  7. /**  8.    This applet can run "outside the sandbox" and read local files  9.    when it is given the right permissions. 10. */ 11. public class FileReadApplet extends JApplet 12. { 13.    public FileReadApplet() 14.    { 15.       fileNameField = new JTextField(20); 16.       JPanel panel = new JPanel(); 17.       panel.add(new JLabel("File name:")); 18.       panel.add(fileNameField); 19.       JButton openButton = new JButton("Open"); 20.       panel.add(openButton); 21.       openButton.addActionListener(new 22.          ActionListener() 23.          { 24.             public void actionPerformed(ActionEvent event) 25.             { 26.                loadFile(fileNameField.getText()); 27.             } 28.          }); 29. 30.       add(panel, "North"); 31. 32.       fileText = new JTextArea(); 33.       add(new JScrollPane(fileText), "Center"); 34.    } 35. 36.    /** 37.       Loads the contents of a file into the text area. 38.       @param filename the file name 39.    */ 40.    public void loadFile(String filename) 41.    { 42.       try 43.       { 44.          fileText.setText(""); 45.          Scanner in = new Scanner(new FileReader(filename)); 46.          while (in.hasNextLine()) 47.          fileText.append(in.nextLine() + "\n"); 48.          in.close(); 49.       } 50.       catch (IOException e) 51.       { 52.          fileText.append(e + "\n"); 53.       } 54.       catch (SecurityException e) 55.       { 56.          fileText.append("I am sorry, but I cannot do that.\n"); 57.          fileText.append(e + "\n"); 58.       } 59.    } 60. 61.    private JTextField fileNameField; 62.    private JTextArea fileText; 63. }

Software Developer Certificates

Up to now, we discussed scenarios in which programs are delivered in an intranet and for which a system administrator configures a security policy that controls the privileges of the programs. However, that strategy only works with programs from known sources.

Suppose while surfing the Internet, you encounter a web site that offers to run an applet or web start application from an unfamiliar vendor, provided you grant it the permission to do so (see Figure 9-16). Such a program is signed with a software developer certificate that is issued by a certificate authority. The pop-up dialog box identifies the software developer and the certificate issuer. You now have two choices:

To run the program with full privileges, or
To confine the program to the sandbox.

Figure 9-16. Launching a signed applet

What facts do you have at your disposal that might influence your decision? Here is what you know:

Thawte sold a certificate to the software developer.
The program really was signed with that certificate, and it hasn't been modified in transit.
The certificate really was signed by Thawteit was verified by the public key in the local cacerts file.

Does that tell you whether the code is safe to run? Do you trust the vendor if all you know is the vendor name and the fact that Thawte sold them a software developer certificate? Presumably Thawte went to some degree of trouble to assure itself that ChemAxon Kft. is not an outright cracker. However, no certificate issuer carries out a comprehensive audit of the honesty and competence of software vendors.

In the situation of an unknown vendor, an end user is ill-equipped to make an intelligent decision whether to let this program run outside the sandbox, with all permissions of a local application. If the vendor is a well-known company, then the user can at least take the past track record of the company into account.

NOTE

It is possible to use very weak certificates to sign codesee http://www.dallaway.com/acad/webstart for a sobering example. Some developers even instruct users to add untrusted certificates into their certificate storefor example, http://www.agsrhichome.bnl.gov/Controls/doc/javaws/javaws_howto.html. From a security standpoint, this seems very bad.

We don't like situations in which a program demands "give me all rights, or I won't run at all." Naïve users are too often cowed into granting access that can put them in danger.

Would it help if each program explained what rights it needs and requested specific permission for those rights? Unfortunately, as you have seen, that can get pretty technical. It doesn't seem reasonable for an end user to have to ponder whether a program should really have the right to inspect the AWT event queue.

We remain unenthusiastic about programs that are signed with software developer certificates and whose execution is approved by end users. We suggest that you limit code signing to corporate applications in which the certificates are configured by a system administrator.