Heterogeneous cluster-based wireless sensor networks (WSN) attracted increasing attention recently. Obviously, the clustering makes the entire networks hierarchical; thus, several kinds of keys are required for hierarchical network topology. However, most existing key management schemes for it place more emphasis on pairwise key management schemes or key predistribution schemes and neglect the property of hierarchy. In this paper, we propose a complete hierarchical key management scheme which only utilizes symmetric cryptographic algorithms and low cost operations for heterogeneous cluster-based WSN. Our scheme considers four kinds of keys, which are an individual key, a cluster key, a master key, and pairwise keys, for each sensor node. Finally, the analysis and experiments demonstrate that the proposed scheme is secure and efficient; thus, it is suitable for heterogeneous cluster-based WSN.

1. Introduction

Recently, wireless sensor networks (WSN) become more and more popular since they have been deployed in various applications, such as military, environmental monitor, industry automation, and smart space. A WSN is composed of a large number of sensor nodes which work together by collaborating with each other. In fact, sensor nodes are constrained in computing, communication, and energy capability; therefore, energy saving and hardware complexity are necessary to be considered carefully when constructing a WSN. For example, asymmetric cryptographic algorithms such as RSA or high cost operations like modular exponentiation operations are not appropriate for designing security mechanisms for a WSN.

Generally, all sensor nodes in a WSN may be divided into several small groups which are known as clusters [13]. Each cluster would have a cluster head responsible for collecting and aggregating sensing data from its cluster members. A cluster-based WSN can be implemented in both homogeneous WSN and heterogeneous WSN. We first consider the case that implementing a cluster-based WSN in homogeneous WSN. Note that all sensor nodes in homogeneous WSN have the same capabilities. After being deployed, every sensor node within the same cluster elects one as a cluster head. Obviously, the workload of acting a cluster head is heavier than a sensor node; as a result, the sensor node which acts as a cluster head would run out of its battery before other sensor nodes. Although it can be solved by rotating the role of the cluster head periodically over all cluster members, the workload of being a cluster head is still heavy for a sensor node. Actually, several studies [4, 5] have demonstrated that a homogeneous ad hoc network has poor performance and scalability.

Hence, several researches have concentrated on a heterogeneous WSN which incorporate different types of sensor nodes with different capabilities. For example, a WSN may contain a small number of powerful high-end sensor nodes ( -Sensors) and a large number of low-end sensor nodes ( -Sensors). If implementing a cluster-based WSN in heterogeneous WSN, -Sensors organize -Sensors around them into clusters, and -Sensors forward sensing reports to the corresponding -Sensor. It is commonly referred to as the heterogeneous cluster-based WSN. The advantage of it is the overall hardware cost of the entire WSN that can be reduced. This is because -Sensors, which only perform the basic functions, can be manufactured very cheap and simple.

In another aspect, security is a vital issue in various WSN applications. Thus, an efficient key management scheme is necessary. Depending on different applications and security requirements, a variety of key management schemes have been proposed for a heterogeneous WSN [610]. In fact, most of these schemes place more emphasis on pairwise key establishment and key predistribution. However, due to the property of a heterogeneous cluster-based WSN that makes the topology hierarchical, a hierarchical key management scheme for cluster-based heterogeneous WSN is essential. Except for an pairwise key, which is shared between two sensor nodes, an individual key, which is shared between each sensor node and the base station, a common cluster key for each cluster, and a master key for all sensor nodes are also required.

Moreover, key updating is also required to be considered for the following reasons. First, sensor nodes may be compromised. The affected keys must be updated or revoked. Second, the network topology may be dynamic. For example, sensor nodes are deployed into the sea for aquatic application. If a sensor node moves to another neighboring cluster, some keys may need to be updated. Third, the base station may desire to update the master key periodically for better security level. For the best of our knowledge, no hierarchical key management scheme with key updating functionality for a heterogeneous cluster-based WSN has been proposed.

In this paper, we propose a complete and efficient hierarchical key management system for a heterogeneous cluster-based WSN. Our design only utilizes symmetric cryptographic algorithms and low cost operations such as bitwise XOR operation and modular multiplication. This construction contains two schemes, key generating scheme and key updating scheme. In the key generating scheme, four kinds of keys, which are an individual key, pairwise keys, a cluster key, and a master key, are generated for each -Sensor. In the key updating scheme, we place the emphasis on updating cluster keys and the master key. In order to improve better efficiency, our design reduces the usage of unicasting. In the performance evaluation, we demonstrate that the storage requirement, communication, and computation cost are reasonable. Besides, in the security analysis, we show that the proposed construction is secure and influence of compromising can be confined to the affected cluster. Finally, the experimental results demonstrate that the operations used in our design are practical.

