An Identity-Based Cross-Domain Authenticated Asymmetric Group Key Agreement

: Cross-domain authenticated asymmetric group key agreement allows group members in different domains to establish a secure group communication channel and the senders can be anyone. However, the existing schemes do not meet the requirement of batch verification in the group key negotiation phase, which makes the schemes have low efficiency. To address this problem, an identity-based cross-domain authenticated asymmetric group key agreement is proposed that supports batch verification. The performance analysis shows that this protocol is highly efficient. Finally, the proposed protocol is proved to be secure under the k -Bilinear Diffie–Hellman Exponent assumption.


Introduction
With the rapid proliferation of the mobile network, secure group communication is usually required in many emerging applications [1], such as teleconference, telemedicine, social group networks, ad hoc networks, and mobile cloud computing [2][3][4][5][6]. A popular approach is to employ the group key agreement (GKA) protocols. The conventional GKA protocols enable group members to exchange information confidentially by negotiating a shared symmetric key over an open network [7]. Nevertheless, this symmetric key is only known to the group members, which results in the problem of sender restriction. This problem means that if an outsider wants to broadcast secret messages to the group, he/she must join this group first. Motivated by the mentioned observation, Wu et al. [8] introduced an asymmetric group key agreement (AGKA) protocol that a common public encryption key (access to outsiders) is negotiated among group members and each member can respectively compute a private decryption key. This protocol is only proved secure to passive attackers who simply eavesdrop on the group communications. By considering active attacks, such as a man in the middle attack, Zhang et al. [9] designed an authenticated AGKA (AAGKA) protocol based on Public Key Infrastructure (PKI). To alleviate the overhead of complicated certificate management, an identity-based AAGKA protocol [10] is presented. However, the above studies only consider the scenarios in a single domain.
In cross-domain scenarios, such as telemedicine [11] and mobile cloud computing networks [12], members physically belong to different regions, clouds, institutions or networks. Each domain has its own domain administrator (DA), resources and members. When there is collaborative work between several domains, members in a domain may ask for resources in other domains [13]. For instance, in an electronic health social system, patients in different hospitals with the same symptoms need to form a group to securely share treatment or rehabilitation information [14] and get medical advice from outside experts. Another example in mobile cloud computing [12], group terminals distributed in different clouds or heterogeneous networks can also share resources with other groups when in collaborative work. In recent years, some cross-domain AAGKA protocols [11,12,15] have been proposed to establish a secure connection between different domains. In the literature [11,15], group members from different domains will authenticate each other with digital signatures before calculating the group session keys. Despite realizing mutual authentication, the digital signature schemes cannot support batch verification so that the number of complex operations (e.g., bilinear pairing) grows linearly with the number of group members. It seems inefficient and impractical that group members may be mobile terminals with limited energy, computation and communication resources. To reduce the computational overhead of group members, a semi-centered scheme [12] was proposed that DAs need to authenticate other group members for their domain members, while DAs may become the bottleneck [16] of the whole system.

1.
Inspired by Zhang et al. [10], this work extends a hierarchical batch signature scheme [17] to a batch multi-signature scheme. Then, we apply it into the construction of the proposed identity-based cross-domain AAGKA (ID-CD-AAGKA) protocol, which is distributed without any trusted party and supports batch verification.

2.
The security proof is given that this protocol offers secrecy, known-key security and partial forward secrecy. Meanwhile, as the performance analysis shows, the IB-CD-AGAKA protocol is more efficient than existing works.
The remainder of this paper is organized as follows. Section 2 gives a brief review of the related works. Section 3 presents bilinear pairing and the complexity assumption. Our IB-CD-AAGKA protocol is described in Section 4. The proof of correctness is provided in Section 5, and the security aspect of the proposed protocol is analyzed in Section 6. Section 7 gives the performance comparison between the IB-CD-AAGKA protocol and the previous works. Finally, Section 8 concludes our work.

