Integrate the hierarchical cluster elliptic curve key agreement with multiple secure data transfer modes into wireless sensor networks

Abstract

Since sensor nodes in wireless sensor networks or Internet of things have limited resources, achieving secure data transmissions among nodes is a challenge. Hence, efficient key management schemes with lightweight ciphers are essential. Many asymmetric keys or public key mechanisms have been developed. However, they are unsuitable for secure group communications in wireless sensor networks, because sensor nodes are usually devoid of sufficient memory, CPU and bandwidth to deal with complex operations. In addition, only a few group key agreements are integrated into secure data transmissions. Therefore, a key agreement using the hierarchy-based cluster elliptic curve key agreement named HCECKA is proposed in this study to deal with secure data transmissions in wireless sensor networks. The presented security mechanism relies on elliptic curves instead of logarithmic curves, and utilises a lesser key length to accomplish similar security classification than Diffie-Hellman and Rivest Shamir Adleman cryptosystems. Simultaneously, the proposed scheme provides a rapid, efficient and dynamic group key synchronisation technique in plenty of sensor nodes with no need for reorganising the whole system key if members join or leave wireless sensor networks.

KEYWORDS:

• Wireless sensor networks
• internet of things
• hierarchy-based cluster elliptic curve key agreement
• Diffie-Hellman
• Rivest Shamir Adleman

1. Introduction

So far, the key management in Wireless Sensor Networks (WSNs) are an important issue. The wireless communications operate in an open environment (Diffie et al., 1976), therefore WSNs are vulnerable (Nicolas & Xin, 2007, p. 3). Many related research papers have been presented. The proposals can be sorted out the listed below classifications: (1) pre-distribution mechanism with random keys, (2) single master key, (3) full pairwise key, and (4) group-based key.

The pre-distribution mechanism with random keys is based on the possibility of a common key shared between two sensors (Du et al., 2005). Every sensor stores a key ring, which casually selects x keys from the common key pool y. When two sensors have an identical key, then they have a secure path. The bigger key ring size improves the probability of owning identical keys and linkages between two nodes, meanwhile improving the storage space required for every sensor node. However, the key ring size increases vulnerabilities on a communication path existed between uncompromised nodes. Moreover, several nodes possibly own a common key, making them unable to identify which node is connected with.

In the single master key system, each node owns the same master key. During data transmissions, this method adopts the master key to secure the transmitted message between sensor nodes, and is plain to perform with a few memory spaces. However, if an enemy steals anyone’s master key, the whole system discloses the secret.

Every two sensors, the full pairwise key method utilises a distinct pair key between them to secure the delivered message. Therefore, each sensor needs pre-assigning and storing n-1 keys. Thus, every sensor owns n(n-1)/2 keys (Dong & Peng, 2003). Namely, every node has to reserve a huge amount of keys for securing data transmissions. Moreover, when increasing or decreasing the amount of sensors, each sensor needs to update pairwise keys (Haowen et al., 2003). Even though this mechanism is flexible and secure, a compromised sensor only impacts on the secure connection between other sensors linking with it. Therefore, the unsecure sensor does not influence the secure connection between uncompromised sensors. However, the heavy memory and storage overload render it inappropriate for a WSN on a wide scale. Additionally, the node addition and deletion complicates the system re-keying.

The mechanism of the group-based key management allocates sensors into separate groups. Every sensor has the same intra-group key for securing transmissions with its nearby nodes (Donggang et al., 2005; Zhou  et al., 2005). The method of the group-based key management exceeds other methods regarding scalability, efficiency and storage overhead. Recently, several ID-based or certificateless authenticated group key agreements for dynamic groups are proposed. They investigate how to manage the intra-group key. However, the research results indicate that a dynamic topology is a complex issue to implement the intra-group key (Lin et al., 2016).

As we know, the mentioned methods concentrate on key managements in WSNs, and are short of the mechanism of secure data transmission, which should be combined with key management protocols. This study presents a HCECKA mechanism to perform quick and effective key synchronisation for hierarchy-based WSNs, in spite of nodes dynamically taking part in or leaving from WSNs. Additionally, to improve the WSNs security, this study integrates the proposed key agreement with transferring data. In other words, we would like to offer an elliptic curve key agreement based on hierarchy with several secure data transfer modes for WSNs.

The remaining sections of this document are structured as follows. Section 2 presents the key agreement of Elliptic Curve Diffie-Hellman (ECDH) and compares Rivest Shamir Adleman (RSA) with elliptic curve cryptography under similar security levels. In Section 3, this study details the proposed HCECKA protocols and operational procedures of HCECKA. Section 4 discusses the multiple modes of secure data transfer of HCECKA. Section 5 includes computing evaluations and depicts the security analyses. Afterwards, in Section 6, we discuss the state of this study, describe future avenues of research, and conclude this study.

2. ECDH, the key agreement of elliptic curve Diffie-Hellman

In general, the asymmetric key system is more secure than a symmetric key system. Therefore, Public Key Infrastructure (PKI) provides higher security level functions, but PKI consumes lots of computing resources. However, WSNs have insufficient computing resources. Thus, sensors could not properly execute security operations very well through the above methods. So far, many studies intended to enhance security for sensor nodes through ECDH security mechanisms. Nicolas et al. (2007) designed and implemented Elliptic Curve Cryptography (ECC) on a hardware architecture. Piotr et al. (2008) surveyed the limit value of ECC, and confirmed that implementation of the public key cryptography on WSNs was achievable. An et al. (2008) developed an executable software and a function library for ECC.

Elliptic Curve Diffie-Hellman (ECDH) is a native of the renowned Diffie-Hellman (DH). The main difference is that ECDH employs the elliptic curve cryptography to create a common secret key known as a session key, which is responsible for secure transmitted data in open environments between two parties. Subsequently, they adopt the session key to cipher or decipher succeeding transmissions through a symmetric key mechanism. However, ECDH uses only 160-bit keys to achieve the same level of security as the DH secret sharing system. But, the raw DH agreement reaches an appropriate security level at least needing a 1024-bit key length, and hence consumes more memory capabilities and computing resources to execute exponential operations. Regrettably, sensors only have limited resources and a few computing power to deal with extra overheads. This study compares the key length of ECC with RSA under the same security levels. Table 1 indicates that the ECC has a key size of less than 160 bits to reach secure levels, which is equivalent to 1024 bits RSA. Besides, in ECC operations, there are only use addition and multiplication and thus can reduce the operational complexity and increase the operational performance. On the contrary, RSA, DH and DSA all need exponential operations. That is why ECC outperforms RSA, DH and DSA algorithms. This study adopts ECC as the cryptosystem is certainly workable for WSNs without sufficient computing sources. Consequently, ECDH is well adequate for WSNs.

Table 1. Under the same security level, different needed length (bits) of key on ECC and RSA.

Required time to break key	Security level	Length of Symmetric key	Required length of RSA/DH/DSA key	Required length of ECC key	Length ratio of ECC/RSA key
10^12	2^80	80	1024	160	1/6
10^24	2^112	112	2048	224	1/9
10^28	2^128	128	3072	256	1/12
10^47	2^192	192	7680	384	1/20
10^66	2^256	256	15360	512	1/30

