A Secure Hierarchical Key Management Scheme in Wireless Sensor Network

Abstract

Due to the vulnerable environment, limited recourse and open communication channel, wireless sensor networks (WSNs) are necessary to be protected from various attacks. The key management is an important way to protect the communication in WSNs. In this paper, we present a hierarchical key management scheme (HKMS) which can efficiently enhance the security and survivability for the clustered WSNs. Different from previous works, the HKMS distributes keys based on hop counts and one-way function by the clustered architecture, which not only localizes the key things but also has no overhead. The HKMS provides the session keys among sensors and the cluster key between the cluster head and member nodes. The HKMS dynamically generates different keys based on different hops in different periods which can protect the network from the compromised nodes and reduce the high probability of the common keys without any special sensors (such as the anchor nodes). The security analysis and simulation show the HKMS can prevent several attacks effectively and reduce the energy consumption.

1. Introduction

Wireless sensor network (WSN) is usually considered as a large-scale network with thousands of tiny sensors and deployed in smart grid, smart city, smart home, and so forth to sense the information. As the most important part in the perception layer of internet of things (IoTs), WSNs are deployed for sensing, monitoring, or controlling various objects [1, 2]. However, there are still some limitations, such as the capability of computation, low energy, small storage and open communication channel. Therefore, WSNs are vulnerable to various attacks, and the security in WSNs is required [3–8].

Some literatures focus on localizing the key things. In [2, 3], the authors presented RPKH and location-dependent key management (LDK) schemes to provide the local key management. The RKPH and LDK utilize different nodes including the normal nodes and anchor nodes to generate keys by different transmission ranges.

In [3], LDK has been presented and it employs the heterogeneous sensors to build a clustered sensor network. In LDK, there are higher ability nodes, the anchor nodes, as the management nodes. The anchor nodes use the different location information to generate sets of keys. Neighboring nodes can establish secure communication link by determining the common keys via exchanging their key materials. LDK takes advantage of relative location of nodes after deployment by utilizing anchor nodes at different power levels. Based on different locations, nodes can receive different sets of keys from anchor nodes. Neighboring nodes can establish secure communication link through the common keys. LDK can increase the direct connectivity ratio among nodes. However, in LDK, nodes need to transmit a message that consists of all the key materials when determining common keys to establish secure links. Therefore, it consumes lots of communicating energy and is not efficient for WSNs, and the adversary also can eavesdrop on the key materials during nodes exchanging packets. Moreover, the special node (anchor node) makes it difficult to deploy.

In [5], the ARPKH is designed based on random key distribution in the heterogeneous sensor networks, which uses separate keys in different clusters and take into consideration distance of sensors from theirs cluster head. Compared with the RPKH, the ARPKH considers a multiple shared keys between pairwise nodes. When a key that used for establishing the secure link between two nodes is revealed, the link has been expired and then the connectivity is broken. Moreover, ARPKH will change the alternative shared keys to replace the revealed key and establish a new secure link between two nodes again. However, the ARPKH needs alternative shared key replacement, which makes sensors predistribute more keys and occupy larger storage. Moreover, ARPKH also needs the anchor nodes as the cluster head, which makes it impracticable.

In this paper, we present a hierarchical key management scheme (HKMS) in the clustered wireless sensor network [9]. Different from the previous works, our network needs no any special nodes (e.g., high-energy or high-capability nodes), which makes it more practicable to deploy. Meanwhile, HKMS also distributes keys through the key seed (nonce) according to TTL (time to live), which has higher level security than previous works transferring key things directly.

The HKMS builds the key system with the clustered architecture formation. The cluster head gets the hop counts from cluster head to the member nodes with ACK packets and then uses the hop count to determine TTL as well as a certain numbers of nonces for building the key system. During the key distribution, nodes in different hop ranges will be obtained different keys. With the cluster head reselection, the key system will be rebuilt, and then the key should be reassigned.

