Secure routing in multi-hop wireless networks (II) - PowerPoint PPT Presentation

About This Presentation

Secure routing in multi-hop wireless networks (II)


Secure routing in multi-hop wireless networks (II) secured ad hoc network routing protocols; routing security in sensor networks; – PowerPoint PPT presentation

Number of Views:216
Avg rating:3.0/5.0
Slides: 32
Provided by: Tahe6


Transcript and Presenter's Notes

Title: Secure routing in multi-hop wireless networks (II)

Secure routing in multi-hop wireless networks
  • secured ad hoc network routing protocols
  • routing security in sensor networks

  • 1 Securing ad hoc network routing protocols
  • 2 Secure routing in sensor networks

Some secure ad hoc network routing protocols
  • how the countermeasures against security threats
    can be used in routing protocols to provide
  • Some secure routing protocols
  • SRP (on-demand source routing)
  • Ariadne (on-demand source routing)
  • S-AODV (on-demand distance vector routing)

SRP (Secure Routing Protocol)
  • SRP a secure variant of DSR
  • uses symmetric-key authentication (MACs)
  • due to mobility, it is impractical to require
    that the source and the destination share keys
    with all intermediate nodes
  • theres only a shared key between the source and
    the destination
  • key management simplified
  • an end-to-end authenticated exchange of routing
    control information provided between the source
    and the destination
  • The integrity of the route request message is
    protected by a MAC generated using the key shared
    between the source and the destination
  • The intermediate nodes add their identity to the
    request message (they do not verify the MAC as
    they do not know the key with which the MAC was
    computed and they do not add their own MACs to
    the message either)

SRP (Secure Routing Protocol)
  • the MAC will be verified at the destination, if
    the verification is successful a reply message
    will be sent back through the reverse of the path
    obtained from the route request
  • integrity of the reply message is ensured by
    another MAC generated by the destination using
    the same shared key.
  • If the MAC is verified successfully by the source
    node, the route will be accepted to be used to
    transmit data packet.
  • An efficient secure routing protocol (only one
    MAC on the request and one MAC on the reply)
  • but does not prevent the manipulation of mutable
    information added by intermediate nodes (the list
    of IDs)
  • Doors open for some attacks e.g. route diversion
    by modifying the list of intermediate nodes on
    the reply packet
  • some of those attacks can be thwarted by secure
    neighbor discovery protocols

SRP operation illustrated
A ? RREQ, A, H, id, sn, macAH, () B ?
RREQ, A, H, id, sn, macAH, (B) C ? RREQ,
A, H, id, sn, macAH, (C) D ? RREQ, A, H,
id, sn, macAH, (D) E ? RREQ, A, H, id, sn,
macAH, (E) F ? RREQ, A, H, id, sn, macAH,
(E, F) G ? RREQ, A, H, id, sn, macAH, (D,
G) H ? A RREP, A, H, id, sn, (E, F), macHA
Message Authentication Code macAH K_AHRREQ, A,
H, id, sn Sn query sequence number maintained
by the source and the sestination
  • Ariadne is another secured variant of DSR
  • it uses control message authentication to prevent
    modification and forgery of routing messages
  • The control message authentication in Ariadne can
    be based on digital signatures, MACs or TESLA
  • Two differences to SRP
  • in Ariadne not only do the source and the
    destination authenticate the messages, but the
    intermediate nodes also authenticate the route
  • Ariadne uses per-hop hash to prevent removal of
    identifiers from the accumulated route in the
    route request.
  • Ariadne with digital signatures is the simplest
    case among the mentioned variations.