Figure 1 represents the sensor A which wishes to connect with the sensor B using a session key within ECDH. Initially, the well-known parameters must first be set, including an elliptic curve y² = x³+ax + b, coefficients a and b, and a generator P with prime and base point in Diffie-Hellman. Moreover, each node owns a proper key pair to perform elliptic curve cryptography, comprising a randomly selected integer as ECC private key K and a well-known C (where C = KP) as the public key. Then the sensor A’s key pair represents (KR, C_R), and the sensor B’s key pair represents (K_V, C_V). Every node has each other’s public key. Subsequently, the node A figures out C_R = K_RP, and the node B figures out C_V=K_VP. Then the node A delivers C_R to the node B, and the node B delivers C_V to the node A. After receiving, each node computes the common session key S = K_RC_V = K_RK_VP = K_VK_RP = K_VC_R. This agreement is secure since two nodes disclose nothing besides public keys, and there is no one who knows the other’s private key unless the Discrete Logarithm Problem (An & Peng, 2008) of Diffie-Hellman can be worked out. Additionally, we assume that there is a secure CA (Certification Authority) server on this system. CA is a trusted digital signature server, and provides both nodes with a digital signature to sign the sent message before transmitting them. Therefore, both nodes ensure each other’s identity, and prevent attacking from malicious nodes (Zhongyuan et al., 2014).

Figure 1. The key agreement of ECDH.

3. The proposed key agreement using the hierarchy-based cluster elliptic curve, HCECKA

This section presents our proposed key agreement using a hierarchy-based cluster elliptic curve. Considering numerous sensor nodes, clustering forms a resilient and scalable architecture in which the entire WSNs are separated into many clusters with gateway sensors managing inter-cluster communications. The proposed hierarchy-based cluster key agreement (HCECKA) is inspired by cluster architecture.

We assume that HCECKA splits the whole sensor network into several groups named clusters through an appropriate cluster algorithm. Besides, each cluster has a cluster head named base station, and the whole network only has a root base station with sufficient computing power, huge memory and constant power. Generally, the base station and root base station comprise a powerful computer and differ from sensor nodes, and they never collapse. For simplicity, this study assumes that the base stations and the root base station provide constant power and are secure. At the same time, the base stations are elected and deployed before arranging the sensor nodes according to secure operations. Simultaneously, the base stations can straightly reach to each sensor node of the intra-cluster, and periodically broadcasts a hello message that includes the cluster identity and the member information to each node of the intra-cluster for determining other node geographic coordinates.

The proposed above architecture quickly synchronises the inner cluster key of plenty of members, intelligently executes key exchange among cluster heads, and ensures secure data transmissions. Our proposed hierarchy-based cluster infrastructure consists of three entities and is scalable for group key managements as below.

Member node (M_xi): a regular sensor node i acquires authentication from a base station (BS_x), and joins the cluster x and protects data transmissions using the obtained descendent cluster key. RBS denotes the controller of the entire system cluster key and is also known as the root base station, and BS is responsible for the controller of the descendent cluster key. Prior to whole sensor nodes being arranged, this study deployed RBS and BS in advance. The detailed HCECKA hierarchical model is illustrated in Figure 2.

Figure 2. The proposed hierarchy-based cluster ECC model.

Base station (BS): it is responsible for the controller of the descendent cluster key in a cluster, managing the descendent cluster operation for a cluster. When a cluster achieves the key synchronisation. In this cluster, every node obtains the same descendent cluster key for future secure data transmissions.

Root base station (RBS): RBS is in charge of controlling the system cluster key, managing operations for the whole WSNs. When the entire system achieves the key synchronisation, every node obtains the same system cluster key for future security communications. RBS is the ancestor of base stations, figures out the system cluster key of the whole system, also assigns a descendent cluster key to every base station.

Necessary settings reduce the quantity of key agreement operations executed in every cluster. Especially, in a quite huge cluster, the computing overload increases if members of a cluster grow. Our proposed mechanism comprises the following stages. Figure 3 depicts the detailed operations in each stage.

Figure 3. The processing stages of HCECKA.

Stage 1. The controller of a descendent cluster key is the base station BS_x, which is deployed for the members M_xi in the cluster, where i represents the quantity of sensors in this cluster, i and n ∈integer, and x represents the identity of the cluster, 1 ≦ x ≦ n.

Stage 2. In this system, the most secure and powerful base station is selected as RBS, responsible for key control for the whole network. The other base stations BS_x, 1≦x≦n, work with RBS to figure out the system cluster key for WSNs.

Stage 3. Every BS_x (BS₁, BS₂, BS₃, … , BS_n-1) executes the agreement of the descendent cluster key as depicted in Figure 4 (such as BS₁) and determines a descendent cluster key KC_xP, where x ∈ [1, n-1] through the ECDH agreement. This study presents the specific descendent cluster key agreement as the following steps.

Step 1. Initially, every node M_1i in the BS₁ cluster creates a private key KM_1i and figures out the public key KM_1iP, where P is a generator in ECDH. M_1i subsequently broadcasts KM_1iP to the rest of member nodes in cluster 1. After receiving KM_1iP, M_1x (x≠i) calculates KM_1xP and multiplies KM_1xP with KM_1iP. Finally, every node obtains the common result KM₁₁P*KM₁₂P*K … M_1n-1P, as shown in Figure 4.

Step 2. After receiving KM₁₁P*KM₁₂P* … *KM_1n-1P, M₁₁ takes out its own factor KM₁₁P, and then unicasts KM₁₂P*KM₁₃P* … *KM_1n-1P to BS₁. Meanwhile, the reset of node M_1i, i ∈ [2, n-1] executes the same processes. Under a secure channel, the M_1i securely unicasts (Janies et al., 2007) the taken out result to BS₁. Figure 4 depicts the processes.

Step 3. After receiving KM₁₂P*KM₁₃P* … *KM_1n-1P from M₁₁, BS₁ computes its own key KM_1nP. Then BS₁ figures out KM₁₂P*KM₁₃P* … *KM_1n-1P*KM_1nP, and enciphers the message to securely unicast it back to M₁₁, as shown in Figure 4. Simultaneously, BS₁ executes the same processes to figure out the keys for M_1i, where i ∈ [2, n-1]. Then, BS₁ transmits the outcome to M_1i. After receiving, M₁₁ multiplies the transmitted key with its own KM₁₁P. Subsequently, M₁₁ acquires the descendent cluster key KM₁₁P*KM₁₂P* … *KM_1n-1P*KM_1nP. Likewise, every node finally obtains the same descendent cluster key KM₁₁P*KM₁₂P* … *KM_1n-1P*KM_1nP, and then we can simplify to represent the above descendent cluster key as the mathematical representation$\prod _{i=1}^{n}K{M}_{1i}\bullet P$, where (i = 1 to n), and the symbol $\mathrm{\Pi }$ denotes a multiplication of multiple elements, such as KM₁₁P multiplies KM₁₂P multiplies KM₁₃P, which can be represented as $\prod _{i=1}^{3}KM$_1iP. Briefly, in BS₁, the descendent cluster key $\prod _{i=1}^{n}K{M}_{1i}\bullet P$ is defined as KC₁P. Finally, every BS_x executes the similar process and obtains a descendent cluster key KC_xP, where x ∈ [1, n-1].

