SECURITY-AWARE AD-HOC ROUTING FOR WIRELESS NETWORKS Seung Yi, Prasad Naldurg, Robin Kravets Department of Computer Science University of Illinois at Urbana-Champaign August, 2001 Presented by: Poonam Munshi

SECURITY-AWARE AD-HOC ROUTING (SAR) Need for Secure Routing - Motivation SAR – Protocol and Behavior Protocol Metrics Protection in SAR Implementation of SAR Performance Evaluation & Conclusion

NEED FOR SECURE ROUTING - MOTIVATION Problems in ad-hoc wireless networks –Lack of fixed infrastructure support –Frequent changes to network topology –Poor protection to protocol packets at physical layer –Network layer routing protocols are “cooperative” by nature Based on implicit ‘trust-your-neighbor’ relationships Susceptible to erroneous routing updates, replay attacks etc. SAR - Approach –Use different security attributes to improve the quality of the security of an ad-hoc route –Incorporate security levels of nodes into traditional routing metrics –Goal : Quantify the notion of trust Represent trust relationships explicitly by defining a suitable hierarchy of trust values Integrate the trust value of a node and the security attributes of a route to provide an “integrated security metric”

NEED FOR SECURE ROUTING - MOTIVATION Challenges –Ensuring data is routed through a secure route composed of trusted nodes –Security of the information in the routing protocol messages Example Scenario – Battlefield communication Transmission range Shortest route Secure route Private Officer General

SAR – PROTOCOL OVERVIEW Similar to policy-based routing protocols for QoS Protocol: –Basic protocol : On-demand protocol AODV –Embed security metric into the RREQ packet itself and change the forwarding behavior of the protocol w.r.t. RREQs –Source node : Specify desired level of security in the RREQ Broadcast the packet –Intermediate node : Process/forward the packet only if it can provide the required security or has the required authorization or trust level ; Otherwise drop the RREQ –If an end-to-end path with the required security found, the intermediate node or eventual destination sends a suitably modified RREP

SAR – BEHAVIOR OVERVIEW Route discovered by SAR may not be the shortest route in terms of hop-count SAR finds a route with a ‘quantifiable guarantee of security’ If one or more routes satisfying the required security attributes exists, SAR finds the shortest such route : All nodes on the shortest path (in terms of hop- count) satisfy the security requirements Optimal route: All nodes on the shortest path (in terms of hop- count) satisfy the security requirements Drawback: –If no path with nodes that meet the RREQ’s security requirements exists, SAR fails to find a route even though the network may be connected

SAR – PROTOCOL METRICS Explicit representation of trust levels using a simple hierarchy that reflects organizational privileges Trust hierarchy –Associate a number with each privilege level Numbers reflect security/importance/capabilities of mobile nodes and also of the paths –QoP (Quality of Protection) bit vector Trust level or protection should be immutable – –Keys can be distributed a priori, or a key agreement can be reached by some form of authentication – –Encrypt the portion of the RREQ and RREP headers that contain the trust level.

SAR – PROTOCOL METRICS Secure Ad Hoc Routing – Properties and Techniques used to guarantee these properties PropertyTechnique TimelinessTimestamp OrderingSequence Number Authenticity Password, Certificate AuthorizationCredential Integrity Digest, Digital Signature ConfidentialityEncryption Non-repudiation Chaining of Digital Signatures

PROTECTION IN SAR PROTOCOL Trust Hierarchy –Protocol User Trust Level User Identity –Nodes and users can be forced to respect trust hierarchy using cryptographic techniques, e.g., encryption, public key certificates, shared secrets – –Outsider attacks Threshold cryptography, key sharing, etc. can be used SAR uses simple shared secret to generate a symmetric encryption/decryption key per trust level. – –Insider Attacks Compromised users within a protection domain or trust level Secure transient associations, tamper proofing etc. can be used AAA

PROTECTION IN SAR PROTOCOL Threats to Information in Transit – – Interruption – –Interception and Subversion – –Modification – –Fabrication Replay Attacks: – –SAR uses sequence numbers and timestamps Passive Attacks: – –Examples: covert channels, traffic analysis, sniffing to compromise keys – –Using a suitable MAC layer encryption protocol for protection against sniffing/eavesdropping

SAR - IMPLEMENTATION SAODV ( Security-aware AODV): – –on-demand route discovery using flooding, reverse path maintenance in intermediate nodes, and forward path setup via RREP messages – – RREQ (Route REQuest) packet: RQ_SEC_REQUIREMENT : the security requirement – –Set by the sender; does not change during route discovery phase – –Simple integer values or bit vector RQ_SEC_GUARANTEE : the security guarantee – –Indicates the maximum level of security afforded by all nodes on the discovered path – –Updated at every hop during the route discovery phase If the application requested integrity support, a new field to store the computed digital signatures added to the RREQ – –RREP (Route REPly) packet : RQ_SEC_GUARANTEE : the security guarantee – –Copied from RREQ and sent back to sender to indicate security level over whole path

SAR - IMPLEMENTATION SAODV Route Discovery – –Source node : Set the RQ_SEC_REQUIREMENT field in the RREQ packet Broadcast the packet just as in AODV – –When an intermediate node receives an RREQ First check if the node can satisfy the security requirement indicated in the packet If yes, update the RQ_SEC_GUARANTEE field; forward to its neighbors If no, drop the RREQ packet – –When RREQ arrives at the destination Indicates the presence of a path from the sender to the receiver that satisfies the security requirement specified by the sender Copy RQ_SEC_GUARANTEE from RREQ into RREP Send the RREP back to sender as in AODV

SAR - IMPLEMENTATION – –When an intermediate node receives an RREP The RREP packet arrives at an intermediate node in the reverse path Update its routing table Record the new RQ_SEC_GUARANTEE value – –This value indicates the maximum security available on the cached forward path. – –When a trusted intermediate node answers a RREQ query using cached information Compare RQ_SEC_GUARANTEE of the cached route to the security requirement in the RREQ packet Sent back RREP containing cached path information only if the forward path can guarantee enough security

EXAMPLE SCENARIO - REVISITED Example Scenario – Battlefield communication – –Embed the rank of the node as a metric in route negotiation (establish routes that avoid all privates) – –If no route found, the generals may decide to set up a route that can support 128-bit encryption Transmission range Shortest route through private Secure route through officers only Private Officer General

PERFORMANCE EVALUATION & CONCLUSION SAR enables the discovery of secure routes in a mobile ad hoc environment. Though not optimal, routes discovered by SAR come with “quality of protection" guarantees. The processing overheads in SAR are offset by restricting the scope of the flooding for more relevant routes, providing comparable price/performance benefits. Its integrated security metrics allow applications to explicitly capture and enforce explicit cooperative trust relationships. SAR also provides customizable security (e.g., encryption for confidentiality etc.) to the flow of routing protocol messages themselves The techniques enabled by SAR can be easily incorporated into generic ad hoc routing protocols