Abstract

Focusing on the problem that existing traditional cross-domain group authentication schemes have a high complexity, a certificateless cross-domain group authentication key agreement scheme based on ECC is proposed. The protocol provides scalability and can meet the requirements of cross-domain key negotiation by multiple participants in different domains. Security analysis shows that the proposed scheme is secure in the random oracle security model, it can resist some attacks under the extended Canetti-Krawczyk (eCK) security model. Performance analysis shows that the proposed scheme is of strong practical application value with high efficiency; it costs relatively low amount of calculation and communication.

1. Introduction

The development of technologies such as wireless networks, multicast, and distributed computing has brought new demands for group-oriented network applications, such as multiparty video conferencing, remote video teaching, and online games. As a typical application scenario in the above applications, cross-domain group communication can realize information exchange and transmission between remote cross-domain group members and will provide users with richer services and maximize the use of resources. However, the increase in the size of group members and the heterogeneous network access caused by cross-domains have also brought new security challenges to the design of user identity authentication systems. A secure cross-domain group authentication key agreement protocol will establish a shared key for remote cross-domain group members, establish a secure cross-domain communication channel, ensure the confidentiality and integrity of cross-domain group communication data, and effectively prevents attackers from stealing, tampering, and forging communication data [14].

The design of the existing cross-domain group authentication key agreement protocol mainly relies on three types of cryptosystems: public key infrastructure, identity-based cryptosystems, and certificateless public key cryptosystems.

Public key infrastructure (PKI) is an important practical cryptographic technology to ensure network security. In PKI-based identity authentication, the certificate service system binds the digital certificate to the public key of the communicating entity, and the communicating entities verify the authenticity of the certificate to perform identity authentication. Wf et al. [5] adopted elliptic curve cryptosystem based on threshold scheme to construct enterprise cross-domain authentication system with the help of virtual bridge CA model. However, due to the high interaction cost caused by the threshold scheme by splitting key factors, the expansibility of joining and withdrawing members is not strong. Bin [6] improved the existing certificate revocation mechanism, but the certificate verification needs to detect from the book to be verified to the root certificate, so that the verification path is too long and the path verification efficiency is low, which greatly affects the application scope of the cross-domain identity authentication technology. Basin et al. proposed a new PKI architecture, ARPKI [7], which was designed by using formal models to ensure the transparency and reliability of certification-related operations (such as certificate issuance, update, revocation, and verification) and effectively deal with security events such as key loss or disclosure. Zhicheng et al. improved the traditional PKI-based cross-domain authentication by using the alliance chain technology [8] and used the alliance chain to manage the license domain, which simplified the authentication signature steps between entities and had high scalability. Dong et al. proposed a cross-domain authentication scheme that can enhance trust between hospitals [9], which solves the problem of fragmentation and isolation caused by traditional hospitals maintaining their own PKI-based information systems and provides better privacy protection services while realizing the sharing of medical data. Chen et al. used blockchain to replace part of CA functions [10]; the scheme has sufficient scalability and can meet the trust transmission requirements of multiple PKI systems. As the number of legitimate users increases, the calculation and communication overhead of the certificate maintenance process increases. Cross-domain identity authentication has problems such as long trust paths, low certificate verification efficiency, and complex interdomain trust path construction. It is not suitable for cross-domain identity authentication of large-scale group members.

In identity-based cryptosystems, there is no need for PKI to verify users’ public keys and identities. Private key generator (PKG) is trusted to generate private keys for users, which can effectively solve the problems such as the overhead of public key certificate management [11]. Changyuan et al. [12] proposed an identity-based signature algorithm to achieve cross-domain authentication by using elliptic curve additive group, avoiding complex bilinear pairings. However, the scheme only analyzes the certification process between the entity and the certification authority and does not consider the extra cost of the certification authority and local resources to verify each other’s legitimacy. The identity-based authenticated key agreement protocol without bilinear pairs proposed by Farash and Attari [13] sets multiple independent PKG, and each PKG sets the private key for the user under its jurisdiction. However, this protocol cannot resist temporary key leakage attack and impersonation attack, and it cannot realize implicit key authentication and key confirmation. Cao et al. [14] proposed a key agreement protocol for identity-based authentication with hierarchical PKG, which uses bilinear pair operation in its design, but the operation is not efficient and it is difficult to resist basic impersonation attacks. Kefei et al. [15] proposed an improved scheme on the basis of the literature [14], but this scheme is difficult to resist the temporary key disclosure attacks, and the operation efficiency was low due to the use of bilinear pair operation in the scheme. Since the user’s private key is completely determined by the key generation center, PKG can decrypt any user’s information and forge any user’s signature. There are key escrowing problems, and user identity multiplicity occurs when cross-domain, making cross-domain identity authentication extremely complicated.

