Open Access

Mobility and Cooperation to Thwart Node Capture Attacks in MANETs

  • Mauro Conti1Email author,
  • Roberto Di Pietro2, 3,
  • Luigi V. Mancini4 and
  • Alessandro Mei4
EURASIP Journal on Wireless Communications and Networking20092009:945943

DOI: 10.1155/2009/945943

Received: 22 February 2009

Accepted: 22 July 2009

Published: 13 September 2009

Abstract

The nature of mobile ad hoc networks (MANETs), often unattended, makes this type of networks subject to some unique security issues. In particular, one of the most vexing problem for MANETs security is the node capture attack: an adversary can capture a node from the network eventually acquiring all the cryptographic material stored in it. Further, the captured node can be reprogrammed by the adversary and redeployed in the network in order to perform malicious activities. In this paper, we address the node capture attack in MANETs. We start from the intuition that mobility, in conjunction with a reduced amount of local cooperation, helps computing effectively and with a limited resource usage network global security properties. Then, we develop this intuition and use it to design a mechanism to detect the node capture attack. We support our proposal with a wide set of experiments showing that mobile networks can leverage mobility to compute global security properties, like node capture detection, with a small overhead.

1. Introduction

Ad hoc network can be deployed in harsh environments to fulfil law enforcement, search-and-rescue, disaster recovery, and other civil applications. Due to their nature, ad hoc networks are often unattended, hence prone to different kinds of novel attacks. For instance, an adversary could eavesdrop all the network communications. Further, the adversary might capture (i.e., remove) nodes from the network. These captured nodes can then be reprogrammed and deployed within the network area, for instance, to subvert the data aggregation or the decision making process in the network [1]. Also, the adversary could perform a sybil attack [2], where a single node illegitimately claims multiple identities also stolen from previously captured nodes. Another type of attack is the clone attack, where the node is first captured, then tampered with, reprogrammed, and finally replicated in the network. The former attack can be efficiently addressed with mechanism based on RSSI [3] or with authentication based on the knowledge of a fixed key set [4], while recent solutions have been proposed also for the detection of the clone attack [5, 6].

To think of a foreseeable application for node capture detection, note that recently the US Defense Advanced Research Projects Agency (DARPA) initiated a new research program to develop so-called LANdroids [7]: Smart robotic radio relay nodes for battlefield deployment. LANdroid mobile nodes are supposed to be deployed in hostile environment, establish an ad-hoc network, and provide connectivity as well as valuable information for soldiers that would later approach the deployment area. LANdroids might retain valuable information for a long time, until soldiers move close to the network. In the interim, the adversary might attempt to capture one of these nodes. We are not interested in the goals of the capture (that could be, e.g., to reprogram the node to infiltrate the network, or simply extracting the information stored in it); but on the open problem of how to detect the node capture that represents, as shown by the above-cited examples, a possible first step to jeopardize an ad hoc network. Indeed, an adversary has often to capture a node to tamper with—that is, to compromise its key set, or to reprogram it with malicious code—before being able to launch other more vicious, and may be still unknown, attacks. Node capture is one of the most vexing problems in ad hoc network security [8]. In fact, it is a very powerful attack and its detection is still an open issue. We believe that any solution to this problem has to meet the following requirements: (i) to detect the node capture as early as possible; (ii) to have a low rate of false positives—nodes which are believed to be captured and thus subject to a revocation process, but which were not actually taken by the adversary; (iii) to introduce a small overhead.

The solutions proposed so far are not satisfactory as for efficiency [8]. Also, while naïve centralized solutions can be applied to generic ad-hoc networks, they presents drawbacks like single point of failure and nonuniform energy consumption. These drawbacks do not make them appealing for ad hoc networks. Moreover, these networks often operates without the support of a base station. Efficient and distributed solutions to the node capture attack are of particular interest in this context.

To the best of our knowledge, there are no distributed solutions for the problem of detecting the node capture attack in Mobile Ad Hoc Networks (MANETs). Following a new interesting research thread that focuses on leveraging mobility to enforce security properties for wireless sensor and ad hoc networks [9, 10], we propose a new capture detection framework that leverages node mobility. We show that this approach can provide better performance compared to traditional solutions. Also, we show that using node cooperation in conjunction with node mobility can still improve the capture detection performance within specific network requirements.

The contribution of this paper is to provide a proof of concept: it is possible to leverage the emergent properties of mobile ad hoc networks via node mobility and node cooperation to design a node capture detection protocol. To this aim, we use the Random Waypoint Mobility Model (RWM) [11], an ideal mobility model which is simple and general enough (at least for some application scenarios) to explore our ideas. Furthermore, the result on any particular mobility model should depend not only from the model but also from the network setting, as pointed out in [12] for the delay-capacity tradeoff. Indeed, providing specific settings and evaluations for other models is out of the scope of this work.

Our solution is based on the simple observation that if node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq1_HTML.gif will not remeet node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq2_HTML.gif within a period https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq3_HTML.gif , then it is possible that node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq4_HTML.gif has been captured. This observation is based on the fact that some time is required to the adversary to tamper with a sensor node. The time required by the adversary to perform such a type of attack was not investigated in the context of sensor network, until the work in [13]. In [13], the authors found out that node capture attacks (that give the adversary full control over a sensor node) are not so easy to implement, contrary to what was usually assumed in literature—indeed, among other requirements (e.g., expert knowledge and costly equipment), node tampering requires the removal of nodes from the network for a nonnegligible amount of time. In particular, while short attacks such as using plug-in devices can be performed in some 5 minutes, medium attacks that require (de-)soldering requires more than 30 minutes, and long attacks and very long attacks (e.g., erasing the security protection bits by UV light or invasive attack on electronic component) can require even some hours.

We will build upon this intuition to provide a protocol that makes use of local cooperation and mobility to locally decide, with a certain probability, whether a node has been captured or not. Our proposed solution does not rely on any specific routing protocol: we resort to one-hop communications and to a sparing use of a message broadcasting primitive. These distinguished features help keep our protocol simple, efficient, and practically deployable, avoiding the use of sophisticated routing that can introduce complexity and overhead in the mobile setting. Furthermore, our experimental results demonstrate the effectiveness and the efficiency of our proposal. For instance, for a given energy budget, while the reference solution requires about 4000 seconds to detect node capture, our proposal requires less than 2000 seconds. We remark that the solution proposed in this paper is completely tunable: the capture detection time can be set as small as desired. However, a smaller detection time would imply an higher energy consumption.

The paper is organized as follows. Section 2 presents the related work in this area. Section 3 introduces the motivation and the framework of our proposal based on simple ad hoc network capabilities like node mobility and message broadcasting. Our specific proposal, the CMC Protocol, is then presented in Section 4, while in Section 5 we discuss the simulation results that give a qualitative idea of how mobility and node cooperation can be leveraged in order to decrease the node capture detection time. Finally, Section 6 reports some concluding remarks.

2. Related Work and Background