The remainder of this paper is organized as follows. In Section 2, some preliminaries are introduced. We describe the related work, network model, attack model, and our design goals. In Section 3, we propose our key generating scheme. In Section 4, the proposed key updating scheme is introduced. Then, Sections 5 and 6 describe the security analysis and performance evaluation of our design, respectively. We further provide experiments in Section 7. Finally, Section 8 concludes.

2. Preliminaries

In this section, the related work is introduced firstly. Then we describe the network model of heterogeneous cluster-based WSN and the attack model. We also list our design goals.

2.1. Related Work

Since several studies [4, 5] demonstrated that a homogeneous WSN has poor performance and scalability; several recent works investigate a heterogeneous WSN. Duarte-Melo and Liu [11] analyzed the energy consumption and lifetime of a heterogeneous WSN. Girod et al. [12] developed tools to support a heterogeneous WSN and measurement and visualization of operational systems. Du and Lin [13] proposed a differentiated coverage algorithm which can provide different coverage degrees for different areas. Lazos and Poovendran [14] studied the problem of coverage in planar heterogeneous WSNs. Lin et al. [15] proposed an ant colony optimization-based approach to maximize the lifetime of a heterogeneous WSN. Chen et al. [16] proposed a recoverable data aggregation scheme for a heterogeneous cluster-based WSN. As shown above, heterogeneous WSN indeed received lots of attention.

In the view of key management or key distribution schemes, several researches have been proposed [69, 17, 18]. Most of these schemes focus on probabilistic key predistribution method. Du et al. [6] presented an asymmetric key management scheme which preloads a large number of keys in each -Sensor while preloading a small number of keys in -Sensors. Later, Hussain et al. [8] also proposed key predistribution scheme, which reduces the storage requirements while maintaining the same security strength. Durresi et al. [7] proposed key predistribution schemes between stationary nodes and nonstationary nodes. Traynor et al. [9] described three keying and trust models for the heterogeneous WSN. Khan et al. [17] presented a key management scheme supporting mobility in a heterogeneous WSN that consists of mobile sensor nodes with few fixed sensor nodes. Shi et al. [18] proposed a resource-efficient authentic key establishment scheme for a heterogeneous WSN.

The above schemes for heterogeneous WSNs put more emphasis on pairwise key distribution and ignore the property of hierarchy. Thus, in this paper, we propose a hierarchical key management construction with the functionality of key updating.

2.2. The Network Model of Heterogeneous Cluster-Based WSN

The network model of a heterogeneous cluster-based WSN contains three components, a base station, a small number of powerful high-end sensor nodes ( -Sensors), and a large number of low-end sensor nodes ( -Sensors). -Sensors are expected to have more energy than -Sensors. They organize -Sensors into clusters, collect and aggregate sensing data from their cluster members ( -Sensors), and send the results to the base station. Besides, an -Sensor is equipped with a tamper-resistant hardware.

On the other hand, -Sensors, which have sensing capability with limited computation, memory, and communication, are small and low-cost devices. Each -Sensor detects a target within its detection range, uses its processing power to locally perform simple computations, and then sends the required data to the corresponding -Sensor. Besides, an -Sensor is not equipped with tamper-resistant hardware; therefore, an adversary can obtain the information stored in an -Sensor after compromising it.

Figure 1 illustrates a simple example of a heterogeneous clustered-based WSN. Note that denotes the -Sensor and denotes the -Sensor; belongs to . Depending on different environments, there might be more than one level of -Sensors between the base station and -Sensors. In Figure 1, cluster 3 contains , , , , and . , an upper level -Sensor of , forwards the data sent from to the base station.

Due to the properties of a heterogeneous WSN, the communication capacity of the base station, -Sensors and -Sensors are different. The communication can be classified into the following categories.(1)Within a cluster: an -Sensor can broadcast/unicast messages to its cluster member through single hop, whereas messages sent to the -Sensor may require multihop or still single hop depending on the distance between them.(2)Between two neighboring -Sensors: an -Sensor can communicate to neighboring -Sensors through single hop.(3)Between the base station and -Sensors: no doubt, messages sent to the base station require hop by hop. For example, in Figure 1, messages which are sent by to the base station would pass through . On the other hand, the base station can broadcast/unicast to all -Sensors through single hop or multihops.

