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.

3 Trust management<br />

Research done <strong>in</strong> mobile ad hoc <strong>networks</strong> has shown that network performance is severely<br />

reduced if nodes <strong>in</strong> the network misbehave [MM02b]. Misbehav<strong>in</strong>g nodes usually refuse to<br />

participate <strong>in</strong> network activity because of selfish or malicious <strong>in</strong>tents. A selfish node may<br />

refuse to forward packets because it is try<strong>in</strong>g to save energy. A selfish node will use the<br />

network but will not cooperate. A malicious node will go beyond that and do anyth<strong>in</strong>g to<br />

disrupt the network.<br />

A <strong>sensor</strong> network organizes and operates very similarly to any ad hoc network. The<br />

network topology is not known beforehand, and nodes may not have complete <strong>trust</strong> about<br />

their neighbour’s <strong>in</strong>tent. Nodes <strong>in</strong> a <strong>sensor</strong> network are often unattended, so ga<strong>in</strong><strong>in</strong>g<br />

physical access to them would be easy for an attacker. Research has suggested [BBD06]<br />

[FC08] that nodes can be compromised on the field with only a m<strong>in</strong>imal lapse <strong>in</strong> the<br />

nodes presence. A general assumption about <strong>sensor</strong>s is that they can be captured and<br />

reprogrammed for malicious purposes.<br />

One countermeasure aga<strong>in</strong>st such an attack would be that each node <strong>in</strong> a network collects<br />

<strong>trust</strong> <strong>in</strong>formation about its neighbours. This would be called distributed <strong>trust</strong> manage-<br />

ment.<br />

A node may gather subjective observations about its neighbour<strong>in</strong>g nodes to determ<strong>in</strong>e<br />

how much it may <strong>trust</strong> them. This is called direct <strong>trust</strong>. This approach would require no<br />

central node or server to determ<strong>in</strong>e who should be <strong>trust</strong>ed, and who should not. Such a<br />

distributed <strong>trust</strong> management system could be more resilient towards attacks where large<br />

parts of the network could be taken over.<br />

Gather<strong>in</strong>g data (or ”evidence”) for <strong>trust</strong> evaluation can be a cumbersome process. Some<br />

relevant behaviour that a <strong>trust</strong> management scheme could look for <strong>in</strong>clude momentary<br />

absence from the network (see node capture <strong>in</strong> Chapter 2.4), answer<strong>in</strong>g to non-exist<strong>in</strong>g<br />

queries, weird or <strong>in</strong>valid <strong>sensor</strong> read<strong>in</strong>gs or reluctance to co-operate <strong>in</strong> rout<strong>in</strong>g or packet<br />

forward<strong>in</strong>g [FGRL07].<br />

Nodes may also engage <strong>in</strong> shar<strong>in</strong>g their <strong>trust</strong>-<strong>in</strong>formation. This sort of behavior could be<br />

18

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

Saved successfully!

Ooh no, something went wrong!