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

1
SECURITY-AWARE AD-HOC ROUTING FOR WIRELESS
NETWORKSSeung Yi, Prasad Naldurg, Robin
KravetsDepartment of Computer
ScienceUniversity of Illinois at
Urbana-ChampaignAugust, 2001

• Presented by
• Poonam Munshi

2
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

3
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

4
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

Secure route
Private Officer General
Shortest route
Transmission range
5
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

6
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
• 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 RREQs
  security requirements exists, SAR fails to find a
  route even though the network may be connected

7
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.

8
SAR PROTOCOL METRICS

• Secure Ad Hoc Routing Properties and Techniques
  used to guarantee these properties

Property Technique
Timeliness Timestamp
Ordering Sequence Number
Authenticity Password, Certificate
Authorization Credential
Integrity Digest, Digital Signature
Confidentiality Encryption
Non-repudiation Chaining of Digital Signatures
9
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
10
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

11
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

12
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

13
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

14
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

Secure route through officers only
Private Officer General
Transmission range
Shortest route through private
15
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