Keys, Certificates, and Object Serialization

Chapter 10. Key Management

In this chapter, were going to discuss key management and the facilities in Java that enable key management. The problem of key management turns out to be a hard one to solve: there is no universally accepted approach to key management, and although many features in Java and on the Internet are available to assist with key management, all key management techniques remain very much works in progress. Keys are important because they allow us to perform a number of cryptographic operations, from digital signatures to encrypted data streams. Well discuss the details of these algorithms in the next few chapters. For now, its enough to know that you must provide some sort of key or certificate for many of these algorithms: sometimes you need a private key, sometimes you need a secret key, and sometimes you need a public key contained within a certificate. The purpose of a key management system is to store such keys and allow you to retrieve them programatically or through certain tools. A key management system may encompass other operations it may, for example, provide information about the degree to which a particular individual should be trusted, but it exists primarily to serve up keys and certificates. In this chapter, well discuss Javas key management system, which is built around the notion of a keystore. Keystores are created and manipulated though an administrative tool keytool , and there is a Java API that allows you to use keystores programatically. Well start this chapter by looking at keytool , which will allow us to become familiar with the concepts embodied by a keystore. Then well see how you can use the keystore programatically. Because Suns implementation of the keystore is not necessarily suitable for all facilities in particular, it is not the best system for enterprise−wide key management, well then look at the facilities available to build your own key management system. Finally, well conclude with other techniques to manage secret keys since secret keys are often managed outside of a traditional keystore.

10.1 Key Management Terms

There are a number of terms that are important in our discussion of Javas key management facilities: keystore The keystore is the file that actually holds the set of keys and certificates. By convention, this file is called .keystore and is held in the users home directory HOME on Unix systems, C:\WINDOWS on Microsoft Windows systems, and so on. However, there is great flexibility about where this file is located: the key management tools allow you to specify the location of the file, and the key management API allows you to use any arbitrary input stream. In fact, at the end of this chapter well discuss how the set of keys may be held in a persistent store like a centralized database. alias Every key in the keystore belongs to an entity. An alias is a shortened, keystore−specific name for an entity that has a key or certificate in the keystore. I choose to store my public and private key in my local keystore under the alias sdo; if you have a copy of my public key certificate, you may use that alias, or you may use another alias like ScottOaks. The alias used for a particular entity is completely up to the discretion of the individual who first enters that entity into the keystore. DN distinguished name The distinguished name for an entity in the keystore is a subset of its full X.500 name. This is a long string; for example, my DN is: CN=Scott Oaks, OU=JSD, O=Sun Microsystems, L=New York, S=NY, C=US DNs are used by certificate authorities to refer to the entities to whom they supply a certificate. Hence, unlike an alias, the DN for a particular key is the same no matter what keystore it is located in: if I send you my public key, it will have the DN encoded in the public keys certificate. However, nothing prevents me from having two public keys with different DNs I might have one for personal use that omits references to my place of employment. And there is no guarantee that two unrelated individuals will not share the same DN in fact, you can count on this type of namespace collision to occur. The common name CN within a DN is usually the domain name of the organization to which the certificate belongs. In fact, SSL uses this convention to verify the identity of the server to which it connects. Whats in a Name? X509 certificates and many other ANSI standards make use of the idea of a distinguished name usually referred to as a DN. The distinguished name of an individual includes these fields: Common name CN The full common name of the individual. Organizational unit OU The unit the individual is associated with. Organization O The organization the individual is associated with. Location L The city where the individual is located. State S The stateprovince where the individual is located. Country C The country where the individual is located. The DN specification allows other fields as well, although these are the only fields used internally in Java. The organization that is associated with an individual is typically the company the individual works for, but it can be any other organization and of course, you may not be associated with an organization under a variety of circumstances. The idea behind a DN is that it limits name duplication to some extent. There are other people named Scott Oaks in the world, but only one who has a DN of: CN=Scott Oaks, OU=JSD, O=Sun Microsystems, L=NY, S=NY, C=US