N. Meghanathan et al. (Eds.): CCSIT 2011, Part I, CCIS 131, pp. 158–167, 2011.
© Springer-Verlag Berlin Heidelberg 2011
Certificate Path Verification in Peer-to-Peer Public Key
Certificate Path Verification in Peer-to-Peer PKI by Constructing DFS Spanning Tree 159 path which is constructed in previous step. The two steps in certificate validation are described in detail below:
1) Path Construction- Path Construction is a process which consists of creating or building one or more candidate certificate path. As in [1], the term candi- date is used to indicate that even though the certificates are chained together a possibility that the path itself may not be validated due to different reasons as path length, name etc.
2) Path Validation- Path Validation is the process in which each certificate in the path is within its established validity period, has not been revoked, has integrity etc. and all the constraints levied on path or all of the certification paths are honored.
A public key infrastructure serves many purposes like enabling the entities to verify public key bindings, binding public keys to the entities and providing a number of services for the management of keys in a distributed system. The protection and dis- tribution of information is one of the main goals of the security architecture which is a must in widely distributed environments, where the users, resources etc. can do their business together even if they are in different places at the same time.
One of the main advantages of using PKI is that it allows to address the security needs and the user will be able to make use of the scalable and distributed characteris- tics. It also allows the user to be in their e-business with a confidence that the integrity of data has not been compromised and the identity of the receiver and the sender are real [2].
Let us consider a basic scenario where two users staying in different places wish to start a business transaction. Here it might not be necessary that these two users have actually met in person. Since these two users have to achieve security goals, they de- cide to use public key cryptography. Then they must obtain the public keys of the other user and should be able to authenticate each other. This is usually performed through a trusted third party.
The work of the trusted third party is the distribution of the public keys and authen- tication. The public key infrastructure consists of a number of different software, en- cryption technologies, and services, whose main goal is the protection of the security of the user’s communication and business transactions. Every user and server in a PKI system will possess a digital certificate, an end-user in enrolment software etc. The PKI is based on public key cryptography and even the name is derived from the same, which is the major technology behind digital signature techniques.
1.1 PKI Components
PKI consists of number of components like certification authorities, registration au- thorities, repositories and archives. The uses of the PKI can be divided into different categories such as certificate holders and relying parties. Sometimes there can be an optional component called an attribute authority.
• Certification authority (CA): The job of a CA is the identification of the us- ers who are sending and receiving electronic payments, or having communi- cation etc. We can say that authentication is a must in case of a formal communication which includes any kind of cash transaction, like a pin
160 Balachandra, A. Rao, and K.V. Prema
number in an ATM. This is one of the basic building blocks of the PKI. A number of computer hardware, software and the operators will together form the CA. There are two attributes for a CA [3]; one is its name and the other, public key. The PKI functions of the CA are as given below. It starts with the issue of the certificate, preceded by maintenance of the status in- formation and issues CRLs followed by publishing of the current certificates and CRL’s and finally the maintenance of the archives of the status informa- tion about the expired certificates. Sometimes the CA may have to distribute these functions to the other components of the infrastructure in order to ac- complish the four steps simultaneously.
• Registration authority (RA): Once authentication is done by a CA it will ask the RA to register or vouch for the identity of users to a CA. The certificate contents are made in such a way that it will reflect the information presented by the requesting entity and sometimes they also reflect third party informa- tion. CA and RA are similar in a way that both contain computer hardware, software and an operator. But a small difference we can say that CA will be mostly operated by multi-user where as RA will be often operated by a sin- gle user. Each CA contains a list of its trustworthy RAs. CA identifies RA by a name and a public key. RAs signature on a message means that a CA which has a trustworthy relation with that RA can trust the message. So the RA should be providing an adequate protection for its own private key.
• PKI Repository: It is a database for a CA where the digital certificates have been stored. When the users want to confirm the status of the digital certifi- cate for any of the other reason they will contact the repository and the re- pository will in turn produces digitally signed messages and will send back to the user.
• Archive: Archive is a database which will be used with PKI for long term storage of archival information on behalf of CA. It is responsible for giving assurance that the information received was in a good condition and it has not been modified while it was in the archive. CA provides all the informa- tion necessary for archive to determine that the certificate is original that is issued by the same CA specified in the certificate and it is valid.
A user doesn’t issue certificate, instead they rely on the other components of the PKI to obtain the certificates. A user can be a group or an individual who make use of the PKI. Even for the verification of the certificates user has to depend on the other com- ponents of the PKI. A user, whether it be an individual or a group they hold certifi- cates for various applications.
1.2 PKI Models
There are many types of PKI architectures. Few popular models are described below:
1. Hierarchical Model: Hierarchical model uses the basic tree structure. There will be a CA which controls and provides information to all the other CA’s, which is called a Root. In this model the root CA is called a “trust anchor”
[4]. Here the root CA can have one or more children CAs and each child will be having their own children CAs. But the leaf node will be the user which
Certificate Path Verification in Peer-to-Peer PKI by Constructing DFS Spanning Tree 161 requests the certificate from the CAs. The certification path is as follows: the root issues certificate to its children and each CAs in the level one issues cer- tificate to other CAs or users in the next level. Advantages of this hierarchi- cal PKI model are, it is scalable and Certificate path construction is simple.
2. Mesh PKI: It is a peer to peer PKI model and it is also called web of trust.
Here each subscriber trusts the CA that issued their certificates. They use a special type of certificate which contains the information about the security policy transformation, which is involved in moving from one domain of trust to another. Since there are a multiple paths between the users, it is more complex to construct a certificate path. One advantage is that the compro- mise of a single CA cannot bring down the entire PKI.
3. Bridge PKI: This is a different approach for the interconnection of the PKIs.
Here they use a special authority called Bridge Certificate Authority (BCA).
This model is used in order to reduce the number of the cross certification paths found in the mesh model. In this, there will be a central cross certifica- tion authority which will be connected to all the other CA’s.
4. Hybrid PKI: As its name implies the hybrid PKI is interconnection of differ- ent PKIs through cross certification. There are three types of cross certifica- tions distinguished by an ISO Hybrid Model. The first one is hierarchical cross certificate [5] which parallels the paths of the subordinated hierarchies but extend upward towards the root CA’s. Another one is general cross- certificate [5] which interconnects the CAs either at the root level or between the points within the connected hierarchies. The last one is the special cross certificate[5] which is intended to allow selective establishment of certifica- tion paths that may not conform to the restrictions ordinarily imposed hierar- chically along the path from the root CA’s.
5. Trust Model Based Gateway CA’s: The certification to different kinds of CAs which is located in different places can be provided by only a gateway CA. Each of the GWCA’s has their own trust regions. All the GWCA’s are connected in a ring fashion. When the GWCA is connected in a ring configu- ration its subordinate CA’s can be connected using different models such as mesh, bridge etc. Here in this model GWCA are the most trusted anchors to their respective end entities.
1.3 Cross Certification
The Cross Certification between CAs [6] can be performed in two basic steps:
• The first step deals with the establishment of a trust relationship between two CAs through the signing of another CA’s public key in a certificate.
This particular certificate is referred to as cross certificate. This is generally executed in different time intervals.
• The second step deals with the verification of the trust worthiness of a user certificate which is signed by a CA. This CA should be in the same PKI network. This step is generally referred to as “walking a chain of trust” [6].
The term chain of trust indicates a number of cross validations which are ei- ther of the roots CA or the trust anchor [6] of the verifying user required to validate the other user certificate.
162 Balachandra, A. Rao, and K.V. Prema
As referred in [6] a trust anchor is generally a key which is used for the verification of the CA by the client application as the validation. The difference of the hierarchical cross certification to peer to peer cross certification is the location of the users trust anchor vis-à-vis the user.
• The user’s local CA is a subordinate CA in hierarchy of CAs, if the users trust anchor is not the user’s local CA. The public key for root CA is the user’s trust anchor. The subordinate CAs can add more subordinate CAs to the hierarchy below it, even if it cannot perform the cross certification with other CAs, if permitted by policy. All certificate validation in the hierarchy starts with the root CA’s public key. The Fig1 shows basic hierarchical cross certification model.
Fig. 1. Hierarchical Cross-Certification Between a root (autonomous) CA and sub- ordinate (non-autonomous) CAs
• The user’s local CA is an autonomous CA if the user’s trust anchor is the user’s local CA. Autonomy refers to the fact that the CA does rely on a supe- rior CA in a hierarchy. Here any CA can perform cross certification with other CA and the CA is superior to himself. Here there is no concept of sub- ordinate CAs. All certificate validation for clients within an autonomous CA starts with the local CA’s self-signed certificate.
Fig. 2. Peer to Peer Cross Certification between two CAs
2 Related Work
In mobile ad hoc networks, the CAs are considered to be dynamic in nature, and the cen- tral PKI service i.e. the root CA may be unavailable for some time. But the assistance
Certificate Path Verification in Peer-to-Peer PKI by Constructing DFS Spanning Tree 163 from intermediate CAs is needed for successful communication between the requestor and the requested node. Any request message for communication by any node or user should pass through the root CA. So there will be bottleneck in the root CA and exces- sive usage of bandwidth causes serious problems in the network. When the request mes- sage is sent and the root CA is not available for some reason, much of the bandwidth used to send that particular message is wasted and that in turn reduces the efficiency of the model. This is the drawback of the hierarchical model in wireless MANET.
Christina et al. [7] propose a scheme of building a virtual hierarchy to simplify the certification path discovery in mobile ad hoc network. They developed an algorithm called PROSEARCH for this purpose. In peer to peer model, the path discovery is difficult because the trust relationship is bidirectional, where as in hierarchical, it is unidirectional. So the algorithm converts a peer to peer model to a virtual hierarchi- cal model. By doing this, path discovery is simplified and maximum path length can be adapted to the characteristics of the user within the limited storage and processing capacity.