Related Works
Studies to secure group communications in cross-domain scenarios can be divided into two categories, i.e., conventional authenticated GKA protocol and AAGKA protocol.

Cross-Domain Conventional Authenticated GKA (CCAGKA) Protocols
In 2015, Guo et al. [18] first put forth a multi-participant cross-domain group passwordbased authenticated key exchange (MCGPAKE) protocol. In this protocol, a domain member shares passwords with trusted domain servers. A header is selected as a proxy of each domain to negotiate a cross-domain session key with other headers. If all the headers are malicious attackers, they can predetermine the session key. Subsequently, Zhu et al. [19] proposed a novel MCGPAKE protocol with explicit authentication and contributiveness in the universally composable (UC) framework. The scheme realizes ( n 2 , n) contributions that if the adversary corrupts less than half of the participants, the session key still cannot be predetermined. On the other hand, the communication rounds in the aforementioned works [18,19] are no less than eight rounds, which is not round-efficient. In 2016, Lan et al. [13] presented a one-round CCAGKA protocol in which group members use different cryptographic settings and signature schemes. An indistinguishability obfuscation program is published by a trusted third party to make all the participants have the uniform computation as the group session key. In 2018, Yang et al. [14] utilized a three-layer tree structure to construct a CCAGKA protocol with symptom-matching for an e-health system. In the group key agreement phase, a powerful patient is chosen to authenticate other group patients. In 2020, Luo et al. [20] pointed out Yang's scheme does not meet the requirement that different domains may have different cryptographic system parameters. In this scheme, a group controller is set up to generate a group session key for all the participants. However, it may lead to single node failure when the group controller is corrupted. All the above CCAGKA protocols have the same shortcoming, i.e., sender restriction [21].

Cross-Domain AAGKA Protocols
In 2014, Qikun et al. [15] proposed a distributed cross-domain AAGKA protocol. Each domain member is assigned with a register key binding to his public key and the domain public key of the corresponding DA. The domain public keys lack an authentication mechanism. Thus, domain members need to store all the domain public keys. In the resource-constrained environment, terminals may not have enough memories to keep them. Besides, when a domain public key is updated, terminals in all domains also need to update this key. In 2018, Zheng et al. proposed a semi-centered scheme to solve the problems in [15] where DAs participate in the key agreement phase as intermediated nodes between users. All the messages received or sent by the group users must be authenticated and transferred by DAs. Moreover, DAs form a pair of alliance public/private keys to validate the domain public keys. In this way, each member only needs to store the corresponding domain public key. It will reduce the computational overhead of group users. Nevertheless, DAs can also compute the group session keys. If a DA fails, the group session keys and the previous group messages would be leaked, which is the single node failure to make DA become the system's bottleneck [16]. In the same year, Qikun et al. [11] proposed a distributed cross-domain AAGKA protocol based on a new signature scheme in the above alliance structure. However, in the verification phase of this signature scheme, the number of bilinear pairings grows linearly with the number of group members. When the group size is large, the consumption of computing resources is considerable so that the resource-constrained terminals cannot afford it.
Then, we give the comparisons between the IB-CD-AAGKA protocol and the above schemes in Table 1. Table 1. Comparison between the above cross-domain group key agreement protocols and the IB-CD-AAGKA protocol.

Schemes Distributed Sender-Unrestricted Constant or No Bilinear Pairing of Each User
Guo et al. [18] no no yes Zhu et al. [19] no no yes Lan et al. [13] no no yes Yang et al. [14] no no yes Luo et al. [20] no no yes Zhang et al. [15] yes yes no Zheng et al. [12] no yes yes Zhang et al. [11] yes yes no The proposed protocol yes yes yes

Bilinear Pairing
As our protocol is constructed from bilinear pairing [22], we give a brief introduction of it in this section.
Let G 1 be an additive group and G 2 be a multiplicative group. Both of them have the same prime order q.ê : G 1 × G 1 → G 2 is called a bilinear pairing if the following properties hold: • Bilinearity: For all P, Q ∈ G 1 and a, b ∈ Z * q , there isê(aP, bQ) =ê(P, Q) ab . • Nondegeneracy: There exists P, Q ∈ G 1 , such thatê(P, Q) = 1. • Computability: For all P, Q ∈ G 1 , there exists an efficient algorithm to computê e(P, Q) ∈ G 2 .