Considering about the security and the life time of WSNs, we will rekey to refresh the cluster and the keys. During the rekey phase, the cluster will elect new cluster head which calculates the new distance from CH to member nodes and then generate the new key system based on the old one.

Our solution has the following scientific research contributions: (1) HKMS utilizes the hierarchical architecture to localize the key things, which prevents the compromised nodes threat the entire network. (2) Without any overhead, HKMS counts the hop count in the cluster formation, which can effectively reduce energy consumption. (3) HKMS employs the normal wireless sensor network but not special nodes, which makes it more practicable.

The rest of this paper is organized as follows Section 2 presents the system model. Section 3 describes the key management in detail. Section 4 evaluates HKMS using security analysis, meanwhile, we simulate the solutions to evaluate the performances of HKMS. Finally, we end the paper with a conclusion as well as the further work in Section 5.

2. System Model

2.1. Network Model

Given G is a WSN which consists of m clusters, that is, $G=C_{\mathrm{1}}\cup C_{\mathrm{2}}\cdots \cup C_m$ and $C_i\cap C_j=\varphi$ , $i\ne j$ , where $C_i$ is a cluster with the cluster head $(\text{CH}\mathrm{\hspace{0.17em}\hspace{0.17em}}\text{or}\mathrm{\hspace{0.17em}\hspace{0.17em}}{\text{CH}}_i)$ and member nodes [10, 11]. In a cluster, the CH collects and aggregates packets from its member nodes and then forwards them to the base station (BS). Normally, a member sensor can transfer packets to CH through several hops. Assume a normal node $v_j^i\in C_i$ , it communicates with CH through multihop, as shown in Figure 1.

Figure 1

The considered wireless sensor network.

2.2. Assumptions

In our network, all sensor nodes are deployed in the network uniformly and randomly and are static. Each sensor has a unique ID. If a node is compromised, all of the information in this node will be revealed including the key materials [12]. The sensors in network should be in at least one cluster.

2.3. Notations

In Table 1, we list some notations used in this paper.

Table 1

Notations.

Notation	Explanation
$K_I$	The initial key shared by all nodes
$\text{I}{\text{D}}_{\text{CH}}$	ID of the cluster head
$n_i$	The ith nonce in the set of nonces N
$\text{I}{\text{D}}_{v_j}$	ID of member node $v_j$
$f()$	The one-way function
TTL	Time to live
$C_i$	The ith cluster in the WSN
$k_j^i$	The ith key for the member node $v_j$
$v_j^i$	The member node in $C_i$

3. The Hierarchical Key Management Scheme

In this section, we introduce the hierarchical key management scheme (HKMS) in detail. Before the deployment of the sensor network, each sensor is predistributed an initial key $K_I$ for the security in deployment phase, the initial key provides the communication during the formation phase and will be erased after key deployment [12].

3.1. The Cluster Head Election

As mentioned above, considering the energy efficiency and management facilitation of WSN, we adopt the hierarchical architecture for our network [10, 11, 13]. Firstly, a node itself decides whether it becomes a candidate CH or not according to the cluster head election algorithm [10, 14]. The node will announce the candidate information to other nodes. And other nodes which may accept several election campaign messages, and they will choose one to join it as follows.

3.2. The Cluster Formation

Once a node becomes a cluster head, it will send a beacon message to other sensors to form a cluster. Each sensor may receive several different beacon messages from different candidate cluster heads, but it only can join one cluster.

When the CH broadcasts a beacon message encrypted by $K_I$ contains ID of CH, the transmission range is limited by TTL, that is, calculated by hop count. Usually, TTL is the hop count plus one. And then, TTL and a set of nonces named N, the random numbers. And the nonces will be different with different TTL, that is, if the $\text{TTL}=3$ , then the sensor will get four $(\text{TTL}+\mathrm{1})$ nonces, such as $N=\{n_1,n_2,n_3,n_4\}$ . We generate more nonces (e.g., $\text{TTL}+\mathrm{1}$ ) for the connectivity, especially the common keys. Where TTL is to limit the cluster size, for example, $\text{TTL}=3$ , and it will be decreased for each forwarding until it becomes 0 and the beacon message will be dropped.

