In SSL, a private key is used for encryption and public keys are used for decryption. Public keys and signatures are stored in certificates, so there must be a place in the organization to store these keys and certificates. The place to store keys is the keystore; a key store can be a flat file, a database, or an LDAP server that can store key material. With the capability to change the keystore type to a different provider, it is possible to implement different types of key stores.
| Cross-Reference | See Chapter 22 for more information about SSL. |
To understand how keys are stored, you must understand how the KeyManager works. A KeyManager manages these key materials, and the KeyManagerFactory manages the KeyManager instance. A TrustManager, in turn , makes decisions about who to trust based on trusted material in the truststore . The truststore is part of the decision mechanism in that it contains trusted key material. If the certificate lives in that area, it is trusted. The keystore can contain several types of key material, such as the keypair used to decrypt and encrypt the messages and DSA and RSA key material.
| Cross-Reference | To further understand how these classes work together, see the examples in Chapter 23. |
Each piece of key material is known as a key entry or a trusted certificate entry . The key entry is a public and private key pair. The trusted certificate entry can hold a set of trusted certificates when moved to a trusted store. When storing a key, there is a relationship between a key entry and a subject; this is normally called an alias . An example of an alias is rich , if the user rich has a key entry. These aliases are created with the key during its generation or import.
| Tip | To retrieve the key, you can look up the alias and get the corresponding key entry to that specific identity. |
The KeyStore class is the interface that implements the provider's key store. One implementation shipped with the JDK 1.4 from the Sun provider is the Java KeyStore type called JKS , for JavaKeyStore . The KeyStore is an engine class and will find the provider using the Security class like the other engine classes. It will find an entry similar to the following:
put("KeyStore.JKS", "sun.security.provider.JavaKeyStore"); This will provide an overwritten implementation of the JavaKeyStore class in the sun.security.provider package when the following code is executed:
ks = KeyStore.getInstance("JKS"); This code example walks down the provider chain and maps the JKS algorithm for the key store to the JavaKeyStore implementation. This is the key store that is used by default and is also specified in the java.security file to be the default key store type, as in the following line:
keystore.type=jks
To understand how keys are stored, first examine the implementation of the KeyStore class. Some of the functions in the KeyStore class are as follows :
-
KeyStore ( KeyStoreSpi keyStoreSpi, Provider provider, String type) : This is the KeyStore that takes in the provider's implementation, the provider itself, and the string type. This creates an instance of the of the KeyStore and is managed by the getInstance( ) function when a KeyStore is loaded through a store. The default store is file based , but could be expanded to use a database or LDAP just as the ACL. An example of a provider is Sun and a type is JKS; the default for the getInstance( ) method is JavaKeyStore (JKS) . This is set by the keytool in the keystore.type field of the java.security configuration file. JKS is exportable and does not contain a strong encryption. The KeyManagerFactory typically initializes the KeyStore instance.
-
The getInstance static functions get the instance of the KeyStore from a string, a string and Provider object, or a string of the type and provider. An example of getting a instance from the provider is KeyStore ks = KeyStore.getInstance("JKS"); . An example from the string type and string provider is KeyStore ks = KeyStore.getInstance("JKS", "SUN"); . To access the instance, the class must first be loaded. The getProvider( ) function can subsequently return the Provider class after the instance is received. There are three getInstance functions:
-
public static KeyStore getInstance ( String type)
-
public static KeyStore getInstance ( String type, Provider provider)
-
public static KeyStore getInstance ( String type, String provider )
-
There are four functions that support the key entry. The string alias is used to name the entry, such as customer . It is very common to relate these aliases to principals. The password is used to password-protect the keys or certificates. If JKS is used to store the key, the format follows the PKCS #8 standard. These functions are used to store the KeyPair . The private key is passed in as an array of bytes. The public key is contained in the certificate. To check the aliases that are available, the aliases( ) function returns an enumeration of the available names . The deleteEntry deletes the key entry based on the name of the entry. The four functions are as follows:
-
public void setKeyEntry ( String alias, byte [ ] key, Certificate [ ] chain)
-
public void setKeyEntry ( String alias, byte [ ] key, char [ ] password, Certificate [ ] chain)
-
public Key getKey ( String alias, char[] password)
-
public void deleteEntry ( String alias)
| Tip | If the protected key is of type java.security.PrivateKey , it must be accompanied by a certificate chain certifying the corresponding public key. If the underlying keystore implementation is of type jks , key must be encoded as an EncryptedPrivateKeyInfo as defined in the PKCS #8 standard. |
-
There are five functions that support the Trusted Certificate Entry. The deleteEntry is also used to delete the Certificate based on its name. The setCertificateEntry passes in the Trusted Certificate Entry and its associated name. The isCertificateEntry( ) function is used to see if the Trusted Certificate Entry is in the Trusted store based on the Certificate's associated name. The getter functions can return the name, Certificate, or Certificate chain of both the Trusted Certificate Entry and the KeyEntry of the entire Certificate chain, from the current Certificate to the root Certificate that contains the chain of public keys. These functions are as follows:
-
public Certificate getCertificate ( String alias)
-
public String getCertificateAlias ( Certificate cert)
-
public Certificate [ ] getCertificateChain ( String alias)
-
public boolean isCertificateEntry ( String alias)
-
public void setCertificateEntry ( String alias, Certificate cert)
-
In order to use any of the KeyStore , it must be loaded into memory as a storage device. By default, the functionality of File IO can be used to store and load the KeyStore from disk. The files are password protected to ensure some protection. However, these functions can be extended into an X.500 LDAP or database storage to improve security of the storage. There are two functions that provide this functionality:
-
public void load ( InputStream stream, char [ ] password)
-
public void store ( OutputStream stream, char [ ] password)
| Note | The KeyManagerFactory typically initializes the KeyStore so that the static getInstance( ) function is called to retrieve the KeyStore . By default, the KeyManagerFactory initializes everything to the SUNX509 provider type. This initializes the KeyManager , KeyManagerFactory , and JavaKeyStore to follow Sun's implementation for the X.509 protocol until something else is specified during one of the objects' startup. |
The JavaKeyStore normally stores the keys in a flat file, which contains signatures for validity and is password protected. Loading the key store into memory requires that a password be authenticated through the KeyStore API. While the key store is loaded into memory, trusted applications can have access to it for gathering key information to other agents . Different implementations could change some of the operation of the key store, however extensibility is part of the API and the purpose of providing an SPI.
Although the JKS implementation comes out of the box from Sun Microsystems, there is nothing prohibiting the organization from increasing the protection of its resources for its own use. By using the signature and password to protect the keys, the key store exhibits the patterns of data integrity and data confidentiality. Keeping keys secure is crucial to the mechanics of security.
