A Study on Certificate Revocation in Mobile Ad Hoc Networks(2011)

Note: Please Scroll Down to See the Download Link.

ABSTRACT:

            Certificate revocation is an important security component in mobile ad hoc networks (MANETs). Owing to their wireless and dynamic nature, MANETs are vulnerable to security attacks from malicious nodes. Certificate revocation mechanisms play an important role in securing a network. When the certificate of a malicious node is revoked, it is denied from all activities and isolated from the network. The main challenge for certificate revocation is to revoke the certificates of malicious nodes promptly and accurately. In this paper, we build upon our previously proposed scheme, a clustering based certificate revocation scheme, which outperforms other techniques in terms of being able to quickly revoke attackers’ certificates and recover falsely accused certificates. However, owing to a limitation in the schemes certificate accusation and recovery mechanism, the number of nodes capable of accusing malicious nodes decreases over time. This can eventually lead to the case where malicious nodes can no longer be revoked in a timely manner. To solve this problem, we propose a new method to enhance the effectiveness and efficiency of the scheme by employing a threshold based approach to restore a node’s accusation ability and to ensure sufficient normal nodes to accuse malicious nodes in MANETs. Extensive simulations show that the new method can effectively improve the performance of certificate revocation.

EXISTING SYSTEM:

For conventional networks, CAs issue certificate revocation lists (CRLs)—containing information about revoked certificates at regular intervals. The CRLs are either placed in online repositories where they are readily available, or they may be broadcast to the individual nodes. Alternatively, online certificate status protocol (OCSP) , can be used to ascertain information about the status of a certificate. Whether CRLs, OCSP, or any other certificate validation protocols are used in the traditional networking settings, a necessary requirement is the availability of network connection to the CAs, the central repositories where CRLs are stored, or to the centralized servers running the certificate validation protocols. The following are the different challenges associated with adapting this scenario to ad hoc networks.

Disadvantages:

  • In any given ad hoc network, there may neither be network connection to centralized CAs nor central repositories where CRLs can be retrieved, or centralized servers running certificate validation protocol(s). Thus, ascertaining whether or not a certificate is revoked presents a challenge in ad hoc networks environments.
  • To-date, the security schemes utilizing digital certificates, proposed for ad hoc networks, either do not explicitly address the issue of certificate revocation, or they require that certificates of nodes be revoked when the nodes are accused of misbehavior.
  • Certificate revocation is too important an issue to be ignored; nonetheless, if adequate safeguards are not built into the process of determining when a certificate should be revoked, malicious nodes can wrongfully accuse other nodes of misbehavior and cause the certificates of good, uncompromised nodes to be revoked. Compromised or malicious nodes can in fact use this
  • The limitation of computational resources and the absence of centralized entities for performing critical key management tasks such as certificate revocation.

 PROPOSED SYSTEM:

The proposed certificate revocation protocol for ad hoc networks, that provides a measure of protection against malicious accusation attacks. The protocol allows individual nodes to use commonly agreed upon criteria to revoke certificates. Information that are used to decide whether or not a certificate should be revoked, is shared by all the nodes; however, it is the individual nodes that are given the responsibility of revoking certificates and storing information about the status of the certificates of the peers they communicate with. Certificate status information is thus readily available to each node; consequently, enabling the elimination of the window of opportunity whereby revoked certificates can be accepted as valid.

In this scheme, the individual nodes within a network are responsible for all key management tasks, except issuing of certificates. Prior to entering a network, a node is required to have a valid certificate issued by a CA that is trusted by the other network peers. It is also expected to have the public keys of the CAs that issued the certificates of the peers it expects to communicate with. The first duty of a node after entering a network is to broadcast its certificate to all the nodes, and simultaneously sends a request that the nodes send their profile tables. The profile table contains information about the behavior profile of each node in a network. The information in the profile tables is used to determine whether or not a given certificate should be revoked. Each node is required to compile and maintain a profile table. A profile table can be represented in the form of a packet of varied length depending on the number of accusation launched against the nodes. The length ranges from a minimum of 80 bits when there are no accusation to a maximum of  97(N-1)+145 bits, where  N is the number of nodes in the network.

Advantages:

  • The proposed certificate revocation scheme for ad hoc networks, that provide some measure of protection  against malicious accusation succeeding in causing the revocation of certificates of trustworthy, well-behaving nodes.
  • The proposed scheme also effectively eliminates the window of opportunity whereby a revoked certificate can be accepted as valid.

MODULES:

  1.   Network Creation
  2.   Certificate Acquisition
  3.   Request For  Profile Tables
  4.   Certificate Revocation

1. Network Creation:

                      Build the network topology according to our requirement.Here in this modules we construct the network with the required no of nodes.

2. Certificate Acquisition and Certificate Storing:

                     In our scheme, the individual nodes within a network are responsible for all key management tasks, except issuing of certificates. Prior to entering a network, a node is required to have a valid certificate issued by a CA that is trusted by the other network peers. It is also expected to have the public keys of the CAs that issued the certificates of the peers it expects to communicate with.

Broadcasting Certificate:

               The first duty of a node after entering a network is to broadcast its certificate to all the nodes.Each node in the network would have to broadcast its certificate atleast once after entering the network .This certificate would contain information such as owners id and issure id and date of  issue and time of expiration.The information in the certificate would helpful to predict whether the  node  is trustable to communicate or not.

3. Request For Profile Tables:

                    The first duty of a node after entering a network is to broadcast its certificate to all the nodes, and simultaneously sends a request that the nodes send their profile tables. The profile table contains information about the behavior profile of each node in a network. The information in the profile tables is used to determine whether or not a given certificate should be revoked. Each node is required to compile and maintain a profile table. A profile table can be represented in the form of a packet of varied length depending on the number of accusation launched against the nodes. The length ranges from a minimum of 80 bits—when there are no accusation—to a maximum of 97(N-1)+145 bits, where is the number of nodes in the network. Details of the fields and content of the profile table are as follows

1.      Owner’s ID: This field is the first 32 bits of the profile table. It contains an integer indicating the serial number of the owner’s (the node that compiled the profile table) digital certificate.

2.      Node count: this is a 16-bit field containing a short integer indicating the owner’s perspective regarding the current number of nodes(N) in the network.

3.      Peer i ID: This is a 32-bit field containing the certificate serial number of a node that is accused of misbehavior. This field also serves the purpose of a marker: if it contains zero, it indicates the end of the profile table.

4.      Certificate status: This field contains a 1-bit flag; it is set if the certificate of peer I is revoked and unset otherwise.

5.      Accusation info: This is a 64-bit field; the first 32 bits contains an integer indicating the certificate serial number of a node that accused peer i of misbehavior. The remaining 32 bits contains the date that the accusation was made.  

4. Certificate Revocation:

                        In addition to a certificate repository, each node is required to compile and maintain a status table. Initially, it is compiled from the data in the profile table, and updated simultaneously along with the latter when a new, pertinent accusation is received. The status table is used to ascertain the status of a certificate

SYSTEM REQUIREMENT SPECIFICATIONS:

Software Specifications:

·         Operating System       : Windows XP

·         Language Used          : Java (Swings)

Hardware Specifications:

·         Processor                    :  Pentium IV

·         Hard disk                     :  40 GB or Above

·         RAM                               :  512 MB or Above

Click here to download A Study on Certificate Revocation in Mobile Ad Hoc Networks(2011) source code