A Blockchain-Based Authentication and Dynamic Group Key Agreement Protocol

With the rapid development of mobile networks, there are more and more application scenarios that require group communication. For example, in mobile edge computing, group communication can be used to transmit messages to all group members with minimal resources. The group key directly affects the security of the group communication. Most existing group key agreement protocols are often flawed in performance, scalability, forward or backward secrecy, or single node failure. Therefore, this paper proposes a blockchain-based authentication and dynamic group key agreement protocol. With our protocol, each group member only needs to authenticate its left neighbor once to complete the authentication, which improved authentication efficiency. In addition, our protocol guarantees the forward secrecy of group members after joining the group and the backward secrecy of group members after leaving the group. Based on blockchain technology, we solve the problem of single node failure. Furthermore, we use mathematics to prove the correctness and security of our protocol, and the comparison to related protocols shows that our protocol reduces computation and communication costs.

and distributing all keys and controlling group communication, the scalability and storage costs of this type of protocol are very large. In addition, once the KDC fails, the entire system cannot continue to operate normally.
(2) Decentralized group key agreement protocol: This type of protocol usually divides the entire group into several subgroups, and each subgroup has a group controller to manage all group members in the subgroup. In this way, the burden of KDC is greatly reduced, and single node failure is also solved. Mittra [15] proposed a scalable multicast framework, which divides large groups into multiple subgroups, and each subgroup has a controller called a group security intermediate node or a group security agent. In the protocol of Setia et al. [16], the group key is updated at regular intervals, rather than when group members join or leave. Naresh et al. [8] proposed a cluster-based hybrid group key agreement protocol, which divides large groups into a certain number of clusters and specifies the last member of the cluster as the cluster head and group controller. In 2018, Gupta et al. [17] proposed a group key agreement protocol based on self-certified public keys. In their protocol, there is a group controller for each group. Moreover, before generating the group key, each group member needs to mutually authenticate with other group members, which leads to high computation and communication costs. Zheng et al. [18] proposed a multi-domain group key agreement protocol. Their protocol uses authentication between group members and a group controller instead of authentication between each group member to reduce computation and communication costs. However, this makes their protocol vulnerable to single node failure. The main problems faced by decentralized group key agreement protocols are key distribution efficiency, how to establish a trusted relationship with a third party, and mutual authentication of sub-members across groups.
(3) Distributed group key agreement protocol: All group members in this type of protocol are equal, and there is no group controller. In addition, the KDC usually does not participate in the generation of group keys. Without a base station, Wang et al. [19] proposed a device-to-device group key agreement protocol. The protocol guarantees the anonymity of each device and uses a signature scheme based on the gap Diffie-Hellman group [20]. In 2018, Zhang et al. [21] proposed a distributed group key agreement protocol. Their agreement achieves cross-domain authentication and key self-certification. Based on the hyper elliptic curve digital signature and ElGamal algorithm, Kavitha et al. [22] proposed a distributed group authentication protocol for the healthcare system in the Internet of Things. Since the KDC or group controller in this type of protocol usually does not participate in the process of group key generation, the mutual authentication between group members becomes the largest computational overhead, which means that the cost of generating a group key will increase as the number of group members increases. Therefore, reducing the number of mutual authentications between group members is the core of reducing the cost of generating a group key. There are many protocols dedicated to reducing the number of authentications between group members by reducing the number of authentication rounds. The group key agreement protocol proposed by Geng et al. [23] and Zheng et al. [9] divides the entire protocol into two rounds. The first round is mutual authentication between members, and the second round is group key generation. In the above two protocols, each group member only needs to authenticate the two adjacent group members. The protocol proposed by Zhang et al. [24] and Shi et al. [25] merges the two processes described above into one. The protocol proposed by Alphonse and Reddy [26] forms each group member into a structure similar to a binary tree, and all group members authenticate each other from the leaf node to the root node. Although their protocol reduces the computation and communication costs required to generate group keys, all group members must wait for the final root node to be authenticated before they can negotiate the group key. Therefore, the computing time is still not low.

