21.08.2013 Views

Protocols for Secure Communication in Wireless Sensor Networks

Protocols for Secure Communication in Wireless Sensor Networks

Protocols for Secure Communication in Wireless 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.

6.4. Security Evaluation 191<br />

of the phase allows that each node can send exactly one message to each of its<br />

neighbours. The model also demands that <strong>in</strong> each slot a message must be sent.<br />

By construction, this <strong>for</strong>bids the possibility of message <strong>in</strong>jection.<br />

Message Sequence Numbers<br />

Any node issu<strong>in</strong>g a message must attach a sequence number to it. A node<br />

receiv<strong>in</strong>g multiple messages from the same source would then be able to notice<br />

the existence of <strong>in</strong>jected messages if the same sequence number is used twice.<br />

A message <strong>in</strong>jection attack might be successful <strong>for</strong> a certa<strong>in</strong> period of time,<br />

until the orig<strong>in</strong>al source starts emitt<strong>in</strong>g messages to the same recipients as the<br />

attacker. If one of them reaches a recipient, the attack is detected.<br />

Source Address Verification<br />

We describe two approaches to source address verification: one that relies on<br />

the cooperation of the source’s neighbours; and a second one that challenges<br />

the source on a random basis. Both procedures could be comb<strong>in</strong>ed and thus<br />

further reduce the risk of message <strong>in</strong>jection.<br />

The first approach is based on monitor<strong>in</strong>g. Whenever a new message is<br />

created, it must be broadcast. This ensures that a number of nodes get a copy<br />

of the message. In many cases, broadcast channels are used by default, thus no<br />

additional changes are required.<br />

When the second node passes the message on, it also has to broadcast the<br />

message. This adds more nodes to those that know the message. Now, a consensus<br />

protocol is executed between the know<strong>in</strong>g nodes. Only if an agreement<br />

can be achieved, the third node on the path is allowed to accept the message.<br />

This approach has a number of drawbacks. First, potentially many nodes<br />

are participat<strong>in</strong>g <strong>in</strong> the consensus protocol, which implies a significant ef<strong>for</strong>t.<br />

Second, it only works if there are neighbours available. A third drawback is the<br />

requirement that messages must be sent <strong>in</strong> cleartext, i.e. without a l<strong>in</strong>k layer<br />

encryption step, at least <strong>for</strong> the duration of the agreement phase.<br />

The second approach requires additional message exchange between the<br />

source and the receiver. The receiver of a message may send a challenge to<br />

the orig<strong>in</strong>al sender. This challenge conta<strong>in</strong>s part of the received message such<br />

that the sender can verify if the sender is the source of the message. If this is the<br />

case, the sender returns an acknowledgement. Only if the acknowledgement is<br />

correctly received, the receiver will accept the message.<br />

The challenge is useful <strong>in</strong> another way, too. If a node gets a challenge about<br />

a message that it has not issued, this <strong>in</strong>dicates the presence of an attacker. This

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

Saved successfully!

Ooh no, something went wrong!