Our IB-CD-AAGKA Protocol
In this section, we present the proposed IB-CD-AAGKA protocol in detail.

Network Architecture
The cross-domain network architecture used in this protocol is illustrated in Figure 1

1.
The RPKG generates a master private key, a master public key, and other system parameters. Then, the RPKG keeps the master private key secret and publishes the master public key and the other system parameters.

2.
Each DPKG manages a domain independently and registers to the RPKG. The RPKG generates all the DPKGs' private keys, and sends them to the DPKGs separately in a secure channel.

3.
When a user joins a domain, he/she registers to the corresponding DPKG. The DPKG generates the user's private key, which is sent to the user securely.

4.
When users from different domains want to establish a group, they generate and publish their parameters of group keys.

5.
The group members verify whether the received parameters of group keys are from other group members or not. If the verification passes, each group member can calculate his/her group decryption private key and a common group encryption public key.
An outside sender can encrypt the messages with the group encryption key and broadcast the ciphertexts to a group. Then, the group members can decrypt the ciphertexts with their group decryption keys.

Assume the number of group members in domain
domain member of D i in the group, who negotiates the asymmetric group keys with other group members. ID i , ID i,j are identities of DPKG i and U i,j , respectively. For simplicity, we also assume the number of group members in each domain is equal, i.e., m 1 = m 2 = · · · = m n = m. The group size is N = n · m.
In the following, we provide a detailed description of our proposed IB-CD-AAGKA protocol, which comprises three phases: system setup and private key distribution, crossdomain group key agreement, group encryption and group decryption.

1.
System setup and private key distribution. First, the RPKG runs Setup to initialize the system parameters, including the master private key and master public key. Second, the RPKG executes DPKG.Register to generate the private key for each DPKG i . Third, each DPKG i generates private keys for D i 's domain members by Member.Register.
(a) Setup: On input a security parameter 1 λ , the RPKG generates system parameters {G 1 , G 2 , q, P, Q,ê, s, PK root }, where G 1 is an additive group, G 2 is a multiplicative group, q is the prime order of G 1 and G 2 , P and Q are generators of G 1 ,ê denotes a bilinear pairing G 1 × G 1 → G 2 , a random number s ∈ Z * q is the master private key, and PK root = s · P is the master public key. The RPKG chooses four hash functions H 1 , H 2 , H 3 : {0, 1} * → Z * q and H 4 : G 2 → {0, 1} τ (τ is the bit-length of plaintexts). Then, the RPKG keeps s secret, and publishes the remaining system parameters and the hash functions. (b) DPKG.Register: When DPKG i registers to the RPKG, the RPKG runs this algorithm to generate the public/private key pair for DPKG i . The RPKG first chooses a random number

2.
Cross-domain group key agreement. All group members' common encryption key and group decryption keys are generated in this phase. The process of cross-domain group key agreement involves four algorithms, namely GenKeyParams, BVerify, GenEncKey and GenDecKey, which are executed by (a) GenKeyParams: U i,j executes this algorithm to generate the parameters of group keys which includes U i,j 's signatures on all the group members' indexes are other group members' signatures on (i, j). Then, U i,j runs this algorithm to take a batch verification of the signatures. First, U i,j computes (1) holds, U i,j ensures that the received messages are really from other group members.
(c) GenEncKey: When someone wants to broadcast secret messages to the group, he/she runs this algorithm to calculate the group encryption public key ek.
(d) GenDecKey: This algorithm helps U i,j calculate his/her unique group private . The parameters to generate all the group members' decryption keys are listed in Table 2, in which S i,j (i, j) is kept secretly by U i,j . {S x,y (i, j)} ((1 ≤ i ≤ n, 1 ≤ j ≤ m, 1 ≤ x ≤ n, 1 ≤ y ≤ m)) in each column are utilized to compute U i,j 's group decryption key.