Mobility as a means to enforce security in mobile networks has been considered in [9]. Further, mobility has been considered in the context of routing [14] and of network property optimization [15]. In particular, the work in [14] leverages node mobility in order to disseminate information about destination location without incurring any communication overhead. In [15], the sink mobility is used to optimize the energy consumption of the whole network. A mobility-based solution for detecting the sybil attack has been recently presented in [10]. Finally, note that a few solutions exist for node failure detection in ad hoc networks [1619]. However, such solutions assume a static network, missing a fundamental component of our scenario, as shown in what follows.

In this work, we use node mobility to cope with the node capture attack. As described in the following section, we specifically rely on the meeting frequencies between honest nodes to gather information about the absence of captured nodes. A property similar to that of node "remeeting" has been already considered in [20]. However, in [20], the authors investigate the time needed for a node to meet (for the first time) a fixed number of other nodes. This analysis is then used together with node mobility to achieve noninteractive recovery of missed messages. To the best of our knowledge no distributed solution leveraging node mobility has been proposed to detect the node capture attack in mobile ad-hoc and sensor networks.

While node capture attack is considered as major threat in many security solutions for WSN, to the best of our knowledge, it has not been directly addressed yet. However, some interest has been shown in modeling the node capture attack. In particular, in [21], both oblivious and smart node capture is considered for the design of a key management scheme for WSN. A deeper analysis on the modeling of the capture attack has been presented [22, 23]. In [22], it is shown how different greedy heuristics can be developed for node capture attacks and how minimum cost node capture attacks can be prevented in particular setting. In [23], the authors formalize node capture attacks using the vulnerability metric as a nonlinear integer programming minimization problem.

We recently published [24, 25]; the former arguments that mobility models have a relevant effect on the properties of the proposed algorithms, while the latter is a short contribution on the possibility to leverage network mobility for node capture detection. In particular, in [25] we presented the rationales for this type of approach and a preliminary solution to the problem. However, while the results given in [25] are encouraging, the specific solution proposed requires a high overhead to bound the number of false positives (wrongly revoked nodes). Note that, without this bounding mechanism, the number of false positives would be unacceptable. Furthermore, in [25] we did not study the feasibility of the new approach compared with other ones. In the present work, we leverage the intuition proposed in [25], which is the "remeeting" time between nodes, to design an efficient solution that leverages different levels of cooperation between nodes. In particular, we introduce a presence-proving mechanism used by allegedly captured nodes to show their actual presence in the network (i.e., eliminating the possibility of revoking a node which is present within the network). Further, we introduce a reference solution in order to quantify the quality of the proposed solutions. The proposed solutions are compared between them and with the reference solution. In particular, to have a fair comparison, we observed the detection time provided by the different protocols using the same energy budget. The result of our study confirms the intuition provided in [25]. Furthermore, it proves that within certain scenarios of node mobility, the proposed solutions provide a sensitive improvement over other possible approaches, such as the one based on classical message exchange.

Node mobility and node cooperation in a mobile ad hoc setting have been considered already in Disruption Tolerant Networks (DTNs) [26, 27]. However, such a message passing paradigm has not been used, so far, to support security. We leverage the concept introduced with DTN to cooperatively control the presence of a network node. Mobility to recover the secret state of a node has been recently introduced in [28, 29]. In this paper, we use one of the most common mobility patterns in literature, the Random Waypoint Mobility Model [11]. In this model, it is assumed that each node in the network acts independently: it selects a geographic destination in the deployment area (the way-point), it selects a speed uniformly at random in a given interval https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq5_HTML.gif , and then it moves toward the destination on a straight route at the selected speed. When at the way-point, it waits for some time, again selected uniformly at random from a given interval, and then the node repeats the process by choosing the next way-point. Some researchers have shown some problems related to this mobility model. One of the problems is that the average speed of the network tends to decrease during the life of the network itself and, if the minimum speed that can be selected by the nodes is zero, then average speed of the system converges to zero [30]. In the same paper, it is suggested to set the minimum speed to a value strictly greater than zero. In this case, the average speed of the system continues decreasing, but it converges to a nonzero asymptotic value. Other problems related to spatial node distribution have been considered by different authors [30, 31]. In the analysis presented in [14], "human speeds" are claimed to be a reasonable practical choice for mobile nodes. Note that the RWM might not be the best model to capture a "realistic" mobility scenario, as highlighted in [12]; however, the results achieved in this paper are meaningful as they are a proof of concept that mobility can be leveraged to enforce security properties; the provided protocols could be used in, and adapted to, more realistic mobility models.

In our proposed approach every node maintains its own clock. However, we require that clocks among nodes are just loosely synchronized. Note that there are a few solutions proposed in literature to provide loose time synchronization, like [32]. Therefore, in the following we will assume that skew and drift errors are negligible.

In our proposal, we also need to take into consideration the cost of broadcasting a message to all the nodes in the network. In [33], a classification of the different solutions for broadcasting scheme is provided: (i) Simple Flooding; (ii) probabilistic-based schemes; (iii) area-based schemes that assume location awareness; (iv) neighbor knowledge schemes that assume knowledge of two hop neighborhood.

Analyzing or comparing broadcasting cost is out of the scope of this paper. However, for a better comparison of the solutions proposed in this paper, we need to set a broadcast cost that will be expressed in terms of unicast messages. In fact, the overhead associated to the broadcasting varies with different network parameters (e.g., node density and communication radius). A deeper analysis on the overhead generated for different broadcasting protocols is presented in [34]. Also, note that probabilistic-based and neighbor-based protocols require a big overhead for a mobile network in order to know the network topology and neighborhood, respectively. Furthermore, the same argument can be considered for the localization protocol that is used in the area-based schemes. In the following, to embrace the more general case, we assume that nodes are not equipped with localization devices, like GPS. Finally, note that a message could be received more than once, for instance, because the receiver is in the transmission range of different rely nodes. However, in the following, we assume that a broadcasted message is received (then counted) only once for each node. A similar assumption is used, for example, in [34].

3. Node Capture Detection through Mobility and Cooperation

The aim of a capture detection protocol is to detect as soon as possible that a node has been removed from the network. In the following, we also refer to this event as a node capture. The protocol should be able to identify which is the captured node, so that its ID could be revoked from the network. Revocation is a fundamental feature—if the adversary reintroduces the captured (and possibly reprogrammed) node in the network, the node should not be able to take part to the network operations.

In the following, we first describe a simple distributed solution that does not exploit neither mobility nor cooperation among nodes; we use this solution as a reference solution to compare with our proposal. Then, we introduce the rationals we leverage to develop our protocol for node capture detection, detailed in the following section.

3.1. Reference Solution