Based on the certificateless public key cryptosystem, the user’s private key is composed of two parts, that is, the partial private key provided by KGC and the secret value selected by the user. Neither KGC nor the user can generate a complete private key independently, which solves the key escrow problem in the identity-based cryptosystem. Literature [16, 17] proposed a cloud user identity authentication scheme based on certificateless password system, but there was no relevant research on cross-domain authentication. Li et al. [18] proposed a cross-domain authentication key exchange protocol in a wireless grid environment, but the use of too much symmetric encryption causes a large amount of computational overhead. In 2015, Sun et al. [19] proposed a certificateless scheme, but it involves the calculation of linear pairs, so the amount of calculation is huge. In 2016, Cheng et al. [20] proposed a one-round certificateless authenticated group key agreement protocol for mobile ad hoc networks, but Luo et al. [21] indicated that their protocol could not achieve user anonymity that was an important aspect of user privacy protection and could not resist known temporary key attack. In 2018, Yang et al. [22] proposed a cross-domain certificateless key agreement protocol for electronic health systems. Although it achieved the security guarantees of dynamic user management, authentication, and session keys, it did not achieve the real cross-domain and could not resist known temporary key attack indicated by Luo et al. [21]. In 2018, Semal et al. [23] proposed a certificateless group authenticated key agreement protocol for secure communication in untrusted UAV networks, and in 2020, Luo et al. [21] proposed a cross-domain certificateless authenticated group key agreement protocol for 5G network slicings. However, in 2022, Ren et al. [24] indicated that the protocol proposed by Semal et al. could not resist public key replacement attack and protocol proposed by Luo only had a secondary security level; the malicious KGC could collude with some malicious users to attack the protocol.

To sum up, the current cross-domain group communication solutions are mainly focused on the security issues of users’ cross-domain communication between two domains. Such solutions not only cannot meet the security requirements of users’ cross-domain group communication, but also the communication process is too cumbersome and requires relatively high communication capabilities and computing capabilities, so it cannot provide good guarantees for the security of cross-domain group communication. Therefore, an efficient and scalable key agreement scheme for cross-domain group authentication is urgently needed to solve and realize the communication security problem of efficient cross-domain group authentication. Focusing on the characteristics and requirements of the existing cross-domain group communication, this paper proposes a certificateless cross-domain group key agreement scheme based on ECC.

2. Preliminaries

2.1. Notation

The symbols and their meanings involved in the cross-domain group key negotiation scheme are shown in Table 1.

2.2. Security Model

In our proposed protocol, a novel eCK security model presented by Lippold et al. [25] is adopted. In the subsections, detailed descriptions about the security model including the adversary model, attack game, and security definition are explained.

2.2.1. Adversary Model

There are two types of adversaries. As a dishonest participant, adversary has no idea of the master key of KGC but has the capability to replace the public key of any participant, which means can replace the secret value of the participant with a value of his choice. As a malicious KGC, adversary cannot replace the public key of any participant but can obtain the master key of KGC, which means is easily accessible for .

The security model is defined by an attack game between a challenger and an adversary . The adversary asks the challenger for a polynomial number of queries, while the challenger issues the replies using simulators and random oracles owned by him. Let represent a simulator of the challenger, which simulates the behavior of participant in the th session with intended participant . Then, simulated as participant , the simulator executes all the steps that participant should do in the protocol session. That is, the simulator takes private key of participant and messages transmitted from participant (or pseudo- personated by the adversary) as inputs and sends the corresponding outputs to the adversary.

Definition 1 (accepted session). The session is accepted when it can generate the session key .