3.
Group encryption and group decryption. Once group members finish the above algorithms and establish a confidential group communication channel, any sender can send encrypted messages to the group in this phase.
(a) Encryption: If someone wants to send a message m * secretly to the group, he/she should run this algorithm to encrypt it. The sender chooses a random number ρ ∈ Z * q and computes C 1 = ρ · P, C 2 = ρ · W, C 3 = m * ⊕ H 4 (Ω ρ ). Then, the sender outputs the ciphertext (C 1 , C 2 , C 3 ).
(b) Decryption : When receiving the ciphertext (C 1 , C 2 , C 3 ), U i,j runs this algorithm to decrypt it. U i,j computes m * in Equation (2).

Correctness Analysis
The correctness of this protocol depends on two conditions. Condition 1. U i,j ensures that the received group key parameters are from other legitimate group members with batch verification. Then, they can use the received parameters to calculate the proper pair of group encryption/decryption keys. To meet this condition, Equation (1) must hold. Condition 2. When receiving the ciphertext encrypted by the group encryption key, U i,j can use his/her decryption key to decrypt it and obtain the correct plaintext. To satisfy this condition, Equation (2) must hold. • Equation (1) is proved as follows.

Security Analysis
This section gives the proofs that the proposed protocol achieves three security properties [10], i.e., the partial forward secrecy, the known key security, and the secrecy. The partial forward secrecy requires that even if some group members' long term keys are leaked, the group decryption keys previously established by these group members would not be compromised. The known-key security ensures that if an adversary learns the encryption/decryption keys of some groups, he cannot calculate other groups' decryption keys. The secrecy means that only the legitimate group members can decrypt the encrypted message under the corresponding group encryption key.

Known Key Security and Partial Forward Secrecy
Because U i,j needs to pick a random number η i,j to generate his/her group key parameters, the encryption/decryption keys of a group are generated independently to the corresponding keys of other groups. As a result, the decryption keys of a group cannot be computed even if all encryption/decryption keys of other groups are leaked, i.e., our protocol satisfies the known key security.
Furthermore, an attacker cannot recover the S i,j (i, j) without the knowledge of η i,j , even if the U i,j 's private key SK i,j is corrupted. Therefore, the proposed protocol satisfies the partial forward secrecy.

Security Model
In this model, secrecy means the indistinguishability of a message encrypted under the negotiated public encryption key from a random string in the ciphertext space [10]. Specifically, we construct a game between a challenger C and an adversary A who has full control of the communication channel to prove the secrecy of our protocol. This game has three phases, which are described as follows: Initial: The challenger C initiates the system and transmits the system parameters to A.
Training: C answers A's queries as follows: • DPKG.Extract: C generates the DPKG i 's public and private keys, then outputs the public key. • Member.Extract: C generates the U i,j 's public and private keys, then outputs the public key. • Execute: C executes an asymmetric group key agreement. • Test: A sends m 1 and m 2 (|m 1 | = |m 2 |) to C. C randomly chooses a bit b ∈ {0, 1}, and encrypts m b using ek . A can submit this query only once and this query is used to model secrecy.
Response: Finally, A returns a bit b ∈ {0, 1} as the guess. If b = b , A wins the game. The advantage of A is Adv(A) = Pr[b = b ] − 1 2 . As defined in the literature [10], we consider that if Adv(A) is negligible, our protocol is secure against semantically indistinguishable chosen identity and plaintext attacks (Ind-ID-CPA).

