MUQAMI+: a scalable and locally distributed key management scheme for clustered sensor networks

Abstract

Wireless sensor networks (WSN) are susceptible to node capture and many network levels attacks. In order to provide protection against such threats, WSNs require lightweight and scalable key management schemes because the nodes are resource-constrained and high in number. Also, the effect of node compromise should be minimized and node capture should not hamper the normal working of a network. In this paper, we present an exclusion basis system-based key management scheme called MUQAMI+ for large-scale clustered sensor networks. We have distributed the responsibility of key management to multiple nodes within clusters, avoiding single points of failure and getting rid of costly inter-cluster communication. Our scheme is scalable and highly efficient in terms of re-keying and compromised node revocation.

Appendices

Appendices

1.1 Appendix A. Storage overhead

The average storage requirements of a CH node in LEAP+ are fairly straightforward. Apart from the pairwise key shared with each node in the cluster, it has to store two more keys, i.e., its cluster key and the communication key. So, if there are r nodes in a cluster, storage requirements of a CH node in LEAP+ turn out to be:

$$ S\!R_{C\!H}^{\mathit{LEAP}+} = r+2 $$

(10)

In LEAP+, the SN nodes only establish pair-wise keys with only their b neighbors. However, they have to store two keys, i.e., the cluster key and the communication key. So, the storage requirement of SN node in LEAP+ becomes:

$$ S\!R_{S\!N}^{\mathit{LEAP}+} = b+2 $$

(11)

Now, we will discuss the storage requirement of a CH node in SHELL. In SHELL, each node has to store a key chain of length l for the key it shares with the CN. Also, it has to store pair-wise keys with h neighboring CH nodes, with whom it shares the EBS matrix. Also, it has to store pair-wise keys with the r nodes, i.e., the average number of nodes in a cluster. Finally, it has to store the k + m administrative keys and the communication key. So, the storage requirement of a CH node in SHELL can be written as

$$ S\!R_{C\!H}^{\mathit{SHELL}} = l+r+h+k+m+1 $$

(12)

Apart from the key chain of length l for the key shared with the CN and the k administrative keys, SN nodes have to store three other keys, i.e., one pair-wise key shared with a neighboring CH node, one shared with its own CH node, and one communication key. So, the average storage requirements of a SN node in SHELL can be written as:

$$ S\!R_{S\!N}^{\mathit{SHELL}} = l+k+3 $$

(13)

1.2 Appendix B. Communication and computation overhead

In this section, we will discuss the communication and computation overhead of LEAP+ and SHELL and explain the formulas listed in Tables 4 to 7. In the initial deployment phase, every CH node receives one message each from h neighboring CH nodes to establish the communication path. Also, for each node in its cluster, the CH node receives one message from one of the neighboring CH nodes in order to establish pair-wise keys. Finally, for the distribution of the communication key, every CH node receives the communication keys k + m times, i.e., encrypted separately in each administrative key. So, the average message exchanges between CH nodes during the initial deployment phase of SHELL comes out to be:

$$ Avg\_Msg\_Count\_Init_{C\!H \to C\!H}^{\mathit{SHELL}} = h+r+k+m, $$

(14)

where $Avg\_Msg\_Count\_Init_{CH \to CH}^{\mathit{SHELL}}$ is the average message exchanges between CH nodes during initial deployment phase of SHELL.

In the initial deployment phase of LEAP+, every SN node sends two unicast messages to the CH node. One message establishes a pair-wise key with the CH node and the other one transfers the cluster key to the CH node. Apart from that, it also has to forward d messages to the CH node, where d is the average number of nodes that establish their pair-wise keys with the CH node through each node. So, the average number of messages transmitted from a SN to its CH in the initial deployment phase turns out to be:

$$ Avg\_Msg\_Count\_Init_{S\!N \to C\!H}^{\mathit{LEAP}+} = d+2 $$

(15)

where $Avg\_Msg\_Count\_Init_{SN \to CH}^{LEAP+}$ is the average number of messages transmitted from a SN to its CH in the initial deployment phase of LEAP+. Also, it is important here to mention the average number of message exchanges between SN nodes in LEAP+. There are b neighbors of each node and each node has to send two messages to each of its neighbors. One message is for the pair-wise key establishment and the other message is for the communication of its cluster key. Apart from that, three messages are exchanged for every node that establishes a pair-wise key with the CH node through this node, i.e., three messages are exchanged for d nodes from each node on average. In one message, the d nodes send a message to the CH node through this node to establish a pair-wise key with the CH node. In the other two messages, cluster keys are exchanged between the CH and the d nodes, i.e., CH and the d nodes send their cluster keys to each other through this node. So, the average number of message exchanges between SN nodes in LEAP+ for the initial deployment phase comes out to be:

