chapter 6 prevention of impersonation attack

127
CHAPTER 6
PREVENTION OF IMPERSONATION ATTACK
6.1
INTRODUCTION
In mobile ad hoc network, any node may compromise the routing
protocol functionality by disrupting the route discovery process. A solution is
proposed for Prevention of Impersonation Attack using Hash chains and
Digital Signatures (PIA-HCDS). In this attack, the attacker assumes the
identity of another node in the network, thus receiving messages directed to
the node it fakes.
6.2
IMPERSONATION ATTACK
Impersonation attacks (Burg 2003) are also called spoofing attacks.
Usually this would be one of the first steps to intrude a network with the aim
of carrying out further attacks to disrupt operation. Depending on the access
level of the impersonated node, the intruder may even be able to reconfigure
the network so that other attackers can (more) easily join or can even remove
security measures to allow subsequent attempts of invasion. A compromised
node may also have access to encryption keys and authentication information.
In many networks, a malicious node could obstruct proper routing by
injecting false routing packets into the network or by modifying routing
information.
128
6.3
PREVENTION
OF IMPERSONATION ATTACK USING
HASH CHAINS AND DIGITAL SIGNATURES (PIA-HCDS)
Hash chains and Digital signatures are two mechanisms used to
secure the AODV messages (Zapata and Asokan 2002; Manel Guerrero
Zapata 2001; Rivest et al 1978).
i)
Hash chains to secure mutable fields of the messages (hop
count information is the only mutable field).
ii)
Digital signatures to authenticate the non-mutable fields of the
messages.
For the non-mutable information, authentication is performed in an
end-to-end manner, but the same kind of techniques cannot be applied to the
mutable information.
6.3.1
Working of Hash Functions
Hash function is a public function that maps a message of any
length into a fixed length hash value, which serves as the authenticator. The
proposed solution uses hash functions to authenticate the hop count field of
RREQ and RREP messages in such a way that it allows every node that
receives the message (either an intermediate node or the destination) to verify
that the hop count has not been decremented by an attacker. This prevents any
change in Hop Count Field. That is, the attacker tries to reduce its hop count
field, to increase the chances of being in the route path between source and
Destination, so that; it can analyze the communication between them. Hence
to avoid the hop count change, a hash function is used. A variant of this is to
increment the destination sequence number to make the other nodes believe
that this is a ‘fresher’ route.
129
Applying a one-way hash function repeatedly to a seed forms a hash
chain. Every time a node originates a RREQ or a RREP message, it performs
the following operations (Zapata and Asokan 2002):
i)
The Max Hop Count field in the RREQ or in the RREP
message format is set to the Time-To-Live value from the IP
header. A random number (seed value) is generated and set
the hash field to the seed value. Top Hash is calculated by
Top Hash = h (Max Hop Count
(Hash)
(6.1)
where - h is a hash function.
ii)
In addition, every time a node receives a RREQ or a RREP
message, it performs the following operations in order to
verify the hop count.
Applies the hash function h Maximum Hop Count
minus Hop Count times to the value in the Hash
field
Verifies that the resultant value is equal to the
value contained in the Top Hash field.
iii)
Before re-broadcasting a RREQ or forwarding a RREP, a node
applies the hash function to the Hash value in the Signature
Extension to account for the new hop.
Hash = h (Hash)
(6.2)
The details of the hash function are given in the Table 6.1. For the
simulation purpose, the following two hash algorithms are implemented.
Table 6.1 Hash Functions
Value
0
1
2
Hash Function
Reserved
RIPEMD-5
SHA
130
RIPEMD-5 -
RACE Integrity Primitives Evaluation Message Digest - 5
SHA
Secure Hash Algorithm
-
The Hash Function field indicates which hash function has to be
used to compute the hash. Trying to use a different hash function will just
create a wrong hash without giving any advantage to a malicious node. Hash
Function, Max Hop Count, Top Hash, and Hash fields are transmitted with
the AODV message, in the Extension. All of them except the Hash fields are
signed to protect its integrity. The format for RREQ with Signature Extension
is shown in Figure 6.1.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Type
D U
Length
Reserved
Hop Count
RREQ ID
Destination IP Address
Destination Sequence Number
Originator IP Address
Originator Sequence Number
Hash Function
Max Hop Count
Top Hash
Signature
Hash
Figure 6.1 RREQ with Signature Extension
The functionality of the hash chain between source and destination
node is illustrated in Figure 6.2, where H is the hash function used.
131
Message
Message
Message
Digest
Digest
H
Digest
H
Compare
Accept/Reject
Figure 6.2 Hash Chain Creation
6.3.2
Working of Digital Signatures
Digital signature is an authentication mechanism that enables the
creator of a message to attach a code that acts as a signature. The signature
guarantees the source and integrity of the message. In the proposed solution
the digital signatures are used to protect the integrity of the non-mutable data
in RREQ and RREP messages. This means that they sign everything except
the Hop Count of the RREQ and RREP messages and the Hash from the
proposed solution extension. The main problem in applying digital signatures
is that AODV allows intermediate nodes to reply RREQ messages if they
have a ‘fresh enough’ route to the destination. While this makes the protocol
more efficient, it also makes it more complicated to secure. The problem is
that a RREP message generated by an intermediate node should be able to
sign it on behalf of the final destination. And in addition, it is possible that the
route stored in the intermediate node would be created as a reverse route after
receiving a RREQ message (i.e. it does not have the signature for the RREP).
132
To avoid this problem, the solution used here is that an
intermediate node is not allowed to reply to a RREQ message and it just
behaves as if it didn’t have the route and forwards the RREQ message.
When a node receives a RREQ, it first verifies the signature before
creating or updating a reverse route to that host. Only after verification of the
signature, it will store the route. When a RREQ is received by the destination
itself, it will reply with a RREP only if it fulfills the requirements to do so.
This RREP will be sent with a RREP Signature Extension. The format for the
RREP with signature extension is shown in Figure 6.3.
Figure 6.3 RREP with Signature Extension
When a node receives a RREP, it first verifies the signature before
creating or updating a route to that host. Only after verification of the
signature, it will store the route with the signature of the RREP. Using digital
signatures we can prevent attacks like,
133
i)
Impersonation of a Source node S by forging a RREQ with its
address as the originator address.
ii)
Impersonation of a Destination node D by forging a RREP
with its address as a destination address.
The mechanism of creating the signature and verifying it is
illustrated in the Figure 6.4.
KUa
Message
Message
Message
Signature
Signature
H
KRb
H
Digest
E
KRa
E
Compare
KUb
Accept/Reject
Figure 6.4 Digital Signature Creation
KRa -Sender’s Private Key
KUa -Sender’s Public Key
KUb - Receivers Public Key
KRb- Receiver’s Private Key
E –Encryption
D-Decryption
6.4
SIMULATION RESULTS
In this section, the simulation study and analysis of PIA-HCDS
protocol is discussed. The simulation is done using GloMoSim and to
analyses the performance of the networks by varying the nodes mobility in the
134
networks. The metrics used to evaluate the performance are Packet Delivery
Ratio, Throughput, Average Path Length and Average End-to-End Delay. The
general simulation profile was given in Table 4.3 in section 4.3.4 and the
metrics used was shown in section 4.3.4.1.
6.4.1
Simulation Profile for PIA-HCDS
The simulation profile for this setup is illustrated in the Table 6.2.
Table 6.2 Simulation Profile for PIA-HCDS
Property
Value
Nodes
25
Simulation time
120 s
Mobility
Random way point , Pause time-30 ms ,
Node mobility varied between 10 m/s to 90 m/s.
Load
300 packets Data pay loads 512 Bytes, Inter
departure time of 1 s.
Coverage Area
800m by 800m
Radio-bandwidth
2 Mb/s
To evaluate the packet delivery ratio and average path length the
simulation is done with 25 nodes with source node 5 transmitting to
destination node 20. The malicious nodes are chosen in random among the
number of nodes and the behavior is also chosen in random, where the node
can increment the hop-count or decrement hop-count. In addition to that a
masquerading node can modify the source or destination address. This kind of
malicious behavior can be detected using the hash function and the signature
comes with the routing packets. When a node detects the above kind of
behavior it adds the last address where it receives the packets in to the black
135
list and drops the packet. The source node after waiting for a timeout period,
start re-transmitting the packets. This action tries to avoid the data packet to
be transferred through the malicious nodes.
Table 6.3 gives the packet delivery comparison data in presence of
malicious node.
Table 6.3 PIA-HCDS - Packet Delivery Comparison
Node Mobility
(m/s)
Packet Delivery (%)
PIA-HCDS
AODV
10
100
98
20
100
98
30
97.5
96
40
97.5
95
50
98
95
60
98
96
70
97
96
80
97.5
96
As shown in Table 6.3 and in Figure 6.5 the packet delivery ratio
obtained using PIA-HCDS is above 95% in all scenarios and almost identical
to that when using a AODV. This suggests that PIA-HCDS is highly effective
in discovering and maintaining routes for delivery of data packets, even with
relatively high node mobility.
136
Packet Delivery Comparison
100
98
96
PIA-HCDS
AODV
94
92
90
10
20
30
40
50
60
70
80
Node M obility (m/s )
Figure 6.5 PIA-HCDS - Packet Delivery Comparison
Table 6.4 gives the average path length. It was calculated by
averaging the number of hops taken by each data packet to reach the
destination.
Table 6.4 PIA-HCDS - Average Path Length
Node Mobility
(m/s)
Average path length (in No. of Hops)
PIA-HCDS
AODV
10
19
3
20
15
11
30
14
15
40
15
14
50
20
14
60
19
12
70
18
12
137
It is seen from the Table 6.4 and Figure 6.6, the proposed solution
has higher average path length than the AODV. Traditionally, the shortest
path to a destination (in terms of number of hops) is considered to be the best
routing path. AODV explicitly seeks shortest path using the hop count field in
the route request/reply packets. PIA-HCDS, on the other hand chooses the
safest path than the shortest. Due to the elimination of malicious nodes in the
route, the average path length is higher than the AODV.
Average Path Length
25
20
15
PIA-HCDS
AODV
10
5
0
10
20
30
40
50
60
70
Node Mobility (m/s)
Figure 6.6 PIA-HCDS - Average Path Length
As seen from Table 6.5 the average end-to-end delay in all cases of
AODV1 (no malicious) and AODV2 (10% malicious) is almost same. But
compared to AODV, the proposed PIA-HCDS protocol, in general has a
higher average end-to-end delay irrespective of the presence of malicious
nodes (10%) or not. This is due to the fact that in the proposed solution,
additional process is involved to maintain security. Again from the figure it is
clear that the presence of malicious node has an impact in PIA-HCDS2
compared to PIA-HCDS1 (No malicious node). This is due to the additional
138
time required to identify the malicious. That is while processing routing
control packets, each node has to verify the hop count and check whether it is
correct else report it to the black list, and if the nodes is the destination then it
has to get the public key of the source node and create the signature and
compare it with the packet. So this hash and signature mechanism adds some
delay in the network, so the average end-to-end delay is also increased.
Table 6.5 PIA-HCDS - Average end-to-end delay
Node Mobility
(m/s)
6.5
Average end-to-end delay (Sec)
PIA-HCDS1
PIA-HCDS2
AODV1
AODV2
10
0.03319721
0.05081524
0.005140870
0.008140870
20
0.04528418
0.09824184
0.005331993
0.005331993
30
0.04694214
0.13215244
0.003796817
0.003796817
40
0.05793415
0.14675852
0.003717365
0.003717365
50
0.06104824
0.16021415
0.003750403
0.003750403
60
0.06234182
0.17251548
0.003750403
0.003750403
70
0.05941254
0.17845241
0.003833736
0.003833736
80
0.06488452
0.18192514
0.003833736
0.003833736
CONCLUSION
In this thesis we have proposed a strategy to counter the
Impersonation attacks prevalent in Mobile Ad Hoc Networks. The solution is
simulated using the Global Mobile Simulator and is found to achieve the
required security with minimal additional delay. Even if the delay is more,
the packet delivery is high and security is increased.

Download Report