Security Proof
This section proves that if an adversary A can corrupt the secrecy of the proposed protocol with a non-negligible advantage, C can solve the k-BDHE problem with a non -negligible advantage.
Initial: At the beginning of the game, C chooses system parameters {G 1 , G 2 ,ê, P, Q, PK root } where PK root = t 1 = a · P and Q = a k · P and sends them to A. Then, C randomly picks a DPKG's identity ID * DPKG and a group member's identity ID * U as challenge identities. Training: In this phase, C answers A's queries as follows.
• H 1 query: C keeps an initially empty list L H 1 . On input ID i , R i (1 ≤ i ≤ n), C does the following: 1. If there is a tuple (ID i , R i , α i ) on L H 1 , C returns α i as the answer; 2. Otherwise, C chooses a random number α i ∈ Z * q and adds (ID i , R i , α i ) to L H 1 . Then, C returns α i as the answer. • H 2 query: C keeps an initially empty list L H 2 . On input , C does the following: j as the answer. 2. Otherwise, C chooses a random number α i,j ∈ Z * q and adds (ID i , R i , ID i,j , R i,j , α i,j ) to L H 2 . Then C returns α i,j as the answer.
• H 3 query: C keeps an initially empty list L H 3 . On input x, y (1 ≤ x ≤ n, 1 ≤ y ≤ m), C does the following: 1. If there is a tuple (x, y, f x,y ) on L H 3 , C returns f x,y as the answer. 2. Otherwise, C chooses a random number f x,y ∈ Z * q and adds (x, y, f x,y ) to L H 3 . Then, C returns f x,y as the answer. • H 4 query: C keeps an initially empty list L H 4 . On input a message , C does the following: 1. If there is a tuple ( , ) on L H 4 , C returns as the answer. 2. Otherwise, C chooses a random number string ∈ {0, 1} τ and adds ( , ) to L H 4 .
Then, C returns as the answer. • DPKG.Extract: C keeps an initially empty list L DPKG . On input ID i (1 ≤ i ≤ n), C does the following: 1. If there is a tuple (ID i , r i , R i , SK i ) on L DPKG , C returns R i as the answer. 2. Otherwise, C randomly chooses α i , r i ∈ Z * q and proceeds as follows: (a) If ID i = ID * DPKG , C computes R i = r i · P − α i · PK root and SK i = r i · Q. (b) Else, C computes R i = α i · P, and sets SK i = null. Then, C adds (ID i , r i , R i , SK i ) to L DPKG and adds (ID i , R i , α i ) to L H 1 . Then C returns R i as the answer.

•
Member.Extract: C keeps an initially empty list L member . On input (ID i , ID i,j ), C does the following : j as the answer. 2. Otherwise, C randomly chooses α i,j , r i,j ∈ Z * q and proceeds as follows: (a) If ID i = ID * DPKG , C computes R i,j = r i,j · P and SK i,j = SK i + α i,j · r i,j · Q. (b) Else, C does the following: i. If Else, C computes R i,j = r i,j · P, and sets SK i,j = null. Subsequently, C adds (ID i , R i , ID i,j , r i,j , R i,j , SK i,j ) to L member and adds (ID i , R i , ID i,j , R i,j , α i,j ) to L H 2 . Then, C returns R i,j as the answer.
• Execute: C keeps an initially empty list L Execute . C does the following: 1. If ID i = ID * DPKG and ID i,j = ID * U , or ID i = ID * DPKG and ID i,j = ID * U : (a) C chooses a random number η i,j ∈ Z * q and computes T i,j = r i,j · P + f −1 x,y · t 1−(i−1)·n−j .

5.
A returns (C 1 , C 2 , C 3 ) to A. Note that, A cannot recognize that (C 1 , C 2 , C 3 ) is not a proper ciphertext, unless A has executed an H 4 query on D =ê( Response: A finishes querying and returns b ∈ {0, 1} as the guess. If b = b , A has recognized that (C 1 , C 2 , C 3 ) is not a proper ciphertext and has executed an H 4 query on Subsequently, C constructs another random number oracle H 1 which has the same probability distribution as H 1 . C uses H 1 to replace H 1 and executes the game with A again. If A can also return the right guess, A has executed an H 4 query on (α i · PK root + R i + α i,j · R i,j · a k ), I). Then, C randomly chooses a tuple ( , ) from H 4 , and returns ( i,j · ( i,j ) −1 ) as the answer to this k-BDHE challenge.
Note that, only if = D and = D , that the above answer ( i,j · ( i,j ) −1 ) is equal toê(P, I) a k+1 . The proof is as follows.