Ariadne with digital signatures
  • A hA macAH( RREQ A H id )
  • A ? RREQ, A, H, id, hA, (), ()
  • E hE H( E hA )
  • E ? RREQ, A, H, id, hE, (E), (sigE)
  • F hF H(F hE)
  • F ? RREQ, A, H, id, hF, (E, F), (sigE,
  • H ? A RREP, H, A, (E, F), (sigE, sigF), sigH
    (sent via F and E)
  • Example A performs the route discovery to
    destination H.
  • The source node computes a MAC over the initial
    route request and broadcasts the message
  • Each intermediate node hashes the received hash
    along with its ID (using a publicly known one-way
    hash function) and computes a digital signature
    and inserts it to the request message (each
    signature is computed over the message fields
    preceding it)
  • The signature is appended to the list of
    signatures of the intermediate nodes and the
    message is re-broadcast.
  • Hash values computed in this way are called
    per-hop hash values

Ariadne with digital signatures
  • When H receives the RREQ it would verify the MAC
    of the source and the per-hop hash values ---gt if
    verified it would generate the RREP
  • Every intermediate node passes the RREP to the
    next node without modifications
  • Node A will verify the signatures of H and the
    intermediate nodes to accept the route returned
    by the reply

Ariadne with standard MACs
  • A hA macAH( RREQ A H id )
  • A ? RREQ, A, H, id, hA, (), ()
  • E hE H( E hA )
  • E ? RREQ, A, H, id, hE, (E), (macEH)
  • F hF H(F hE)
  • F ? RREQ, A, H, id, hF, (E, F), (macEH,
  • H ? A RREP, H, A, (E, F), macHA
  • In Ariadne with standard MACs it is assumed that
    each intermediate node shares a key with the
  • Each intermediate node generates a MAC using such
    a key
  • Again per-hop hash mechanism is used to prevent
    removal of the MACs from the end of the packet by
  • The destination would verify the MACs and the
    hash values if it is successful it will generate
    a RREP

Ariadne with standard MACs
  • The RREP message includes the discovered path and
    a MAC value generated by the destination which
    will be verified by the source to authenticate
    the destination
  • Note that the source can not authenticate the
    intermediate nodes and it must trust to the
    destination to have authenticated them correctly
  • intermediate nodes can authenticate neither the
    RREQ nor the RREP

Symmetric-key broadcast authentication with TESLA
  • MAC keys are consecutive elements in a one-way
    key chain
  • Kn ? Kn-1 ? ? K0
  • Ki h(Ki1)
  • TESLA protocol
  • setup K0 is sent to each node in an authentic
  • time is divided into epochs
  • each message sent in epoch i is authenticated
    with key Ki
  • Ki is disclosed in epoch id, where d is a system
  • When Ki is disclosed it can be verified by
    checking h(Ki) Ki-1 and then the
    authentication can be verified
  • example

Ariadne with TESLA
  • Ariadne with TESLA is very similar to Ariadne
    with digital signatures, but instead of the
    signatures the intermediate nodes compute MACs on
    the route request with their current TESLA keys
  • assumptions
  • each source-destination pair (S, D) shares a
    symmetric key KSD
  • each node F (intermediate node) has a TESLA key
    chain KF,i
  • each node knows an authentic TESLA key of every
    other nodes
  • route request (source S, destination D)
  • S authenticates the request with a MAC using KSD
  • each intermediate node, F, appends a MAC computed
    with its current TESLA key
  • D verifies the MAC of S
  • D verifies that the TESLA key used by F to
    generate its MAC has not been disclosed yet

Ariadne with TESLA
  • route reply
  • D generates a MAC using KSD
  • each intermediate node delays the reply until it
    can disclose its TESLA key that was used to
    generate its MAC and then appends its TESLA key
    to the reply
  • S verifies the MAC of D, and all the MACs of the
    intermediate nodes using their disclosed TESLA
  • Advantage MACs can be calculated more
    efficiently than digital signatures (because of
    using symmetric cryptography)
  • Disadvantage key disclosure delay of TESLA

Ariadne with TESLA
  • A ? RREQ, A, H, id, hA, (), ()
  • E ? RREQ, A, H, id, hE, (E), (macKE,i)
  • F ? RREQ, A, H, id, hF, (E, F), (macKE,i,
  • H ? F RREP, H, A, (E, F), (macKE,i, macKF,i),
    macHA, ()
  • F ? E RREP, H, A, (E, F), (macKE,i, macKF,i),
    macHA, (KF,i)
  • E ? A RREP, H, A, (E, F), (macKE,i, macKF,i),
    macKHA, (KF,i, KE,i)
  • Example A is going to discover a route to H
  • A broadcasts the RREQ and each intermediate node
    (E and F consequently) computes its MAC and the
    per-hop hash value appends them to the message
  • H would verify that the TESLA keys used have not
    been disclosed yet then it will verify the
    per-hop hash values of intermediate nodes
  • If verifications are successful, a RREP will be
    sent back by H over the discovered route, A-E-F-H.

Ariadne with TESLA
  • F waits until it can disclose KF,I and then
    appends the key to the RREP before passing it to
    E (who will do the same).
  • A will authenticate the intermediate nodes by
    verifying their MAC values using the keys KF,I
    and KF,I, and also authenticates the MAC
    generated by H to accept the route.

  • SAODV a secure variant of AODV
  • Provides authenticity, and integrity of routing
    messages and prevents the manipulation of
    hop-count information
  • non-mutable information on the routing messages
    (including the IDs and the sequence numbers of
    the sender and the receiver) is protected with a
    digital signature (of the originator of the RREQ
    or the RREP packets)
  • uses hash chains for the protection of the
    HopCount value
  • new non-mutable fields (added to AODV routing
  • MaxHopCount ( TTL (Time To Live) max number of
    hops that the packet can go)
  • TopHash
  • new mutable field
  • Hash (contains the current hash value
    corresponding to the HopCount value)

  • operation
  • When a node initiates a routing message, it would
  • the Hash field to a random seed value
  • the HopCount field to zero
  • the MaxHopCount field to TTL value
  • The TopHash field to the iterative hash of the
    random seed for MaxHopCount times
  • each time a node increases HopCount, it also
    replaces Hash with H(Hash)
  • verification of the HopCount is done by hashing
    the Hash field (MaxHopCount-HopCount) times and
    checking if the result matches TopHash
  • If the attacker decreases the HopCount the above
    verification would fail and therefore the
    manipulation will be realized by the intermediate
  • But the attacker still can do the following
  • Passing the message without increasing the
    HopCount value and without updating the hash

Provable security for ad hoc network routing
  • the security of the secure routing protocols
    needs to be analyzed to ensure they are free of
  • It has been done mainly by informal means
  • informal reasoning about security protocols is
    prone to errors
  • some attacks have been found against Ariadne and
  • To prove the security of protocols one needs more
  • mathematical models
  • precise definitions
  • sound proof techniques

Elements of such a framework
  • Network model
  • multi-hop communication and the broadcast nature
    of radio channels are explicitly modeled using a
    graph (each vertex models a node and each edge
    models the link between two node who can hear
    each other)
  • Adversary model
  • The abilities and the power of the adversary
    (computational power, ability to capture nods,
  • Configuration
  • Includes the network graph, the set of
    adversarial nodes, labeling of the nodes with
    identifiers, assignments of costs to the nodes
    and the links
  • Correctness criteria
  • Secure routing e.g. only existing routes are
    returned by the protocol

Elements of such a framework
  • Dynamic representation of the system
  • real-world model
  • describes the behavior of the real system
  • ideal-world model
  • How the system should work ideally
  • Formal definition of security
  • Once the models are defined, the goal is to prove
    that for any real-world adversary there exists an
    ideal-world adversary that can achieve
    essentially the same effects in the ideal-world
    model as those achieved by the real-world
    adversary in the real-world model.
  • The existence of such a proof means no attack
    could be possible in real-world model, because
    otherwise it should be possible in the
    ideal-world model too (which is by definition

  • 1 Securing ad hoc network routing protocols
  • 2 Secure routing in sensor networks

Secure routing in sensor networks
  • multi-hop communications
  • Increased network lifetime -- gt crucial to sensor
  • Problem of secure routing
  • Nodes must rely on each other to send their
    packets to others
  • The security issues in wireless sensor networks
    are similar to the ones of ad hoc networks
  • There is more emphasis on resource constraints
    (power, memory size, CPU speed) in sensor
  • Such differences are likely to persist in future
    to keep the price of sensor nodes very low

How are sensor networks different from MANETs?
  • communication patterns
  • sensors to base station (many-to-one)
  • base station to sensors (one-to-many)
  • limited mobility
  • sensor nodes are mainly static
  • topology can change due to node and link failures
  • resource constraints
  • sensor nodes are much more constrained in terms
    of resources
  • infrastructure support
  • the base station can act as a trusted entity

Sensor routing protocols TinyOS beaconing
  • A topology-based routing protocol for sensor
    networks, but insecure.
  • A routing tree is established rooted at the
  • The data packets are sent between the
    base-station and the nodes on the tree.
  • The tree is established using route update
    messages (beacon messages) which are broadcast by
    the sink.
  • A node receiving the route update message for the
    first time sets the neighbor, who is receiving
    the message from, as its parent.

base station (sink)
Authenticated TinyOS beaconing
  • since beacon messages are not authenticated, an
    adversary can initiate the route update process
    and become the root of the established tree
  • to prevent this, the base station should
    authenticate the beacons
  • needs broadcast authentication
  • due to resource constraints, symmetric key crypto
    should be used
  • a possible solution is TESLA
  • this does not entirely solve the problem

Authenticated TinyOS beaconing
  • A more subtle attack
  • intermediate nodes are not authenticated
  • an adversary can use spoofing to create a routing
  • The adversary resides near node u
  • V is a neighbor of u which is further away from
    the sink than u itself
  • The attacker re-broadcasts the beacons in the
    name of v and therefore u sets v as its parent.
  • Later, when u re-broadcasts the beacon v will set
    u as its parent.
  • Result a routing loop is created
  • The resources of the nodes on the loop will be
  • Some packets will never arrive at the sink

IGF (Implicit Geographic Forwarding)
  • Advantage of position-based routing protocols
  • No routing state is required to be maintained by
    the nodes
  • Less overhead than topology-based routing
    protocols (suitable for sensor networks)
  • also more resistance against attacks aiming at
    creating incorrect routing states
  • One example is Implicit Geographic Forwarding
    (IGF) routing protocol

IGF (Implicit Geographic Forwarding)
  • position-based routing integrated with the
    RTS/CTS handshake of the MAC layer
  • when u wants to send a packet, it broadcasts an
  • contains the position of u and that of the
  • neighbors in the 60o sextant set their CTS timer
    inversely proportional to the weighted sum to
    their distance from u, remaining energy, and
    their distance to the line between u and the
  • most desirable next hop will send CTS first
  • all other nodes hear the first CTS and cancel
    their timers

Securing IGF
  • an adversarial node can send CTS immediately and
    become the next hop
  • Solution nodes do not cancel their CTS timers
  • u waits until more neighbors send CTS, and
    selects the next hop randomly
  • an adversary can spoof node IDs and appear with
    multiple identifiers to increase her chances to
    be selected as the next hop (sybil attack)
  • Solution neighbors should be authenticated and
    next hop should be selected from the set of
    authenticated neighbors
  • an insider adversary can still use her
    compromised identifiers
  • Solution monitoring the behavior of neighbors
  • those that often fail to forward packets should
    not be selected as next hop (e.g. assigning trust

  • routing is a fundamental function in networking,
    hence, an ideal target for attacks
  • attacks against routing aim at
  • increasing adversarial control over the
    communications between some nodes
  • degrading the quality of the service provided by
    the network
  • increasing the resource consumption of some nodes
    (e.g., CPU, memory, or energy)
  • many attacks (but not all!) can be prevented by
    authenticating routing control messages
  • it is difficult to protect the mutable parts of
    control messages
  • several secured ad hoc and sensor network routing
    protocols have been proposed which protect the
    network against security threats to some extent.
Write a Comment
User Comments (0)