$$ Avg\_Msg\_Count\_Init_{S\!N \to S\!N}^{\mathit{LEAP}+} = 2b+3d, $$

(16)

where $Avg\_Msg\_Count\_Init_{SN \to SN}^{LEAP+}$ is the average number of messages exchanged between SN nodes in the initial deployment phase of LEAP+. It is not difficult to understand the rest of the expressions in Table 4.

For key refreshment in SHELL, every CH sends a message to h neighboring CH nodes. In turn, it receives k + m messages from them to broadcast in the cluster. So, the average number of messages exchanged between the CH nodes in the key refreshment phase can be written as:

$$ Avg\_Msg\_Count\_Rekey_{C\!H \to C\!H}^{\mathit{SHELL}} = h+k+m, $$

(17)

where $Avg\_Msg\_Count\_Rekey_{CH \to CH}^{SHELL}$ is the average message exchanges between CH nodes during the key refreshment phase of SHELL. Also, the keys between the neighboring CH nodes and the keys between CH nodes and the CN will also be refreshed. So, in order to refresh those keys, the CN will send h + 1 messages to all the CH nodes, i.e., to g CH nodes. h messages contain new keys for communication with the neighboring CH nodes and one message contains a key for communication with the command node. So, the total number of messages transferred from CN to the CH nodes in key refreshment phase of SHELL comes out to be:

$$ Msg\_Count\_Rekey_{C\!N \to C\!H}^{\mathit{SHELL}} = g \times (h+1) $$

(18)

where $Msg\_Count\_Rekey_{CN \to CH}^{\mathit{SHELL}}$ is the total number of messages transferred from CN to the CH nodes in key refreshment phase of SHELL.

In order to refresh its cluster key, each node will send one message to the CH node. Also, it will forward one message each from d nodes, so the average number of messages transmitted from a SN to its CH in the key refreshment phase turns out to be:

$$ Avg\_Msg\_Count\_Rekey_{S\!N \to C\!H}^{\mathit{LEAP}+} = d+1 $$

(19)

where $Avg\_Msg\_Count\_Rekey_{SN \to CH}^{LEAP+}$ is the average number of messages transmitted from a SN to its CH in the key refreshment phase of LEAP+. In the same way, when a SN node refreshes its cluster key in LEAP+, it send one message each to its b neighbors. Also, the CH node exchange cluster keys with d nodes through every node on average. On a particular SN node, one message is received from each of the d nodes and forwarded to the CH node and one message from the CH node is forwarded to them. So, the average number of message exchanges between SN nodes in LEAP+ for the key refreshment phase comes out to be:

$$ Avg\_Msg\_Count\_Rekey_{S\!N \to S\!N}^{\mathit{LEAP}+} = b+2d $$

(20)

where $Avg\_Msg\_Count\_Rekey_{SN \to SN}^{LEAP+}$ is the average number of messages exchanged between SN nodes in the key refreshment phase of LEAP+. The rest of the expressions in Table 5 are trivial and easily understandable. Expressions in Table 6 are similar to the ones in Table 4 except that h + 1 messages are sent from the CN to the CH nodes in case a CH node is compromised. One message is sent to the new CH node and h messages are sent to its neighboring CH nodes, so that keys can be established between the new CH node and its neighboring CH nodes. Explanations for the rest of the expressions in Table 6 are similar to the ones in Table 4.

In case a SN node is compromised, k compromised keys are refreshed using m remaining keys that the compromised SN node does not know. So, the number of broadcast messages in the cluster by the CH node is m. However, the CH has to send k messages to the neighboring CH nodes, which manage the k compromised keys. k messages will be returned to the CH node with the new key values encrypted in the old ones. Then, those k keys will be aggregated and sent to the h neighboring CH nodes, so that they can encrypt the aggregated message using them using all keys that they manage other than the k compromised keys. In turn, the CH will receive m messages, which it will broadcast in its cluster. So, the average number of messages exchanged between the CH nodes in case of SN node revocation in SHELL can be written as:

$$ Avg\_Msg\_Count\_Revoc\_S\!N_{C\!H \to C\!H}^{\mathit{SHELL}} = h+2k+m $$

(21)

where $Avg\_Msg\_Count\_Revoc\_SN_{CH \to CH}^{SHELL}$ is the average message exchanges between CH nodes when a SN node is compromised in SHELL. In LEAP+, if a SN node is compromised, only its neighbors perform the SN →CH and SN →SN communication. So, in order to calculate the average message count, we divide the expressions for the count of both such messages by b/r. The rest of the expressions in Table 7 do not require much elaboration.