Performance Analysis
In this section, the performance of the IB-CD-AAGKA protocol is analyzed. Due to the limited resources of mobile terminals, we adopt the following five metrics, i.e., the computational complexity, the computational cost, the communication complexity, the communication cost and the energy consumption. As mentioned in Section 2, most works have shortcomings in security or functionalities. Specifically, the CCAGKA protocols [13,[18][19][20]24] have the limitation of sender restriction. In addition, the semi-centered AAGKA protocol [12] faces single node failure. To our best knowledge, only schemes [11,15] are distributed and sender-unrestricted. Thus, we take a performance comparison between the proposed protocol and the schemes [11,15].

Computational Complexity and Cost
The computational complexity relates to the number of cryptographic operations of a group member in the cross-domain group key agreement phase. The symbols T mul , T add , T bp , and T h denote the computing time for a scalar multiplication in G 1 , an addition in G 1 , a bilinear pairing, and a hash function, respectively. The computational complexity is analyzed in the following.
Because, the part of Ω, which is (α x · PK root + R x + α x,y · R x,y ) (x = i or y = j), has been computed in BVerify. In GenDecKey, the computational complexity is T add , because n ∑ x=1 m ∑ y=1 S x,y (i, j) (x = i or y = j) has also been calculated in BVerify. The computational complexity of the IB-CD-AAGKA protocol is 5N · T mul + (7N − 4)T add + 3T bp + (3N + 1)T h . Moreover, as shown in the Table 3, the computational complexity of scheme [11] is (3N + 2)T mul + 2N · T bp and the computational complexity of scheme [15] is To calculate the computational cost, we adopt the values provided by the literature [25], where T mul = 0.817 ms, T add = 0.002 ms, T bp = 5.5832 ms, and T h = 0.0012 ms. Their experiment was run on a Windows 7 machine with an Intel I7-6700 processor (3.40 GHZ) and 8GB memory, and the cryptographic operations were implemented using the MIRACL [26] cryptographic library. The bilinear pairingê : G 1 × G 1 → G 2 is built on 80-bit security levels. q is the order of the additive group G 1 . p is a generator of G 1 and it is a point on the super singular elliptic curve y 2 = x 3 + x (mod p) with the embedding degree 2. Moreover, p is a 512-bit prime number and q is a 160-bit Solinas prime number. Then, the computational cost of our protocol is (5N) × 0.817 + (7N − 4) × 0.002 + 3 × 5.5832 + (3N + 1) × 0.0012 = (4.103N + 16.743) ms. The computational cost of [11] is (3N + 2) × 0.817 + 2N × 5.5832 = (13.621N + 1.634) ms and the one of [15] is (N + 4) × 0.817 + (2N − 1) × 0.002 + 3N × 5.5832 = (17.571N + 3.266) ms. As we can see, the number of bilinear pairing in our protocol is 3. By comparison, the ones in the schemes [11,15] are 2N and 3N. The reason for this is that the proposed protocol employs batch verification while in other schemes, group members can only verify one signature at a time. Moreover, our protocol has less computational cost than that of [11,15], when N ≥ 2 and N ≥ 1, respectively.