2.3. Attack Models

Here we discuss the attack model for key management schemes in a WSN. Depending on the abilities of adversary, attacks can be categorized into two situations.(1)Without compromising sensor nodes: an adversary can only eavesdrop packets or send false messages to legal sensor nodes without any knowledge.(2)Compromising sensor nodes: after compromising a sensor node, an adversary can obtain the information stored in this sensor node. He may calculate other keys or secrets through the compromised information.

Note that detecting compromised sensor nodes which still act as normal sensor nodes is infeasible in all existing detection mechanisms in WSN. However, if an adversary compromises a sensor node and performs abnormal behavior or attacks, it will be detected [1923]. Besides, in a heterogeneous WSN, it is assumed that every -Sensor is equipped with a temper-resistant hardware; thus, considering the case that he compromises an -Sensor is not required.

Based on the above attack models, a key management scheme for a WSN must satisfy the following security requirements.Requirement 1: all messages, including sensing data and control messages, must be encrypted.Requirement 2: an adversary cannot compromise the entire WSN with the compromised secrets. More specifically, he cannot derive the secrets that belong to other clusters. Furthermore, if he compromises two sensor nodes which belong to different clusters, he cannot obtain the secrets with other clusters either.Requirement 3: if compromised sensor nodes are detected, the affected keys must be updated or revoked.

2.4. Design Goals

Four kinds of keys, individual key, master key, cluster key, and pairwise key, are generated in the proposed construction.(1)Individual key: every -Sensor and -Sensor share an individual key with the base station. The base station can encrypt the secret information with the individual key if required.(2)Cluster key: every cluster has one cluster key which is shared with all cluster members including one -Sensor and several -Sensors. The cluster key is utilized for encrypting the cluster traffic. An -Sensor can securely transfer control messages to its cluster members with this key. For example, an -Sensor may turn some cluster members into sleep mode; it can encrypt this control message with the cluster key. On the other hand, all -Sensors within the same cluster may encrypt the sensing reports with the same cluster key. The importance of cluster key is also discussed in [24].(3)Master key: this master key is shared between all -Sensors and the base station within the entire network. The base station can securely broadcast the information to all -Sensors with the master key.(4)Pairwise key: the pairwise key is shared with two neighboring -Sensors. In some applications, two neighboring -Sensors may require secure channel to protect their communication. For example, if the cluster key is compromised, -Sensors in this cluster may encrypt the data with pairwise keys. In this paper, we also consider how to update some of the above keys efficiently. Sensor nodes may be compromised or move to another neighboring cluster; consequently, the master key and the corresponding cluster keys must be updated. Besides, the master key may be updated periodically for security considerations.

3. The Proposed Key Generating Scheme

In this section, we propose a key generating scheme for a heterogeneous cluster-based WSN. As mentioned above, this scheme generates four kinds of keys, individual key, master key, cluster key, and pairwise key. Notations used in this paper are summarized as shown in Notation section.

3.1. Generating Each Individual Key

Actually, individual keys of each -Sensor and -Sensor are preloaded before being deployed. More specifically, an individual key is preloaded to and is preloaded to .

After deployment, -Sensors partition all -Sensors into several clusters. Each -Sensor can realize which -Sensors are organized in its cluster. Then every -Sensor reports its cluster information to .

Before generating other keys, requires to securely assign each -Sensor a key which is shared with the attached -Sensor. For example, which is assigned to is shared between and . Since realizes the cluster information of each cluster, it can securely send the key encrypted with or to every -Sensor and -Sensor. Hence, all -Sensors would share the keys with their attached -Sensors. Note that the key is transmitted only once before the stages of generating other kinds of keys.

3.2. Generating Cluster Keys

The procedure of generating cluster keys is modified from [25, 26]. To generate the cluster key, each -Sensor constructs a binary tree and assigns its cluster members to leaf nodes. The root of the binary tree is the cluster key and intermediate nodes are key encryption keys. Note that the key encryption keys are used for updating the cluster key. Each -Sensor knows all the keys from the parent of its corresponding leaf node up to the root. This set of keys is called the key path. The procedure of generating the cluster key is described as follows.

