TrustManager

The TrustManager manages the truststores . The default TrustManager assumes the public certificates are held in $JREHOME/lib/security/jssecacerts . If that file doesn't exist, it assumes they are held in $JREHOME/lib/security/cacerts . These properties can be set in javax.net.ssl. trustStore . The KeyTool class manages the truststore , just like the keystore, and even further inherits the KeyStore class.

TrustManagers are initialized from the TrustManagerFactory . The com.sun.net.ssl.TrustManagerFactory has the same characteristics as the KeyManagerFactory . Just like the KeyManagerFactory , the TrustManagerFactory contains a static getDefaultAlgorithm( ) method that returns the sun.ssl.trustmanager.type property defined in the $JREHOME/lib/security/java.security file. The TrustManagerFactory generates the instances of the TrustManager .

Keytool

The keytool utility distributed with the JDK 1.4 provides the capability to manage a keystore . A keystore is a container for two types of entries: the key entry and the trusted certificate entry. The key entry has a private and a public key. The private key is used with the corresponding public key from the certificate entry. The private key and the public key that it is related to make up a key pair. The trusted certificate entry is a certificate associated with a principal trusted to the organization to be used to decrypt and verify information from that specific principal. The certificates are used for ensuring integrity in their digital signatures, their public key for decrypting information, and their private key for encrypting data.

The keytool is an implementation of the Java KeyStore API designed for the management of key entries . A key entry consists of a private key and an X.509 certificate chain that authenticates the associated public key. The keytool does not provide support for secret keys but only for the certificates and key pairs. A trusted certificate entry is a certificate that authenticates the public key of another party.

The keytool offers a management of private and public keys in a secure format, which is X.509, and is encrypted also using X.509. Therefore, access to the X.509 certificate is limited to the individuals who can decrypt the public key, and the public key can be a password. The X.509 certificates are stored in an X.500 tree structure, which is similar to LDAP.

Tip	The keytool can differentiate between trusted certificates and untrusted certificates.

If a certificate is trusted, it is assumed that the organization has authenticated the certificate; a trusted certificate can be used to establish other certificates that can also be trusted. A user could be part of a certificate so a user can also be authenticated in this manner. An organization's local private keys can also be stored in the keystore and managed by the keytool . This can be summarized by stating that the keytool has the following capabilities:

Key pair generation
Certificate generation
Certificate signing request generation
Management of key entries
Management of trusted certificate entries
Management of passwords
Authenticating the X.509 certificate chains to the corresponding public keys

The keytool is a management utility to accompany this functionality. It provides the ability to manage keypairs and certificates. The keystore that is implemented by the keytool is using the keystore as a file.

The keytool loads and stores the keys that are specified in the keystore . The keytool defaults to the file named .keystore in the user's home directory. Otherwise, the -keystore parameter can be use to specify the location of the keystore 's file location. The keystore file is created whenever a key is generated or the -identitydb command is used to read the identity of the database.

The keystore uses aliases to associate the principals to the store. The aliases are not case sensitive, so rich and Rich are the same entry. The entry is specified when a key is generated with the -genkey command to generate a key pair (a public and private key) with a self-signed certificate or the -import command to import a trusted certificate. A self-signed certificate is when the certificate chain starts out with a single identity of the issuer and the subject being the same.

This is accomplished with the following command:

 keytool -genkey -alias rich -keypass password

This command generates a public and private key for the principal rich and assigns the password password for the principal rich to use when accessing the private key (after a few questions are answered to develop the fields for the X.500 specification to fill the matching X.509 certificate). When not specifying the password with the command line, the user that is generating the key is prompted for the password at the command line. If the verification password does not match the initial password, an exception is thrown, as shown in the following code snippet:

 D:\Working\SecurityBook\code>keytool -genkey -alias rich -keypass password Enter keystore password:  test keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

The questions that are asked when entering a matching password are needed for filling the X.500 specification. These entries are stored in the X.509 digital certificate for information in self-signing the certificate. The information is needed to fill both the identification of the issuer and the signer. The fields appear as the following:

Common Name ( CN ): The common name of the issuer that consists of the first and last name of the alias.
Organization Unit ( OU ): The small organization, or the department of an organization such as "Marketing."
Organization Name ( O ): The organization or company name.
Locality ( L ): The city name.
State ( S ): The state name.
Country ( C ): The country name.

The X.500 specification uses these fields for storing the directory structure, which is also used in LDAP. X.509 stores these fields on the certificate for certificate storage wherever the certificate will travel. These fields are discussed throughout various chapters of the book. The keytool utility inquires about these fields in the interaction in Listing 8-1.