Definition 2 (session identity). The session identity () is denoted as the concatenation of the participants’ identities and messages in the session. For instance, , where is the message transmitted from and is the message received by

Definition 3 (matched session). Honest participants and are involved in the protocol session. The session matches when they have the same session identity.

2.2.2. Attack Game

Steps of the attack game are described as follows: (1)The challenger executes the SETUP algorithm:

For adversary , the challenger sends system params to but keeps in secret. For adversary , the challenger sends system params and to (2)The adversary asks the challenger for a polynomial number of the following queries: (i)Create : generates private key/public key pair of participant (ii): reveals to the partial private key of participant (iii): reveals to the secret value of participant (iv): reveals to the ephemeral private key of participant in the session (v): reveals to the master key of KGC. Then, can obtain the partial private keys of all participants(vi): replaces the public key of participant with the value chosen by , which means that the secret values of all participants can be set by (vii): reveals to the accepted session key if is accepted. Otherwise, returns ⊥to A(viii)Send (): (pseudoparticipant ) sends the message to the session (simulated participant ) and gets a reply according to the protocol. If , simulated participant of the session is an initiator. Otherwise, it is a responder(3)When deciding to end aforementioned queries, chooses a fresh session (defined later) and asks a test () query. By tossing a fair coin with , replies the session key held by if , or a random string if (4)The adversary asks the challenger for a polynomial number of the above queries about fresh session (5)When terminating the game, makes a guess bit . If , wins the game. The advantage of for winning the game is defined as

Definition 4 (fresh session against ). The accepted session is fresh if none of the following condition holds: (i) raises the query or (if the matched session of exists)(ii)Matching: if honest participant is engaged in that matches , either inquires both (or ) and or both (or ) and (iii)Not matching: if there is no session matched to , either inquires both and or (or )

Definition 5 (fresh session against ). (i) raises the query or (if the matched session of exists)(ii)Matching: if honest participant is engaged in that matches , either inquires both (or ) and or both (or ) and (iii)Not matching: if there is no session matched to , either inquires both and or (or )

According to the adversary model stated in Section 2.2.1, and are deemed to be knowable for and by query and query, respectively. Supposing that participant and want to establish a session key, the session is not fresh in seven cases for and , respectively, which is shown in Table 2. Then, the fresh session can appear in seven cases for and , respectively, as shown in Table 3. As a case of fresh sessions, type FI1 can be regarded as FI1 and type FII1 can be regarded as FII1.

2.2.3. Security Definition

A certificateless cross-domain group key agreement protocol is deemed authenticated key agreement (AKA) secure if no adversary except the protocol participants can get the session key. Detailed and accurate definition is as follows.

Definition 6. A protocol is secure when the following set of conditions is assumed: (1)In the presence of an adversary , sessions and always agree on the same session key that distributed uniformly at random(2)For any adversary , is negligible

3. Key Agreement Scheme for Cross-Domain Group Authentication

Figure 1 shows the member structure of cross-domain group authentication in the scheme. Suppose there are domains, each with members participating in cross-domain authentication, where represents any participant and let represent the collection of remote participants scattered across domains that intend to negotiate a shared session key. Let the symbol represent the set of all participants in the same service domain . The protocol consists of two phases: intradomain key negotiation and interdomain key negotiation.

3.1. System Initialization

This algorithm takes a security parameter as input, and the performs the following steps to generate a master secret key and a set of public parameter param. (i) generates a group with prime order and determines a point of order as a generator of (ii) chooses a master secret key and computes the corresponding public key (iii) chooses seven cryptographic secure hash functions: , , and (iv) publishes the system generated parameters while keeping the master key () secret

3.2. Registration Phase

The registration phase consists of registration and user registration.

3.2.1. registration

When applies to RA as the key generation center of domain , it needs to register with RA. The algorithm is as follows: (1)Set secret value: randomly chooses , calculates , and sets as a secret value(2)Extract partial private key: key generation center sends identity information to , and picks a random number for ; calculates , , and ; and issues to by secure channel(3)Set private key: sets as his private key(4)Set public key: sets as his public key

3.2.2. User Registration

