Centre for Wireless Communications University of Oulu, Finland 17/04/2017 Securing Ad Hoc Routing Protocols Isameldin Suliman isam@ee.oulu.fi 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

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

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

Ad Hoc Network Security Goals Security is an important issue for ad hoc networks. The main goals of network security are: Availability: Ensures the survivability of network services 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

Broadcast RREQ message AODV Routing Protocol A source node S wishes to communicate with destination node D broadcast a Route Request (RREQ) to its neighbors Intermediate nodes forward the RREQ to their neighbors The destination node sends a Route Reply Message (RREP) back to the source node An intermediate node may send a RREP provided 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 C D A S B Broadcast RREQ message RREP message

Routing Protocols Security Requirements The paper considers the following security requirements: Import autohrization: Only authorize route information if it concerns the node that is sending the information Source authentication: Verify that the node is the one it claims to be Integrity: routing information that is being sent has arrived unaltered The source authentication and integrity combined build data authentication

Securing Ad Hoc Routing Protocols There are two kinds of messages in ad hoc networks: Routing Messages: Used for protocol signaling and sent to immediate neighbors, processed, possibly modified, and resent. 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

Security Flaws of AODV AODV protocol is vulnerable to the following kinds of attacks by a malicious node M: Impersonate a node S by forging a RREQ with its address as the originator address Reduce the hop count field when forwarding RREQ generated by S Impersonate a node D by forging a RREP with its address as a destination address Selectively, not forward certain RREQs and RREPs, not reply certain RREPs, and not forward certain data messages Forge a RERR messages pretending it is the node S and send it to its neighbor D Set the sequence number of a node to a much bigger number.

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.

SAODV Hash Chains 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 Start Stop 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 one-way 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 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 Type Length Hash Function Max Hop Count Top Hash Signature Hash 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:

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

SAODV Digital Signature (3) Original information of the route is signed by the final destination and the lifetime is signed by the intermediate node This leads to two different SAODV extensions: single and double signature extensions When a node receives a RREP/ RREQ, it first verify the signature before creating or updating a route/ reverse route to the host Type Length Hash Function Max Hop Count Top Hash Signature Hash RREQ Single Signature Extension R A Reserved Prefix size Signature for RREP 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

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)

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

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

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

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 protocols