Figure 4. The descendent cluster key management of HCECHA.

Stage 4. Meanwhile, this entire network gathers every cluster head BS_x’s descendent cluster keys. Subsequently, each BS_x figures out KC₁PKC₂P … KC_xP by multiplying its own KC_xP with the received KC₁PKC₂P … KC_x-1P, and forwards its own descendent cluster key to the next BS_x+1, as shown in Figure 5. For instance, BS₄ receives the forwarding descendent key KC₁PKC₂PKC₃P from BS₃, then multiplies KC₁PKC₂PKC₃P with its descendent key KC₄P, and then delivers KC₁PKC₂PKC₃PKC₄P to the next BS₅. Consequently, the forwarding key from BS_n-2 is obtained, and BS_n-1 then can derive KC₁PKC₂PKC₃P … KC_n-2PKC_n-1P=$\prod _{i=1}^{n-1}K{C}_i\bullet P$, where (i=1 to n-1), and the symbol $\mathrm{\Pi }$ denotes a multiplication of multiple elements.

Figure 5. The system cluster key management of HCECKA.

Stage 5. Subsequently, as shown in Figure 5, BS_n-1 declare KC₁PKC₂PKC₃P … KC_n-1PKC_n-1P to all other cluster heads (BS₁, BS₂, BS₃, … , BS_n-2).

Stage 6. Every BS_i (i ∈ [1, n-1]) obtains the declared key $\prod _{i=1}^{n-1}K{C}_i\bullet P$, then takes out its own factor KC_iP, and sends the outcome to RBS. Figure 5 depicts the detailed process.

Stage 7. At the last stage, after receiving all descendent cluster keys from every BS_x, RBS subsequently multiplies its own KC_nP with every descendent cluster key, and enciphers the message to securely unicast $\prod _{i=1}^{n}K{C}_i\bullet P\{where,i\ne x,x\in [1,n-1]\}$ back to BS_x. Figure 5 depicts the detailed process. After receiving the unicasted key, BS_x multiplies the received key with its own descendent key KC_xP. Consequently, every cluster head obtains the same KP = $\sum _{i=1}^{n}K{C}_i\bullet P\{where,i\in [1,n]\}$ as the system cluster key for the entire network.

The above-mentioned stages introduce the complete synchronisation process to construct the system cluster key for the whole system. In a practical environment, the root cluster head could be replaced or may collapse down, also ordinary sensors or cluster heads may join or leave the network. This study only explores multiplication and addition operations, and thus the proposed scheme can rapidly achieve synchronisation of the system key.

3.1. The system cluster key synchronisation for clusters participating in or departing from networks

3.1.1. Mobile nodes participate in or leave a cluster

When a node M_1i participates in (or leaves) cluster 1, M_1i only needs to broadcast its public key KM_1iP to each node in the cluster once. Other nodes multiply (or remove) the received key with their own key KM_1xP (x≠i). Subsequently, each node repeats steps 2 and 3 in stage 3, and then the cluster obtains the new descendent cluster key KC₁P. Eventually, the system performs the stages 4–7, and obtains the system cluster key.

3.1.2. Cluster participation

A system must reconstruct the system cluster key for the entire network when a new cluster head BS (nominated during system deployment) joins a WSN. The key exchange processes are categorised into three cases as presented in detail below.

• (1) In the general case

The joining cluster head BS_x is between BS₁ and BS_n. Then the BS_x-1 system forwards KC₁PKC₂PKC₃P … KC_x-1P to BS_x, and BS_x generates a private key KC_x using ECC. Subsequently, BS_x multiplies KC_xP with KC₁PKC₂PKC₃P … KC_x-1P to obtain KC₁PKC₂PKC₃P … KC_x-1PKC_xP, and forwards the result to BS_x+1. Eventually, the system performs the stages 5–7 in section 3. The performance of recalculating the system cluster key depends on the joining position of a new cluster head.

• (2) In the worst case

The joining cluster head is BS₀ allocated at the leftmost position, the system has to completely perform the stages 4–7 in section 3.

(3) In the best case

The joining cluster head is BS_n allocated at the rightmost position. Achieving the system cluster key for the whole network, this system only performs several computations. The detailed procedures are as follows.

Phase 1

The last cluster head BS_n-1 forwards KC₁PKC₂PKC₃P … KC_n-1P to BS_n, and then BS_n generates a private key KC_n using ECC. Subsequently, BS_n multiplies KC_nP with KC₁PKC₂PKC₃P … KC_n-1P to obtain KC₁PKC₂PKC₃P … KC_n-1PKC_nP, and then unicasts the result to RBS.

Phase 2

Upon receiving KC₁PKC₂PKC₃P … KC_n-1PKC_nP, RBS generates a new ECC private key KC_n+1, and replaces its own old public key KC_nP with KC_n+1P. Subsequently, RBS calculates a new system cluster key value as below.

KC₁PKC₂PKC₃P … KC_n-1PKC_nPKC_n+1P=$\prod _{i=1}^{n}K{C}_i\bullet P\{where,i\ne x,x\in [1,n-1]\}$, and the symbol $\mathrm{\Pi }$ denotes a multiplication of multiple elements, such as KC₁P multiplies KC₂P multiplies KC₂P.

Phase 3

RBS extracts the key KC_xP of the target base station BS_x, and calculates the n descendent cluster keys for the other clusters as below, and securely unicasts it to BS_x. $\prod _{i=1}^{n}K{\text{C}}_i\{where,i\ne x,x\in [1,n]\}\bullet P$

Phase 4

Each base station BS_x receives the descendent cluster key from RBS, and multiplies the received key by its own key KC_xP. Thus, each BS_x can derive the new system cluster key K _n+1P.

The HCECKA rapidly and efficiently calculates the new system cluster key K_n+1P, and requires only a few operations to calculate n descendent cluster keys if a new cluster is added. Additionally, all former clusters recalculate the new system cluster key by K_n+1P with a single multiplication. Only an RBS needs to generate a new private key and perform n multiplications for n descendent cluster keys. RBS inevitably requires additional operational loads.

3.1.3. Cluster departure

The procedure in HCECKA for a cluster head departing from a network is similar to a cluster head joining a network. Let BS_x denote a cluster removed from the network. In the general case, assume that x ∈ [1, n-1] and x ≠ n. Thus, BS_x-1 forwards KC₁PKC₂PKC₃P … KC_x-1P to BS_x+1, and the subsequent key generation procedure is performed with BS_x+1 replacing BS_x. Subsequently, the system performs stages 4–7 in section 3, and obtains the system cluster key.

In the worst case, if the leftmost node BS₁ leaves the network, the system has to completely perform the stages 4–7 in section 3. However, each BS_x (x≠1) only needs to extract KC₁P from its previous KC₁PKC₂PKC₃P … KC_x-1PKC_xP, and thus can reduce operational time in stage 4.