Communication Complexity and Cost
The communication complexity is relevant to the length of sent messages, the length of received messages and the length of total messages in the group key agreement phase. We also employ the symbols and values from [25], in which |G| = 1024 bits denotes the length of an element in G 1 or G 2 , and l = 160 bits is the length of an identity. The analysis of communication complexity and communication cost is as follows.
As for each group member U i,j , his/her sent messages are M i,j = (R i , ID i , R i,j , ID i,j , T i,j , {S i,j (x, y)}(1 ≤ x ≤ n, 1 ≤ y ≤ m, x = i, y = j)) and the received messages are {R x , ID x , R x,y , ID x,y , T x,y , S x,y (i, j)}(1 ≤ x ≤ n, 1 ≤ y ≤ m, x = i, y = j), where R i , R i,j , T i,j , S i,j (x, y), R x , R x,y , T x,y , S x,y (i, j) ∈ G 1 and ID i , ID i,j , ID x , ID x,y are identities of DPKG i , U i,j , DPKG x and U x,y . Thus, the length of sent messages is (N + 2)|G| + 2l and the length of received messages is 4(N − 1)|G| + 2(N − 1)l. The length of total messages is (5N − 2)|G| + 2N · l. The communication cost is (5N − 2) × 1024 + (2N) × 160 = (5440N − 2048) bits.
Moreover, as shown in the Table 3, the communication cost of scheme [11] is (3392N − 2048) bits and the one of scheme [15] is (6304N − 2048) bits. Thus, the proposed protocol has more communication cost than that of [11] and less communication cost in than [15]. However, we found that in the group key agreement phase of [11], a group member's sent messages do not include his/her own public key and the corresponding domain key. Both of them are not known by other members in the group. The length of the two keys is 2|G|. Then, we recompute the communication complexity of [11], where the length of sent messages is (N + 2)|G| + 2l, the length of received messages is 4(N − 1)|G| + 2(N − 1)l, the length of total messages is (5N − 2)|G| + 2N · l and the communication cost is (5444N − 2048) bits. In this condition, the IB-CD-AAGKA protocol has the same communication complexity and communication cost. Table 3. The performance comparison between the proposed protocol and the schemes [11,15].

Performance Metrics
Proposed Protocol Zhang et al. [11] Zhang et al. [15] Computational complexity   [15] believe, in their scheme, the number of parameters in received messages is N + 4. However, the authors of [27] point out that this value is incorrect and give a new value, which is 4(N − 1). We further recounted the number of parameters in received messages based on two types of parameters, i.e., identities, and points on group G 1 or G 2 . The results are shown in the Table 3, which is 2(N − 1)|G| + 2(N − 1)l. The total number of parameters is 2(N − 1) + 2(N − 1) = 4(N − 1), which is the same as the value provided by [27]; 2 In the schemes [11,15], each group member's secret parameter of group keys is encrypted separately by other members' public keys, and the encrypted parameters are published. The scheme [11] assumes that each group member only receives the parameters encrypted by his/her public key, while the scheme [15] assumes that group members receive all the encrypted parameters. For comparison, we adopt the assumption in the scheme [11] and recalculate the length of received messages in scheme [15]. Compared with [15], the recalculated length of received messages is smaller.

Energy Consumption
The computational and communication costs are the main factors that impact the energy consumption. We adopt the energy consumption values of cryptographic operations and transmission data provided by Tan et al. [28] and Xu et al. [27], where a "Strong ARM" microprocessor running at 133 MHz performing a scalar multiplication, a point addition, hash function and bilinear pairing consumes 8.8, 0.001085, 0.000108 and 47 mJ, respectively. 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.

Conclusions
To solve the efficiency problem of the existing cross-domain AAGKA protocols, this paper proposed a distributed IB-CD-AAGKA protocol with batch verification. The security analysis shows that our work achieves some typical security properties, i.e., secrecy, known-key security, and partial forward secrecy. Furthermore, the performance analysis indicates that the IB-CD-AAGKA protocol has lower computational and energy costs than those of [11,15]. With strong security and efficient performance, the proposed protocol is suitable for some resource-constrained environments, e.g., mobile computing networks.
Author Contributions: Q.C. and T.W. conceived of the presented idea. Q.C., T.W. and Q.Z. mainly wrote the manuscript. T.W. and Q.Z. reviewed the manuscript. Q.C., C.H. and A.C. processed the experimental data and performed the analysis. All authors have read and agreed to the published version of the manuscript.