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

outline 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 security? 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 there’s 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 B G E A C H F 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_AH{RREQ, A, H, id, sn} Sn: query sequence number maintained by the source and the sestination

Ariadne 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 requests 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, sigF) ] 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 B G E A C H F

Ariadne with digital signatures When H receives the RREQ it would verify the MAC of the source and the per-hop hash values ---> 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, macFH) ] 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 destination 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 attackers The destination would verify the MACs and the hash values; if it is successful it will generate a RREP B G E A C H F

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(Ki+1) TESLA protocol: setup: K0 is sent to each node in an authentic way time is divided into epochs each message sent in epoch i is authenticated with key Ki Ki is disclosed in epoch i+d, where d is a system parameter When Ki is disclosed it can be verified by checking h(Ki) = Ki-1 and then the authentication can be verified example: K1 K2 K3 K4 time K0 P1 P2 P3 P4 P5 P6 P7 K1 K2 K3 key disclosure schedule

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 keys Advantage: MACs can be calculated more efficiently than digital signatures (because of using symmetric cryptography) Disadvantage: key disclosure delay of TESLA

Ariadne with TESLA Example: A is going to discover a route to H 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, macKF,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. B G E A C H F

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 (Secure AODV) 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 packets): 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)

SAODV (Secure AODV) operation When a node initiates a routing message, it would set: 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 node But the attacker still can do the following attack: Passing the message without increasing the HopCount value and without updating the hash field

Provable security for ad hoc network routing protocols the security of the “secure” routing protocols needs to be analyzed to ensure they are free of flaws 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 S-AODV To prove the security of protocols one needs more assurances 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, etc.) 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 impossible).

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

Secure routing in sensor networks multi-hop communications: Increased network lifetime -- > crucial to sensor networks 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 networks 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 base-station. 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. sensor 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 loop: 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 exhausted 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 RTS contains the position of u and that of the destination 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 destination 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 values)

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