Network Model
There are two parts in our network model, namely KDC and General Node (GN). In MEC, the KDC can be regarded as the SCM, and the GN can be regarded as the SCC. All GNs are equal, and there is no hierarchy or subordinate relationship. In addition, all GNs usually have certain computing and storage resources, and they can join or leave a group at any time. All KDCs are wire connected, and each KDC can manage one or more GNs. The network model used in our protocol is shown in Figure 1.
In our protocol, multiple KDCs form a blockchain network. In order to improve the efficiency of new block generation, we consider using a more efficient Proof-of-Stake (PoS) [27] or Delegated Proof-of-Stake (DPoS) [28] consensus mechanism, such as ouroboros, a provably secure PoS protocol [27], instead of using a Proof-of-Work (PoW) mechanism [29]. According to this consensus mechanism, at regular intervals, all KDCs will regenerate new blocks including groups whose GNs have changed during this period. In each block, in addition to the hash value of the previous block, the timestamp, and Merkle tree root, it also contains the identifier of these groups, the identity list of all GNs in these group, and the related parameters of all GNs in these group. All GNs only have the permission to read information from the blockchain. In addition, there may be multiple different groups, so after the GN enters the network, it first needs to select a group to join. Before the GN joins the network, it can submit its identity to a KDC closest to it. The KDC will calculate a pair of keys based on the identity and distribute it to the GN. After that, all KDCs will generate a new block containing the identity and related information of the newly added GN through the consensus mechanism. The detailed operation of KDCs is described in the next section. Note that not all KDCs participate in group key agreement.

Threat Model
We define the threat model as follows: • The adversary has the ability to intercept all data transmitted over unsecured channels, and he/she can inject new data and replace or replay the previously sent data. • All KDCs are semi-trusted parties, which means that they may misbehave themselves, but do not conspire with any other KDC [30]. • With the help of a Tamper-Proof Device (TPD), we assume that even if the adversary compromises the KDC, he/she cannot extract any secret keys from it. • The adversary has the ability to capture any number of GNs and can access all the secret information stored in the GN's memory by capturing attack.

Bilinear Pairing
Let G 1 and G 2 be cyclic additive and multiplicative groups of prime order q, respectively. The generator of G 1 is g 1 . Let e : G 1 × G 1 → G 2 be a bilinear pairing, which satisfies the following properties: • Bilinearity: ∀P, Q ∈ G 1 and ∀a, b ∈ Z * q , e(aP, bQ) = e(P, bQ) a = e(aP, Q) b = e(P, Q) ab are satisfied.
• Computable: for all P, Q ∈ G 1 , there is always an effective algorithm to compute e(P, Q).
The security of our protocol is based on the following computationally infeasible problems.

Proposed Protocol
In the distributed group key agreement protocol, each group member is equal, which means that before the group key is negotiated, each group member usually needs to consume many communication and computing resources to perform mutual authentication with all other group members. In order to reduce these costs, in our protocol, we arrange all GNs into a list according to their identities. According to the list, before the group key is negotiated, each GN only needs to send an authentication request to its right neighbor once and be authenticated by its right neighbor. In other words, each GN will receive an authentication request from its left neighbor and authenticate its left neighbor. Since each GN only needs to complete authentication once, this can greatly reduce the computation and communication costs caused by authentication between group members. In addition, when any GN needs to join or leave the group, only the left neighbor of the GN needs to update the parameters, which can also reduce the computation and communication overhead.
Our protocol has seven parts: the initialization phase, the registration phase, the mutual authentication phase, the group key generation phase, the GN join phase, the GN leave phase, and the internal attacker detection process. When the system runs for the first time, the initialization phase is performed by the System Administrator (SA). Each GN performs the registration phase before entering the network. When the group key needs to be negotiated, all GNs perform the mutual authentication phase and the group key generation phase. When a GN wants to join a group, it needs to perform the GN join phase. When a GN in the group wants to leave, the GN leave phase is performed. If the group key fails to be generated multiple times, the KDC will execute the internal attacker detection process to find the malicious GN and expel it from the group.
Suppose there are GN i (1 ≤ i ≤ n) that need to generate the group key, and their identities are where n is the number of GN. Since there may be multiple groups, we named each group GID u , where u is the number of groups. Each group has a list L that stores the identity ID i of all GNs in the group and is managed by the KDC. All ID i in L are sorted in descending order, and L is a circular list, which means that the largest ID i and the smallest ID i are linked. Table 1 shows the description of the symbols. The details of the above seven parts are as follows. Table 1. Symbols used in our protocol.