When user applies to for joining the domain as the th member, the registration needs to be completed at . The algorithm is as follows: (1)Set secret value: randomly chooses , calculates , and sets as a secret value(2)Extract partial private key: user sends identity information to , and picks a random number for ; calculates , , and ; and issues to by secure channel(3)Set private key: sets as his private key(4)Set public key: sets as his public key

3.3. Intradomain Key Negotiation

As shown in Figure 2, in the key negotiation phases of intradomain, all participants in set negotiate the session key of the intradomain group (no negotiation is required if there is only one user in the domain). Pick a participant randomly from all participants in domain as the domain head . If user is selected as domain header , users of domain are classified into common user and domain header . (1)By exchanging messages with domain header , each common user proves that they are legitimate members of the same domain

Step 1: randomly chooses and calculates and then sends message to .

Step2: randomly chooses and calculates and then sends message to .

Step 3: calculates and and then sends the signature message to .

Step 4: calculates . If , is a legitimate member of domain . (2)Domain header calculates the session key of domain based on the information received from the negotiation members and sends it to the negotiation members in encrypted form. The legitimate members who in the domain can calculate the session key

Step 1: At first, calculates , , , , , , , , and , then calculates the session key of domain , and finally sends to .

Step 2: receives the message sent by and then calculates and . If , calculates . Finally, the intradomain session key of the domain is calculated.

3.4. Interdomain Key Negotiation

As shown in Figure 3, in the key negotiation phase of interdomain, remote participants scattered in each domain who intend to negotiate the shared session key randomly choose user as domain head in their respective domains, and the key negotiation between domain heads is carried out. Assume that the domain header is divided into and , and the process of interdomain key negotiation is as follows: (1)To prove that domain heads and domain head are legitimate members of the same system, they should send messages to each other

Step 1: randomly chooses and calculates and then sends message to .

Step2: randomly chooses and calculates and then sends message to .

Step 3: calculates and and then sends the signature message to .

Step 4: calculates . If , and are legitimate members of the same system. (2)Domain head calculates the interdomain session key for interdomain negotiation based on the information received from domain head member that participates in the negotiation in each domain and sends the key to other members in the negotiation in encrypted form. Legitimate members who in the system can calculate the interzone session key

Step 1: At first, calculates , , , , , , , , and , then calculates the interdomain session key , and finally sends to .

Step 2: receives the message sent by and then calculates and . If , calculates . Finally, the interdomain session key is calculated.

3.5. Join Phase

Assume that user wants to join the protocol, obtains the system parameters of , generates its own public key and private key , and performs the key negotiation again. The procedure is the same as steps (1) to (2) in intradomain key negotiation.

3.6. Removal Phase

(1)If the domain head leave, the remaining members will reselect a computationally powerful member as the domain head, and intradomain key negotiation and interdomain key negotiation are restarted. Perform steps (1) to (2) in intradomain key negotiation, and perform steps (1) to (2) in interdomain key negotiation(2)If it is a common intradomain member that leaves, the intradomain member initiates key negotiation again. The procedure is the same as steps (1) to (2) in intradomain key negotiation

4. Security Analysis

Take intradomain key negotiation as an example. The intradomain session key is , where . Hence, we can prove the security of the protocol by proving the security of .

For ease of understanding, the negotiation process of in the protocol is assumed to be the negotiation process of and in domain to generate .

Suppose , , and are treated as random oracles owned by . is a DDH oracle, which outputs 1 if , otherwise 0. Assume that makes at most queries to (), , queries to , queries to , queries to , queries to , queries to , queries to , queries to , and queries to . Assume also that bounded running time of query () is , is , is , is , is , is , is , is , is , and is .

The challenger maintains the query lists as follows:

: a tuple of ()

: a tuple of

: a tuple of

: a tuple of

(): a tuple of ()

Given an instance of the GDH problem, for unknown by giving and an oracle DDH, compute .

Lemma 7. Suppose win the game in case FI1 with advantage and running time , with the help of ; an algorithm can be constructed to solve the above instance of the GDH problem with advantage and running time by interacting with .