Listing 8-1: Interaction with keytool

 D:\Working\SecurityBook\code>keytool -genkey -alias richh -keypass password Enter keystore password:  password What is your first and last name?   [Unknown]:  Rich Helton What is the name of your organizational unit?   [Unknown]:  development What is the name of your organization?   [Unknown]:  richware What is the name of your City or Locality?   [Unknown]:  denver What is the name of your State or Province?   [Unknown]:  co What is the two-letter country code for this unit?   [Unknown]:  us Is CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us correct?   [no]:  yes

To ensure that the entry was entered, the keytool -list command is used to print the keystore entries and to show how the key was stored, as shown in Listing 8-2.

Listing 8-2: Output of keytool -list

 D:\Working\SecurityBook\code>keytool -list Enter keystore password:  password     Keystore type: jks Keystore provider: SUN     Your keystore contains 1 entry     richh, Nov 23, 2001, keyEntry, Certificate fingerprint (MD5): 87:88:11:84:31:20:54:04:8F:CB:EE:C9:5D:5C:F0:B8

Certificates can be stored in either a binary format or a printable encoded format that is specified in the RFC 1421. RFC 1421 defines the Privacy Enhancement for Electronic Mail. This format is normally seen at the bottom of e- mails for digital certificate exchanges and is parsed out for authentication by applications that support Privacy Enhanced Mail (PEM), and other mail protocols such as Pretty Good Privacy (PGP). The keytool exports the program to a certificate file using the -export parameter and in the RFC 1421 format by using the -rfc command:

 D:\Working\SecurityBook\code>keytool -export -rfc -alias richh -file richcert.cer Enter keystore password:  password Certificate stored in file <richcert.cer>

The keytool utility always prompts the user for a password every time that it accesses a particular key to authenticate access to the key. The certificate that is generated with RFC 1421 looks like Listing 8-3.

Listing 8-3: RFC 1421-generated certificate

The digital signature in Listing 8-3 is not very human readable. It is used to give to other users for authentication, validation, and to retrieve the public key to decrypt messages that can be sent in mail, data to be exchanged through SSL, or by many other applications. The digital certificate can be displayed through the keytool by using the -printcert parameter as shown in Listing 8-4.

Listing 8-4: Output of keytool -printcert

 D:\Working\SecurityBook\code>keytool -printcert -file richcert.cer Owner: CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us Issuer: CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us Serial number: 3bfe9c13 Valid from: Fri Nov 23 11:57:23 MST 2001 until: Thu Feb 21 11:57:23 MST 2002 Certificate fingerprints:          MD5:  87:88:11:84:31:20:54:04:8F:CB:EE:C9:5D:5C:F0:B8          SHA1: B7:85:C5:C6:8E:DB:C6:88:47:BE:9E:2A:C7:A9:5E:23:6D:7F:4A:E5

The keytool is a utility implemented with the KeyStore class. It has some of the same properties as the KeyStore class, such as using the JKS key store type by default and being able to be extended. To extend the keytool, you extend the keystore utility; this is done by extending the KeyStoreSPI . The JDK 1.4 comes with the JKS implementation for the keystore type, but if another keystore type is desired and retrieved, it can be specified in the implementation supported in the {$JREHOME}/lib/security/java.security file by setting the keystore property as follows :

 # # Default keystore type. # keystore.type=jks

This entry specifies the keystore type to use from the jarsigner and keytool utilities unless they explicitly use a different one in their command-line parameter. The keystore.type entry is retrieved by the following function:

 KeyStore keyStore  = KeyStore.getInstance(KeyStore.getDefaultType ( ) );

The getDefaultType( ) function returns the keystore type defined in the java.security file. This function initializes the keytool . The keytool is a utility that extends the KeyStore class.

The keytool has the capability to generate the key and certificate entry. To accomplish this task, the keystore must be able to support multiple keying and encryption algorithms in order to be useful. By default, the keytool supports the DSA algorithm for the private key. When it uses DSA, the message digest will be SHA-1, and the public key will be stored in DSA. Another key algorithm that can be used is RSA, and the message digest will be MD5. The key sizes are by default 1024 bits, but it can support anywhere from 512 bits to 1024 bits at increments of 64 bits. Each algorithm, either the RSA or DSA, can be applied to both the key pair algorithm or the self-signed certificate. The key pair algorithm is defined with the -keyalg parameter, and the self-signed algorithm is defined with the -sigalg parameter.

The keytool is a rudimentary tool to store Java keys and to extract them from a file. It has the capability to use a lot of functionality through the policy files and command line. However, that might not be enough for some organizations that want to put everything in an LDAP system instead of using files. The keytool makes use of standard classes of the JDK 1.4 such as KeyStore , X509Certificate , and X500Name classes. In fact, when it generates a key pair, it performs a setKeyEntry method, passing in the X509Certificate array, the alias, the password, and the key of the alias. The java.security.KeyStore class demonstrates the setKeyEntry method.