In the best case, the leaving cluster head is BS_n-1 allocated at the rightmost position. RBS generates a new private key KC* replacing KC_n, and calculates a new system cluster key KP = KC₁PKC₂P … .KC_n-2PKC*P for the entire network. RBS then securely unicasts a new set of n-2 partial system cluster keys $\prod _{i=1}^{n-\text{2}}K{\text{C}}_i\{where,i\ne x\}\bullet P$ to the base station BS_x. Additionally, if RBS leaves the system, then BS_n-1 substitutes the role of RBS, and performs the system cluster key procedures. Consequently, the system generally regains the system cluster key in a few operations.

From the above presentation, we propose an elliptic curve key agreement based on a hierarchy cluster infrastructure to improve the efficiency of a group key synchronisation when nodes or clusters dynamically join or leave. Besides, we integrate the proposed key agreement into communications and then secure the data transmission. The detailed description is as follows.

4. The mechanism of secure data transmissions

This section introduces how to deal with secure data transmissions for inter-cluster and intra-cluster, and applies the descendent cluster key, system cluster key and ECDH session key on various scenarios to enhance secure data transmission efficiency.

This study adopts the descendent cluster key to protect and confirm the data security of intra-cluster, exploits the system cluster key performing security operations of inter-cluster, and utilises the ECDH session key to provide flexible modes of secure data transmissions for intra-cluster, inter-cluster and gateway. The detailed description is as follows.

4.1. Transmission mode of data security using the descendent or system cluster key

Considering the key synchronisation of the descendent cluster key or the system cluster key in WSNs, this proposed mode gives the best efficient secure data transmissions. Since, the whole network utilises the same key to secure data transmissions. This operational process is just like a single master key mechanism. We present the transmission mode of data security using the descendent or system cluster key for inter-cluster and intra-cluster as below.

4.1.1. Transmission mode of data security for intra-cluster

As shown in Figure 6, when a sink node (a data collector) named M₁₃ dynamically enters the cluster to collect information, the cluster head BS₁ first performs the descendent key operations to calculate the descendent key. Subsequently, in the same cluster, M₁₁, M₁₂ and BS₁ deliver their collected data to M₁₃. This operational mode utilises the same descendent cluster key to encipher and decipher the transmitted data, and performs operational processes of data security from M₁₁ sending data to M₁₃ as below. $\begin{array}{l}{M}_{11}\to M_{12}\\ E{K_{KC}}_{1\text{P}}[M_{11}|D{M}_{11}|\text{HMAC}(D{M}_{11})]\end{array}$Sensor node M₁₁ exploits the descendent cluster key KC₁P to encipher the path of routing nodes, the sensed message DM₁₁ of node M₁₁ and HMAC (DM₁₁). Then, this study inputs the sensed message DM₁₁ and the KC₁P descendent cluster key, and figures out the Hash Message Authenticated Code HMAC (DM₁₁). After that, M₁₁ puts the above data into the relevant fields, and subsequently sends the encoded message to the following M₁₂.

Figure 6. Secure intra-cluster data transmission mode.

When the transmitted message is received, M₁₂ enciphers them utilising the descendent cluster key KC₁P. After that, M₁₂ inspects the integrity of HMAC (DM₁₁) by KC₁P, accumulates sensed data DM₁₂ with DM₁₁, appends self M₁₂ identity into the route, generates HMAC (DM₁₂||DM₁₁), and enciphers them using KC₁P. Subsequently, M₁₂ sends the enciphered result to the next BS₁. $\begin{array}{rl}& M_{12}\to B{S}_1\\ & E{K_{KC}}_{1\text{P}}[M_{12}{M}_{11}|(D{M}_{12}||D{M}_{11})|\text{HMAC}(D{M}_{12}||D{M}_{11})]\end{array}$When BS₁ accepts the enciphered message, and then deciphers the received message utilising KC₁P. Subsequently, BS₁ executes the similar processes as the above procedures. Eventually, BS₁ delivers the enciphered result to the end sensor M₁₃. $\begin{array}{rl}& B{S}_1\to M_{13}\\ & E{K_{KC}}_{1\text{P}}[B{S}_1{M}_{12}{M}_{11}|(DB{S}_1||D{M}_{12}||D{M}_{11})|\text{HMAC}(DB{S}_1||D{M}_{12}||D{M}_{11})]\end{array}$As M₁₃ receives the enciphered message, M₁₃ deciphers the received message and inspects the HMAC (DBS₁||DM₁₂||DM₁₁) integrity by KC₁P to identify if these original messages have been modified.

The proposed scheme for secure data transmissions of intra-cluster is straightforward and clear. The early single master key mechanism is a particular instance in our proposed cluster architecture.

4.1.2. Transmission mode of data security for inter-cluster

When two nodes in different clusters would like to communicate with each other, this study secures the data transmissions utilising the system cluster key. During transmission, nodes employ the system cluster key KP to encipher and decipher messages, exploit KP to generate the HMAC code through hash functions, and inspect the transmitted message integrity by KP. The whole processes are similar to the transmission mode of data security for intra-cluster.

4.1.3. Urgent transmission mode of data security

If sensor nodes are deployed in critical environments for detecting urgent accidents, this mode provides a rapid and secure data transmission method. Figure 6 depicts that M₁₁ detects an urgent message and needs to notify RBS immediately. Since RBS serves as the urgent operation centre, in this mode, M₁₁ adopts the system cluster key KP to encipher the urgent message, and then dispatches the enciphered result to the next sensor along the routing path toward RBS. Consequently, RBS obtains the enciphered message and deciphers them utilising KP to enhance the efficiency of data transmissions. The detailed transmission procedure from M₁₁ to RBS is as follows.

First, M₁₁ exploits the system key KP to encipher its identity and an urgent message EM₁₁ sensed from M₁₁, and then attaches the routing path and HMAC on the tail of the enciphered message. Subsequently, M₁₁ sends the enciphered message to the following M₁₂. $\begin{array}{rl}& (\text{a})M_{11}\to M_{12}\\ & E{K}_{KP}[M_{11}|E{M}_{11}],M_{11},\text{HMA}{\text{C}}_{KP}(E{K}_{KP}[M_{11}|E{M}_{11}],M_{11})\end{array}$As M₁₂ receives the transmitted data, M₁₂ only needs to inspect the integrity of the attached HMAC by KP instead of deciphering the message. Subsequently, M₁₂ appends its own ID into the route, meanwhile and calculates a new HMAC code containing the enciphered urgent data and the updated routing path. Then, M₁₂ delivers the new enciphered message to its cluster head BS₁. $\begin{array}{rl}& (\text{b})M_{12}\to B{S}_1\\ & E{K}_{KP}[M_{11}|E{M}_{11}],M_{12}{M}_{11},\text{HMA}{\text{C}}_{KP}(E{K}_{KP}[M_{11}|E{M}_{11}],M_{12}{M}_{11})\end{array}$After receiving the transmitted message, BS₁ executes the similar processes as the above procedures, and transmits the enciphered message to its cluster head RBS. $\begin{array}{rl}& (\text{c})B{S}_1\to RBS\\ & E{K}_{KP}[M_{11}|E{M}_{11}],B{S}_1{M}_{12}{M}_{11},\text{HMA}{\text{C}}_{KP}(E{K}_{KP}[M_{11}|E{M}_{11}],B{S}_1{M}_{12}{M}_{11})\end{array}$After receiving the message, RBS calculates HMAC for (EK_KP[M₁₁|EM₁₁],BS₁M₁₂M₁₁), and compares the result with the received HMAC_KP(EK_KP[M₁₁|EM₁₁], BS₁M₁₂M₁₁). If both HMACs are equal, RBS adopts the system cluster key KP to decipher the enciphered message, and obtains the emergency message EM₁₁.