Therefore, depending on the cluster size (TTL), other nodes can receive different sets of beacon messages from different CHs as (1) in different distance (hop ranges) as shown in Figure 2:

$$\begin{array}{cc}& N=\left\{n_i\mid n_{\mathrm{1}},\dots ,n_{\text{TTL}+\mathrm{1}}\right\}\\ \text{CH}\to *:{\left\{\text{I}{\text{D}}_{\text{CH}},N,\text{TTL}\right\}}_{K_I}.\end{array}$$

(1)

Figure 2

The nodes in different hop range to CH (assume these nodes join in the same cluster, $\text{TTL}=3$ ).

3.3. The Initial Key Generation

Assume $v_j\in C_i,\hspace{0.17em}{v}_j\ne \text{CH}$ , we call $v_j$ as member node. When member node $v_j$ receives a beacon message and wants to join the cluster $C_i$ , it counts the TTL and sends the ACK including the ${\text{ID}}_{v_j}$ and the ${\text{TTL}}_{v_j}$ back to its interest cluster, and then the cluster head knows the hops from ${\text{ID}}_{v_j}$ to CH.

The beacon messages are orderly transmitted at different distance levels. And then, the member node $v_j$ decrypts the beacon messages and obtains $\text{I}{\text{D}}_{\text{CH}}$ and then set of nonces $N_i$ .

And then, $v_j$ calculates the candidate keys $k_j^i$ and gets the key set $K^i$ based on the received nonces as follows:

$$\begin{array}{cc}& K^i=\left\{k_j^i\mid k_{\mathrm{1}}^i,\dots ,k_{{\text{TTL}}_{v_j}}^i\right\},\hspace{1em}{k}_j^i=f\left(k_I,n_i\right),\end{array}$$

(2)

where $f()$ denotes a one-way hash function. The specific algorithm of key distribution is designed as in Algorithm 1.

Algorithm 1: Key distribution algorithm (TTL = 3).

(1) CH broadcasts beacon messages with different nonces:

          $\text{CH}\to \mathrm{*}:\{\text{I}{\text{D}}_{\text{CH}},N,\text{TTL}{\}}_{K_I}$

(2)   $v_j$ decrypts $\{\text{I}{\text{D}}_{\text{CH}},N,\text{TTL}{\}}_{K_I}$

(3)   $K^i=\varphi$

(4)   $k_{\text{length}}=\text{TT}{\text{L}}_{v_j^i}$

(5)  For $j=1$ to $k_{\text{length}}\{$

    $k_j^i=f(k_I,n_i)$  // generate the key pool

    $K^i=K^i\cup \{k_j^i\}$

  }

(6)  Erase $K_I$ .

(7)  end.

And the initial key generation process is as shown in Figures 3 and 4.

Figure 3

The initial key generation process.

Figure 4

The deployment of nonces from the cluster head $(\text{TTL}=3)$ .

After the calculations, nodes erase $K_I$ . Consequently, $v_j$ stores the key things as follows in Table 2.

Table 2

Keys table of member nodes in different hop ranges (TTL = 3).

Keys for 1st hop	Keys for 2nd hop	Keys for 3rd hop
$k_j^{\mathrm{1}}$ , $k_j^{\mathrm{2}}$ , $k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$	$k_j^{\mathrm{2}}$ , $k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$	$k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$
$k_j^{\mathrm{1}}$ , $k_j^{\mathrm{2}}$ , $k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$	$k_j^{\mathrm{2}}$ , $k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$	$k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$
⋯	⋯	⋯
$k_j^{\mathrm{1}}$ , $k_j^{\mathrm{2}}$ , $k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$	$k_j^{\mathrm{2}}$ , $k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$	$k_j^{\mathrm{3}}$ , $k_j^{\mathrm{4}}$