Caution

There are many undocumented classes that make up the sun.security.tools.KeyTool class to store certificates. One of the classes is the sun.security.X509.X500Name class.

The X500Name is set based on the fields passed in for CN , OU , O , L , S , and C . The X509Certificate is generated from the X500Name . The private key is generated and encrypted with the algorithm that is specified for the private key. These entries are set in the KeyStore 's setKeyEntry function along with a password to protect the entry in the KeyStore . The KeyStore supports loading and unloading of these entries, which are password protected for file access. To extend these entries without changing the keytool , a new implementation (instead of JKS ) needs to be implemented with the KeyStoreSpi implementation and specified as the keystore type. To support an LDAP implementation, the X500Name already gives the directory naming structure variables ; the LDAP extensions have to be implemented in the KeyStoreSpi and specified.

This type of implementation enables the developer to ignore a lot of the functionality of the keytool when extending it and to only focus on changing the SPI layer. The SPI layer redirects the actual store of the keys into any extension, such as LDAP, desired for the organization. The SPI extension gives the developers a lot of possibilities for extending interfaces without breaking the other interfaces or changing their behavior. Using the SPI to extend the functionality decouples the new implementation and its functionality from the rest of the interfaces that work together in the keytool . One popular extension that has been accomplished this way is the PKCS #12 implementation. The keytool can easily be extended for internal use in an organization.

Also, the keytool can be extended to design new security systems for an organization to implement, and this new implementation would not be made public to attackers. To help block attacks, an organization may use internal systems, which attackers have no knowledge of. These internal systems still support protocols to other organizations and customers. The keytool is a blueprint to store keys using the JDK 1.4. Organizations can extend this to further protect the access and management of keys. The keytool provides enough functionality out of the box to secure, generate, store, load, and manage keys.

Tip	Security beyond the standard protocols can be implemented by using the SPI extensions designed for extending the functionality of the key management system.

Jarsigner

The jarsigner tool uses the keystore information to generate and verify digital signatures for Java Archive (JAR) files. When the JAR has been signed with a private key, the jarsigner tool verifies the digital signature block of the JAR. The jarsigner extracts the public key from the keystore . Then the digital signature is recomputed from the data using the principal's public key. This will allow the jarsigner to detect any modifications.

The concept comes from signing a contract. In a contract, two things are usually needed: the identity of the principal (a key) and the contract itself (the JAR). To read the JAR, the private key doesn't need to be used, but a public key, which is distributed by the principal, does. This is similar to a person giving someone else permission to read the document. One of the limitations of paper contracts is that they can be tampered with without knowledge of the person who signs. Unlike a contract, the integrity of each byte in the data can be rehashed, checked, and compared with the previous hash to ensure that no values are different. If any of the data has changed, it will produce a different hash result.

Note	The public key cannot be forged because it requires the private key to be generated.

In order for a digital signature to be generated, a public and private key must be associated with the principal. A principal can be a user, group , or system. The jarsigner uses key and certificate information from the keystore to generate the digital signatures. The keystore may contain the key pair or the X.509 certificate. The X.509 certificate contains the public key to check the digital signature. The following steps are used for signing a JAR file:

Create the key pair using the keytool utility.
Use the keytool to export the public key into a file for others to access.
Create a JAR file with the jar utility for classes and resources to be distributed to others.
Sign the JAR file using the jarsigner and the private key created with the key pair.

The keytool has been described in developing a keystore . If multiple keystores are stored in the organization, the -keystore parameter can be used to stipulate the specific store by specifying its URL location. Using the default store from the previous examples, Listing 8-5 can be used to sign the JAR Java2.jar .

Listing 8-5: Signing the Java2.jar

 D:\Working\SecurityBook\code>jarsigner -storepass password -verbose Java2.jar richh  updating: META-INF/MANIFEST.MF    adding: META-INF/RICHH.SF    adding: META-INF/RICHH.DSA    adding: scjd/   signing: scjd/instructions.html    adding: scjd/starting/    adding: scjd/starting/suncertify/    adding: scjd/starting/suncertify/db/   signing: scjd/starting/suncertify/db/Data.java   signing: scjd/starting/suncertify/db/DataInfo.java   signing: scjd/starting/suncertify/db/DatabaseException.java   signing: scjd/starting/suncertify/db/FieldInfo.java   signing: scjd/starting/suncertify/db/Data.class   signing: scjd/starting/suncertify/db/DataInfo.class   signing: scjd/starting/suncertify/db/DatabaseException.class   signing: scjd/starting/suncertify/db/FieldInfo.class   signing: scjd/starting/suncertify/db/db.db