If there are -Sensors in cluster , the -Sensor will generate random elements and to calculate key encryption keys and the cluster key. Both key encryption keys and the cluster key are composed of one random element and several random elements , where and . means that this key is at level in the key tree and means that this key belongs to the key path . All keys on the same key path have the same random elements .

The example in Figure 2 shows 8 -Sensors in cluster 0. constructs a key tree with 8 leaves and generates random elements , , , , , , and . In Figure 2, (= ), (= ), and (= ) are on the key path 0, , , and are on the key path 1, and so on. , , and belong to key path of and . Note that is a 128-bit prime number. Since is at level 0 in the key tree and belongs to the key path 0, 1, 2, and 3, it is composed of , , , , and . After the key tree is constructed, assigns each cluster member to a leaf node and securely sends the cluster key and key encryption keys on the key path to using the key .

3.3. Generating the Master Key

Assume that there are -Sensors which are denoted as in a WSN. Before generating the master key, needs to deliver the secure information and to each -Sensor and -Sensor. Note that this secure information is used when generating and updating other keys (see Section 4.2).

first chooses a 128-bit prime number , where is public, and two secret random numbers , . It also selects distinct numbers which are denoted as from . then securely sends the following message to all -Sensors: where and . After receiving it, each -Sensor, for example, , broadcasts to all its cluster members. Note that is the cluster key of cluster . As a result, all its cluster members can obtain . Note that -Sensors attached to the same -Sensor will have the same secure information . Figure 3 shows an example of a WSN with secure information.

After that, starts to generate the master key. The procedure of master key generation is described as follows.

Step 1. first selects a random number and computes a master key .

Step 2. broadcasts to all -Sensors.

Step 3. When each -Sensor receives from , it calculates the following equations and broadcasts the result to all its cluster members.
For all , calculates We use bitewise XOR operation to guarantee that messages can be securely sent to legitimate -Sensors.

Step 4. When receives from , it computes the master key , where By the above steps, all -Sensors have the same master key .

3.4. Generating Pairwise Keys

The pairwise key shared with two neighboring -Sensors can be generated through their corresponding -Sensor. For example, if desires to share a pairwise key with , will generate this pairwise key and send and to and , respectively; consequently, both and can obtain this pairwise key.

4. The Proposed Key Updating Scheme

In this section, we propose the key updating scheme to update some of the generated keys. We discuss these kinds of keys separately as follows.(1)Individual key: since it is only shared between and each -Sensor, this key is revoked automatically if an -Sensor is compromised.(2)Cluster key: obviously, if an -Sensor is compromised, the corresponding cluster requires updating the cluster key. Besides, -Sensors may move to another neighboring clusters if the deployment of -Sensors is nonstationary; consequently, both clusters (the original cluster and the target cluster) require updating their cluster key, respectively.(3)Master key: similarly, if -Sensors are compromised, the master key must be updated. Besides, may desire to update the master key periodically for better security considerations.(4)Pairwise key: for example, assume that two -Sensors, and , have shared a pairwise key. If is compromised, would revoke the shared pairwise key automatically. Besides, these two -Sensors can also update this key periodically.

4.1. Updating the Cluster Key

Here we discuss how to update cluster keys. First, we consider that an -Sensor leaves a cluster. It is because this -Sensor is compromised or moves to other neighboring cluster. Second, we consider an -Sensor joins a cluster.

4.1.1. An -Sensor Leaves a Cluster

In Figure 2, if leaves cluster 0, the keys , , and must be updated. The detailed procedure is described in the following.

Step 1. selects a random number from and sends the following key update messages: (i) ,(ii) ,(iii) .

Step 2. , , , and can obtain with and then compute the new cluster key where

Step 3. and can obtain with and then compute the new keys and where

Step 4. can obtain with and then compute the new keys , , and where

Obviously, it only requires updating the value in this example. Since has no keys to obtain , it cannot compute the new cluster key and key encryption keys.

4.1.2. An -Sensor Joins a Cluster

When an -Sensor joins a new cluster, the target -Sensor authenticates this joined -Sensor. This can be accomplished by coordinating with the original -Sensor. Then would deliver a key which will be shared between the target -Sensor and this -Sensor. After receiving this key, the -Sensor would assign this new -Sensor a leaf node of the key tree. To prevent this new -Sensor from decrypting the past traffic, all the keys on this key path need to be updated.