To the best of our knowledge, no efficient and distributed solution leveraging mobility was proposed so far to cope with the node capture detection problem in Mobile Ad Hoc Network. However, a naïve solution that makes use of node communication capabilities can be easily figured out. We first describe this solution assuming the presence of a base station (BS); then, we will show how to relax this assumption. In the BS-based solution, each node periodically sends a message to the BS carrying some evidence of its own presence. In this way, the base station can witness for the presence of the claiming nodes. If a node does not send the claim of its presence to the BS within a given time range, the base station will revoke the corresponding node ID from the network (e.g., flooding the network with a revocation message). To remove the centralization point given by the presence of the BS, we require each node to notify its presence to any other node in the network. To achieve this goal, every https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq6_HTML.gif seconds a node sends a claim message advertising its presence to all the network nodes through a broadcast message. A node receiving this claim would restart a timeout set to https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq7_HTML.gif where https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq8_HTML.gif accounts for network propagation delay. Should the presence claim not be received before the timeout elapses, the revocation procedure would be triggered. However, note that if a node is required to store the ID of any other node as well as the receiving time of the received claim message, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq9_HTML.gif memory locations would be needed in every node. To reduce the memory requirement on node, it is possible to assume that the presence in the network of each node is tracked by a small subset of the nodes of the network. Hence, if a node is absent from the network for more than https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq10_HTML.gif seconds, its absence can still be detected by a set of nodes.

3.2. Our Approach

Our approach is based on the intuition that leveraging node mobility and cooperation helps node capture detection. We start from the following observation: if node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq11_HTML.gif has detected a transmission originated by node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq12_HTML.gif , at time https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq13_HTML.gif , we will say that a meeting occurred. Now, nodes https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq14_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq15_HTML.gif are mobile, so they will leave the communication range of each other after some time. However, we expect these two nodes to remeet again within a certain interval of time, or at least within a certain time interval with a certain probability. The solution can also be thought of as an exploitation of the opportunistic communication concept [27], like contact-based message delivery, to wireless ad hoc network security. In [25], the authors investigated how mobility can be used to detect a node capture and investigated the feasibility of mobility-based solutions. As a starting point, we analysed the remeeting probability through network simulation: the results comply with previous studies on delay in mobile ad hoc networks [12]. In Figure 1, we report on the simulation results on the probability that two nodes that had a meeting would not have a meeting again after https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq16_HTML.gif seconds. This probability has been evaluated for different values of the communication radius. In particular, we assume that the nodes are randomly deployed in a square area of https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq17_HTML.gif and that they move according to the random way-point mobility model. While the https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq18_HTML.gif -axis indicates the time after the last meeting, the https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq19_HTML.gif -axis indicates the probability that the two nodes have not remet yet. For example, assume that node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq20_HTML.gif meets node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq21_HTML.gif at time https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq22_HTML.gif , then the probability that these two nodes have not met again after https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq23_HTML.gif seconds is very close to https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq24_HTML.gif (for a sensing radius https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq25_HTML.gif ).
https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_Fig1_HTML.jpg
Figure 1

Noncooperative approach: the probability for two nodes not to remeet again: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq26_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq27_HTML.gif  m/s, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq28_HTML.gif  m/s.

In the following section, we propose a protocol that leverages node mobility to enhance node capture detection probability.

3.3. Assumptions and Notation

In the remaining of the paper, we assume a "smart" attacker model: it knows the detection protocol implemented in the network. This implies, for the reference solution, that a node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq29_HTML.gif is captured just after node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq30_HTML.gif has broadcasted its presence claim message. The assumption at the base of our protocol is that if a node has been absent from the network for a given interval time (i.e., none can prove its presence in that interval) the node has been captured. It is worth noticing that also if a node is temporarily disconnected, a DTN-like routing mechanism [35] can be used to deliver a message to that node with some delay. For the aim of our protocol, we do not explicitly consider that interval time.

In the following we define a false-positive alarm as an alarm raised for a node that is actually present. One or more false-positive alarms can imply a false-positive detection, which corresponds to the revocation of a not captured node. Further, we refer to a false-negative detection as a captured node not actually revoked. However, we observe that using the presence-proving mechanism introduced in this paper (later discussed in Section 4), a node that is accused by a false-positive alarm would prove its presence, hence neutralizing the revoke. Furthermore, we observe that accordingly to our protocol, a node no longer active (e.g., destroyed or with run out batteries) would be revoked. However, there would be no false alarms and the overhead paid for the protocol would be just one network flooding. The flooding would allow every node in the network to be aware of the absence of the failed node—having a beneficial effect for other protocols such as routing. In general, we cannot distinguish if a node is not able to communicate with the other network nodes for a nonmalicious reason, or because it has been actually captured—our solution is conservative in this way, revoking such a node. It is out of the scope of this paper, and left as future work, to address the recovery of the former type of revoked nodes.

Another issue is Denial of Service (DoS). Indeed, since alarms are flooded in the network, it could be possible for a corrupted node to trigger false alarms so as to generate a DoS. This issue is out of the scope of this paper, however, for the sake of completeness, we sketch in the following a possible solution. The impact of false positives can be mitigated noticing that it could be possible, once the recovery mechanism detects a false alarm, to associate a failure tally to the node that raised the false alarm. If the tally exceeds a certain threshold, the appropriate action to isolate the misbehaving node could be take.

Further, we assume the existence of a failure-free node broadcasting mechanism [36]; and, finally, we point out that addressing node-to-node secure communications properties such as confidentiality, integrity, privacy, and authentication are out of the scope of this paper. However, note that a few solutions explicitly addressing these issues can be found in literature [4, 37, 38].

Table 1 resumes the intervals time notation used in this paper.
Table 1

Time-related notation.

Symbol

Meaning

https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq31_HTML.gif

Message propagation delay.

https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq32_HTML.gif

Alarm time used in CMC (our proposal).

https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq33_HTML.gif

Time available to the allegedly captured node

 

to prove its presence.

4. The Protocol

In this section, we describe our proposal for a node Capture detection protocol that leverages Mobility and Cooperation (CMC Protocol). Basically, each node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq34_HTML.gif is given the task of witnessing for the presence of a specific set https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq35_HTML.gif of other nodes (we will say that https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq36_HTML.gif is tracking nodes in https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq37_HTML.gif ). For each node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq38_HTML.gif that https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq39_HTML.gif gets into the communication range of, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq40_HTML.gif sets a new time-out for https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq41_HTML.gif with the value of the https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq42_HTML.gif 's internal clock; the time out will expire after https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq43_HTML.gif seconds. The meeting nodes can also cooperate, exchanging information on the meeting time of nodes of interests, that is, nodes that are tracked by both https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq44_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq45_HTML.gif . Note that node cooperation is an option that can be enabled or disabled in our protocol. If the time-out expires (i.e., https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq46_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq47_HTML.gif did not remeet within https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq48_HTML.gif seconds), https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq49_HTML.gif floods the network with an alarm message. If node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq50_HTML.gif does not prove its presence within https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq51_HTML.gif seconds after the broadcasted alarm is flooded, every node in the network will revoke node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq52_HTML.gif . The detailed description of the CMC protocol follows.

4.1. Protocol Description