In Listing 8-5, the alias richh was used from the keystore using the alias's password password with the - storepass command.

After the jarsigner has signed the JAR file, there will be two new files in the JAR for each alias. One file is the .SF file, or Signature File, which will have a set of signatures associated with each file in the JAR file. Each entry will contain the file name that it signed, the signature type (SHA-1 Digest in this example), and the digest value itself as shown in Listing 8-6.

Listing 8-6: Signature File example

 Signature-Version: 1.0 Created-By: 1.4.0 (Sun Microsystems Inc.) SHA1-Digest-Manifest: dfbEUpMl7mh66sLA/UFf0NZJ7E8=     Name: scjd/instructions.html SHA1-Digest: XOeMFEQYda2AGXO/YKHzNMK/XGo=

The other file that is created by default is the .DSA file. DSA is the algorithm that the alias used to create the private key in the keystore . The .DSA file is the signature block that contains the certificate, or certificate chain, that is used to authenticate the public key. The signing was used with the corresponding private key from the alias. To verify that JAR has been signed correctly and to view the certifications, the -certs and -verify commands are used, as shown in Listing 8-7.

Cross-Reference

See Chapter 11 for a discussion on the Digital Signature Algorithm (DSA).

Listing 8-7: DSA file example

 D:\Working\SecurityBook\code>jarsigner -certs -verify -verbose Java2.jar              997 Sat Nov 24 01:15:30 MST 2001 META-INF/MANIFEST.MF         1056 Sat Nov 24 01:15:36 MST 2001 META-INF/RICHH.SF         1033 Sat Nov 24 01:15:36 MST 2001 META-INF/RICHH.DSA            0 Fri Aug 04 13:38:14 MDT 2000 META-INF/            0 Thu Aug 03 10:58:02 MDT 2000 scjd/ smk    22680 Fri Aug 04 13:36:52 MDT 2000 scjd/instructions.html       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh)            0 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/            0 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/            0 Fri Aug 04 08:53:58 MDT 2000 scjd/starting/suncertify/db/ smk    12482 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/db/Data.java           X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh) smk     3232 Thu Aug 03 10:57:56 MDT 2000 cjd/starting/suncertify/db/DataInfo.java       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh) smk    188 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/db/DatabaseException.java       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh) smk      933 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/db/FieldInfo.java       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh)  smk     5352 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/db/Data.class           X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh) smk     1565 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/db/DataInfo.class       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh)  smk      307 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/db/DatabaseException.class       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh) smk      541 Thu Aug 03 10:57:56 MDT 2000 scjd/starting/suncertify/db/FieldInfo.class       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh) smk     1646 Fri Aug 04 08:53:58 MDT 2000 scjd/starting/suncertify/db/db.db       X.509, CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us (richh)       s = signature was verified   m = entry is listed in manifest   k = at least one certificate was found in keystore   i = at least one certificate was found in identity scope     jar verified.

The jarsigner utility is useful for signing JAR files. It will ensure the integrity of the files that the JAR contains and stores. It provides the functionality to access keystores in case the application requires an authentication with the public key.

Note	The jarsigner signs JARs from the specified keystore using trusted certificates. When a JAR file is received, one cannot verify the certificate unless the proper keystore is present. In addition, one cannot resign the JAR file unless one has access to the keystore .

The command to create a jar file is: jar {ctxu}[vfm0M] [jar-file] [manifest-file] [-C dir] files ... much as in the following code example.

 jar cvf myjar.jar MyClass.class examples\MyOtherClass.class

This creates the myjar.jar file that make up the payload of the JAR packed into a copy of the original structure, and the directory META-INF with a MANIFEST.MF file. The manifest file ( MANIFEST.MF ) is created - by default - in the META-INF directory as per Sun specifications. The manifest file has details of the payload for the JAR, and there can be only one manifest in the JAR. The manifest file uses the RFC 822 ASCII format.

Caution

Although you can manually edit the manifest, you must take great care to follow the syntax. A customized manifest can be added to the JAR file with the m or M option in the command line for the jar command.

As mentioned earlier, the JAR file can be signed. The signature file is also added to the META-INF directory (an example of a signature file is shown in Listing 8-6) and the digests (of the signature file) are created from the manifest file (and not from the payload). The signature file is in ASCII format. The signature block files are automatically created every time the JAR is signed. These signature block files are binary files and typically have a .DSA extension (since the DSA algorithm is usually used).

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Project Management JumpStart

Image Processing with LabVIEW and IMAQ Vision

Cisco IOS in a Nutshell (In a Nutshell (OReilly))

Postfix: The Definitive Guide

Pocket Guide to the National Electrical Code(R), 2005 Edition (8th Edition)

VBScript in a Nutshell, 2nd Edition