4.2. Transmission mode of data security using the ECDH session key

As known to all, ECDH stems from the key agreement protocol of Diffie-Hellman. The variation is that ECDH utilises elliptic curve cryptography to create a session key for securing the communication between two parties over unshielded channels. Here, for simplicity, we assume that a secure and trusted server named CA takes charge of certificate authority in this system. The CA server issues digital certificates for both parties to ensure the identity of each other for communications. As a result, this system prevents identity theft and the attack of the man-in-the-middle. Subsequently, we perform secure data transmissions between two nodes directly connected utilising the session key from ECDH.

4.2.1. Transmission mode of data security for intra-cluster

Within an intra-cluster, sensor nodes employ the common ECDH session key to protect and securely transmit data. Our designed scheme is both straightforward and efficient, and offers secure data transmissions of peer-to-peer. Figure 7 indicates that M₁₁ is located in the left cluster and would like to forward the sensed data to M₁₄. The following is the procedure of secure data transmissions. $\begin{array}{rl}& (\text{a})M_{11}\to M_{12}\\ & E{K_{SK}}_{1,12}[M_{11}|D{M}_{11}|\text{HMAC}(D{M}_{11})]\end{array}$Initially, the sensor node M₁₁ adds its sensed message DM₁₁ and its own ID to the routing path. Subsequently, we use the descendent cluster key KC₁P (not session key SK_1,12 of two nodes, where ₁ denotes the cluster ID and ₁₂ denotes node 1 and node 2) for later secure verification of inter-cluster. Then, M₁₁ takes DM₁₁ as an input and executes a hash function to generate HMAC (DM₁₁). Eventually, M₁₁ puts the above data into the relevant fields, uses session key SK_1,12 to encipher them, and then forwards the enciphered result to the next M₁₂.

Figure 7. Secure inter-cluster data transmission mode.

Upon receipt of the transmitted data, M₁₂ utilises the SK_1,12 session key to decipher it and inspects the HMAC(DM₁₁) integrity through the descendent cluster key KC₁P. After that, M₁₂ aggregates sensed data DM₁₂ with DM₁₁ as (DM₁₂||DM₁₁), calculates HMAC (DM₁₂||DM₁₁) using KC₁P, and puts its own ID in the routing path. Finally, M₁₂ uses the SK_1,2BS1 session key to encipher the above fields, thereafter and sends the enciphered result to the subsequent BS₁ base station. $\begin{array}{rl}& (\text{b})M_{12}\to B{S}_1\\ & E{K_{SK}}_{1,2BS1}[(M_{12}{M}_{11})|(D{M}_{12}||D{M}_{11})|\text{HMAC}(D{M}_{12}||D{M}_{11})]\end{array}$Upon receipt of the transmitted data, BS₁ utilises the SK_1,2BS1 session key to decipher it. Then, BS₁ checks the integrity of HMAC, combines sensed data DBS₁ with DM₁₂||DM₁₁, generates HMAC(DBS₁||DM₁₂||DM₁₁), and puts its own ID into the routing path. Eventually, BS₁ enciphers these fields using session key SK_1,BS13, thereafter and sends the enciphered result to the subsequent M₁₃. This system duplicates the above procedures until the transmitted data arrives at the target M₁₄. $\begin{array}{rl}& (\text{c})M_{13}\to M_{14}\\ & E{K_{SK}}_{1,34}[(M_{13}B{S}_1{M}_{12}{M}_{11})|(D{M}_{13}||DB{S}_1||D{M}_{12}||D{M}_{11})|\text{HMAC}(D{M}_{13}||DB{S}_1||D{M}_{12}||D{M}_{11})]\end{array}$Upon receipt of the transmitted data, M₁₄ utilises the SK_1,34 session key to decipher the incoming data, employs descendent cluster key KC₁P to examine the integrity of the aggregated data HMAC (DM₁₃||BS₁||DM₁₂||DM₁₁), and then identifies if the original data were modified during communication. As such, this system can accomplish secure data transmissions for Intra-cluster.

4.2.2. Transmission mode of data security for inter-cluster

Figure 7 depicts when M₁₁ would like to send a message to M₂₄. Because two nodes are situated in separate clusters, the procedures for securely transmitting data are similar to those described above steps in session 4.2 (1) (a)-(b) until the delivered message reaches BS₁. Subsequently, BS₁ executes a hash function for the accumulated message DBS₁||DM₁₂||DM₁₁, and utilises the system cluster key KP to product HMAC (DBS₁||DM₁₂||DM₁₁) for the later inspecting the HMAC integrity. Finally, BS₁ utilises the session key SK_BS1,BS2 to decipher the received message, and performs the following steps (c)-(e) to secure data transmission until the transmitted message arrives in BS₂, which is located in a different cluster. $\begin{array}{rl}& (\text{c})B{S}_1\to B{S}_2\\ & E{K_{SKBS}}_{1,BS2}[(B{S}_1{M}_{12}{M}_{11})|(DB{S}_1||D{M}_{12}||D{M}_{11})|\text{HMAC}(DB{S}_1||D{M}_{12}||D{M}_{11})]\end{array}$After receiving the enciphered messages, BS₂ utilises the SK_BS1,BS2 session key to decipher them, and inspects the HMAC integrity through the system cluster key KP. After that, BS₂ accumulates the sensed message DBS₂ with DBS₁||DM₁₂||DM₁₁, utilises the descendent cluster key KC₂P to compute HMAC (DBS₂||DBS₁||DM₁₂||DM₁₁) for the internal cluster security, appends self-identification to the routing path, puts them into the relevant fields, and enciphers all fields using the session key SK_2,BS23. Eventually, BS₂ sends the enciphered result to the next M₂₃. $\begin{array}{rl}& (\text{d})B{S}_2\to M_{23}\\ & E{K}_{2,BS23}[(B{S}_{2}B{S}_1{M}_{12}{M}_{11})|(DB{S}_2||DB{S}_1||D{M}_{12}||D{M}_{11})|\text{HMAC}(DB{S}_2||DB{S}_1||D{M}_{12}||D{M}_{11})]\end{array}$After receiving the enciphered messages, M₂₃ utilises the SK_2,BS23 session key to decipher them, and adopts KC₂P to inspect the HMAC(DBS₂||DBS₁||DM₁₂||DM₁₁) integrity. Subsequently, M₂₃ accumulates the sensed message DM₂₃ with DBS₂||DBS₁||DM₁₂||DM₁₁, uses the descendent cluster key KC₂P to generate HMAC (DM₂₃||DBS₂||DBS₁||DM₁₂||DM₁₁), puts its own ID M₂₃ into the routing path, enciphers all fields using the session key SK_2,34, and subsequently forwards the enciphered result to the following M₂₄. $\begin{array}{rl}& (\text{e})M_{23}\to M_{24}\\ & E{K_{SK}}_{2,34}[(M_{23}B{S}_{2}B{S}_1{M}_{12}{M}_{11})|(D{M}_{23}||DB{S}_2||DB{S}_1||D{M}_{12}||D{M}_{11})|\\ & \text{HMAC}(D{M}_{23}||DB{S}_2||DB{S}_1||D{M}_{12}||D{M}_{11})]\end{array}$After receiving the enciphered messages, the target node M₂₄ utilises the SK_2,34 session key for deciphering the enciphered message and inspecting the HMAC (DM₂₃||DBS₂||DBS₁||DM₁₂||DM₁₁) integrity by the descendent cluster key KC₂P to verify if the data has been modified during data transmissions.

