MISCELLANEOUS PROPERTIES

requiring limited overhead. One such approach is based on the use of HMAC. In this case, the two parties share a secret which is then used in the HMAC to verify the authenticity of the message. Thus, the receiver can verify the originator of the data. This approach can be extended to the broadcast domain, where a single sender shares a MAC key with several receivers. The sender then calculates the HMAC of every message before sending it and attaches to the message. Each of the receivers of the message can check the MAC and verify the authenticity of the message.

Unfortunately there is a problem with applying this approach directly to the broadcast/ multicast domain. Any receiver in the group can also use the shared key to provide an HMAC value on a message. The node can transmit this message claiming that the message was sent from another node. Therefore, a receiver does not have a guarantee that the source has indeed created the message. This implies that symmetric schemes cannot be used for providing individual authentication. This is because users share the key and therefore it is not possible to verify which one of the users sharing the secret actu- ally created the message. Of course, an alternative here is to have the source share pairwise keys with every receiver and use these pairwise keys to authenticate the message. However, such an approach is highly inefficient.

Therefore, more efficient schemes to ensure broadcast authentication are needed. One such scheme is TESLA (timed efficient stream loss-tolerant authentication), [10], which makes use of only symmetric cryptographic primitives. TESLA requires loose time syn- chronization among the entities participating in the network. Further it achieves its objec- tive by making use of delayed key disclosure as we explain next.

To understand TESLA, consider Figure 2.11. We consider a single sender and multiple receivers. The sender in the group determines a secret keyK, which is then hashed to get the hashed valueH(K). The sender discloses the hashed value authentically (using a digital signature for example) to all the receivers. The sender then transmits all packetsPsuch that the transmitted packet contains the HMAC ofPin addition toP. The HMAC calcu- lation is done using the keyK. The receivers on receiving these packets cannot verify the HMAC since they do not have the keyK, so receivers will have to buffer all the packets.

After a certain duration, the sender discloses the keyKto all the receivers. At this point every receiver can check if the disclosed keyKis indeed valid. This can be done by check- ing if the hash of K corresponds to the hashed value sent authentically by the sender earlier. If this is true, then every receiver can verify the authenticity of every packet. Note that the receiver must not accept any packet the HMAC of which has been calculated using keyKafter the disclosure of the keyK. This is achieved by the sender disclosing the timeout schedule to the receivers and by having loose time synchronization between the receivers and the sender.

The approach given above can be easily extended (and is in fact more efficient) when considering multiple time intervals. In this case, each sender splits time into multiple inter- vals. It then chooses a secret key and generates a one-way key chain through repeated use of the one-way hash function property. The last value of the hash chain is then transferred to the receivers authentically. Each generated key that is one of the values of the hash chain will be used in one time interval. The keys are used in the reverse order of gener- ation. Thus, the message authentication keys used for packets in the previous interval are derived (via hashing) from the message authentication keys used in the current interval. During each interval the sender calculates the HMAC of each packet using the key corre- sponding to that interval. The transmitted packet contains the original contents of the packet, the calculated HMAC value over the original packet and the most recent one-way chain value that can be disclosed. Thus, the sender discloses the keys used after the time interval of their use.

The receivers must know the key disclosure schedule, so when the receiver receives a packet, it checks that the key used to compute the HMAC on the received packet is still secret. It can do so using its knowledge of the key disclosure schedule since the receivers and the sender are assumed to be loosely synchronized in time. As long as this key is still secret, the receiver buffers the packet. If the key is not secret then the receiver has to drop the packets. When the key is disclosed, the receiver checks the correctness of the key (using the one way property of hash functions) and then authenticates the buffered packets. This operation of TESLA is illustrated in Figure 2.12.

Thus, TESLA achieves asymmetry needed for broadcast authentication through clock synchronization and a delayed key disclosure. Note also that TESLA is robust to packet loss. A drawback, though, is the need for receiver to buffer packets transmitted during an

Figure 2.12. Operation of TESLA.

interval. In addition, the time synchronization (loose though it may be) might also be pro- blematic. The sender also needs to compute the entire chain before communication starts.

In addition to the above shortcomings, TESLA has a few additional inadequacies when used in sensor networks [11]. Firstly, TESLA authenticates the initial packet with a digital signature, which is impractical in sensor nodes. Secondly TESLA discloses a key in each packet, which is inefficient given the severe bandwidth constraints in sensor networks. This leads to an overhead of approximately 24 bytes per packet. This is significant consid- ering that sensor nodes send very small messages that are around 30 bytes long. Thirdly, it is expensive to store a one-way chain in a sensor node.

To address these limitations of TESLA,mTesla has been proposed in [11] for sensor network deployments. In this case, a sink or basestation is assumed to be present in the network. The base station is expected to execute many of the functions needed in TESLA.mTesla requires loose time synchronization just like TESLA, but the synchroni- zation is only between the base station and sensor nodes. Packets are also broadcast by the base station. The initial key is transmitted authentically by the base station to the various sensor nodes. This could be done by having the base station share keys with every node in the network. The shared key between the base station and a sensor node is proposed to be used for authentic transmission of the initial key. Additionally, it is not necessary for the key to be included in every packet. Finally, if a sensor node needs to broadcast data, then it either sends the data to the base station, which broadcasts it after setting up the keys in the manner of TESLA or the sensor node gets the authentication keys from the base station. Thus, a sensor node does not have to either store the one-way chain or perform the hashing operations.

2.5 SUMMARY

In this chapter we have described the basic concepts of cryptography. These concepts are very important for providing security services in a wireless ad hoc networking environ- ment and will be used throughout the book. Note, however, that we have skipped several other important concepts such as secret sharing, threshold cryptography, and identity-based keying, since we do not need these for the schemes described in this book. Cryptographic techniques can be used for providing encryption, authentication, and integrity in such an environment. A key problem with utilizing cryptographic techniques in such an environment is the management of cryptographic keys, as remarked earlier. Network dynamics such as the degree of change in the network and the lack of a central infrastructure make this problem more difficult. We focus on key management techniques in the next chapter.