SA
System Administrator KDC Key Distribution Center GN General node q A large prime number G 1 Cyclic additive groups of prime order q G 2 Cyclic multiplicative groups of prime order q Q The generator of G 1 e Bilinear pairing e : The identity of the group L A circular list that stores all GN-related information in the group s The KDC's private key P pub The KDC's public key The timestamp when the latest information was received ∆t

Maximum communication transmission delay KT i
Symmetric key E k Symmetric encryption algorithm D k Symmetric decryption algorithm h(.)

Hash operation Ks
Group key ⊕ Bitwise XOR operation (a, b) Concatenation of data a and data b

Initialization Phase
First, the SA picks {G 1 , G 2 , Q, e, p}, where G 1 is a cyclic additive group of order p, G 2 is a cyclic multiplicative group of order p, Q is a generator of G 1 , and e : G 1 × G 1 → G 2 is a bilinear map. Second, the SA generates a random private key s and computes the corresponding public key P pub = sQ. Finally, the SA publishes parameters {p, G 1 , G 2 , Q, e, P pub , h(.), E k , D k } and stores s in the memory of each KDC in a secure environment, where h(.) is the hash function used by this protocol, E k is the symmetric encryption algorithm, and D k is the symmetric decryption algorithm.

Registration Phase
Before the GN joins the network, it needs to choose the nearest KDC to register and receive the corresponding key. The steps in this phase are as follows.
Step R1: The KDC generates a unique identity ID i for the GN i and computes its public key W i = h(ID i ) and the corresponding private key S i = sW i . Finally, the KDC sends S i to GN i through a secure channel.
Step R2: GN i generates a random a i , computes A i = a i Q, and sends A i to the KDC through a secure channel.
Step R3: The KDC broadcasts ID i , W i , and A i .
Step R4: According to the group's identity GID, the GN can choose to join a group or pick a new unique GID to create a new group. Based on the selection of the GN, there are three different situations: (1) Situation A: the GN joins a group that already has a group key; (2) Situation B: the GN joins a group that has not started negotiating group keys; (3) Situation C: the GN creates a new group. In Situation A, the GN performs the GN join phase. In Situation B and Situation C, the KDC will package GID, the corresponding L, and multiple tuples (ID i , W i , A i ) related to all members of the group into a new block, which will be verified by all other KDCs. After successful verification, the new block will be linked to the blockchain. Figure 2 shows the three situations faced by the GN and the solution strategies.