In this secure inter-cluster data transmission, the transmitted message goes through various clusters, and therefore BS₁ and BS₂ take charge of the secure data transmission for inter-cluster, and inspect the integrity of the HMAC during the passage of the various clusters. Thus, BS₁ and BS₂ can utilise the system cluster key KP to compute HMAC and inspect the received HMAC integrity.

4.2.3. Transmission mode of data security via gateway nodes

In this mode, Figure 7 depicts if two different clusters have common gateway nodes, the source node can pass through gateway nodes to reach the target node. Under this situation, the secure transmission procedure is similar to the secure data transmission mode of inter-cluster. When the transmitted message passes through the gateway (M₁₄→M₂₁), this mode utilises the system cluster key KP to generate and inspect HMAC, and employs the session key SK_1,2 of gateway nodes to en/deciphered the transmitted messages. Since the other nodes do not have the session key SK_1,2 of gateway nodes, then cannot decipher the enciphered message. Eventually, the target node receives the transmitted message and inspects the HMAC integrity by the system cluster key KP, and identifies if the original data has been modified during transmissions.

4.2.4. Urgent transmission mode of data security

Between clusters, delivering urgent data enciphered by the system key is efficient, but probably not secure, since each member equipped with the system key can reveal the urgent data. Therefore, this study exploits session keys to achieve advanced protection. Suppose that M₁₁ delivers urgent data to RBS using session keys belonging to participants in the routing path. The following is the detailed procedure. $\begin{array}{rl}& (\text{a})M_{11}\to M_{12}\\ & E{K_{SK}}_{1,12}[M_{11}|E{M}_{11}|\text{HMA}{\text{C}}_{KP}(E{M}_{11})]\end{array}$Sensor node M₁₁ adds emergency message EM₁₁, adopts the system cluster key KP for later confirmation and EM₁₁ as inputs to execute hash functions and generates HMAC_KP (EM₁₁), and then places its own ID to the routing path. After that, M₁₁ puts those data into the relevant fields, subsequently utilises the session key SK_1,12 to encipher all fields, and then transmits the enciphered result to the next M₁₂. $\begin{array}{rl}& (\text{b})M_{12}\to B{S}_1\\ & E{K_{SK}}_{1,2BS1}[(M_{12}{M}_{11})|E{M}_{11}|\text{HMA}{\text{C}}_{KP}(E{M}_{11})]\end{array}$Once M₁₂ obtains the transmitted message, it utilises the SK_1,12 session key to decipher the received message, and then adopts the system cluster key KP to inspect the integrity of the received HMAC. After that, M₁₂ calculates HMAC_KP (EM₁₁) and appends its own ID to the router. Eventually, M₁₂ employs SK_1,2BS1 for encryption of the whole message, subsequently and forwards the enciphered result to BS₁. $\begin{array}{rl}& (\text{c})B{S}_1\to RBS\\ & E{K_{SK}}_{1,BS1RBS}[(B{S}_1{M}_{12}{M}_{11})|E{M}_{11}|\text{HMA}{\text{C}}_{KP}(E{M}_{11})]\end{array}$When BS₁ receives the transmitted message, BS₁ utilises the session key SK_1,2BS1 to decipher them, and verifies the HMAC integrity. Subsequently, BS₁ puts its own ID to the routing path, and generates HMAC of the emergency message. Eventually, BS₁ enciphers all fields using the session key SK_SK1,BS1RBS, and then forwards the result to RBS. When RBS receives the enciphered message, subsequently deciphers them and inspects the integrity of the transmitted emergency message EM₁₁ sent from M₁₁.

5. Secure data transmission analyses and computing evaluations

This research investigates the effectiveness evaluation of the above models of secure data transmissions, and performs several security analyses. Additionally, we also demonstrate that the proposed methods indeed decrease key resynchronisation time when nodes are leaving or joining, enhance the performance of secure data transmissions, and decrease key resynchronisation time when nodes are leaving or joining. Additionally, we also provides the decentralised key management with a scalable and flexible infrastructure. The detailed security analysis is as below.

• (1) Authentication and confidentiality

During the transmission, this study secures transmitted messages using a session key. Upon receipt of the enciphered message, it can only be deciphered by the owner of the same session key. However, since the other nodes have different session keys, they cannot decipher the enciphered message.

• (2) Failure tolerance of the transmission path

In the proposed mechanism, there are multiple routing paths that exist among sensors. If the original selected path is interrupted, the gateway mode will be the alternative route to execute information security transmissions, and therefore the entire system reverts to regularity. In addition, when transmitting data securely between peers, this mechanism makes it possible to carry out fast and efficient fault-tolerant routing protocols without a single point of failure.

• (3) Correctness and integrity of data transmitted

While transmitting, the present study examines the correctness and integrity of the transmission of the message by HMAC. Where two nodes are situated in separate clusters, the sender utilises the descendent or system cluster key to generate HMAC for later verification. As a result, the system prevents malware nodes from utilising the session keys to pass HMAC inspection. After reception of the enciphered message, the recipient deciphers the enciphered message, subsequently adopts the related cluster key and plain messages as inputs to compute and inspects the HMAC integrity. As we know, the hash function H is a non-reversible operation to generate HMAC. Where i ≠ j is H(i) ≠ H(j). A random number i and j cannot be taken into consideration in such a way that H(i) = H(j). Consequently, while transmitting, there is a sensor node which changes the delivered message, and the recipient immediately inspects the unequal HMAC and determines the altered data.

• (4) Operations of data encryption and decryption

As we know, PKI and asymmetric key schemes need lots of computing power. However, sensor nodes have no sufficient computing resources, and thus asymmetric key infrastructures are unsuitable for WSNs. In the proposed design, every sensor retains only one system group key, one descending group key and one session key for securing the delivered message, subsequently and adopts like MD5, SHA-3 or RIPEMD-160 hash functions to inspect the delivered message correctness and integrity. Additionally, session key operations and hash functions only consume few resources. As a result, the proposed schemes are plain, straightforward and quite appropriate for WSNs.