The CMC protocol is event-based; in particular, it is executed when the following holds.
  1. (i)Node

    https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq53_HTML.gif and node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq54_HTML.gif meet: this event triggers node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq55_HTML.gif and node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq56_HTML.gif to execute https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq57_HTML.gif and CMC_Meeting https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq58_HTML.gif respectively, if the cooperation parameter is set to false. Otherwise, node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq59_HTML.gif executes CMC_Meeting https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq60_HTML.gif and node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq61_HTML.gif executes CMC_Meeting https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq62_HTML.gif . The function CMC_Meeting is also used in the cooperative scenario as a virtual meeting in order to update node presence information.

     
  2. (ii)

    The time-out related to node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq63_HTML.gif expires on node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq64_HTML.gif : node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq65_HTML.gif executes the procedure CMC_TimeOut https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq66_HTML.gif .

     
  3. (iii)

    Node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq67_HTML.gif eavesdrops a message https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq68_HTML.gif : node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq69_HTML.gif executes the procedure CMC_Receive(m).

     

Algorithms 1, 2, and 3 show the corresponding pseudocode. The procedure CMC_Meeting, shown in Algorithm 1, is executed by both nodes involved in a meeting. In the case of a real meeting, the time is not specified, then the current node time https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq70_HTML.gif is used. However, when the procedure is invoked as a virtual meeting, a reference time ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq71_HTML.gif ) is also considered (lines 2, 3, and 4). When node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq72_HTML.gif meets node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq73_HTML.gif , node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq74_HTML.gif checks if it is supposed to trace node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq75_HTML.gif (that is if https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq76_HTML.gif ). This check is performed using the Trace function (line 5). It takes in input two node IDs, and provides a result pseudouniformly distributed in https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq77_HTML.gif —where https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq78_HTML.gif is the size of the wireless ad hoc network and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq79_HTML.gif is the number of nodes tracked by each node. Node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq80_HTML.gif is to be tracked if and only if the result of the Trace function is one. A simple and efficient implementation of the function Trace can be found in [39], where it has been used in the context of pairwise key establishment. Assume now that https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq81_HTML.gif , then a further check on node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq82_HTML.gif is performed (line 6). Indeed, node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq83_HTML.gif could be already revoked. Hence, each node stores a Revocation Table ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq84_HTML.gif ) that lists the revoked nodes. If both previous tests (lines 5 and 6) succeed, then https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq85_HTML.gif calls the function Update that updates the information about the last meeting with node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq86_HTML.gif (line 7). For example, if node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq87_HTML.gif meets https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq88_HTML.gif at a given time https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq89_HTML.gif , the function Update sets the information https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq90_HTML.gif in the https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq91_HTML.gif (a Check Table stored in node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq92_HTML.gif memory). Node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq93_HTML.gif uses a Time-out Table https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq94_HTML.gif to store and signal the following time-outs:

Algorithm 1: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq95_HTML.gif . Node meeting event handler.

Input: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq96_HTML.gif : ID of the executing node. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq97_HTML.gif : ID of the met node. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq98_HTML.gif : Current time of node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq99_HTML.gif . https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq100_HTML.gif : Check Table stored in node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq101_HTML.gif memory. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq102_HTML.gif : Revoked nodes table stored in node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq103_HTML.gif memory. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq104_HTML.gif : Time out table stored in node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq105_HTML.gif memory. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq106_HTML.gif : Alarm time. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq107_HTML.gif : Time for the accused node to prove its presence. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq108_HTML.gif : Boolean variable for cooperation option.
  1. 1

    begin

     
  2. 2

    if  NotSpecified ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq109_HTML.gif )then

     
  3. 3

    https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq110_HTML.gif ;

     
  4. 4

    end

     
  5. 5

    if  Trace( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq111_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq112_HTML.gif = https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq113_HTML.gif   then

     
  6. 6

      if   Is-Not-Revoked ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq114_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq115_HTML.gif )then

     
  7. 7

    Update ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq116_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq117_HTML.gif );

     
  8. 8

    UpdateTimeOut ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq118_HTML.gif ,

    https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq119_HTML.gif );

     
  9. 9

      end

     
  10. 10

    end

     
  11. 11

    if https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq120_HTML.gif   then

     
  12. 12

      foreach   https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq121_HTML.gif   do

     
  13. 13

         If  Is-Not-Revoked ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq122_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq123_HTML.gif )then

     
  14. 14

             If   Trace ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq124_HTML.gif ) = 1then

     
  15. 15

              https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq125_HTML.gif Look-Up ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq126_HTML.gif );

     
  16. 16

              https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq127_HTML.gif ;

     
  17. 17

             end

     
  18. 18

         end

     
  19. 19

      end

     
  20. 20

    end

     
  21. 21

      end

     

Algorithm 2: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq128_HTML.gif . Node Time Out event handler.

Input: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq129_HTML.gif : ID of the executing node. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq130_HTML.gif : ID of the node which time-out is expired. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq131_HTML.gif : Current time of node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq132_HTML.gif . https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq133_HTML.gif : Revoked nodes table stored in node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq134_HTML.gif memory. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq135_HTML.gif : Time out table stored in node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq136_HTML.gif memory. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq137_HTML.gif : Time for the accused node to prove its presence.
  1. 1

       begin

     
  2. 2

    if   TimeOutKind(ALARM) then

     
  3. 3

       Flooding ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq138_HTML.gif );

     
  4. 4

       UpdatingTimeOut ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq139_HTML.gif

    https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq140_HTML.gif );

     
  5. 5

    else

     
  6. 6

    RevokeNode ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq141_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq142_HTML.gif )

     
  7. 7

    end

     
  8. 8

       end

     

Algorithm 3: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq143_HTML.gif . Received message event handler.

Input: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq144_HTML.gif : ID of the executing node. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq145_HTML.gif : Current time of node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq146_HTML.gif . https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq147_HTML.gif : Received message. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq148_HTML.gif : Revocation Table stored in node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq149_HTML.gif memory. https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq150_HTML.gif : Time for the accused node to prove its presence.
  1. 1

      begin

     
  2. 2

    https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq151_HTML.gif ;

     
  3. 3

    if https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq152_HTML.gif   then

     
  4. 4

    if https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq153_HTML.gif   then

     
  5. 5

    if   Is-Not-Revoked ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq154_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq155_HTML.gif ) then

     
  6. 6

    UpdateTimeOut ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq156_HTML.gif

        https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq157_HTML.gif );

     
  7. 7

    end

     
  8. 8

    else

     
  9. 9

    Flooding ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq158_HTML.gif );

     
  10. 10

      end

     
  11. 11

    end

     
  12. 12

    if https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq159_HTML.gif then

     
  13. 13

    https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq160_HTML.gif ( https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq161_HTML.gif );

     
  14. 14

    end

     
  15. 15

    https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq162_HTML.gif ;

     
  16. 16

      end

     
  1. (i)

    ALARM time-out, which is triggered after https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq163_HTML.gif seconds are elapsed without remeeting node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq164_HTML.gif .,

     
  2. (ii)

    REVOKE time-out, which is triggered after https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq165_HTML.gif seconds are elapsed from receiving/triggering a node revocation for node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq166_HTML.gif —assuming that in these https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq167_HTML.gif seconds no presence claim from https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq168_HTML.gif are received.

     