According to Table 2, we can find that the nodes can communicate with its neighbour nodes for the common keys. The specific algorithm of hop count and key information acquirement is as in Algorithm 2.

Algorithm 2: Hop count and key information acquirement algorithm (TTL = 3).

$(\mathrm{1})$ CH broadcasts beacon messages with different nonces:

  $\text{CH}\to \mathrm{*}:\{\text{I}{\text{D}}_{\text{CH}},n_{\mathrm{1}}\cdots n_{\text{TTL}+\mathrm{1}},\text{TTL}{\}}_{K_I}$

(2)   $v_j\to \text{CH}:\{\text{I}{\text{D}}_{v_j},\text{TT}{\text{L}}_{v_j}{\}}_{K_I}$ , Key pool generation for $v_j$ by $k_j^i=f(k_I,N_i)$

$(\mathrm{3})$   Erase $K_I$ .

$(\mathrm{4})$ CH obtains the hop count: $N_{\text{hops}}=\text{TT}{\text{L}}_{\text{CH}}-\text{TT}{\text{L}}_{v_j}+\mathrm{1}$

$(\mathrm{5})$ According to the $N_{\text{hops}}$ , nonces N, and oneway function f(), the cluster head

 can get the $\text{I}{\text{D}}_{v_j}$ 's key information.

$(\mathrm{6})$   end

3.4. The Common Key Discovery

For communication with ites neighbouring nodes, member node should establish secure link between them which needs the common keys to encrypt/decrypt messages. According to those candidate keys, member nodes in the same distance receive the same beacon messages and they can also generate the same keys. Moreover, the nodes in the adjacent areas also have some duplicate candidate keys.

If a node can receive $\{{\text{ID}}_{\text{CH}},N_i,{\text{TTL}}_i{\}}_{K_i}$ , it also can receive $\{{\text{ID}}_{\text{CH}},N_j,{\text{TTL}}_j{\}}_{K_i}$ , where ${\text{TTL}}_i>{\text{TTL}}_j\hspace{0.17em}\hspace{0.17em}(i<j)$ . Since the distance range of hops j covers the distance range of hops i, the node near cluster head has more keys than the one far away from cluster head.

Therefore, each member node $v_j$ generates a list $L_j$ which just stores the keys as follows:

$$\begin{array}{cc}& L_j=\left\{k_j^i\mid k_j^{\text{Hops}},\dots ,k_j^{{\text{TTL}}_{v_j}+\mathrm{1}}\right\}.\end{array}$$

(3)

According to the principle of key generation, given two nodes $v_i$ and $v_j\hspace{0.17em}\hspace{0.17em}(i<j)$ , the set of common keys is S, then we have: $S=L_j\cap L_i=L_j$ .

Moreover, since the packets from members will be collected by the cluster head, the cluster head should have the ability to decrypt these messages. During this process, the member nodes should report its keys, which will increase the transmission. Because the nonces are sent by the cluster head, it also knows the function, and then it can calculate the keys of members as mentioned in Algorithm 2.

Due to the keys generated by hop count, nodes in the same cluster can be connected. And the path key between $v_i$ and $v_j$ is calculated as follows:

$$\begin{array}{cc}& k_{ij}=f^{\text{abs}\left(i-j\right)}\left(k_I,N_i\right).\end{array}$$

(4)

Equation (4) makes it possible for any two nodes in the cluster to communicate with each other. Actually, there is another way to make every two nodes communicate, that is, the last nonce is the same in a cluster, which makes the same key for the cluster. (the last nonce is used to the cluster key).

3.5. The Cluster Key

The cluster key is the key which is used for communication between the CH and its members also for generating new key in next round. Since there are $\text{TTL}+1$ nonces, according to Algorithms 1 and 2, the last nonce in the set N will be transferred to every sensor.