Moreover, this study simulates performance evaluation and analyses of various public key cryptosystems, and compares key operating costs and key communication costs. Here we assume that RBS and BS are absolutely secure and have constant power. The study performs a few ECDH processes on the sensor node, which utilises the prime field to establish an ECDH session key, subsequently and figures out a point multiplication on a SECP-160 curve.

Regarding the simulation scenarios of intra-cluster and inter-cluster infrastructures, this study evaluates the data transmission time and the key synchronisation time, and adopts the descendent cluster key and the system cluster key to achieve secure data transmissions of intra-cluster and inter-cluster. Moreover, we employ an ECDH session key for securely transmitting messages, which is similar to estimate the efficiency of gateway, inter-clusters and intra-clusters modes. For simplicity, this study utilises <x, y> pair to denote the length of the key of a security level, where x corresponds to the length of one HCECKA private key, and y corresponds to the length of one Diffie-Hellman (DH) private key. The mechanism of the DH key agreement is for both parties to find a shared private key to securely exchange and transmit the message in non-secure connections. Additionally, both the receiver and the sender own key pairs in the DH key protocol. Two parties combine one's private key with the other's public key to identify the shared common session key (Zhong et al., 2014). GDH extends the renowned two-party DH key protocol to n parties. The several versions of GDH, including GDH.2 and GDH.3, are considered to be particular group protocols. GDH places all members of a group into a binary tree or a logic ring. When increasing the quantity of group members, the quantity of communication rounds and the computing cost seriously influence the efficiency of the GDH key agreement.

To evaluate the efficiency and scalability of our proposed schemes in WSNs, this scenario adopts different cluster member nodes (1, 2, 4, and 8) to simulate various numbers of sensor nodes in WSNs (1, 4, 8, 16, 32, and 64), and compares various scenarios of the system cluster key convergence time for 1–64 members in WSNs. When the number of a cluster member node is 1, which means that each node is similar to a cluster head (BS); this is a special case. Simulation results in Figure 8 indicate that when member nodes of a cluster increase, the system cluster key synchronisation time for the cluster scheme outperforms that of the non-cluster schemes. The non-cluster scheme performs more operations in stages 1–7 to achieve key synchronisation.

Figure 8. A cluster with different members, the convergence time for computing the descendent cluster key.

In the same cluster, the simulated network of nodes (5, 10, 15, 20, 25, and 30) is used to build the descendent cluster key, and determines the synchronisation time. This study compares our proposed HCECKA with DH and GDH schemes on different key lengths. Simulation results indicate that GDH and DH must execute exponent operations. However, HCECKA needs only multiplication operations. Consequently, GDH requires significantly more computing time than HCECKA. Figure 9 illustrates the results of the simulation and shows the synchronisation time for constructing the descendant cluster key on HCECKA is less than GDH for <224, 2048 bits> and <160, 1024 bits>. Therefore, HCECKA exceeds DH in computing the descendent key on the synchronisation time.

Figure 9. The timing of the derivation of the descendent cluster key for DH, GDH and HCECKA.

In Figure 10, this study evaluates the time to synchronise the system cluster key construction for HCECKA and GDH. Initially, this study divides a network into two clusters containing member nodes (1, 2, 3, 4, 5, and 6). For two clusters, simulation results reveal that GDH takes more time than HCECKA to converge the system cluster key. The main reason is that every cluster head (BS) is the controller of the descendent cluster key. Consequently, in HCECKA, the entire system can rapidly synchronise the system cluster key, and only need both cluster heads to interchange their descendent cluster keys. However, in this GDH mechanism, each pair of nodes must exchange their keys, and therefore GDH takes more time than HCECKA.

Figure 10. Between two clusters, the synchronisation time of generating the system cluster key.

Figures 11 and 12 demonstrate that when a node is added or removed, the system must resynchronise the system cluster key. The simulation result shows that HCECKA spends less time than GDH to resynchronise the new system cluster key. The main factor is because multiplications spend significantly less time than exponential operations. Moreover, in the HCECKA scheme, only a cluster with nodes leaving must recalculate the descendent cluster key, and the main loading focuses on three steps in stage 3 of section 3 for the purpose of recalculating the descendent cluster key. Subsequently, the system can determine the system cluster key within a few operations. However, in the non-cluster scheme for GDH, each node must perform all stages; thus the system requires many operations to calculate the system cluster key.

Figure 11. When one node participates in the system, the time to resynchronise the generation of the system cluster key.

Figure 12. When a node departs from the system, the time to resynchronise the system cluster key.

In different key management schemes, Figure 13 demonstrates the elapsed time of secure data transmission for gateway, inter-cluster, intra-cluster modes. Initially, HCECKA takes more time than ECDH to derive the system cluster key. After synchronisation, each node performs secure data transmission using the system cluster key. However, the ECDH scheme must perform session key operations during each secure data transmission phase. Comparison results demonstrate that the intra-cluster equipped with the mechanism using the system cluster key is more efficient than other mechanisms.

Figure 13. Compare secure data transmission time for gateway, inter-cluster and intra-cluster modes.

Figure 14 illustrates the consuming time of intra-cluster secure data transmissions. This investigation compares ECDH with the system cluster key scheme of HCECKA, and finds that the transmission time of ECDH is almost 3.5 times that of the system cluster key scheme. These simulation results demonstrate that members of an intra-cluster exploit the descendent cluster key to secure transmitted messages without maintaining the session key for each transmission and take a lower time than ECDH. Additionally, our proposed scheme contains the single master key agreement, which is a particular case of HCECKA. Therefore, the Elliptic Curve Cryptography indeed reduces the key operation time.

Figure 14. The time required to securely transmit data within an intra-cluster.

Figure 15 depicts the inter-cluster secure data transmission time. After the system cluster key synchronisation, each node enciphers the transmitted message, and adopts the same system cluster key (KP) between distinct clusters to generate HMAC. However, ECDH exchanges a session key between two linked sensors within the routing path, causing the system cluster key scheme to outperform ECDH.

Figure 15. The time required to securely transmit data between two clusters within the inter-cluster.

Figure 16 illustrates the time to securely transmit inter-cluster data through the gateway approach. That is this mode. The proposed approach exploits the shortest routing path to secure data transmissions between two distinct clusters using the ECDH session key. Meanwhile, this investigation provides a system cluster key option to improve the secure data transmission efficiency. As the results of these simulations demonstrate that the system cluster key scheme using the gateway mode outperforms ECDH. The transmission time of using ECDH is nearly 4.2 times that of the system cluster key scheme with the gateway mode.

Figure 16. Pass through the gateway nodes, the time required to securely transmit data within an inter-cluster.

Based on the proposed scheme, this study demonstrates that the main computing load of each base station (BS) performs n-1 times multiplication operations to determine the descendent cluster key (for nodes 1∼n-1), and two multiplication operations in order to determine the system cluster key. Additionally, during transmissions, a routing path includes the cluster head that requires the cluster head to encipher and decipher transmitted data and calculate the HMAC code. Moreover, the sensor nodes are responsible for two multiplication operations to assist in determining the descendent cluster key, encipher and decipher transmitted data, and estimate HMAC. The root base station (RBS) performs n-1 times multiplication operations to determine the system cluster key (for base stations 1∼n-1). Consequently, the computing overhead of cluster heads is larger than that of others.