Then, for each meeting with non-revoked nodes in https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq169_HTML.gif , node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq170_HTML.gif removes any previous time-out for the met node and sets a new ALARM time-out for that node (line 8). Note that both the update functions (lines 7 and 8) do not perform any operation if the time argument https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq171_HTML.gif is lower than the currently stored meeting time for the node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq172_HTML.gif : . This could happen in the case of a virtual meeting.

If the cooperation option is set (COOP_opt=true in line 11), also the following steps are performed. For each not revoked node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq173_HTML.gif traced by both node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq174_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq175_HTML.gif (lines 12, 13, and 14), node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq176_HTML.gif sends a CLAIM message to https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq177_HTML.gif carrying the meeting time between https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq178_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq179_HTML.gif . Each CLAIM message has the following format: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq180_HTML.gif , where https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq181_HTML.gif is the sender of the claim message, CLAIM is the message type, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq182_HTML.gif is the ID of node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq183_HTML.gif the claim is related to, and the last parameter indicates the meeting time between https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq184_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq185_HTML.gif . Another message type is ALARM, described in the following.

CMC_TimeOut (Algorithm 2) is triggered when a time-out expires. If on node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq186_HTML.gif an ALARM time-out expires for node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq187_HTML.gif , this means that node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq188_HTML.gif did not meet node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq189_HTML.gif for a time https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq190_HTML.gif . Then, node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq191_HTML.gif floods the network with an alarm (Algorithm 2, line 3) and a new REVOKE time-out for node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq192_HTML.gif is set. Each ALARM message has the following format: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq193_HTML.gif , where https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq194_HTML.gif is the sender of the claim message, ALARM notifies the message type, and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq195_HTML.gif is the ID of node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq196_HTML.gif the alarm is related to. When a REVOKE time-out expires, this means that after https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq197_HTML.gif seconds elapsed from the alarm triggering, no evidence of the presence in the network of the suspected captured node appeared. In this latter case, a node revocation procedure for node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq198_HTML.gif is invoked by node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq199_HTML.gif .

CMC_Receive (Algorithm 3) is invoked when a message MSG is received. The fields of the message are assigned to local variables (line 2) and the type of the message is checked (line 3). Assume the message is of type ALARM: the executing node checks if the alarm is related to itself (line 4).

If the latter test fails, a further check is performed: the node checks whether the node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq200_HTML.gif is not already revoked (line 5). If the check succeeds, a REVOKE time-out is set through an UpdateTimeOut procedure. Note that a REVOKE time-out for node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq201_HTML.gif already should be in place, this procedure does not override the existing REVOKE time-out and simply returns. If the ALARM is related to the executing node itself (test performed at line 4 fails) node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq202_HTML.gif will flood the network with a presence CLAIM message (line 9). This measure prevents false-positive detection, that is, the revocation of nodes that are active in the network.

If the received message is of type CLAIM, this means that a node that was the target of an ALARM message is proving its presence; this message triggers a virtual meeting between https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq203_HTML.gif and the wrongly accused nodes (line 13). The overall result is that node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq204_HTML.gif disables the REVOKE time-out for that node while restarting the ALARM time-out for the same node. These activities are also triggered when the COOP_opt is set (in fact, a CLAIM message is also sent in line 16, Algorithm 1). The objective of this invocation is to update the information on traced nodes via an information exchange with the met nodes.

Finally, when https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq205_HTML.gif receives a message issued by node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq206_HTML.gif which is not originated within the protocol (e.g., it can be originated by the application layer), this message can be interpreted by the protocol as an evidence of the presence of node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq207_HTML.gif . Therefore, this can be interpreted as a special case of a node meeting, and the appropriate actions are triggered (line 15).

5. Simulations and Discussion

We performed simulations using a self-developed discrete event simulator. The simulator is written in C++ and implements the Random Waypoint Mobility Model. The events (nodes meeting, node arrival at its selected destination, and alarms time-out) are pushed to and pulled from an ideal time-line. Initially, nodes are assumed to be randomly deployed over a network area. Then, until the simulation ends, for each node, a random speed and destination location are randomly chosen (within the bounds set by the user): this implies to analyze and to order all the meeting events and the node arrival events with reference to the time-line. While the time goes by, the events on the time-line are processed. The events corresponding to node arrival are processed as previously described (choosing a destination, a node speed, and analyzing the new generated events). The node meeting events are processed as the core part of our detection protocol, for example, updating the time-out or sharing information with the met nodes. The alarms time-out expiring event generates the network flooding.

As for the energy model, we adopted the one proposed in [40]. To plot each point in the following graphs (as well as for Figure 1), we performed a set of experiments and reported the averaged results; the number of experiments has been set to achieve a confidence interval of https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq208_HTML.gif .

The comparison on the detection time between our protocol and the reference solution has been performed considering the energy cost. In particular, the energy cost has been expressed as a frequency of network flooding, as explained later.

5.1. Node Remeeting

In order to better understand how mobility and cooperation can speed up the capture detection process, we performed a first set of simulations to assess the frequency of node-to-node meetings. We considered a network of https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq209_HTML.gif nodes randomly deployed over a square area of https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq210_HTML.gif . We used the random waypoint mobility model as the node mobility pattern. In particular, in our simulations we set the value for the minimum node speed greater than zero—this is a way to solve the decreasing average node speed problem of the random waypoint mobility model [8].

The experiment was set in this way: we choose two nodes https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq211_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq212_HTML.gif ; when they meet, we set time at https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq213_HTML.gif and continued following these nodes thorough their network evolution to experimentally determine how long it takes for these two nodes to meet again, in both the noncooperative and in the cooperative case. Crucially, in the cooperative scenario, if node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq214_HTML.gif meets node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq215_HTML.gif and sends to it all the information https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq216_HTML.gif received during its last meeting with node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq217_HTML.gif , this also accounts as a meeting between https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq218_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq219_HTML.gif .

We performed the simulation for different values of sensing radius and average node speed both for the noncooperative and the cooperative scenario. The results are shown in Figure 2. The experiments support the following, simple intuitions: node cooperation increases the meeting probability; the higher is the sensing radius, the higher is the meeting probability; and the higher is the average node speed, the higher is the meeting probability. We used these results also to propose a reasonable value for the variable https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq220_HTML.gif to be used in the implementation of our proposal, for both the cooperative and noncooperative case.
https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_Fig2_HTML.jpg
Figure 2

Probability for two nodes not to remeet: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq221_HTML.gif Without node cooperation, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq222_HTML.gif  m/sWith node cooperation, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq223_HTML.gif  m/sWithout node cooperation, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq224_HTML.gif  m/sWith node cooperation, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq225_HTML.gif  m/s