3.6. The Rekey Process

For prolonging the lifetime of the whole network, it is necessary to change the cluster head. On the other hand, the key should be rekeyed for the security [15, 16], otherwise, when CH receives a certain amount of encrypted messages (more than $2^{2k/3}$ , k is the length of key) [15], the keys will be no longer safe. According to the requirements above, we should recluster after a certain phase. Assume that the process of reclustering happens inside the cluster, which can reduce the energy consumption.

During the reselection of CH, we can rekey as the initial phase. When the new cluster head has been selected according to the algorithm [10], it will announce itself as the cluster head and recalculate the distance from its members.

As shown in Figure 5, after reclustering, the new cluster head changes not only the relative position but also hop counts from CH to members, which make the nonces as well as the key things different.

Figure 5

The reselection of cluster head.

4. Security Analyses

4.1. The Security Analyses

Compared to previous works, the salient advantage of our solution is that we addressed challenging runtime security issues using localizing key things and design a dynamic key management.

During the cluster formation phase, the cluster head can calculate the hop counts from the cluster head to member nodes, and then the member nodes can generate keys by the nonces and hops from the beacon message. According to the different hop counts, the cluster is divided into several security belts as shown in Figure 2, the nodes in different belts have different keys. Because the keys are generated by the set of nonces, the adjacent nodes have some common keys, which makes it possible to communicate with each other.

Moreover, nodes near the cluster head have more keys than the nodes far away from CH, which means that the far nodes just can submit message to the CH. And then the messages just can be decrypted by near nodes, which makes the HKMS protocol more suitable to the collection type wireless sensor networks. The one-way security model prevents the eavesdrop attack, selective-forwarding attack DoS attack (denial-of-service) and hello flood attack, and so forth as shown in Table 3.

Table 3

Analysis in local key management.

Attack types	RPKH	LDK	HKMS
Selective forwarding	×	×	√
Sink-Hole attack	×	√	√
Sybil attack	√	√	√
Worm-Hole	√	√	√
HELLO flood	√	√	√
DoS	×	×	√

To communicate with members, the cluster head utilizes the last nonce as the seed of cluster key which is shared with all the sensors (including the CH) as shown in Figure 6. The cluster also can be used to rekey during the next round cluster, since the rekey process is with the redistribution of nonces. Comparing with RPKH and LDK [2, 3], the HKMS has no special requirements about the nodes, which makes it more feasibly. Also the HKMS utilizes the process of cluster formation to generate the key system without overhead, which reduces more energy consumption than previous works.

Figure 6

The cluster key in the HKMS.

Furthermore, the key system forms during the cluster formation, which almost does not consume any energy overhead.

Furthermore, as described above, if a node can receive beacon message in the jth hop range, meanwhile, it also can receive beacon message transmitted at kth hop range, where $j<k\le \text{TTL}$ . And then, the probability can be given based on the binomial distribution as follows:

$$\begin{array}{l}{p}_j^{\text{TTL}}=\left(\begin{array}{l}\text{TTL}\\ j\end{array}\right){\left(\frac{\text{TTL}-j+\mathrm{1}}{\text{TTL}}\right)}^{\text{TTL}-j+\mathrm{1}}\\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{0.17em}\times {\left(\mathrm{1}-\frac{\text{TTL}-j+\mathrm{1}}{\text{TTL}}\right)}^{j-\mathrm{1}}.\end{array}$$

(5)

According to (5), with the increase of TTL, the probability also increases, that is, the common keys between two nodes are increased, which enhances the connectivity. The increase of TTL also can shrink the size of each sub-region, which decreases the number of nodes who use the same communicating key and then localizes the impact of attacks. Moreover, the pair of nodes who do not have enough common keys can communicate with each other via a key path in HKMS. It also can improve the indirect network connectivity and then improve the whole network connectivity.

4.2. Simulation