This study surveys various ID-Based Cryptography (IBC) schemes (Sumalatha & Sathyanarayana, 2015). M. Arifi et al. utilised a ternary tree to come up with an authenticated group key agreement based on identification (ID-AGKA) (Bala et al., 2016; Mandal et al., 2020), which was also considered when a member takes part in or departs from the group, and this system needed to reconstruct the group key. Contrary to conventional public key cryptosystems, non-certified public key cryptographic systems assure the authenticity of non-certified public keys. A similar protocol “Certificateless Authenticated Group Key Agreement protocol for dynamic groups” (CAGKA) was considered. Sungchul et al. (2007; Yong et al., 2013) proposed CAGKA to overcome the shortcomings of CL-PKC and to support changing group membership (joining or leaving). Debabrat et al. (2014) implemented the ElGamal Elliptic Curve Cryptography over prime field using C. The Distributed Local Key Hierarchy (DLKH) such as the Group Tree-based Diffie-Hellman (TGDH) (Ranjani  et al., 2011; Lin et al., 2011) agreement and the Distributed One-way Function Trees (DOFT) (Hajyvahabzadeh et al., 2012; Liang  et al., 2020) were also considered.

Since HCECKA is enhanced DH and GDH version, they use a key exchange protocol. So we use DH and GDH as evaluated standards to prove that our proposed scheme outperforms DH and GDH. Here, we survey the additional ECC EIgama scheme that is approximate to our proposed scheme, and ECC EIgama uses additions, minuses and multiplications without exponentiations to achieve the entire operations. This study adds the comparison of key operating costs and communication costs between HCECKA and ECC EIgama, and proves that our proposed architecture is better than traditional DH and GDH as well as ECC EIgama. Table 2 compares key operating costs and communication costs of these schemes.

Table 2. Comparison of computing costs.

		Key Operating Costs				Communication Costs
Key Agreement	Action	Descendent cluster key		System cluster/group key		Descendent cluster key	System cluster/group key
HCECKA	A node joins	Node	(n-2)+1 Multiplications	Perform re-computing cluster key operations		Broadcasts: 1 (per node) Unicasts: 2 x (n-1) Operational stages: 3	Perform cluster joining communications
		BS	(n-1) Multiplications
	A node leaves	Node	(n-1)+1 Multiplications	Perform re-computing cluster key operations		Broadcasts: 1(per node) Unicasts: 2 x (n-1) Stages: 3	Perform cluster joining communications
		BS	(n-2) Multiplications
	A cluster joins	Best case	Descendent cluster key is already done	BSx	1 Multiplication	Descendent cluster key is already done	Unicasts: 3 x (n-2) Stages: 3
				RBS	(n-2) Multiplications
		General case	–	BSx	[(n-2)+1]/2 Multiplications	–	Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications
		Worst case	–	BSx	1+1 Multiplications	–	Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications
	A cluster leaves	Best case	Descendent cluster key is already done	BSx	0	Descendent cluster key is already done	Unicasts: 3 x (n-2) Stages: 3
				RBS	(n-2) Multiplications
		General case	–	BSx	[(n-2)+1]/2 Multiplications	–	Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications
		Worst case	–	BSx	1 Multiplication	–	Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications
ECC-EIgamal	A node joins	Node	(n-2)+1 Multiplications, Addition and Minus	Perform re-computing cluster key operations		Broadcasts: 1 (per node) Unicasts: 2 x (n-1) Operational stages: 3	Perform cluster joining communications
		BS	(n-1) Multiplications, Addition and Minus
	A node leaves	Node	(n-1)+1 Multiplications, Addition and Minus	Perform re-computing cluster key operations		Broadcasts: 1(per node) Unicasts: 2 x (n-1) Stages: 3	Perform cluster joining communications
		BS	(n-2) Multiplications, Addition and Minus
	A cluster joins	Best case	Descendent cluster key is already done	BSx	1 Multiplication Additions and Minuses	Descendent cluster key is already done	Unicasts: 3 x (n-2) Stages: 3
				RBS	(n-2) Multiplications Additions and Minuses
		General case		BSx	[(n-2)+1]/2 Multiplications Additions and Minuses		Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications Additions and Minuses
		Worst case	–	BSx	1+1 Multiplications Additions and Minuses		Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications Additions and Minuses
	A cluster leaves	Best case		BSx	0	Descendent cluster key is already done	Unicasts: 3 x (n-2) Stages: 3
				RBS	(n-2) Multiplications Additions and Minuses
		General case		BSx	[(n-2)+1]/2 Multiplications Additions and Minuses		Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications Additions and Minuses
		Worst case		BSx	1 Multiplications Additions and Minuses		Unicasts: 3 x (n-2) Stages: 4
				RBS	(n-2) Multiplications Additions and Minuses

6. Conclusions

This study employs the elliptic curve cryptography to integrate a key management scheme, and furthermore propose a hierarchy-based key agreement named HCECKA to deal with secure group data transmission. The mechanism that we propose utilises shorter keys to reach the same security level as RSA and Diffe-Hellman (Wei et al., 2021; Li  et al., 2017). Furthermore, this study implements HCECKA on large-scale WSNs to perform key management very well suited. The simulation result shows that HCECKA is quite appropriate for resource-constrained environments such as Internet of Things (IoT) (Dezhi et al., 2020; Liang  et al., 2020), Ad Hoc networks and WSNs. Moreover, during the secure data transmission, HCECKA indeed consumes less resynchronisation time of constructing the system key than GDH and DH key agreement.

Moreover, we also propose a distributed group key agreement protocol with scalable and flexible capabilities. This mechanism utilises multiplications instead of exponential operations when performing ECDH (Jiang et al., 2021; Xiao et al., 2018), and therefore effectively lowers the CPU overhead (Alessandro et al., 2020; Tingting et al., 2020). The mechanism we offer is very well suited to implement on a large scale WSNs carrying out dynamic key operations.

This research offers multiple communication modes to increase the performance for securely transmitting data. Within the same cluster, this study provides the intra-cluster mode to secure transmitted data among nodes. When the source node and the target node are located in different clusters, the proposed inter-cluster mode or gateway mode also can accomplish secure data transmissions. Our method employs an efficient hash function and simple key operations to inspect the integrity of transmitted data and secure the transmitted data, respectively, and therefore reduce the requirement of complicated operations in WSNs.

Eventually, the analyses of simulation results demonstrate that HCECKA exceeds other mechanisms on rekeying efficiency and communication overhead. Therefore, HCECKA is quite suited for the large scale of IoT or WSNs without sufficient resources. Especially, in industry, IoT is a tendency. However, IoT is exposed to an open environment. Our proposed approach could be applied to many industrial fields, and significantly improve the security issues.

Disclosure statement

No potential conflict of interest was reported by the author.

Data availability statement

The data that support the findings of this study are available on request.