5.2. Experimental Results

Parameters Tuning

As observed in previous work [25], all the protocols parameters are correlated, for example, increasing the average speed of the network would increase the number of meetings between nodes, hence reducing the number of false alarms. However, if we assume that parameters such as the network size, the nodes' mobility, and the network area are given, the main parameters that the network administrator can set is the alarm time https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq226_HTML.gif . In Figures 3(a) and 3(b) we show the influence of https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq227_HTML.gif over the detection time and the rate of false positive alarms. We notice that increasing the alarm time also increases the detection time while decreasing the number of false positives. In particular, from Figure 3(a), we observe that the detection time increases linearly with https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq228_HTML.gif . Furthermore, we observe that the detection time using node cooperation is higher than the one without node cooperation. The motivation follows from the fact that without node cooperation nodes have stale information about the presence of the traced nodes. So, when a node is really captured, in the noncooperative scenario there will be some nodes that are already not meeting the captured node for a while. These nodes would raise the capture alarm before https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq229_HTML.gif seconds elapses after the real node capture, hence decreasing the detection time with respect to the cooperative protocol. From Figure 3(a), we observe that the false alarms rate decreases exponentially with https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq230_HTML.gif . Comparison between Figures 3(a) and 3(b) suggests that there is a tradeoff between the detection time and the number of false alarms. In order to give a straight and fair comparison between the proposed solutions (cooperative and noncooperative) and also with the reference solution, in the following section, we compare the detection time of the solutions on the basis of the overall energetic cost.
https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_Fig3_HTML.jpg
Figure 3

Influence of on CMC performances: ,  m, Avg speed = 15 m/s. Detection timeFalse alarms rate

Energy-Driven Comparison

One of the key issues in ad hoc and sensor network is the energy consumption. Hence, we compared our proposal with the reference solution focusing on energy consumption. To provide an evaluation of our protocols in a manner that is device-independent, we chose to express the energy consumption in terms of generated messages. As for the energy devoted to computation, we considered the cost be negligible, as in [40].

The main communication cost of both our protocol and the reference solution is the number of flooding. The reference solution uses the flooding as a presence claim message while our protocol uses the flooding for both alarm broadcast and alarm-triggered presence notification; the latter flooding occurs when a node that has been erroneously advertised as possibly compromised sends (floods) a claim of its actual presence. To simplify our discussion, we assume that a network flooding corresponds to sending and to receiving a message by each network node. This is not always the case; actually, the load for broadcasting varies with different network parameters and the specific broadcasting protocol used [34]. However, this approximation is good enough to achieve our goal, that is, to show the qualitative improvement of our solution over the reference solution. To better appreciate the comparison with the reference solution—where a flooding occurs every time interval—in the following graphs, we report on the https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq234_HTML.gif -axis the time interval between two subsequent flooding, instead of the flooding frequency. Note that once the flooding interval is fixed, also the amount of required energy is fixed, and we can plot the performance of our protocol when using the same amount of energy, that is, the same amount of messages.

In our simulation, we analyze how increasing the energy overhead affects the detection time. In other words, we fix the energy overhead at the same level for both protocols under evaluation, and measure which protocol achieves the best detection time.

Performance

To compare the performance of the proposed solution with the reference solution presented in Section 3.1, we implemented our protocol. In what follows, we fix a sensing radius of https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq235_HTML.gif . Since nodes in ad hoc settings could have strict memory constraints (e.g., in sensor network), in our simulations, we assume that each node traces a small number of other nodes. In fact, as a result of the pseudorandom function Trace (Algorithm 1, line 2) each node traces exactly 5 other network nodes. For the cooperative scenario, when two nodes https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq236_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq237_HTML.gif meet, they exchange the information concerning the nodes tracked by both https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq238_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq239_HTML.gif ; we assume that this information can be contained in one message. Indeed, the number of shared traced nodes can be up to 5 (number of nodes traced by each node), but in practice, it turns out to be much smaller, on average (0.25 in our setting). We simulated our protocol with and without node cooperation, varying the alarm time from 250 to 8000 seconds and the average node speed from 5 m/s to 20 m/s. Figures 4(a) and 4(b) show the results of the simulation of our protocol without and with cooperation, respectively. Figure 4(a) shows the results when cooperation is switched off, for the two protocols and different speeds. On the https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq240_HTML.gif -axis, we fix the flooding interval for the reference solution protocol. In this way, the detection time is also fixed for the reference solution and it does not change when changing the speed. The quality of the detection for the reference solution is just linear: by doubling the flooding interval also the detection time doubles, while the energy cost halves. Figure 4(a) confirms our intuition: mobility with local cooperation can help computing global properties incurring in a small overhead.

In this simulation scenario, for a reasonable speed of nodes, our protocol outperforms the reference solution. Take, as an example, a flooding interval of 50 seconds. From Figure 4(a), we can see that the detection time of the reference solution protocol is 5000 seconds. The performance of our protocol depends on the average speed of the system. If the average speed of the system is slow, for example, 5 m/s, then the detection time is more than 6000 seconds. However, if the network nodes move faster, then our solution improves over the reference solution. For instance, when the average speed is 20 m/s, the detection time is as low as 1600 seconds, much faster than the reference solution. From this experiment, it is also clear that the performance of our protocol depends on the average speed in the network: the faster the better. While the reference solution is an excellent solution for slow networks, for example, where nodes are carried by humans walking, our solution is the best for faster networks, and it is always the best when the energy overhead must be low. Now, we will switch cooperation on, and see that the performance of our protocol increases considerably, even though with some drawbacks when the energy budget is small.

Figure 4(b) describes the performance of our protocol when using cooperation. When the network flooding frequency is high, that is, network flooding interval is small, cooperation is very effective. Further, with cooperation, the performance of our protocol improves as the average speed of the nodes increases. In this case, our protocol is better than the reference solution even when starting from very high flooding frequency, that is, starting from systems that are very fast in detecting the node capture attack and that, consequently, have very high energy requirements. What is less intuitive is that cooperation is not useful when we move to more energy-saving systems. Take, as an example, a network where the average speed is 15 m/s. Our protocol is better than the reference solution whenever the design goal is to have a network with more energy available and to achieve a small detection time, that is, in Figure 4(b), whenever the flooding interval is smaller than 38 seconds. However, when considering a network with more stringent energy requirements, for example, when the flooding interval is 50 seconds, then it is simply not possible to reach such low energy costs by using cooperation. Cooperation has a cost, which is higher when the network is faster—indeed, in a faster network, the nodes meet more frequently, and thus cooperation is higher. In this case, the correct design guideline is to use our protocol with cooperation, if the objective is to have a system that is fast in detecting the node capture attack, though using more energy—in particular, in our example until a flooding interval of 38 seconds—and then to switch cooperation off, to get a cheaper protocol that can be used when the flooding interval can be larger.

