Information Gathering and Sharing Phase

This phase compromises the communication and collection of reputation ratings. A reputation system design must specify the type of information to be collected about other neighboring

nodes, and how it should be collected. The metrics for collected ratings can for example accept only positive ratings, only negative ratings, both types, or any rating on continuous scales. It is believed that this phase is the core component of any reputation system, because it evaluates current activities and gathers the available information about the system and then hands it to the next phase; the information modeling phase. The information gathering and sharing phase has four components: information source, information type, information gathering approach, and gathering scope. These components are discussed as follows:

Information Source: The information source in any reputation system can be either man-

ual or automatic. The manual information source is obtained in the form of user ratings for other entities as a result of being involved in a single transaction, such as in the eBay rating system [68]. This type of source is not available in WSNs due to the lack of user interaction with the network. The only user interaction with WSNs usually occurs at the base station, whereas the reputation system gathers information from every device within the WSNs. The automatic information source does not involve user interaction and can be either direct or indirect observation. Direct observations, sometimes called first-hand information, are com- puted based on the node’s observations and experience with neighboring nodes, such as the success and failure of forwarding aggregated data within an error rate. In some reputation systems, direct observations need to be propagated to other nodes in the neighborhood. Then, this propagated information is called indirect observation, or second-hand information, at the receiving nodes. In other words, an indirect observation for one node is a propagated direct observation of another node. Indirect observation helps to build up the reputation system more quickly than using only direct observation, since nodes will be able to learn about other nodes’ behaviors even though no direct communications (observations) have occurred. However, prop- agating reputation information between nodes makes the system vulnerable to different attacks such as Bad Mouthing (BM), Ballot Stuffing (BS), and On-Off (OO) attacks as discussed in Section 3.2.

Information Type: The type of the reputation information shared between sensor nodes

can be unary, i.e., either only negative [14], or only positive [81], or binary, i.e, meaning pos- itive or negative [13, 117, 118], discrete, i.e., positive, neutral, negative as in eBay, a natural number on a scale from 1 (untrusted) to 10 (trusted) [48], or continuous [66], e.g., real val- ues in the range of [0,1]. The choice of the information type is up to the system designer, but designers should be aware of the consequences of any choice. Considering only positive feedback on the one hand, the BM attack can be prevented because malicious nodes would not be able to affect the trust level of trustworthy nodes by propagating negative reputation ratings. However, malicious nodes can collude and falsely praise misbehaved nodes to launch a BS attack. Propagating positive feedback also exhausts the network’s limited resources since the number of nodes that behave correctly in general is supposed to be larger than those which do not. Thus, the number of transmissions required to update reputation values is high, which depletes the limited energy source. On the other hand, considering only negative feedback helps prevent malicious nodes from colluding and praising misbehaving nodes (BS attack), because they could not propagate positive feedback. It also helps to minimize the number of

transmission required to update the reputation values. However, malicious nodes can assign negative reputation ratings/feedback for trustworthy nodes in order to affect their trust level (BM attack).

Information Gathering Approach: As discussed earlier, the main task of this phase is to

collect information about other sensor nodes in the neighborhood. This information is gathered by a sensor node based on its observations and experience about other nodes. Most current reputation-based trust systems in WSNs use monitoring mechanisms such as the Watchdog mechanism (WDM) [81] as an approach to collect these direct observations. When a node forwards a packet, the node’s WDM verifies that the next node in the path also forwards the packet. The WDM is implemented by maintaining a buffer of recently sent packets. The WDM compares each overheard packets with the packet in the buffer in order to see if they match or not. Once there is a match, the packet is removed from the buffer. If the packet has remained in the buffer for longer than a certain timeout, the WDM increments a failure tally for the node that is responsible for forwarding activities.

Reputation System Scope: In the current literature, most reputation-based trust systems

destined to WSNs focus on specific functions. For example, CORE [81], and CONFIDANT [14] focus on detecting misbehaviors related to routing functionalities, while DRBTS [118] focuses on enforcing cooperation between beacon nodes by motivating them to provide correct location information. Comparison between reputation-based trust systems with different scopes is dif- ficult. This is because a scope-specific reputation system requires the WDM to be tailored in order to monitor activities related to the chosen scope. For example, the aggregation scope re- quires the WDM to monitor routing, forwarding, sensing, and aggregation activities where each activity may use different reputation information type, while the localization scope requires the WDM to focus only on the provided location information. Thus, applying the reputation system destined for the aggregation scope directly to the localization scope is impractical; the system has to be modified. However, there might be cases, where a trust model that has been developed for a specific scope can be also applied to another scope with only minor changes, especially in scenarios where the input parameters for the trust model come from the same domain.