Download WINE (IST-1999

Securing Ad Hoc Routing
Protocols
Isameldin Suliman
[email protected]
Centre for Wireless Communications
University of Oulu, Finland
•
•
•
•
•
•
•
•
•
•
•
•
•
Overview
Introduction
Research objectives
Ad hoc network security goals
Motivations
Ad hoc On Demand Distance Vector (AODV) Routing
Protocol
Routing protocols security requirements
Security flaws of AODV
SAODV hash chains
SAODV digital signature
Other routing protocols
Key management
Discussion
Conclusion
2
Research Objectives
• The main goal of the paper is to incorporate
security mechanisms into ad hoc networks
routing protocols
• Discuss whether the algorithms would be
applicable to other ad hoc routing protocols
• Present how the key management scheme could
be used in conjunction with the proposed
algorithms
• AODV is used as an example of ad hoc routing
3
Motivations
• Routing in ad hoc networks has interesting
security problems
• Use of wireless links renders an ad hoc network
susceptible to link attacks
• Nodes roaming in a hostile environment, with
relatively poor physical protection, have non
negligible probability of being compromised
• There is very little published prior work on the
security issues in ad hoc routing protocols
4
Ad Hoc Network Security Goals
• Security is an important issue for ad hoc networks.
The main goals of network security are:
1. Availability: Ensures the survivability of network services
2.
3.
4.
5.
despite denial-of-service attacks
Confidentiality: Ensures that certain information is never
disclosed to unauthorized entities
Integrity: Guarantees that a message being transferred is
never corrupted
Authentication: Enables a node to ensure the identity of
the peer node with which it is communicating
Non-repudiation: ensures that the origin of the message
cannot deny having sent the message
5
AODV Routing Protocol
• A source node S wishes to communicate with destination
•
•
•
•
node D broadcast a Route Request (RREQ) to its neighbors
Broadcast RREQ
Intermediate nodes forward the
D
message
B
C
RREP message
RREQ to their neighbors
S
The destination node sends a Route Reply
Message (RREP) back to the source node
An intermediate node may send a RREP provided A
that it knows a ‘fresh enough’ route to the destination
Nodes maintain routing table entries only for active routes,
unused routes are removed from the routing table after
active_route_timeout interval
6
Routing Protocols Security Requirements
• The paper considers the following security
requirements:
1. Import autohrization: Only authorize route information
if it concerns the node that is sending the information
2. Source authentication: Verify that the node is the one it
claims to be
3. Integrity: routing information that is being sent has
arrived unaltered
4. The source authentication and integrity combined
build data authentication
7
Securing Ad Hoc Routing Protocols
• There are two kinds of messages in ad hoc networks:
1. Routing Messages: Used for protocol signaling and sent
to immediate neighbors, processed, possibly modified, and
resent.
2. Data Messages: Point-to-pint and can be protected with
any point-to-point security mechanism (like IPSec).
• Intermediate nodes need to be able to authenticate
routing messages.
• Routing messages can be distinguished in two
types of information:
• Mutable
• Non-mutable
8
Security Flaws of AODV
• AODV protocol is vulnerable to the following kinds
of attacks by a malicious node M:
1. Impersonate a node S by forging a RREQ with its address as the
originator address
2. Reduce the hop count field when forwarding RREQ generated by
S
3. Impersonate a node D by forging a RREP with its address as a
destination address
4. Selectively, not forward certain RREQs and RREPs, not reply
certain RREPs, and not forward certain data messages
5. Forge a RERR messages pretending it is the node S and send it to
its neighbor D
6. Set the sequence number of a node to a much bigger number.
9
Securing AODV Protocol (SAODV)
• It is assumed that there is a key management sub-
•
system that makes it possible for each ad hoc node to
obtain public keys from the other nodes of the
network.
Two mechanisms are used to secure the AODV
routing messages:
• Digital signatures: To authenticate non-mutable fields of the
messages
• Hash chain: To secure the hop count field in mutable messages
• The information relative to the hash chains and the
signature is transmitted as “Signature Extension” with
the AODV messages.
10
SAODV Hash Chains
• SAODV hash chains uses hash chains to
•
•
authenticate the hop count field of RREQ
and RREP messages
A hash chain is formed by applying a oneway hash function (e.g. MD5) repeatedly
to a seed
When receiving RREQ and RREP
messages, a node perform the following
• Apply the hash function to verify the value
Type
contained in the Top Hash field
• Before re-broadcasting RREQ or
forwarding RREP, apply the hash function
to hash the value in the signature
extension to account for the new hop
Start
Generates a random number
(seed)
Set the Max_Hop_Count field
to the Time_To_Live value
Set the Hash field to the hash
value
Set the Hash_Function field to
the hash function identifier
Calculates Top_Hash by hashing
seed Max_Hop_count times
Stop
Length Hash Function Max Hop Count
Top Hash
Signature
Hash
11
RREQ (Single) Signature Extension
SAODV Digital Signature (1)
• Digital signatures (DS) are used to protect the
•
•
integrity of non-mutable data in RREQ and RREP
messages
They sign every thing but the hop count of the AODV
message and the hash from SAODV extension
The main problem in applying DS is that AODV
allows intermediate nodes to reply RREQ messages if
they have a route to the destination (i.e. intermediate
nodes should be able to sign the RREP on behalf of the final
destination)
• To solve this problem, the paper offers two
alternatives:
12
SAODV Digital Signature (2)
• The first solution is that if an intermediate node
•
•
•
cannot reply to a RREQ (because it cannot properly signs
its RREP), it just behave as if it didn’t have the route
and forwards the RREQ message
The second one is that, a node generating a RREQ
message, includes the RREP flags, the prefix size,
and the signature that can be used to create RREP
When an intermediate node generates a RREP, the
route life time will change from the original one
The intermediate node should include both life
times and sign the new lifetime
13
SAODV Digital Signature (3)
• Original information of the route is signed by the final
destination and the lifetime is signed by the intermediate
node
Type Length Hash Function Max Hop Count
• This leads to two different
Top Hash
Signature
SAODV extensions: single and
Hash
double signature extensions
RREQ Single Signature Extension
• When a node receives a RREP/ Type Length Hash Function Max Hop Count
RREQ, it first verify the signature R A
Reserved
Prefix size
Top Hash
before creating or updating a
Signature
route/ reverse route to the host
Signature for RREP
Hash
14
RREQ Double Signature Extension
SAODV Error Messages
• Route Error (RERR) messages are generated by a
•
•
•
neighbor node to other nodes informing that it is not
able to route messages to certain destination anymore
Every node (generating or forwarding a RERR message) uses
digital signature to sign the whole message
Any neighbors that receives the RERR verifies the
signature
Verify that the sender of the RERR message is really
the one that it claims to be
15
Other Routing Protocols
• In principle SAODV could be used to create “secure
•
•
•
•
version” of other routing protocols
If the routing protocol has some other mutable
information, intermediate nodes that mutate part of the
messages also have to sign it.
Dynamic Source Routing (DSR) has been used as an
example for other routing protocols
DSR includes in its routing message the IP addresses of
all intermediate nodes
Signing the message by each intermediate nodes reduces
the routing pereformance (due to additional
cryptographic computations)
16
Key Management
• It is assumed that each node has a trustworthy means
•
•
•
of checking the association between the addresses
and signatures of other nodes
This association (binding) is typically achieved by
using public key certificates issued by a certification
authority (CA)
This can work if ad hoc nodes could have permanent
addresses
One secure and potentially expensive solution would
be to pick a key pair, and map the public key to a
tentative address . If there is a collision, pick a new
key pair and try again
17
Discussion (1)
• Ad hoc networks are inherently vulnerable so security
attacks and need security mechanisms
• The paper relies on public key management. It is not
realistic to assume that nodes in ad hoc networks will
have access to public key infrastructure to obtain public
key certificates
• Distribution of certificates by CA implies huge
overhead, and it is not effective in the presence of
partitions and high mobility
• The hash chain algorithm only addresses single mutable
information (hop count), it would be more complex if
more mutable information is to be addressed
18
Discussion (2)
• The authors reported that SAODV cannot detect
•
•
tunneling attacks
More work is needed to apply the proposed
security algoritms to other ad hoc routing
protocols
Th use of asymmetric cryptography adds more
overhead to the processing power requirements of
the SAODV
19
Conclusion
• The paper presents two security mechanism for
protecting ad hoc routing protocols (AODV in
particular)
• The proposed algorithms do not require modification to
the AODV protocol, they are added as an extension to
the existing AODV message formats
• An effective mechanism is needed to address the
problem of key certificates distribution
• The paper tries to provide a general mechanism that
could be applied to different routing protocols. However,
it would more effectient to extend the algorimths and
define separate meachanisms for different ad hoc routing
20
protocols