Let us take Figure 2 as an illustration. Assume that joins this cluster and has received an individual key . The procedure of updating the cluster key is described as follows.

Step 1. assigns a leaf node of the key tree. then selects a random number from to compute the new keys, , , and , where

Step 2. needs to send the following two messages; one is broadcasted to all -Sensors within this cluster for updating the key path; one is additionally unicasted to the new -Sensor : (i) ,(ii) : Since does not have , it cannot obtain to compute the previous keys. On the contrary, all other -Sensors in this cluster will obtain .

Step 3. computes the new keys , , and with .

Step 4. , , , and can compute the new key from (7) with the obtained .

Step 5. and can compute the new keys and from (7) and (8) with the obtained .

Step 6. can compute the new keys , , and from (7), (8), and (9) with the obtained .

Similarly, only the value is required to be updated.

4.1.3. Further Discussion

Notice that in Step 1 of Section 4.1.1, for example, will receive protected by . The reason that we use the equation rather than is to protect . More specifically, if we only use (12), , , and can utilize the obtained to further obtain . In fact, is not revealed to , , and ; therefore, an additional bitewise XOR operation is required.

Similarly, in Step 2 of Section 4.1.2, the reason we use (10) rather than is to protect ; otherwise, other cluster members can obtain with , , or .

4.2. Updating the Master Key

Here we discuss how to update the master key in the following situations. First, may update the master key periodically to improve the security level. Second, the master key is required to be updated if -Sensors are compromised.

4.2.1. Updating the Master Key Periodically

The master key may be updated periodically, for example, monthly. The procedure of updating master key is described as follows.

Step 1. selects a new random number and calculates a new master key . broadcasts to all -Sensors.

Step 2. While receives , it calculates
then broadcasts the result to all its cluster members.

Step 3. can calculate the new master key where

In conclusion, all -Sensors can obtain the new master key .

4.2.2. Updating the Master Key If -Sensors Are Compromised

Assume that -Sensor which is attached to is compromised and denotes the -Sensor which is also attached to , where . Besides, there are -Sensors which are denoted as in the entire WSN. The procedure of updating the master key is described as follows.

Step 1. selects a new random number and calculates a new master key . also selects a random number to compute and broadcasts to all -Sensors.

Step 2. Except for , each -Sensor calculates the following equations and broadcasts the result to its cluster members.
For all , , calculates
Then, all their cluster members can obtain the new master key , where

Step 3. (a) obtains from and further computes the new secure information where
(b) obtains from and new secure information . Then broadcasts . Note that is the new cluster key of cluster .
(c) Except for , all the other -Sensors which are also attached to can derive and from the obtained message and then compute , where
(d) After updating , all the other -Sensors except within cluster can compute new master key where

Only can obtain by decrypting . Besides, the compromised -Sensor cannot obtain and to compute the new secure information without ; therefore, it is unable to obtain the new master key.

Obviously, only the -Sensors within the affected cluster require updating the secure information before updating the master key; as a result, the influence can be confined locally.

4.2.3. Further Discussion

We have already discussed how to update the master key. It may be questioned why we need to do it in this way. A trivial idea is to let generate a random master key (either for master key generation or master key updating). Then encrypts it using each cluster key and transmits it to every -Sensor. This method seems simpler and more straightforward.

The reason is that the proposed scheme attempts to reduce the usage of unicasting. More precisely, in the above method, requires to unicast each encrypted master key to corresponding -Sensor. However, only needs to broadcast the same message ( ) to every -Sensor in our design. Actually, using broadcast is more efficient than using unicasting. We will demonstrate it through experiments in Section 7.

4.3. Updating the Pairwise Key

Assume that two -Sensors, and , have shared a pairwise key. If these two -Sensors decide to update their shared pairwise key, generates a new pairwise key and sends and to and , respectively.

5. Security Analysis

In this section, we demonstrate that the proposed construction is secure through the following analyses. We first explain that our design satisfies the following security requirements mentioned in Section 2.3.Requirement 1: indeed, this requirement is satisfied. All kinds of messages (sensing reports and control messages) will be encrypted with the generated keys. An adversary cannot realize any information without keys.Requirement 2: if an adversary compromises an -Sensor which is denoted as , he can obtain , , , and several key encryption keys . However, he is not capable of calculating cluster key and secure information belonging to other clusters. Moreover, the secrets belonging to other clusters cannot be derived even if he compromises two -Sensors belonging to different clusters.Requirement 3: actually, the purpose of our key updating scheme can achieve Requirement 3.

