TRADITIONAL SOLUTION

and the TTP. Following this, user A decrypts the incoming message, performs checks to verify that it is communicating with the authentic TTP, and sends the token received to B in a separate message, shown in figure as message 3. On the receipt of this separate message, user B can decrypt it using the key that it shares with the TTP and thereby recover the session key. Following this, secure communication between users A and B is possible using the session key. We would like to remark here that, if the TTP has infor- mation that a particular user is compromised or if any of the checks fail then it can refuse to proceed with the key distribution. Similarly, either of the users A or B can also refuse to proceed with the protocol if the checks that they carry out are not satisfied. The approach described here is followed by Kerberos, the widely used symmetric key man- agement system for wireline networks.

Key distribution when dealing with asymmetric keys can also follow a similar approach. The difference, though, is that in this case the public keys of nodes have to be distributed to other nodes while the private keys will have to be kept secret by each node. Since public keys do not need to be hidden, authenticity of the distribution channels is needed while confidentiality is not required at all. This is as opposed to the distribution of symmetric keys, where the distribution channel has to guarantee both authenticity and confidentiality.

The traditional and best known approach to solving the problem of authentic distri- bution of public keys has been in the form of public key certificates. A public key certi- ficate is a statement issued by some trusted party also called the certification authority, which guarantees that the public key indeed belongs to the claimed user. The trusted party (i.e. the CA) then digitally signs this statement. In order to do this, the CA is assumed to have its own public – private key pair. Every node in the system is assumed to know the authentic public key of the CA. This could be done for example by using out-of-band techniques such as direct contact.

In order to sign certificates binding the public key of a node to the identity of the node, the CA might use a procedure that includes verifying the identity of the node and also ver- ifying that the node has the private key corresponding to the public key. Any node that wishes to verify the public key of another node will then just have to request the latter node to provide the certificate signed by the CA. A new node entering the system can contact the CA to obtain such a certificate. A certificate can also be revoked by the CA. The revocation can be based either on timeouts present in the certificate or on explicit revocation lists. Thus we see from this approach that it is necessary that every node in

the network should just be able to obtain the authentic public key of the CA, which makes the problem more manageable. Note that the CA can be considered as an off-line TTP.

Figure 3.3 shows the information in an X.509 certificate, which is a public key certifi- cate scheme widely used today. It consists of several information items. The serial number is used to uniquely identify the certificate. The issuer name is the name of the trusted party that has issued the certificate. The validity period specifies the duration of time for which the certificate is valid. The subject is the entity to whom the certificate is issued and whose public key is being certified. The public key information field contains the public key while the key usage field provides details about the ways in which the key is to be used. This could be either for encryption or for signature. The extension field supports possible extensions. Finally, the last field contains the digital signature of the certificate authority along with any information needed to verify the signature, such as the algorithms used.

It is also clear from this description that a CA is required in order to determine the auth- enticity of the public key of any node, but a single CA cannot be expected to be able to verify the authenticity of the public keys of all the nodes. Hence, several proposals have been made in order to distribute the functions required of a CA. The steps that a CA needs to follow before certifying a public key are also specified in detail. All this together forms what is generally called as the public key infrastructure. We do not go into the details of this concept. A PKI for our purpose is assumed without loss of generality to consist of a group of CAs that can verify the authenticity of the public keys of the nodes in the network.

Several key management protocols based on the use of public keys have been proposed for wireline networks. Examples include IKE [12] and JFK [13]. However these solutions that have been proposed for wireline networks are not always applicable to ad hoc networks. This is due to the differences in the basic characteristics of the wireline and wireless ad hoc networks discussed earlier. Hence, it is necessary to study the solutions proposed for such networks. We look at this in the next section.

Figure 3.3. X.509 certificate format.