As described in Figure 4(b), the limits of cooperation appear sooner in faster networks. This is intuitive, cooperation is more costly when nodes meet more often, and so the tradeoff moves toward noncooperation earlier. The implications of using mobility and local communications to compute global properties are not self-evident. If the network is fast enough, it is always better to use protocols like the one we propose rather than using static approaches like the reference solution. However, node cooperation flavored techniques, which appears to be effective in any case, have the result of making the information in the network spread faster, but at a cost.
https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_Fig4_HTML.jpg
Figure 4

CMC Detection time: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq241_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq242_HTML.gif  m. Without node cooperationUsing node cooperation

5.3. Massive Attacks

In order to investigate the behavior of our protocol under a massive attack, we simulated the capture of 10% of the network nodes (10 out of 100) at the same time. We fixed the average speed at 15 m/s. Simulation results are shown in Figures 5(a) and 5(b) for the noncooperative and cooperative scenarios, respectively. For both cases, the figures show the result for one captured node and 10 captured nodes in a network of 100 nodes. From both figures, we can see that all the protocols, both the reference solution and our solution, with or without cooperation, are robust against massive attacks. Indeed, the small differences in performance do not justify a change in the defense strategy but for small intervals.
https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_Fig5_HTML.jpg
Figure 5

CMC Detection time under massive attack: https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq243_HTML.gif , https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq244_HTML.gif  m, https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq245_HTML.gif  m/s. Without node cooperationUsing node cooperation

5.4. Other Mobility Patterns

We stress once again that the aim of this work is to give a proof of concept that both node mobility and node cooperation can help thwarting the node capture attack. Hence, to abstract from mobility details we choose to use the Random Waypoint Mobility Model. Mobility models based on randomly moving nodes may, for example, provide useful analytical approximations to the motion of vehicles that operate in dispatch mode or delivery mode [41]. It is important to note that the results obtained in this work are not directly applicable to others scenario-inspired mobility models [12]; for instance, while intermeeting time follows an exponential distribution under the RWM, intermeeting time is shown to be better approximated by a power-law distribution in some scenarios [12, 42]. However, it is also interesting to note that our solution allows the network to let autonomously emerge the subgroups of nodes that meet with higher frequency (communities). In fact, this can be done leveraging the false-positive alarm: if node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq246_HTML.gif sends a high number of false alarms (further revoked by the accused node) related to node https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq247_HTML.gif , this implies that https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq248_HTML.gif actually does not meet with https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq249_HTML.gif with "high" frequency. This information can be interpreted as if https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq250_HTML.gif and https://static-content.springer.com/image/art%3A10.1155%2F2009%2F945943/MediaObjects/13638_2009_Article_1776_IEq251_HTML.gif do not belong to the same community.

6. Conclusions

In this paper we have proposed, to the best of our knowledge, the first distributed solution to a major security threat in MANETs: the node capture attack. Our solution is based on the intuition that node mobility, together with local node cooperation, can be leveraged to design security protocols that are extremely effective and energy-efficient. We have also developed a protocol that, increasing the level of cooperation among nodes, makes global information flow faster in the network, even if at a cost in terms of energy. The experiments clearly show that leveraging mobility and cooperation helps in designing effective and efficient protocols. In particular, we also pointed out that there is critical speed necessary to induce enough information flow to make these new protocols outperform traditional ones, designed for static networks.

We believe that the ideas and protocols introduced in this paper pave the way for further research in the area; furthermore, even if specifically suited to address a major security threat, they could be also adopted in other scenarios to support other emergent properties as well.

Declarations

Acknowledgments

The authors would like to thank the anonymous reviewers for their helpful comments that helped to improve the quality of this paper. The authors are solely responsible for the views expressed in this paper, which do not necessarily reflect the position of supporting Organizations. This work was partly supported by: (1) the Spanish Ministry of Education through projects TSI2007-65406-C03-01 "E-AEGIS" and CONSOLIDER INGENIO 2010 CSD2007-0004 "ARES," (2) the Government of Catalonia under grant 2005 SGR 00446, and (3) the project APPLICAZIONI GOVERNATIVE LEGATE ALL'USO DEL PRS GALILEO (PRESAGO)—contract ASI I/030/07/0 starting September 6, 2007.

Authors’ Affiliations

(1)
Department of Computer Science, Vrije Universiteit Amsterdam
(2)
UNESCO Chair in Data Privacy, Universitat Rovira i Virgili
(3)
Dipartimento di Matematica, Università di Roma Tre
(4)
Dipartimento di Informatica, Università di Roma "Sapienza"