In this section, we evaluate the performance of HKMS implemented in Visual C++ and MATLAB. The network scenario that we consider in simulation contains 100 nodes. According to the requirement of the HKMS, we designed a wireless sensor network simulation incorporating ECDG, essentially a multihop hierarchical sensor network [17]. The parameters for the simulations are listed in Table 4.

Table 4

Simulation parameters.

Parameter	Value
Area size	100 * 100
Quantity of sensor	100
BS position	(50, 250)
Initial energy	2 J
Cluster radius	40 m
Packet size	500 Bytes
$E_{\text{elec}}$	50 nJ/bit
${\epsilon }_{fs}$	10 pJ/bit/m2
${\epsilon }_{\text{amp}}$	0.0013 pJ/bit/m4
$E_{DA}$	5 nJ/bit/signal
$d_0$	86.2 m

In Table 4, the $E_{\text{elec}}$ is for running the transmitter or receiver circuitry; the ${\epsilon }_{\text{amp}}$ is for the transmit amplifier.

Firstly, we compare the performance of HKMS with that of LDK in energy consumption. Figure 7 shows the comparison LDK versus HKMS in energy consumption for key framework. From Figure 7, we can see that the number of messages for key formation increased with the increase of number of hops (energy levels in LDK). For LDK, the curve looks smooth for the anchor node which has more ability to enhance the energy level to form clusters and keys. However, LDK needs transfering more messages to generate the keys. Meanwhile, with the increase of hops of HKMS, it needs more messages to be forwarded from far nodes to generate keys. Since the key things are included in the packets of ACK, the HKMS needs less message transmission. As shown in Figure 7, the HKMS uses 50% energy of LDK to form the key framework. However, due to the noise and attenuation, more hops will increase energy consumption when the hops are more than 5.

Figure 7

The comparison in energy consumption for key framework with different hop ranges (energy levels).

Under the same simulation environment, Figure 8 demonstrates the comparison of the connectivity of HKMS and LDK. And we can observe that more hops (energy levels) will reduce connectivity. Since the HKMS happens in one cluster, which makes it possible to communicate with each other. However, with the hop count increase, the coverage becomes bigger, which makes it difficult to forward packets. When the hops are more than 3, the QoS almost is less than 80%. For LDK, it also faces the same problem. The sensors in the radio of anchor may be not the number of the cluster. When the energy level increases, the uncertainty also increases, which reduces the connectivity.

Figure 8

Comparing the performance of HKMS with that of LDK on energy consumption versus network connectivity.

Figure 9 shows the excepted number of keys for each member node with different TTL, which indicates that we can adjust the value of TTL to adapt to the network with the different density. Compared with LDK, HKMS has more ability to be employed for different WSNs, even in a network, there can be different size clusters because of the different TTL. In our solution, we can adjust the TTL value to average the cluster size. Figure 9 shows that the TTL value will change the density of cluster head number in the network. Here, given the TTLs are 3, 4, 5 respectively, the cluster head will be about 10%, 20%, and 30% of all nodes, respectively. From Figure 9, we can see that with the increase of TTL, the number of common keys also increases. As shown in Figure 9, when TTL is 5, the number of CHs is about 20%.

Figure 9

Excepted number of keys for each RN.

5. Conclusion and Future Work

In this paper, we propose a hierarchical key management scheme (HKMS) to enhance network security and survivability. Unlike previous works, we employ the hierarchical architecture but not fixed-node network. In contrast to other clustered architectural security solutions, the salient advantage of this work is that we addressed challenging security issues by localizing key things. We generate new keys in different hop ranges in a cluster. Also we present a rekey mechanism in the cluster head selection with low energy consumption. Meanwhile, HKMS can adjust the TTL to control the cluster size and the connectivity of nodes in the common keys. The simulations and security analysis show that our solution cannot only reduce the energy consumption effectively but also enhance the security level. In the future, we will focus on how to enhance security in mobile and scalable WSNs.