Here we analyze the proposed construction in the following aspects.

5.1. The Influence of Compromised -Sensors

Actually, an adversary can obtain all information which is stored in an -Sensor after compromising it. Fortunately, the adversary cannot calculate the information (cluster key and secure information) of other clusters in our design; as a result, the proposed construction ensures that the compromise of -Sensors does not cause the compromise of the entire network.

To prevent the adversary from decrypting future traffic, the compromised individual key and the pairwise keys are revoked automatically. Besides, updates the affected cluster key and the master key. In our design, the adversary cannot obtain this updated information. Moreover, as an example showed in Section 4, only the affected cluster needs to update the secure information before updating the master key. Obviously, the influence of compromising can be confined to be affected cluster.

Besides, if an -Sensor moves to another cluster, both clusters (original and targeting clusters) would update the cluster keys. It can prevent the -Sensor from decrypting the traffic of both clusters after it leaves or before it joins. In fact, it can also effectually reduce the influence of compromising. An adversary may eavesdrop and record all packets before compromising -Sensors. Let us consider the following situations if an -Sensor moves from cluster 0 to cluster 1. Note that and are the cluster keys of cluster 0 and cluster 1, respectively.(1) and are updated: and are updated to and , separately. If which already has moved to cluster 1 is compromised, an adversary would obtain . Hence, he cannot decrypt the messages encrypted with . Similarly, if the adversary compromises an -Sensor within cluster 0 after leaves, he can only decrypt the messages encrypted with .(2) and are not updated: receives after arriving to cluster 1. If is compromised, an adversary can decrypt the messages encrypted with . More specifically, after compromising , he can retrieve the messages which are sent before joins. Similarly, the same condition happened if he compromises an -Sensor within cluster 0. Obviously, the influence of compromising is effectually reduced.

5.2. Confidentiality

An outsider cannot obtain the current cluster keys or master key because the cluster keys and the secure information which is used for computing the master key are securely distributed to all legitimate -Sensors. Although a leaving -Sensor has the old secure information or the old cluster key, this -Sensor cannot derive the new master key or the new cluster key. To prevent a leaving -Sensor from obtaining the parameter or , we choose the length of the prime number as 128-bit. It is large enough to ensure that deriving correct ( , ) pair from is infeasible. Although a leaving -Sensor knows the messages and , it cannot compute the current master key .

5.3. Integrity

To achieve message authentication and integrity, we can utilize hash algorithms, for example, SHA-1 or MD5, to compute message authentication code (MAC) for a message. For example, in the master key generation phase of the key generating scheme, computes the MAC of with , appends it to , and then broadcasts it to all -Sensors. Each -Sensor broadcasts and the received message ( and its MAC) to its cluster members. Eventually, each -Sensor uses the computed master key to recompute the MAC and compares it with the received MAC value. This implies that if an adversary masquerades as to send a message, he does not have the master key to compute the corresponding MAC value, and -Sensors will reject this message.

6. Performance Evaluation

In this section, we show that the proposed construction is efficient in storage, communication, and computation. Besides, it is scalable because the additional overhead of increasing -Sensors is confined to .

6.1. The Storage Requirement

In the key generating scheme, each -Sensor requires storing some keys and necessary information. For example, an -Sensor , would store , , , a cluster key , and a common master key . Also, several key encryption keys must be stored to update the cluster key. The number of key encryption keys of is about where is the number of -Sensors in cluster . The total storage of these secrets is 128-bit (5 + ( )). Since usually there are at most one hundred -Sensors within a cluster, total storage is about 176 bytes. Comparing with the current generation of sensor nodes (128 Kbytes in programmable flash memory in MICAz), the storage of the proposed scheme is much less. Besides, as the cluster size grows, the number of keys stored in an -Sensor increases proportional to the number of -Sensors within the cluster in an order of . Note that each -Sensor may also require to store the pairwise keys shared with its neighbors if necessary, but the total storage requirement is still reasonable.

6.2. The Communication Cost

