The SignedObject Class The Signature Class

This method shows yet another need for an alternate implementation of the KeyStore class −− if you have to search the entire list of keys for a matching certificate like this, you clearly dont want to perform a linear search each time. An alternate keystore could provide a more efficient means of searching for certificates.

12.2 Signed Classes

One of the primary applications of digital signatures in Java is to create and verify signed classes. Signed classes allow the expansion of Javas sandbox in two ways: The policy file can insist that classes coming from a particular site be signed by a particular entity before the access controller will grant that particular set of permissions. In the policy file, such an entry contains a signedBy directive: grant signedBy sdo, codeBase http:piccolo.East.Sun.COM { java.io.FilePermission −, read,write; } This entry allows classes that are loaded from piccolo.East.Sun.COM to read and write any local files under the current directory only if the classes have been signed by sdo . • The security manager can cooperate with the class loader in order to determine whether or not a particular class is signed; the security manager is then free to grant permissions to that class based on its own internal policy. However, while this was an important technique in Java 1.1, it is rarely used in Java 2. • We talked about these operations throughout this book; in this section, well fill in the last details about how the digital signatures are created and verified. There are three necessary ingredients to expand the Java sandbox with signed classes: A method to create the signed class. The jarsigner utility is used for this. • A class loader that knows how to understand the digital signature associated with the class. The URLClassLoader class knows how to do this, but well show an example of how to do that for a custom class loader as well. • A security manager or access controller that grants the desired permissions based on the digital signature. The access controller will do this for us; well show how the security manager might do this directly in Appendix D. •

12.2.1 The jarsigner Tool

Signed jar files are managed with jarsigner . jarsigner uses the information in a keystore to look up information about a particular entity and uses that information either to sign or to verify a jar file. As we discussed in Chapter 10, the keystore that jarsigner uses is subject to the KeyStore class that has been installed into the virtual machine; if you have your own keystore implementation, jarsigner will be able to use it. Similarly, if you use the standard keystore implementation but hold the keys in a file other than the default .keystore file, jarsigner will allow you to use that other file as well. A signed jar file is identical to a standard jar file except that a signed jar file contains two additional entries: SIGNER.SF A file containing an SHA message digest for each class file in the archive. The digest is calculated from the three lines in the manifest for the class file. The base of this name SIGNER varies; it is typically based upon the alias of the keystore entry used to sign the archive. 230 SIGNER.DSA A file containing the digital signature of the .SF file. The base of this name matches the first part of the .SF file; the extension is the algorithm used to generate the signature. This file also contains the certificate of the entity that signed the archive. The algorithm used to generate the signature depends upon the type of the key found in the keystore: if the key is an X509 DSA key, a DSA signature will be generated. If the key is an RSA key, an RSA signature will be generated. These entries are held in the META−INF directory of the jar file.

12.2.1.1 Creating a signed jar file

The simplest command to sign a jar file is: piccolo jarsigner xyz.jar sdo This command takes the existing jar file xyz.jar and signs it using the private key of the given alias sdo . The private key is obtained by searching for the given alias from the default keystore HOME.keystore. The signature files in this example will be named SDO.SF and SDO.DSA and will be added to the existing jar file. A jar file can be signed by any number of entities simply by executing this command multiple times with different aliases. Each act of signing the jar file creates a new set of .SF and .DSA or .RSA files in the archive. A number of options can be used in conjunction with this command: −keystore keystore Specify the file that should be used as the keystore. −storepass storepass Specify the global password that should be used to open the keystore. If this value is not provided, you will be prompted for it which, as always, is the more secure way to enter a password. −storetype storetype The algorithm type of the keystore e.g., JCEKS. −keypass password Specify the password for the key entry of the given alias. If this value is not provided, you will be prompted for it. −sigfile file Specify the base name to be used for the .SF and .DSA.RSA files. The default for this value is the alias specified on the command line translated to all uppercase letters e.g., SDO for the example above. If the alias name has more than eight letters, only the first eight letters are used. The file argument in this option can only contain uppercase letters, the digits 0−9, and an underscore; it must contain eight or fewer letters.