Public-Key Cryptography and Diffie-Hellman Certificates

Public-Private Keys

Cryptography takes the original message, and produces an encoded version by using a special piece of information known to the sender and receiver. The original message is called the plaintext, the special information is called the key, and the resulting message is called the ciphertext. Cryptosystems work by taking the digital representation of the plaintext and manipulating it mathematically under the control of the digital key to produce the ciphertext.

Public-key cryptography was invented by Whitfield Diffie and Martin Hellman. It takes a message encrypted in one shared secret and decrypts it in another. The keys are mathematically related in such a way that a knowledge of one key does not make it possible to figure out the other key. This permits the one key, the public key, to be made widely known, while the corresponding private key is known only to a single user. The two keys together are called a key pair.

The Diffie-Hellman key produces shared secret keys directly from private and public components that are not in themselves keys. The advantage of a public-key system is that the secret components do not have to be shared to exchange information securely. The private portion is never given out to anyone, and it cannot feasibly be calculated from the public portion.

Certificates

To know that the key pair being used in the transaction is actually the key pair for that user, a special sort of signed record is used called a certificate. A certificate contains information identifying the user: distinguished name, public key, and expiration date; for example, digitally signed by a trusted network entity called a certification authority (CA).

Certification Authority

The CA's public key is known to every user of the network. This permits anyone wishing to authenticate a certificate to follow the same procedure for authenticating a message. The CA's public key is available in certificate format so that it, too, can be verified. The major commercial application for CAs is to authenticate businesses and the employees of those businesses. SunCA and SunCAglobal are Sun Microsystems' certification authority in the Internet Commerce Group (ICG).

Unsigned Diffie-Hellman (UDH) Keys

Unsigned Diffie-Hellman (UDH) keys derive their certificate name from the hash of the public key. By communicating the hash over the telephone or some other trusted method of communication with another party, user's can securely communicate without requiring the infrastructure of a CA. How their certificate name is derived and how this is placed in the SKIP packet are shown in Figure B-4.

Figure B-4 Unsigned Diffie-Hellman Keys

The advantages of UDH pairs of public and private keys over signed certificates are as follows:

• The private key is a 256-bit secret that is generated by the user. This secret never leaves the user's machine so there is no longer any need to keep the floppy diskettes containing the certificate locked up somewhere nor to trust that the packages have not been tampered with. All that is necessary is to trust that the user's machine is kept secure.

• Since the private key is always in the user's machine, the physical handling of the key is eliminated so there is no need for a CA and no need to package and ship the private keys.

• Since a key cannot be duplicated and is not registered by a CA, it does not need to be formally revoked; if there is reason to believe a key has been compromised, just generate a new key and repeat the distribution and authentication of your public value and its ID.

• The authentication of the public keys is simplified because it does not have to be done secretly, merely securely.

An example of this last point might be as follows: Two users call each other on the telephone and exchange public keys using the recognition of each other's voice as the authentication mechanism. Because these are hashes of public keys, it does not matter if anyone overhears the conversation.

The disadvantage of UDH keys is that the names must be communicated out of band, such as over the telephone by PGP.

SKIP must be able to name or identify a given key. It does this by using a name or identifier drawn from a namespace identifier (NSID). It also must be able to figure out which certificate name to use when communicating with a remote system. This information can be derived from its IP address or explicitly stated in the protocol via NSID/key ID.

If NSID is set to 0, the IP address is used for key lookup. By default, the NSID is set at 0 and a key ID is not sent; however, with the key ID feature activated, key names are no longer tied to IP addresses. This means that regardless of their physical location on the network or on the Internet, various people have the ability to communicate with each other and corporate using encryption.

The Namespace Identifiers (NSID)

SunScreen SKIP provides users with the ability to separate the identity of an entity from its physical address. This means that each person (sender or receiver) participating in a transfer of encrypted data over a computer network can be identified by a namespace identifier/key identifier (NSID/key ID) pair.

NSIDs are a part of SKIP; these identifiers are used to identify the keys being used. The NSIDs supported by SunScreen SKIP are

• NSID 0 (No Key ID present, figure out which key to use from the IP address)

• NSID 1 (IPv4 address key ID, for hosts whose key IDs do not match their IP address, such as hosts that use signed SunCA keys)

• NSID 8 (MD5 hash of Diffie-Hellman Public Value Key ID present, for UDH keys that are not signed by any CA)

The first two are nearly identical in that they both use signed X.509 keys, with one very important difference. SKIP packets that use NSID 1 include the key ID in the packet. SKIP packets that use NSID 0 figure out which key to use.

With SunCA keys, for example, it is necessary to put the key identifier into the SKIP header because the IP address may not correspond to the identifier in the certificate. If there is a SunCA key identifier of "0a000101" for a certificate, it becomes "10.0.1.1" in IP address terminology.

Further, if your IP address is "192.12.10.49," then you would have to include your key identifier in the SKIP header because it does not equal your IP address. But with NSID 0, which also uses X.509 certificates, it is guaranteed that the key identifier is the IP address; therefore, the key identifier does not have to be sent.

Using NSID 0 results in a small gain in efficiency by not having to send the key identifier. This is what is meant by "No Key ID present" in the NSID 0 bullet above. This approach reduces the amount of packet expansion because of SKIP.

Traffic Encryption

Traffic is encrypted using conventional symmetric key cryptography, such as RC2, RC4, DES, and the like. The user installs SunScreen SKIP, which has the algorithm packages that are required. Traffic encryption keys are changed based on the volume of data and the length of time a key is used.

There is a tool with a GUI to control how often you want the traffic encryption keys changed. As shipped, the default is to change traffic keys after every 512K bytes of data or after being used for 30 seconds; traffic keys are deleted after being unused for 30 seconds. You can change these values to meet the security needs of your site. This tool is discussed in detail in Chapter 3.

It is important to change the traffic encryption keys frequently enough so that cracking a key will leave little data, and yet not so frequently so that reconfiguring the keys incurs excessive overhead.