Here we discuss the communication cost of the proposed construction. The communication cost is closely related to two factors. The first one is the message size. Obviously, the number of bits of every message is less than 128-bit. It is reasonable in a WSN. The second one is the transmission types. In fact, using broadcasting is more efficient than using unicasting in a WSN (we will show it in the next section). The majority of transmission in the key generating scheme is using broadcasting. For example, in the master key generation phase, broadcasts to all -Sensors. Similarly, -Sensors also broadcast the calculating results to its cluster members. The use of unicasting in the proposed scheme is normally involved in the initial stage of some phases. For example, unicasts to all -Sensors at the initial stage of master key generation phase; thus, this transmission would be executed only once; even the master key must be updated. Similarly, transmitting is still executed only once before generating cluster keys and the master key.

In the key updating scheme, every -Sensor in the affected clusters only receives one message to update the cluster key. In order to avoid using unicasting, we aim to reduce the number of kinds of messages transmitted on the air. As the example shown in Section 4.1, only three kinds of messages are transmitted on the air. Similarly, only two kinds of messages are transmitted in Section 4.1. In the view of updating the master key, it only requires two broadcasts. More specifically, broadcasts same information to all -Sensors, then each -Sensor broadcasts the calculating result to all cluster members. Only the -Sensors within the affected cluster require updating the secure information; consequently, the impact can be confined locally. As a result, updating keys incurs less communication overhead and is beneficial for the limited energy of -Sensors.

6.3. The Computation Cost

The proposed construction utilizes symmetric cryptosystem, such as AES, and modular multiplication. AES is practical and efficient based on previous experimental studies. Another operation, modular multiplication, is always considered as an inefficient operation where the modulus is large, for example, 1024-bit moduli. However, the length of the modulus we adopted is only 128 bits. To demonstrate high effect of the modular multiplication with a 128-bit modulus, we implement it on MICAz sensor nodes. Computation results are given in Section 7.2.

7. Experiments

In our experiments, we choose MICAz sensor nodes. MICAz is capable of ATmega128L microcontroller. The architecture is 8-bit with 8 MHz computation speed. Total programmable memory storage of MICAz sensor is 128 Kbytes. For communication interface, MICAz uses ZigBee (802.15.4) to communicate with other MICAz sensors. Figure 4(a) shows one MICAz sensor. Another device is the base station. Figure 4(b) shows one MICAz sensor plugged on a MIB510 hardware interface, which is the interface of the base station. The MIB510 broad is connected to the desktop computer.

7.1. Experiment Assumptions and Design

After deployment, routing paths will be constructed. Normally, a routing path is constructed as a tree structure. In order to simplify this experiment, we assume that all -Sensors in the routing path have the same degree. Figure 5 illustrates a constructed routing path with degree and height .

Some researches assume that is capable of transmitting data to all -Sensors through one hop. However, this assumption is not reasonable. In our experiments, we assume that data transmitted to all -Sensors require multihops. For example, in Figure 5, the message sent to by would pass through and . Therefore, if desires to update the master key, the following two scenarios may happen using the example shown in Figure 5.(1)Using unicasting: encrypts the new master key with each cluster key ( ), respectively. then sends these encrypted master keys to all -Sensors. Therefore, receives seven messages which are , , , , , , and . obtains and then transmits three messages ( , , and ) to and transmits the remainder three messages to . Similarly, will receive three messages and then transmit two messages. Note that the size of the encrypted master key is 128 bits.(2)Using broadcasting: the proposed master key updating method actually uses broadcasting. broadcasts a common message to all -Sensors. Every -Sensor receives only one message from the upper level -Sensor and then broadcasts it to lower level -Sensors. For example, receives a message from and then broadcasts it to and . Note that the size of the broadcasted message depends on two situations. First, if desires to update the master key periodically, the size of the broadcasted message is 128 bits ( ). Second, updates the master key if -Sensors are compromised. The size of broadcasted message is 256 bits .

Three experiments are performed in this paper.(1)Experiment 1: we evaluate the energy consumption of an MICAz sensor node while transmitting or receiving messages with different sizes.(2)Experiment 2: we calculate the communication overhead of the entire network. We consider the above two scenarios.(3)Experiment 3: we evaluate the cost of AES and modulus multiplication.

In our experiments, we use MICAz sensor nodes to act as -Sensors and calculate their energy consumption. If fact, energy consumed on powerful devices is the same as one on weak devices, such as MICAz. Besides, energy consumption measurement depends on the number of clock cycles spent [27]. Energy consumption for executing 2090 clock cycles on the ATmega128L microcontroller is equivalent to 7.4 μJ (Joule).

