13.01.2013 Views

Calculating trust in sensor networks

Calculating trust in sensor networks

Calculating trust in sensor networks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Figure 6 summarizes some of the most common characteristics of the previous rout<strong>in</strong>g<br />

protocols.<br />

Some approaches detailed what should be monitored about other nodes, some did not. The<br />

most common trait to look for was whether the other node forwarded packets. The most<br />

complete list of monitored traits was used <strong>in</strong> Dynamic Trusted Rout<strong>in</strong>g. WSNodeRater<br />

used a shared monitor<strong>in</strong>g mechanism to m<strong>in</strong>imize energy consumption, by shar<strong>in</strong>g the<br />

monitor<strong>in</strong>g load amongst many nodes. Several different ways of detect<strong>in</strong>g and identify<strong>in</strong>g<br />

malicious or suspicious activity have been identified [FGRL07], but the previously detailed<br />

<strong>trust</strong> management approaches implemented only a subset of these.<br />

Not every approach used <strong>in</strong>direct <strong>trust</strong>, these were TGPSR and the Trust-Based Geo-<br />

graphical Rout<strong>in</strong>g Scheme. Indirect <strong>trust</strong> is when nodes share their <strong>trust</strong>-<strong>in</strong>formation<br />

about other nodes. Some approaches used <strong>in</strong>direct <strong>trust</strong>, but did not consider whether the<br />

<strong>in</strong>formation itself should be <strong>trust</strong>ed. This k<strong>in</strong>d of behavior could be used to spread false<br />

rumors about other nodes. In TLEACH, only the elected cluster-head is allowed to spread<br />

<strong>in</strong>direct <strong>trust</strong>-<strong>in</strong>formation about other nodes. In CORE, only positive observations about<br />

other nodes is spread as <strong>in</strong>direct <strong>trust</strong>-<strong>in</strong>formation.<br />

Rout<strong>in</strong>g was based on the idea that less <strong>trust</strong>worthy nodes should be cut off from rout<strong>in</strong>g-<br />

duties and thus excluded from the network. In some approaches other services were also<br />

denied from un<strong>trust</strong>worthy nodes, such as packet forward<strong>in</strong>g or route discovery. In the<br />

Trust-based Geographical Rout<strong>in</strong>g Scheme, a sender could def<strong>in</strong>e a m<strong>in</strong>imum <strong>trust</strong> for<br />

every packet that it sends. The packet is then forwarded to nodes whose <strong>trust</strong> is atleast<br />

the required m<strong>in</strong>imum <strong>trust</strong> of the packet.<br />

A clear dist<strong>in</strong>ction should be made about <strong>trust</strong> and reliability. A node should be <strong>trust</strong>ed<br />

when it is seen as friendly. A node should be seen as reliable when it is friendly and<br />

participat<strong>in</strong>g <strong>in</strong> the network. This raises the question, how do we separate the <strong>in</strong>truders<br />

from the faulty nodes, and should both be handled the same way?<br />

Someth<strong>in</strong>g that should be taken <strong>in</strong>to consideration is how a potential attack is seen through<br />

<strong>trust</strong> management. If an attacker manages to <strong>in</strong>sert a malicious node to the network, can<br />

this be detected by these different monitor<strong>in</strong>g schemes? Is it likely that they report false<br />

34

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!