Proof. To interact with , a GDH slover simulates as and runs the following steps to solve the above instance of the GDH problem with the help of :
(C1) executes the SETUP algorithm and sends system params to .
(C2) Suppose that will choose for challenge in the next step. asks the for a polynomial number of the queries.
: on receiving , performs as follows: (1)If contains a tuple of , returns all the elements of the tuple to (2)Otherwise, randomly chooses and then computes and ; inserts to and () to and returns to All the following queries should be asked after .
query: on receiving , after query , there must be a tuple of () in ; returns to .
query: on receiving , if contains a tuple of , returns to . Otherwise, randomly chooses that has not been chosen by and inserts to and returns to .
: on receiving , returns to from .
: on receiving , returns to from .
: returns to .
: on receiving , computes and updates all the tuples with ,
: (1)If , , or , , and (a)If , , and , sets , inserts to , and returns to (b)If , , and, sets , inserts to , and returns to (2)Otherwise,(a)if () contains a tuple of (), returns to (b) randomly chooses , computes , inserts to , and returns to : If the matched session of exists, this query should be asked after and when gets and . (1) gets from and and sets , and returns from and (). That is, initiates the session with message and gets respond with of the matched session (2)If , gets , , , and from and and initiates the session with . Then, gets from as the message of the matched session query: on receiving (1)If contains a tuple of , returns to (2)Otherwise, randomly chooses that has not been chosen by and inserts to and returns to : (1)If and , gets from ; gets , , , , , , , and from , , and ; computes ; and checks whether or not. If they are equal, returns from . Otherwise, sets , randomly chooses that has not been chosen by and inserts to , and returns to (2)Otherwise, returns to (C3) asks a test () query; the challenger performs as follows: (1)gets , , , , , , , and from , , and () where (2) computes with the candidate solution of and gets from with (3) picks randomly If , replies to ; otherwise, replies as a random string to (C4) asks the for a polynomial number of the queries about fresh session .
(C5) makes a guess bit .
wins the game in case FI1 by guessing . After the test () query, asks query with . gets in and asks RDDH oracle with ,). If with the probability of , the above RDDH oracle will return 1; then, can get and compute with Let be the time for one scalar multiplication operation and be the point addition operation over elliptic curve. The time to compute is .
Then, if win the game in case FI1 with advantage and running time , then an algorithm can be constructed to solve the GDH problem with advantage and running time by interacting with only if the game is completed, where events and occur.
: chooses for challenge.
: .
Meanwhile, event occurs which means all of the events , , and occur.
chooses participants and for the challenge with and query.
: makes query or.
: makes query and query.

Lemma 8. The same as Lemma 7 but in case FI2.

Proof. To interact with , a GDH slover runs the same steps as that in Lemma 7 to solve the instance of the GDH problem. asks the for a polynomial number of the queries as shown in Lemma 7; answers the following queries differently:
: on receiving , performs as follows: (1)If contains a tuple of (a)If , returns all the elements of the tuple to (b)Otherwise, returns to (2)Otherwise,(a)if , randomly chooses and then computes and ; inserts to and () to and returns to (b) randomly chooses and computes and (I = A when ; I=B when ); inserts to and () to and returns to : on receiving , performs as follows: (1)If , returns from to (2)Otherwise, returns to : (1)If contains a tuple of (), returns to (2)Otherwise, randomly chooses , computes , inserts to (), and returns to Moreover, the first step of (C3) is also different with that of Lemma 7.
(C3) asks a test () query; the challenger performs as follows: (1)gets , , , , , , , , , , , , , and from , , , and () where gets with

Lemma 9. The same as Lemma 7 but in case FI3.

Proof. To interact with , a GDH slover runs the same steps as that in Lemma 7 to solve the instance of the GDH problem. asks the for a polynomial number of the queries as shown in Lemma 7; answers the following queries differently:
: on receiving , performs as follows: (1)If contains a tuple of (a)If , returns all the elements of the tuple to (b)Otherwise, returns to (1)Otherwise,(a)if , randomly chooses and then computes and ; inserts to and () to and returns to (b) randomly chooses , and computes and ; inserts to and () to and returns to : on receiving , performs as follows: (1)If , returns from to (2)Otherwise, returns to : (1)If , , and , sets , inserts to , and returns to (2)Otherwise,(a)if () contains a tuple of (), returns to (b) randomly chooses , computes , inserts to , and returns to Moreover, the first step of (C3) is also different with that of Lemma 7.
(C3) asks a test () query; the challenger performs as follows: (1)