7.2. Experiment Results

Experiment 1. To measure energy consumed on transmitting and receiving data, the number of clock cycles is recorded when a data packet is received and sent. Broadcasting and unicasting executed 10 rounds for different length of data packets. The average results are showed in Table 1. Obviously, the values of broadcast 128-bit and unicast 128-bit are almost equal. Besides, the value of broadcasting 256-bit is larger but twice smaller than broadcasting 128-bit. It is because transmitting a 256-bit message still requires one package.

Experiment 2. According to the results in Experiment 1, total energy consumed for a WSN is simulated and evaluated. Table 2 lists the result of communication overhead of the above two scenarios. We consider several routing paths with different degree and height . For example, if a routing path is generated as a tree with degree and height , the total energy consumption of all -Sensors when broadcasting 128-bit/broadcasting 256-bit/unicasting 128-bit is 0.0149/0.0174/0.3551 mJ, respectively. The number of -Sensors in this tree is 6. While performing unicasting 128-bit, the maximum energy consumption among all -Sensors is 0.0923 mJ. Besides, the average energy consumption of all -Sensors is 0.0592 mJ when performing unicasting 128-bit.
Since senor nodes may be deployed in a large scale environment, the number of clusters may be up to thousands. Thus, we consider several candidates with different and . Obviously, the communication overhead is closely related to the number of -Sensors. If it grows to hundreds or thousands of nodes, it causes huge energy consumption.
In the view of average energy consumption of an -Sensor, we can consider the following cases. (1)Broadcast 128-bit: in this condition, every node receives one 128-bit message and broadcasts it. The total energy consumption of every node is 21.3 μJ (= ).(2)Broadcast 256-bit: similarly, the total energy consumption of every node is 24.84 μJ (= ).(3)Unicast 128-bit: the average energy consumption is listed in Table 2. Obviously, the values are quite larger.

Experiment 3. The goal of this experiment is to evaluate the costs of AES and modulus multiplication. Execution time and energy consumed by them are recorded. For AES, we choose an AES library based on TinyOS-2.x for comparison. We also implemented modulus multiplication by ourselves. These two operations were executed on MICAz physical sensors for 100 rounds. The average results are given in Table 3. In Table 3, one multiplication over 128-bit modulus is equivalent to 1.75 AES encryptions. As a result, modulus multiplication is feasible on physical sensors.

7.3. Discussion

Through these experiments, we can demonstrate that the proposed key updating scheme is efficient. This is because we utilize broadcasting instead of unicasting. Actually, we must take something into consideration. First, every -Sensor in the routing path may not have the same degree. Second, may have more powerful transmission capability. Let us use Figure 5 as an example. The transmission range of may reach the second level -Sensors. Therefore, the total energy consumption would not equal the result shown in Table 2. However, the overall energy consumption is still high if using unicasting.

8. Conclusion

In this paper, we proposed a complete hierarchical key management construction for heterogeneous cluster-based WSN which only utilizes simple operations. It considered several kinds of keys which are necessary for WSN. Besides, some kinds of keys may require updating; an efficient key updating scheme is also proposed. In order to provide better efficiency, the majority of transmission in our design is using broadcasting. In fact, using unicasting is inevitable in designing security mechanisms for WSN. Fortunately, the usage of unicasting in our design is normally involved at the initial stage of some phases. In the security analysis, we showed that the influence of compromising is effectually reduced and confined locally. We also showed that the proposed construction is efficient in storage, communication, and computation. Finally, we gave some experiments to further demonstrate two things. First, the operations we used are simple and practical. Second, using unicasting will cause uncontrollable overhead. In conclusion, the proposed construction is appropriate for heterogeneous cluster-based WSN.


The base station
:The -Sensor
:The -Sensor belongs to
:A message encrypted with the key
:The predeployed key shared between and
:The predeployed key shared between and
:The key shared between and
:The secure information shared between and
:The secure information shared between and
:The cluster key for the cluster
:The key encryption key in the cluster
:The master key
:Bitewise XOR operation

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.


The work was supported in part by the Project HIT.NSRIF.2014098 by Natural Scientific Research Innovation Foundation in Harbin Institute of Technology, in part by Shenzhen Peacock Project, China, under Contract KQC201109020055A, and in part by Shenzhen Strategic Emerging Industries Program under Grant ZDSY20120613125016389.