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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

2.8. Cryptography <strong>for</strong> <strong>Sensor</strong> <strong>Networks</strong> 55<br />

output length of the hash function. If this output is truncated to, <strong>for</strong> example,<br />

its m-bit prefix, where m is large enough (depend<strong>in</strong>g on the anticipated attacker<br />

strength), this would still provide a sufficiently high security level.<br />

It is important to dist<strong>in</strong>guish between offl<strong>in</strong>e and onl<strong>in</strong>e attacks on a MAC.<br />

If only onl<strong>in</strong>e attacks are possible, <strong>for</strong> example if HMAC is be<strong>in</strong>g used <strong>for</strong> creat<strong>in</strong>g<br />

MACs, a relatively small MAC size would be adequate. As an example,<br />

assume a sensor node requires a time of t = 10 ms <strong>for</strong> receiv<strong>in</strong>g a message and<br />

verify<strong>in</strong>g its authentication code. With a bitlength m = 32 of the authentication<br />

code, around 2 32 attempts are necessary be<strong>for</strong>e the sensor node accepts the<br />

message as be<strong>in</strong>g valid. Thus, the node would accept the message only after<br />

approximately 5965 hours (248 days). Obviously, runn<strong>in</strong>g under constant load,<br />

a battery-powered sensor node would run out of energy long be<strong>for</strong>e that time<br />

has passed.<br />

The same MAC length would be <strong>in</strong>sufficient to prevent offl<strong>in</strong>e attacks, however.<br />

In offl<strong>in</strong>e attack, the computations are per<strong>for</strong>med without <strong>in</strong>teraction with<br />

the attack target and can be massively parallelized. To prevent such attacks,<br />

at least 80 bits are required, which would still lead to a 10 byte overhead per<br />

MAC.<br />

2.8.6 Key Management<br />

Cryptographic keys are necessary to establish secure channels between communicat<strong>in</strong>g<br />

nodes. The ma<strong>in</strong> tasks of key management are the distribution,<br />

refreshment, and revocation of keys. In centralized architectures, one can use<br />

key distribution centers (KDC) to which nodes securely connect (by means of a<br />

predef<strong>in</strong>ed secret between the KDC and each node) <strong>in</strong> order to receive updates<br />

on their keys or to retrieve new keys <strong>for</strong> pairwise communication among nodes.<br />

Generally, sensor networks are highly distributed, multi-hop systems <strong>in</strong><br />

which communication to a central entity is expensive. Transient disconnectedness<br />

of parts of the network would even make it impossible to reach a KDC<br />

and thus prevent nodes from exchang<strong>in</strong>g messages. There<strong>for</strong>e, a distributed<br />

solution to key management <strong>in</strong> sensor networks is preferable.<br />

One viable approach is to pre-load a set of keys onto each sensor node be<strong>for</strong>e<br />

deployment. This can be done <strong>in</strong> a secure environment that has no tight energy<br />

restrictions. These keys can serve various purposes after deployment:<br />

• <strong>Secure</strong> <strong>in</strong>teraction with the base station – Each node is assigned a secret<br />

key that is only known to the node itself and the base station.<br />

• Key agreement between nodes – A key agreement scheme based on (random)<br />

subsets of a large key pool such as proposed <strong>in</strong> [64] can be used to

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

Saved successfully!

Ooh no, something went wrong!