Mutual Authentication Phase
In this phase, GN i first sends a message to its right neighbor GN i+1 , and GN i+1 will authenticate GN i . At the same time, GN i will also receive a message from its left neighbor GN i−1 , and it needs to authenticate GN i−1 . Figure 3 shows the mutual authentication phase and the group key generation phase of our protocol. GN i performs the following operations.
Step A1: Generates a random m i and a timestamp t 1 i and gets A i+1 from the blockchain.
Step A2: Step A3: Step A4: GN i receives a message (SE i , C i−1 , t 1 i−1 ) from GN i−1 and gets A i−1 from the blockchain.
Step A5: Checks that t new − t 1 i−1 < ∆t holds or not. If the check fails, it broadcasts an authentication failure message.
Step A6: Step A7: Checks whether the condition e(Q, If the condition is not true, it broadcasts an authentication failure message.
Step A8: Uses KT i to decrypt SE i and get M i−1 .
Step A9: Generates a random b i and a timestamp t 2 i .

Group Key Generation Phase
During this phase, each GN i receives the message R r (r ∈ n, r = i) from all other GNs. At this point, each GN i will perform a group authentication and then negotiate the group key. The execution steps of each GN i are as follows.
Step K1: Checks that the timestamp t new − t 2 r < ∆t, (r ∈ n, r = i) in each received message is valid. If the check fails, it broadcasts an authentication failure message.
Step K2: After receiving the message from all other GNs, it checks that: holds or not. If the check fails, it broadcasts an authentication failure message.

GN Join Phase
When a new GN j wants to join the group, it needs to be registered in the KDC first. This means that according to the registration phase, GN j has selected a group to join. Figure 4 shows the GN join phase of our protocol. The detailed steps are as follows.
Step J1: GN j obtains the corresponding list L of the group from the blockchain, inserts its identity ID j into the appropriate position in L, and broadcasts the new L.
Step J2: GN j generates a random number a j and computes A j = a j Q. After that, GN j broadcasts A j .
Step J3: GN j 's left neighbor GN j−1 regenerates a new random number a j−1 and computes A j−1 = a j−1 Q. After that, GN j−1 broadcasts A j−1 .
Step J4: The KDC packages the updated L, corresponding GID, and multiple tuples (ID i , W i , A i ) related to all members of the group into a new block, which will be verified by all other KDCs. After successful verification, the new block will be linked to the blockchain.
Step J5: According to the steps in the mutual authentication phase, GN j sends (SE j+1 , C j , t 1 j ) to its right neighbor GN j+1 and receives message (SE j , C j 1 , t 1 j−1 ) from GN j−1 .
Step J6: After the messages received by GN j and GN j+1 are successfully authenticated, all GNs broadcast R i = (X i , Y i , Z i , t 2 i ) and perform the group key generation phase to complete the key update.

GN Leave Phase
When a GN j in the group wants to leave, the following steps need to be performed. Figure 5 shows the GN leave phase of our protocol.
Step L1: GN j deletes its identity ID j from list L and broadcasts the new L.
Step L2: GN j−1 regenerates a new random number a j−1 , and computes A j−1 = a j−1 Q. After that, GN j−1 broadcasts A j−1 .
Step L3: The KDC packages the updated L, corresponding GID, and multiple tuples (ID i , W i , A i ) related to all members of the group into a new block, which will be verified by all other KDCs. After successful verification, the new block will be linked to the blockchain.
Step L4: According to the steps in the mutual authentication phase, GN j−1 sends (SE j , D j−1 , t 1 j−1 ) to GN j+1 .
Step L5: After U j+1 authenticates U j−1 , all GNs broadcast R i = (X i , Y i , Z i , t 2 i ) and perform the group key generation phase to complete the key update.

Internal Attacker Detection Process
It can be found in our protocol that every GN is required to be honest during the group key generation phase. If a malicious GN intentionally broadcasts an error message, the entire group cannot generate a group key. However, since all GNs are equal, it is impossible to discover malicious GNs through these GNs. Therefore, our agreement regards KDC as the judging body. When the group fails to negotiate multiple times, the process will be executed and try to find the malicious GN. The steps of this process are as follows.
Step D1: The KDC first records all messages sent by each GN i in the group GID.
Step D2: Step D3: After receiving the tuple, the KDC first verifies the validity of the time stamp t D i . Then, the KDC computes S i = sW i , H = h(W i , S i , ID i , KT i+1 , b i ) and verifies H ? = H. If it does not hold, GN i is regarded as a malicious GN.
Step D4: If the above formula holds, the KDC continues to compute If it does not hold, the corresponding GN i will be expelled from the group immediately.

Correctness Analysis
Theorem 1. GN i and GN i+1 can calculate the same symmetric key KT i+1 , so that GN i+1 can get M i .

Proof.
Since GN i computes KT i+1 = a i A i+1 to get KT i+1 and GN i+1 computes KT i+1 = a i+1 A i to get KT i+1 , then: Since the same KT i+1 can be obtained by calculating a i A i+1 and a i+1 A i , GN i and GN i+1 can use the symmetric key KT i+1 to encrypt or decrypt transmitted messages.

Theorem 2. It is valid for GN i to authenticate GN i−1 .
Proof. The authentication of GN i for GN i−1 is achieved by verifying whether the formula e(Q, C i−1 ) = e(P pub , h(SE i , KT i , t 1 i−1 )W i−1 ) holds. The correctness of the formula is proven as follows.
Although the adversary can easily obtain Q, P pub , A i ∈ G 1 , due to the ECDL and the CDH, he/she cannot calculate s, any a i , or KT i in polynomial time. Therefore, the adversary also cannot calculate h(SE i , KT i , t 1 i−1 ). If the adversary wants to forge a GN i to pass the above verification, he/she needs to create a new valid e(P pub , h(SE i , KT i , t 1 i−1 )W i−1 ). However, since the adversary cannot obtain a i and s, he/she cannot calculate a new e(P pub , h(SE i , KT i , t 1 i−1 )W i−1 ). In addition, due to the DDH, for a random z ∈ G 1 , the adversary cannot decide if e(Q, C i−1 ) = e(P pub , z) in polynomial time.

Theorem 3. During the group key generation phase, GN i is valid for the batch authentication of other group members.
Proof. In the group key generation phase, GN i authenticates other group members in batches by verifying whether formula e( ∑ r =i Y r , Q) = e( ∑ r =i (X r + h(X r , Z r , t 2 r )W r ), P pub ) holds. The correctness of the formula is proven as follows.
If the adversary wants to forge a GN * i to pass the above batch authentication, he/she needs to create a valid X is revealed by the adversary, but he/she still cannot calculate a valid X * i or Y * i because he/she cannot get s. In addition, due to the DDH, for a random z ∈ G 1 , the adversary cannot decide if e( ∑ r =i Y r , Q) = e(z, P pub ) in polynomial time. Proof. According to Theorem 1, as long as all GN i s participating in the group key generation phase are honest, each GN i can obtain the parameter M i−1 sent by its left neighbor. Therefore, = e(Q, Q) m 1 +m 2 +···+m i .
From the above, it can be found that all GN i s can calculate the same parameter k. Therefore, their group keys Ks = h(k, R 1 , R 2 , · · · , R n ) are also the same.

Simulation Based on the ProVerif Tool
ProVerif is a widely known authentication protocol verification tool that can prove the security of multiple encryption schemes or authentication protocols, such as signature schemes and Diffie-Hellman key exchange algorithms [31,32]. Since each GN does not need to communicate with other nodes during the group key generation phase, we use ProVerif to verify the security of the mutual authentication phase of our protocol. In addition, since we do not need to verify the performance of our protocol in this section, we assume that there are only three GNs that need to negotiate a group key, which are GN 1 , GN 2 , and GN 3 . Figure 6 shows the code for the mutual authentication phase of our protocol. Figure 7 shows the simulation results. The results show that in our protocol, the secret parameters M 1 , M 2 , and M 3 for group key generation, as well as the private keys s, a 1 , a 2 , and a 3 will not be obtained by the adversary.

GN Impersonation Attack
The adversary needs to create valid messages (SE i+1 , C i , t 1 i ) or (X i , Y i , Z i , t 2 i ) to perform an impersonation attack on GN i . However, according to Theorem 2 and Theorem 3, the adversary cannot create a valid message.

GN Capture Attack
After the adversary has captured several GNs, we need to ensure that the private key s cannot be obtained by the adversary. After the adversary captures a GN i , he/she can obtain S i containing information about s. However, according to the ECDL, although the adversary can obtain W i and sW i , he/she cannot calculate s in polynomial time.

Replay Attack
Our protocol uses timestamps t 1 and t 2 to defend against replay attacks. In addition, our protocol guarantees that the timestamp cannot be modified. For messages (SE i+1 , C i , t 1 i ), the adversary must obtain KT i+1 and S i before replacing a new valid timestamp t 1 i . For messages (X i , Y i , Z i , t 2 i ), the adversary must obtain b i and S i before replacing a new valid timestamp t 2 i . However, the adversary cannot get KT i+1 , b i or S i because they are never transmitted directly in the channel. In addition, due to the ECDL, it is difficult for the adversary to calculate these parameters.

Forward Secrecy after a New GN Joins
When a GN wants to join a group, it needs to ensure that GN j cannot get the previous group key. In our protocol, we assume that GN j has intercepted all historical communication messages of the group. This results in that when GN j joins the group, as long as it obtains m j−1 , it can calculate the previous group key. However, when the GN j joins the group, its left neighbor GN j−1 will regenerate a new m j−1 and send it to GN j , which means GN j can only get m j−1 instead of m j−1 . Therefore, our protocol ensures the forward secrecy after a new GN joins.

Backward Secrecy after a GN Leaves
When a GN j leaves the group, it needs to ensure that it cannot get the group key generated in the future. We assume that after GN j leaves the group, it still retains the secret parameter m j−1 sent by its left neighbor and is able to intercept all group communication messages. This means that as long as m j−1 is kept unchanged, GN j can still calculate the group key after leaving the group. However, in our protocol, after GN j leaves the group, its left neighbor U j−1 will regenerate a new m j−1 and send it to GN j+1 . This results in that at Step A11, GN j−1 will broadcast Z j−1 = e(M j−1 − M j−2 , Q) and U j+1 will broadcast Z j+1 = e(M j+1 − M j−1 , Q). At this point, m j−1 has expired, and GN j cannot calculate the group key through this parameter. Therefore, our protocol ensures the backward secrecy after a GN leaves.

Single Node Failure
Although all KDCs will not participate in the mutual authentication phase and the group key generation phase, each group still needs to be managed by a KDC. This is because each group may need the KDC to act as a judging body to expel malicious nodes. If the KDC fails, since all KDCs share the same blockchain that stores all GNs' authentication parameters, it only needs to switch to another KDC. This means that in our protocol, as long as there is a working KDC, the entire system can operate normally.

Computation Cost
The symbols t sym , t h , t pm , t pa , and t bp represent the computing time required to implement one symmetric encryption or decryption, one general hash function operation, one point multiplication operation on Elliptic Curve Cryptography (ECC), one point addition operation on ECC, and one bilinear pairing operation, respectively. In the mutual authentication phase and the group key generation phase of our protocol, each GN needs to perform n + 7 point multiplication operations on ECC, 4 bilinear pairing operations, n + 3 hash operations, 2 symmetric encryption or decryption operations, and n + 1 point addition operations on ECC, where n is the number of GN. In other words, the total computation cost of each GN is (n + 7)t pm + 4t bp + (n + 3)t h + 2t sym + (n + 1)t pa .

Communication Cost
We assume C is 256 bits and timestamp T is 64 bits. In the mutual authentication phase of our protocol, each GN needs to send message (SE i+1 , C i , t 1 i ) to GN i+1 and broadcast (X i , Y i , Z i , t 2 i ). Therefore, each GN needs to send messages of length 5C + 2T and receive messages of length (3n − 1)C + nT. The total communication cost in the the mutual authentication phase and the group key generation phase of our protocol is (3n 2 + 4n)C + (n 2 + 2n)T.

Comparison with Related Protocols
We compare our protocol with the protocol of Zheng et al. [9], the protocol of Zhang et al. [21], and the protocol of Gupta et al. [17] in terms of computation costs, energy consumption, communication costs, and security.
In the protocol of Zheng et al. [9], the total computation cost required to generate the group key is (n + 4)t pm + 6t bp + (n + 4)t h + (3n + 1)t pa , and each group member needs to send messages of length 7C + 2T and receive messages of length (7C + 2T)(n − 1). In the protocol of Zhang et al. [21], the total computation cost required to generate the group key is (3n + 2)t pm + 2nt bp , and each group member needs to send messages of length 4C and receive messages of length 4(n − 1)C. In the protocol of Gupta et al. [17], the total computation cost required to generate the group key is 4nt pm + 5t h + (2n + 1)t pa . In their protocol, there is a group controller in each group, which undertakes most of the communication work and causes the communication cost of each group member to be very low. Therefore, we consider that the total length of the messages that need to be sent and received is 6nC + 1, rather than the communication cost of each group member. Table 2 shows the comparison of computation cost and communication cost between our protocol and related protocols.
Next, we will compare our protocol with related protocols in terms of energy consumption. According to the work of Carman et al. [33] and Zhang et al. [21], we obtained that a "Strong ARM" microprocessor running at 133MHz performing one symmetric encryption or decryption operation needs to consume 0.00217 mJ, one point multiplication operation on ECC requires 8.8 mJ, one general hash function operation requires 0.000108 mJ, and one bilinear pairing operation requires 47 mJ. According to the work of Makri and Konstantinou [34], we obtained that an IEEE 802.11 Spectrum24 WLAN card requires 0.00066 mJ for the transmission of 1 bit and 0.00031 mJ for the reception of 1 bit. According to [35], the computing time of one point addition operation on ECC is about half of one symmetric encryption or decryption operation. Therefore, we considered that the energy consumption of a point addition operation is about 0.001085 mJ. We summarize the above energy consumption in Table 3. Figure 8 shows the total communication energy consumption in different protocols. Figure 9 shows the communication energy consumption of each group member in different protocols. Figure 10 shows the total communication and computation energy consumption in different protocols.
It can be found from Table 2 that our protocol has the lowest computation costs, and the computation costs of our protocol and the protocol of Zheng et al. [9] are very similar. However, from Figure 8, it can be found that our protocol consumes less communication resources. In addition, because after group members join or leave a group, neither their left neighbor nor their right neighbor updated the corresponding temporary secret parameter, this leads to the newly joined group members being able to easily obtain the previous group key, and group members who leave the group can also easily obtain the subsequent group key. Therefore, the protocol of Zheng et al. [9] lacks forward or backward secrecy.
According to Figure 10, in the distributed group key agreement protocol, such as the protocol of Zheng et al. [9] and the protocol of Zhang et al. [21], our protocol has the least total communication and computation energy consumption. With the help of the group controller, the decentralized group key agreement protocol such as the protocol of Gupta et al. [17] will consume less energy when there is a large number of group members. However, in the protocol of Gupta et al. [17], each group member needs to perform mutual authentication with the group controller one by one, which requires much total computing time. Moreover, the existence of the group controller makes their protocol vulnerable to single node failure. Once the group controller fails, the group cannot continue to negotiate the group key. According to Figures 8 and 9, excluding the protocol of Gupta et al. [17], the total communication energy consumption of our protocol is the lowest, and the communication energy consumption of each group member in our protocol is also the lowest.

Conclusions
This paper proposes a blockchain-based authentication and dynamic group key agreement protocol. Each group member in our protocol only needs to authenticate its left neighbor once to complete the authentication, which improves authentication efficiency. When a node joins or leaves a group, only the left neighbor of the node needs to update the data, which also improves the scalability of our protocol. Our protocol also guarantees forward or backward secrecy when group members join or leave the group. In addition, we use blockchain technology to store group identities, a list of group members, and some group member-related parameters, which can solve the problem of single node failure. Finally, we use mathematics and ProVerif to prove the correctness and security of our protocol. The comparison with related protocols shows that our protocol reduces computation and communication costs.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: