Research Article
a
November
2018
Computer Science and Software Engineering
ISSN: 2277-128X (Volume-8, Issue-11)
Real-Time Security of MAODV Protocol in Multicast
Mobile Ad-Hoc Network
Jeenat Sultana*, Mohammed Arif Hasan Chowdhury
Department of CSIT, Southern University Bangladesh
[email protected], [email protected]
Abstract— This paper deals with the security of multicast Mobile Ad-hoc networks (MANET). The security here has been assured by extending the well-known routing protocol, Multicast Ad-hoc On Demand Distance Vector routing protocol (MAODV) to a secure one using the RSA algorithm. Some security features have been added with the MAODV protocol and has been named SecMAODV. The concept of SAODV, a well-known protocol of unicast MANET, has been used for the security extension of MAODV. Security features in the routing protocol includes mechanisms for non-repudiation and authentication. Security is the most important factor in mobile ad-hoc networks. Without an infrastructure a network is more vulnerable. So a protocol with digital sign and certificate may reduce the possibility of external attacks. We have calculated the additional time needed for securing with RSA and compared the time difference without security.
Keywords— SecMAODV, RSA, security, manet, MAODV.
I. INTRODUCTION
A Mobile Ad-hoc Network (MANET) is a comprised of autonomous nodes, operating as both terminal nodes and intermediate ones, communicate with each other in a decentralized manner using the radio network. Moreover, the routing path in MANET is dynamic in nature and tough to apply the security techniques applied for the wired networks. Multicasting means the transmission of packets from a source or a group of sources to a group of one or more hosts that are identified by a single destination address. Multicasting greatly reduces the transmission cost when sending the same packet to multiple recipients. It can improve the usage of wireless links by sending multiple copies of data packets using inherent broadcast behaviour of wireless transmission though reducing transmission overhead and power consumption is a very challenging part in multicasting. There are many applications where one-to-many and many-to-many transmissions are required creating the need for multicasting. Most of the multicast routing protocols proposed for ad hoc networks assume a trusted, non-adversarial environment and do not take security issues into account in their design.
Anand Patwardhan et al [1] presented the implementation of a secure routing protocol based on AODV over IPv6, covered by an Intrusion Detection and Response system for ad-hoc networks. Kimaya Sanzgiri et al [2] designed a new secured protocol ARAN, after examining the security threats against the ad hoc routing protocols, AODV and DSR. Lidong Zhou et al [3] used the facility of multiple routes between nodes to defend the denial of service attacks. They also used threshold cryptography to build a highly secure framework with key management service. Prasad P. et al [4] implemented the security technique to prevent the data loss at the time of transmission and to prevent from attacker node. They provided the security with the help of the Diffie-Hellman algorithm. Gaurav Dwivedi et al [5] implemented RSA in AODV routing protocol to prevent the blackhole attack. We have investigated the security of MAODV (Multicast Ad hoc On-Demand Distance Vector protocol), a well-known multicast routing protocol, in this paper using RSA encryption algorithm and calculated the time required for additional security. The algorithm considered to be implemented is used at the very beginning of joining the multicast group. Once the node, requested for joining the multicast group, is verified as an authentic one, the prevention of attack will work initially. Moreover, it will save cost while transmitting data.
The rest of the paper is designed as follows: section II demonstrates the literature review; methodology is explained in section III, while section IV describes the performance analysis and section V is about discussion, limitation and future scope of the work.
II. LITERATURE REVIEW
A. Multicasting with MAODV
The use of multicasting within MANETs has many benefits.
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 52-59
Instead of sending data via multiple unicasts, multicasting minimizes channel capacity consumption, sender and router processing, energy consumption, and delivery delay, which are considered important MANET factors. In addition, multicasting provides a simple yet robust communication method whereby a receiver’s individual
address remains unknown to the transmitter or changeable in a transparent manner by the transmitter. Multicasting is necessary for secure transmission to a group of defence or military arena.
MAODV routing protocol used for multicasting, follows rules directly from unicast AODV and discovers multicast routes on demand using a broadcast route discovery mechanism employing the same route request (RREQ) and route reply (RREP) messages that exist in the unicast AODV protocol [3]. Each node running MAODV maintains two routing tables:
1. Route Table (RT), used for recording the next hop for routes to other nodes in the network. 2. Multicast Route Table (MRT), used when a node becomes router for a multicast group.
B. MAODV while joining a multicast group
When a node, S in Fig. 1 wishes to join a multicast group with the group leader M and multicast group members 1, 2 and 3, the RREQ propagation can be either through broadcast or unicast[6][7][8][9]:
• Unicast when the route to the group leader known (an extension field set to multicast_leader_IP_addr). • broadcast when unknown or the unicast option fails.
Fig. 1 Joining a multicast group with MAODV
Table I Multicast Route Table (MRT) Fields in MRT
multicast group IP address multicast group leader IP address multicast group sequence number Hop count to the multicast group leader
next hops: with Enabled flag Lifetime
The source unicasts/broadcasts a signed RREQ message with the joinflag set. When intermediary nodes, A and B in Fig. 1, receive the RREQ, they create an entry in their Multicast Route Table, shown in Table 1, for that group, with the Next Hopfield set to the IP address (of the originator) of the node from which it received the RREQ. It also sets the downstreamflag for this Next Hop entry. If this node is a member of the multicast tree, for this group, it will unicast a RREP back to the originator of the RREQ. Otherwise, it rebroadcasts the RREQ. A node that receives a RREP for a multicast group, forwards it, if it provides the best route to the multicast tree and it also adds an entry in its Multicast Route Table for that group’s Next Hop list, with an IP address (of the originator in RREP) of the node from which it received the RREP, and also marks this entry with the upstream flag. The source node (RREQ generator) selects a suitable route from the RREPs and sends an activation message called MACT along this route.
C. Problems with MAODV
The problems found with MAODV are as follows:
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 52-59 • A malicious node intentionally drops control packets, misroutes data, or disseminates incorrect information
about its neighbours.
D. Design goals
We distinguish between two types of nodes that can launch attacks on the operation of MAODV. 1. Attacks can be launched by outsiders, who do not possess the certificate to join the ad hoc network. 2. Attacks can be launched by compromised group members.
The Sec MAODV implements two concepts:
1. Signed evidence produced by the originator of the message and signature verification by the destination, without any form of delegation of trust.
2. Certificate generated by the originator to verify that the message is signed by the actual sender/node.
III. METHODOLOGY
A. Sec MAODV Routing Protocol Format
Each node has to verify the digital signature of the previous node [8] [10], and then replace this with its own digital signature, in addition to the normal processing of the packet as done by AODV. This signature generation and verification causes additional delays at each hop.
The RREQ in Sec MAODV protocol contains the following rules:
Table II Rreq in Secmaodv Routing Protocol
Type of Fields Fields in RREQ
Regular Fields in MAODV 32-bit RREQ ID
128-bit multicast group IP address 128-bit multicast group leader IP address 32-bit multicast group sequence number 128-bit originator IP address
32-bit originator sequence number hop count to the multicast group leader Next hops: with Enabled flag
Lifetime
Added Fields in SecMAODV 32-bit signature length
32-bit key length 32-bit exponent length 256-bit public exponent 1024-bit RSA public key 128-bit Certificate of the sender
The RREP in Sec MAODV protocol contains the following rules:
Table III Rrep In Secmaodv Routing Protocol
Type of Fields Fields in RREP
Regular Fields in MAODV 128-bit multicast group IP address 128-bit originator IP address 128-bit destination IP address multicast group leader IP address 32-bit destination sequence number multicast group sequence number hop count to the RREQ generator next hops: with Enabled flag
Added Fields in SecMAODV 32-bit lifetime
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 52-59
256-bit public exponent length 256-bit public exponent 1024-bit RSA public key
128-bit certificate of multicast group
B. Public-key based scheme
In RSA, which is an asymmetric cryptographic algorithm where each of the nodes possesses a pair of public and private keys [4] [11]. Based on the key pair, every node is able to perform authentication and other encryption operations. Digital signature is a mechanism, much like a signature on a paper document, used to identify an authentic sender. As an example, if a node, A wants to transmit a message to B in a secure and authenticate way; it may digitally sign the message as shown in Fig. 2. In order to do that, it uses private-key to encrypt the message and sends the message along with its public-key. Since the message can only be decrypted with A’s public-key, a successful decryption constitutes a Digital Signature Verification, meaning that there is no doubt that it is A’s private key that encrypted the message.
Fig. 2 Transmission of message with Digital Signature
A certificate is a piece of information that proves the identity of a public-key’s owner. It is used as verification or proof of a node’s identity. Certificate Authority (CA) [12] [13], a trusted third party entity, is responsible to sign and delivering the certificates to the nodes in a MANET. As long as the nodes A and B trust the third party, the CA, they can be assured that the keys belong to the nodes they claim to be. Fig. 3 shows that a certificate is added after encrypting the message with public/ private key pair while transmission.
A certificate contains among other things: 1) The CA’s identity
2) The owner’s identity 3) The owner’s public-key 4) The certificate expiry date
5) The CA’s signature of that certificate
Fig. 3 Transmission of message with certificates
C. Process of Joining with RSA
For the same network represented in Fig. 1, Sender (S) wants to join the multicast group and broadcast a join request using SecMAODV protocol with the extended features of RREQ and RREP shown in table 2 and table 3. The RSA algorithm is used to ensure the security and verification against malicious nodes at the time of joining multicast group.
1. S signs the group information with the public key (pukM) of the group and broadcast it along with the sender’s
certificate (certS), certS [S_ID, validity, pukS, CA_ID]
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 52-59
Prks= private key of the senders
Puks= public key of the sender
Prkm= private key of the multicast group member
Pukm= public key of the multicast group member
S broadcast | IP_grp, (join req, Req_ID) pukM, certS
certS contains 32-bit signature length, 32-bit key length, 32-bit exponent length, 256-bit public exponent, 1024-bit
RSA public key.
2. The neighboring nodes (assuming the 1st node be A) verify the sender’s certificate, signs the message with its own private key and broadcast it with its certificate.
A broadcast | (IP_grp, (join req, Req_ID) pukM, certS ) prkA, certA
3. B be the next hop of A. B verifies A’s certificate, decrypts the message with A’s public key (pukA) and signs it
with its own private key (prkB) and broadcast again until it reaches any group member.
B broadcast | (IP_grp, (join req, Req_ID) pukM, certS ) prkB, certB
4. When the request reaches a group member, it verifies the signature of the sender and sends back (unicast) a RREP, with the certificate of the group leader, certM [M_ID, validity, pukM, CA_ID].
M unicast | IP_S, next hop, IP_grp, (join rep, Req_ID, certM) pukS
B unicast | (IP_S, next hop, IP_grp, (join rep, Req_ID, certM ) pukS) prkB, certB
A unicast | (IP_S, next hop, IP_grp, (join rep, Req_ID, certM ) pukS) prkA, certA
5. S then sends a multicast acknowledgment, MACT, and joins the multicast group.
IV. PERFORMANCE ANALYSIS
A. Calculations for Additional time required with Sec MAODV
Every node in the routing path using SecMAODV protocol needs some additional time for encryption and decryption, digital sign and also for generating certificates. Additional time has been added with the original packet sending time used by MAODV to calculate the time needed with Sec MAODV.
Time required by the sender (S) and the intermediary nodes (A and B) are calculated below: S= packet sending time + public key(S) encryption + generating cert(S)
A= time for verifying cert(S) + private key(A) encryption + generating cert(A) + packet sending time
B= time for verifying cert(A) + public key(A) decryption + private key(B) encryption + generating cert(B) + packet sending time
1) Time for sending packets using MAODV (without security features)
Time is calculated considering the following parameters for MAODV protocol in Table 4[7].
Table IV Maodv Parameters
Parameters Value
Number of nodes 50
Sending rate Two Packets per Second
Packet Size 256 bytes
Transmission Range 250 meters
Thus, Packets are sent at the ratio of 512 bytes (4096 bits) per second.
MAODV RREQ contains the following fields without security features, as shown in Table 1: 32-bit RREQ ID
128-bit multicast group IP address 128-bit multicast group leader IP address 32-bit multicast group sequence number 128-bit originator IP address
32-bit originator sequence number hop count to the multicast group leader 128-bit next hops: with Enabled flag lifetime
Thus, the size of a packet used by MAODV is of 630 bits (approx).
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 52-59
2) Time for Encryption and Decryption
Time for encryption and decryption is calculated using RSA keys [1]. Time for encryption (512 bit at 883 Kbps) = 0.57 ms
Time for decryption (512 bit at 36 Kbps) = 14.2 ms Time for encryption (1024 bit at 731 Kbps) = 1.40 ms Time for decryption (1024 bit at 15 Kbps) = 68.2 ms Time for encryption (2048 bit at 583 Kbps) = 3.512 ms Time for decryption (2048 bit at 5 Kbps) = 409.6 ms Thus,
Average time for encryption (1 bit) = 0.01407 ms Average time for decryption (1 bit) = 0.097 ms
3) Time for Generating and Verifying Certificates
Time for generating cert =0.007035 ms [assumed] Time for verifying cert =0.0085 ms
4) Comparison of Computation Time used by MAODV and Sec MAODV
As public key of the sender (pukS) contains 32-bit signature length, 32-bit key length, 32-bit exponent length, 256-bit public exponent, 1024-bit RSA public key, thus, pukS consists of 1376 bits.
certS [S_ID, validity, pukS, CA_ID] is of 1440 bits (approx.). Thus, packet sent by S is of 2070 bits (approx.).
Time for sending packets by the sender,
S = packet sending time (with 1440 bit certS)+public key(S) encryption+ generating cert(S) =505.3711 [630+1440 bits at 4096 bps] + 0.5628[40*0.01407] + 0.007035 ms
=505.9409 ms
Time for sending packets by the first hop,
A = time for verifying cert(S) + private key(A) encryption +generating cert(A) + packet sending time(with certA)
= 0.0085 + (2070*0.01407) + 0.007035 + (505.3711 + 351.5625) = 0.0085+29.1249+0.007035 +856.9336
= 886.0740 ms
Thus, packet sent by A is of 3510 bits (approx.).
Time for sending packets by the second hop,
B = time for verifying cert(A) +public key(A) decryption+ private key(B) encryption +generating cert(B)+ packet sending time(with certB)
= 0.0085 + (2070*0.097) + (2070*0.01407) + 0.007035 + (505.3711+351.5625) = 0.0085+200.79+29.1249+0.007035 +856.9336
= 1086.864 ms
5) Time difference for route discovery between Sec MAODV and MAODV protocol
Time difference for route discovery between SecMAODV and MAODV protocol for 1 hop = (505.9409-153.8) ms
= 352.1409 ms
Time difference for route discovery between SecMAODV and MAODV protocol for 2 hops = (868.6272+505.9409)-(153.8+153.8) ms
=1066.9681 ms
Time difference for route discovery between SecMAODV and MAODV protocol for 3 hops = (1086.864+868.6272+505.9409) - (153.8+153.8+153.8) ms
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 52-59
The time differences found using MAODV and SecMAODV protocols for 1 hop, 2 hops and 3 hops consecutively are shown in Table 5.
Table V Time Difference For Route Discovery By Maodv And Secmaodv
Hops MOADV (in
miliseconds)
SecMAODV (in miliseconds)
1 hop 153.8 505.9409
2 hops 307.6 1392.0149
3 hops 461.4 2478.8789
B. Route Discovery Time Ratio
The delay experienced by packet from the time it was sent by a source till the time it reached the destination is shown in Fig. 4. The delay is counted for 1 hop, 2 hops and 3 hops consecutively. The values shown in table 5 are represented through the chart. The chart signifies that with security, the time delay increases gradually with hops. The line of SecMAODV is slightly higher than that of MAODV, as time for encryption and decryption is added to ensure the security.
Fig. 4 Computation time for multiple hops
V. CONCLUSIONS
Existing multicast ad hoc routing protocols are vulnerable to attacks and allowing attackers may impact a victim’s route selection and may even cause denial-of-service attacks. Any of the attacks including tunneling attack, blackhole attack or grayhole attack may be resolved as the proposed protocol ensures security while joining the multicast group. The protocol, SecMAODV, provides a solution for securing routing in an open adversary environment. It provides authentication and non-repudiation services using pre-determined cryptographic certificates that guarantees end-to-end authentication. In doing so, SecMAODV limits or prevents attacks that can trouble transmission by joining a multicast group. It is a simple protocol that needs no additional work for implementation. Further, it can be implemented with any simulator like NS2 to verify the mathematical calculation. It is as efficient as MAODV and may retrieve the information from MAODV as needed for discovering and maintaining routes and thus can be cost effective.
REFERENCES
[1] Patwardhan, A., Parker, J., Iorga, M., Joshi, A., Karygiannis, T. and Yesha, Y., “Threshold-based intrusion detection in ad hoc networks and secure AODV”, Ad Hoc Networks, vol. 6(4), pp.578-599, 2008.
[2] Sanzgiri, K., Dahill, B., Levine, B.N., Shields, C. and Belding-Royer, E.M., “A secure routing protocol for ad hoc networks”, in Proceedings, 10th IEEE International Conference on Network Protocols, IEEE, November,2002. pp. 78-87.
[3] Zhou, L. and Haas, Z.J., “Securing ad hoc networks”, IEEE network, vol. 13(6), pp.24-30, 1999.
[4] Lokulwar, P.P. and Pandey, Y., “A Survey paper on Secure AODV protocol in MANAET using RSA algorithm and Diffie-hellman algorithm”, International Journal on Scientific & Engineering Research ,vol. 4(6),2013. [5] Dwivedi, G. and Kaur, M., “Prevention from Black Hole Attack using RSA Algorithm”, International Journal
of Advanced Research in Computer Science & Technology, vol. 4(2), 2016.
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 52-59
[7] Zhu, Y. and Kunz, T., “MAODV implementation for NS-2.26”, Systems and Computing Engineering, Carleton University, Technical Report SCE-04-01. 2004.
[8] Shyamala, R. and Valli, S., “Securing Route Discovery in MAODV for Wireless Sensor Networks”, UbiCC Journal, vol. 4(3), pp.775-783, 2009.
[9] Aparna, K., “Performance Comparison of MANET (Mobile Ad hoc Network) Protocols (ODMRP with AMRIS and MAODV)”, International Journal of Computer Applications, vol. 1(10), pp. 42-46, 2010.
[10] “Public Key Encryption and Digital Signature: How do they work?” White Paper by CGI Group Inc, September 2002.
[11] Kaur, S. and Kaur, H., “Implementing RSA Algorithm in MANET and Comparison with RSA Digital Signature”, International Journal for Advance Research in Engineering and Technology, vol. 3(5), 2015. [12] Masdari, M. and Pashaei, J., “Distributed certificate management in mobile ad hoc networks”, International
Journal of Applied Information Systems, vol. 4(6), pp.33-40, 2012.