References

  1. Chan H, Perrig A, Song D: Random key predistribution schemes for sensor networks. Proceedings of the IEEE Symposium on Security and Privacy (S&P '03), September 2003
  2. Newsome J, Shi E, Song D, Perrig A: The sybil attack in sensor networks: analysis & defenses. Proceedings of the 3rd International Conference on Information Processing in Sensor Networks (IPSN '04), April 2004
  3. Demirbas M, Song Y: An RSSI-based scheme for sybil attack detection in wireless sensor networks. Proceedings of the International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM '06), June 2006, New York, NY, USA 564-568.
  4. Di Pietro R, Mancini LV, Mei A: Energy efficient node-to-node authentication and communication confidentiality in wireless sensor networks. Wireless Networks 2006, 12(6):709-721. 10.1007/s11276-006-6530-5View Article
  5. Conti M, Di Pietro R, Mancini LV, Mei A: A randomized, efficient, and distributed protocol for the detection of node replication attacks in wireless sensor networks. Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '07), 2007 80-89.View Article
  6. Parno B, Perrig A, Gligor VD: Distributed detection of node replication attacks in sensor networks. Proceedings of the IEEE Symposium on Security and Privacy (S&P '05), 2005
  7. Information Processing Technology Office (IPTO) Defense Advanced Research Projects Agency (DARPA) BAA 07-46 LANdroids Broad Agency Announcement, 2007, http://​www.​darpa.​mil/​index.​html
  8. Perrig A, Stankovic J, Wagner D: Security in wireless sensor networks. Commununications of ACM 2004, 47(6):53-57. 10.1145/990680.990707View Article
  9. Capkun S, Hubaux J-P, Buttyán L: Mobility helps security in ad hoc networks. Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '03), 2003 46-56.View Article
  10. Piro C, Shields C, Levine BN: Detecting the sybil attack in mobile ad hoc networks. Proceedings of the 2nd International Conference on Security and Privacy in Communication Networks (SecureComm '06), 2006, Baltimore, Md, USA
  11. Broch J, Maltz DA, Johnson DB, Hu Y-C, Jetcheva J: A performance comparison of multi-hop wireless ad hoc network routing protocols. Proceedings of the 4th Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom '98), 1998 85-79.View Article
  12. Sharma G, Mazumdar R, Shroff NB: Delay and capacity trade-offs in mobile ad hoc networks: a global perspective. Proceedings of the 25th Conference on Computer Communications (INFOCOM '06), 2006
  13. Becher A, Becher E, Benenson Z, Dornseif M: Tampering with motes: real-world physical attacks on wireless sensor networks. Proceeding of the 3rd International Conference on Security in Pervasive Computing (SPC '06), 2006 104-118.
  14. Grossglauser M, Vetterli M: Locating nodes with EASE: last encounter routing in ad hoc networks through mobility diffusion. Proceedings of the 22nd Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '03), 2003, San Francisco, Calif, USA
  15. Luo J, Hubaux J-P: Joint mobility and routing for lifetime elongation in wireless sensor networks. Proceedings of the 24th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '05), March 2005, Miami, Fla, USA
  16. fan Hsin C, Liu M: A distributed monitoring mechanism for wireless sensor networks. Proceedings of the Workshop on Wireless Security (WiSe '02), 2002 57-66.View Article
  17. fan Hsin C, Liu M: Self-monitoring of wireless sensor networks. Computer Communications 2006, 29(4):462-476. 10.1016/j.comcom.2004.12.031View Article
  18. Hayashibara N, Cherif A, Katayama T: Failure detectors for large-scale distributed systems. Proceedings of the 21st IEEE Symposium on Reliable Distributed Systems (SRDS '02), October 2002, Suita, Japan
  19. Ranganathan S, George AD, Todd RW, Chidester MC: Gossip-style failure detection and distributed consensus for scalable heterogeneous clusters. Cluster Computing 2001, 4(3):197-209. 10.1023/A:1011494323443View Article
  20. Curtmola R, Kamara S: A mechanism for communication-efficient broadcast encryption over wireless ad hoc networks. Electronic Notes in Theoretical Computer Science 2007, 171(1):57-69. 10.1016/j.entcs.2006.11.009View Article
  21. Huang D, Mehta M, Medhi D, Harn L: Location-aware key management scheme for wireless sensor networks. Proceedings of the 2nd ACM Workshop on Security of Ad Hoc and Sensor Networks (SASN '04), November 2004, Washington, DC, USA 29-42.View Article
  22. Tague P, Poovendran R: Modeling adaptive node capture attacks in multi-hop wireless networks. Ad Hoc Network 2007, 5(6):801-814. 10.1016/j.adhoc.2007.01.002View Article
  23. Tague P, Slater D, Rogers J, Poovendran R: Vulnerability of network traffic under node capture attacks using circuit theoretic analysis. Proceedings of the 27th IEEE International Conference on Computer Communications (INFOCOM '08), 2008 161-165.
  24. Conti M, Di Pietro R, Gabrielli A, Mancini LV, Mei A: The quest for mobility models to analyse security in mobile ad hoc networks. Proceedings of the 7th International Conference on Wired/Wireless Internet Communications (WWIC '09), May 2009 85-96.
  25. Conti M, Di Pietro R, Mancini LV, Mei A: Emergent properties: detection of the node-capture attack in mobile wireless sensor networks. Proceedings of the 1st ACM Conference on Wireless Network Security (WiSec '08), 2008 214-219.View Article
  26. Daly EM, Haahr M: Social network analysis for routing in disconnected delay-tolerant MANETs. Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '07), September 2007 32-40.View Article
  27. Sterbenz JPG, Krishnan R, Hain RR, et al.: Survivable mobile wireless networks: issues, challenges, and research directions. Proceedings of the 1st ACM Workshop on Wireless Security (WiSe '02), 2002, Atlanta, Ga, USA 31-40.View Article
  28. Di Pietro R, Mancini L, Soriente C, Spognardi A, Tsudik G: Data security in unattended sensor networks. IEEE Transactions on Computers 2009, 58(11):1500-1511.MathSciNetView Article
  29. Di Pietro R, Mancini L, Soriente C, Spognardi A, Tsudik G: Playing hide-and-seek with a focused mobile adversary in unattended wireless sensor networks. Ad Hoc Networks 2009, 7(8):1463-1475. 10.1016/j.adhoc.2009.04.002View Article
  30. Yoon J, Liu M, Noble B: Random waypoint considered harmful. Proceedings of the 22nd Annual Joint Conference of the IEEE Computer and Communications Societies, March 2003, San Franciso, Calif, USA 2: 1312-1321.
  31. Hyytiä E, Lassila P, Virtamo J: Spatial node distribution of the random waypoint mobility model with applications. IEEE Transactions on Mobile Computing 2006, 5(6):680-694.View Article
  32. Sun K, Ning P, Wang C: Fault-tolerant cluster-wise clock synchronization for wireless sensor networks. IEEE Transactions on Dependable and Secure Computing 2005, 2(3):177-189. 10.1109/TDSC.2005.36View Article
  33. Williams B, Camp T: Comparison of broadcasting techniques for mobile ad hoc networks. Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '02), 2002 194-205.View Article
  34. Orecchia L, Panconesi A, Petrioli C, Vitaletti A: Localized techniques for broadcasting in wireless sensor networks. Proceedings of the Joint Workshop on Foundations of Mobile Computing (DIALM-POMC '04), October 2004, Philadelphia, Pa, USA
  35. Burns B, Brock O, Levine BN: MORA routing and capacity building in disruption-tolerant networks. Ad Hoc Networks 2008, 6(4):600-620. 10.1016/j.adhoc.2007.05.002View Article
  36. Liu H, Wan P-J, Liu X, Yao F: A distributed and efficient flooding scheme using 1-hop information in mobile ad hoc networks. IEEE Transactions on Parallel and Distributed Systems 2007, 18(5):658-671.View Article
  37. Rahman SMM, Nasser N, Inomata A, Okamoto T, Mambo M, Okamoto E: Anonymous authentication and secure communication protocol for wireless mobile ad hoc networks. Security and Communication Networks 2008, 1(2):179-189. 10.1002/sec.4View Article
  38. Striki M, Baras J, Manousakis K: A robust, distributed TGDH-based scheme for secure group communications in MANET. Proceedings of the IEEE International Conference on Communications (ICC '04), May 2004
  39. Di Pietro R, Mancini LV, Mei A: Efficient and resilient key discovery based on pseudo-random key pre-deployment. Proceedings of the IEEE International Parallel and Distributed Processing Symposium (IPDPS '04), 2004 2991-2998.
  40. Wander A, Gura N, Eberle H, Gupta V, Shantz SC: Energy analysis of public-key cryptography for wireless sensor networks. Proceedings of the 3rd IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW '05), 2005
  41. Bandyopadhyay S, Coyle EJ, Falck T: Stochastic properties of mobility models in mobile ad hoc networks. IEEE Transactions on Mobile Computing 2007, 6(11):1218-1229.View Article
  42. Chaintreau A, Hui P, Diot C, Gass R, Scott J: Impact of human mobility on opportunistic forwarding algorithms. IEEE Transactions on Mobile Computing 2007, 6(6):606-620.View Article

Copyright

© Mauro Conti et al 2009

This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.