On-Demand Anonymous Access and Roaming Authentication Protocols for 6G Satellite–Ground Integrated Networks

Satellite–ground integrated networks (SGIN) are in line with 6th generation wireless network technology (6G) requirements. However, security and privacy issues are challenging with heterogeneous networks. Specifically, although 5G authentication and key agreement (AKA) protects terminal anonymity, privacy preserving authentication protocols are still important in satellite networks. Meanwhile, 6G will have a large number of nodes with low energy consumption. The balance between security and performance needs to be investigated. Furthermore, 6G networks will likely belong to different operators. How to optimize the repeated authentication during roaming between different networks is also a key issue. To address these challenges, on-demand anonymous access and novel roaming authentication protocols are presented in this paper. Ordinary nodes implement unlinkable authentication by adopting a bilinear pairing-based short group signature algorithm. When low-energy nodes achieve fast authentication by utilizing the proposed lightweight batch authentication protocol, which can protect malicious nodes from DoS attacks. An efficient cross-domain roaming authentication protocol, which allows terminals to quickly connect to different operator networks, is designed to reduce the authentication delay. The security of our scheme is verified through formal and informal security analysis. Finally, the performance analysis results show that our scheme is feasible.


Introduction
The fifth generation (5G) of wireless communication technology has promoted the development of the Internet of Things, automatic driving, virtual reality [1], etc. However, challenges still exist [2,3]. Although the terrestrial network has developed unprecedentedly, the seamless coverage of global heterogeneous networks has not been achieved. It is difficult for users to enjoy high-quality network services in many underserved areas (such as mountains, oceans, etc.) and in more than 50% of countries [4]. Oriented toward the 6G network, satellite-ground integrated networks (SGIN), which could provide global coverage and integrated management of satellite and terrestrial networks, have become a hot topic of current research [5][6][7]. In recent years, Amazon, SpaceX, and other major manufacturers are making great efforts to build satellite networks, which are expected to form a satellite communication system with a network capacity of 10 Tbps [8], providing reliable communication services for SGIN. With 6G, satellites will obtain more computing power through mobile edge computing (MEC) [9] and they will therefore be able to undertake heavier computing tasks.
Nevertheless, due to the high cost of satellite launches and maintenance, it is difficult for large satellite operators to hold all the satellites. There will still be many satellite operators maintaining a small number of satellites and providing personalized services. Since the information in a SGIN is transmitted through a public wireless channel, the user's information is vulnerable to malicious attacks. Access authentication is the first step for UE to connect to the core network, so as to guarantee mutual authentication, forward and backward security, and be resistant to typical attacks. Unlike existing terrestrial networks, there is a large propagation delay (more than 10 ms) between satellite and terrestrial networks. In the traditional satellite network authentication scheme, the satellite generally transmits the forwarding messages [10], which causes a transmission delay in communication at least four times that of satellite and terrestrial networks [11]. Therefore, addressing efficient and secure authentication in SGINs is the first issue. Since the information in a SGIN is transmitted through a public wireless channel, the user's information is vulnerable to malicious attacks. Access authentication is the first step for UE to connect to the core network, so as to guarantee mutual authentication, forward and backward security, and be resistant to typical attacks. Unlike existing terrestrial networks, there is a large propagation delay (more than 10 ms) between satellite and terrestrial networks. In the traditional satellite network authentication scheme, the satellite generally transmits the forwarding messages [10], which causes a transmission delay in communication at least four times that of satellite and terrestrial networks [11]. Therefore, addressing efficient and secure authentication in SGINs is the first issue.
To make things even more challenging, heterogeneous devices need to be authenticated in this network. Based on our above architecture, the different types of user equipment and their diverse security requirements pose great challenges to the research of SGIN access authentication. At present, terrestrial networks usually use the authentication and key agreement (AKA) protocol to implement UE access authentication. The 5G AKA proposes to protect the privacy of users by encrypting their permanent identity and transmitting encrypted SUCI. However, there is no privacy authentication for heterogeneous terminals that access via satellite networks. For diverse users in SGIN, a targeted authentication model is required. For example, for IoT nodes with a large scale and relatively weak computing power, anonymous batch authentication with lower complexity is needed to achieve a faster speed. However, the existing batch authentication schemes do not effectively protect user privacy [11] or incur excessive costs [12]. While individual endusers are more computationally capable and care a lot about their privacy and security, they can choose protocols with higher security and better protect their privacy. That is to say, it is difficult to unify these users with different needs.
Meanwhile, due to the existence of multiple operators, SGIN secure roaming authentication also deserves attention. The current situation of many large satellite service providers (such as SpaceX and OneWeb) [13,14] as well as small providers cannot achieve continuous global coverage of signals, which causes many inconveniences for UE to enjoy diverse and stable services. As mentioned above, different network services in 6G may be provided by various operators, and the core network (CN) of satellite and terrestrial networks may be disparate. If a new satellite or terrestrial base station providing service to a subscriber originates from a different operator, the new operator needs to perform roaming authentication with the subscriber. However, the existing 3GPP roaming authentication approach [15] is not applicable for SGINs, because satellite transmission will bring significant time delays. How to provide fast multi-operator cross-network roaming authentication for subscribers is also a key challenge.
Motivated by these challenges, we present an on-demand authentication protocol model for SGINs. In the model, we propose protocols for mutual authentication of UE and satellites, to reduce transmission overheads. Our protocols propose different access authentication scenarios for different users' performance and security requirements, so that UE can have on-demand access. Among these, UE privacy is protected to different degrees. In addition, a roaming authentication protocol is proposed for cross-domain roaming by different operators, in line with the mutual authentication between the UE and satellite. Compared with other related works, we give consideration to authentication and roaming, and provide on-demand access authentication for terminals with different abilities and needs. The contributions of this paper are as follows: • On-demand privacy-preserving authentication protocols for SGIN: We propose an on-demand access authentication protocol for satellite networks in SGINs based on the protocol architecture. For UE with high security and privacy requirements, an anonymous unlinkable authentication protocol is proposed which ensures UE's unlinkability. For large numbers of UE with demand for short delay times, a batch authentication protocol is proposed. The protocol supports rebatch authentication after authentication failure and can effectively alleviate DoS attacks. • A lightweight roaming authentication protocol for SGIN: The roaming authentication protocol provides a strategy for roaming between different operator networks for satellite-connected UE in SGINs, which needs to pre-negotiate with the corresponding core network after the last authentication is completed. The UE only needs to complete mutual authentication with the satellite when roaming, thus reducing the propagation delay.
The remainder of this article is organized as follows: We review the related work in Section 2. Then, we introduce the prior knowledge involved in the protocol and SGIN system model in Section 3. The details of our scheme are presented in Section 4. The security of the proposed scheme is proven in Section 5. We compare the performance of related schemes in Section 6. Finally, we summarize the article in Section 7.

Related Work
In recent years, researchers have made many contributions to the access authentication of SGINs. Nguyen et al. [2] provided a systematic overview of 6G security and privacy issues. They analyzed the security architecture of 6G and considered the new open authentication protocols (e.g., satellite, sea area) for non-3GPP networks, as one of the priorities for 6G network access security. Zhao et al. [16] made use of the broadcasting function of satellites to propose an efficient and lightweight access authentication scheme, to prevent the burden of "message storms" on satellite authentication. Cui et al. [17] proposed an authentication scheme for heterogeneous B5G networks (including satellite networks) and proposed a user detection scheme based on trust evaluation. Guo et al. [18] proposed an anonymous mutual authentication scheme based on RLWE, which can resist attacks based on quantum computing and guarantee efficiency and security in the post-quantum era. Yao et al. [19] proposed a mutual authentication protocol named IMAS, which introduced group management forms to the satellite, to accomplish the multicast authentication between UE and satellites. Guo et al. [20] proposed an access authentication protocol based on elliptic curve cryptography (ECC), which included three entities: the UE, satellite, and ground station. In addition, the scheme designed a batch handover scheme to reduce overheads.
In the face of the high privacy requirements of users of 6G, anonymous authentication based on aliases or group signature authentication can be used. Although the alias mechanism [21] has good performance in information transmission and privacy protection, users need to store a large number of certificates, which leads to a large amount of overheads [22]. The traditional group signature message will bring some transmission overheads. Boneh et al. [23] proposed a short group signature (SGS) scheme, which allows bilinear pairing to be widely used in modern cryptography. Wasef and Shen [12] proposed a batch authentication scheme based on SGS, so that SGS can be applied to a large number of user authentication scenarios. Alamer [24] proposed a scheme to transform the SGS signature algorithm into a signcryption algorithm, which ensures message integrity and confidentiality.
Owing to the large number of user nodes, researchers have proposed batch authentication. Huang et al. [25] proposed a fast anonymous batch authentication scheme for vehicle networking, which can verify multiple requests at a time and negotiate a session key with the vehicle through broadcast messages. Considering that a failure of batch authentication will lead to the failure of all authentication of a batch of nodes, the author also proposed to rebatch authentication to prevent possible DoS attacks. Lai et al. [26] proposed a lightweight group authentication scheme for M2M networks, and the UE in their scheme can also accomplish rebatch authentication by dichotomizing. Mahmood et al. [27] proposed ECC-based lightweight security without using a batch verification method (LSWBVM). Their method can authenticate a large number of request messages and verify messages one by one.
Due to the presence of multiple SGIN operators, cross-domain roaming authentication has become a research direction. Xue et al. [28] proposed a lightweight group key negotiation protocol based on (t, n) secret sharing and proposed a cross-domain handover authentication scheme. Considering the problems of different operators in the converged network, Liu et al. [29] proposed a decentralized anonymous authentication scheme applied to the cross-operator satellite service scenario, which can carry out cross-domain fast handover authentication and ensure the fairness of billing. Yang et al. [30] proposed an authentication scheme based on group signatures and completed cross-domain roaming of users through advanced negotiation between ground stations and satellites. Guo et al. [31] proposed a new secure roaming authentication and key negotiation protocol called SRAKN, which enables efficient and fast roaming between users, satellites, and foreign terrestrial control stations (FTCS), and finally negotiates secure session keys. Yang et al. [32] proposed a fast handover authentication protocol for high-speed mobile terminals for railways in SGINs. Their method forms a temporary group of terminals in the same compartment and completes the handover based on preset information. Table 1 shows a summary of the Sensors 2023, 23, 5075 5 of 23 related works described in this paper. We study their schemes according to four aspects of these related works: performance objective, algorithm/scheme, scenario, and motivation.

Preliminaries and System Model
In this section, we first review the mathematical preliminaries of our scheme, including bilinear pairing and ECDSA. Then, we present the system model and security requirements for SGIN networks. In particular, we describe the model of the SGIN protocol in detail. We describe the security model adopted by the SGIN system and provide security requirements to meet the security assumptions.

Bilinear Pairing
Let G be the addictive cyclic group of the prime order q and G T be the multiplicative cyclic group of the same prime order q. Let P be a generator of group of G. The bilinear pairingê : G × G → G T satisfies: • Bilinearity:ê(aP, bQ) =ê(P, Q) ab , where a, b ∈ Z * q and P, Q ∈ G; • Nondegeneracy: ∃P, Q ∈ G, letê(P, Q) = 1; • Computability: ∀P, Q ∈ G,ê(P, Q) can be calculated efficiently.

ECDSA
The elliptic curve digital signature algorithm (ECDSA) is a simulation of the digital signature algorithm (DSA) based on the elliptic curve cryptography (ECC) algorithm. Let q, P be the public parameters as discussed above. ECDSA can be divided into the following three steps [33]: • ECKeyGen(·): Select a random integer k as the private key, where k ∈ [1, q − 1]. Compute the public key K = kP. The entity can obtain the key pair (k, K). , (x , y ) = h · S −1 P + R · S −1 K and R = x mod q. If R = R, the entity can accept the signature.

System Model
Referring to the overall architecture shown in Figure 1, the satellite network members for the SGIN in this article include the UE, regenerative LEO with gNB-DU (distributed unit), GS with gNB-CU (centralized unit), and NCC; the terrestrial network members include the UE, gNB, and 6GC. Due to the heterogeneous 6G environment and different user needs, we put forward two different scenarios of satellite network access: (1) An Unlinkable Authentication Scenario, which requires higher anonymity and unlinkability, based on a short group signature [23]; (2) a Batch Authentication Scenario, which includes massive lightweight UE, where their requirement for anonymity is relatively low. We designed different access authentication protocols for the two scenarios. The UE can select corresponding authentication modes based on their requirements. In addition, the proposed scheme provides roaming authentication methods for users who need to roam across domains.
The protocol model of the SGIN is shown in Figure 2. The protocol involved in this paper is represented by orange lines. The dashed lines mean that the channel between two entities is insecure, and the solid lines are the contrary. The UE, connected to the satellite, can access the NCC through the two protocols designed in the following section. In addition, since regenerative satellites are equipped with gNBs, the UE can also access the 6G core network through regenerative satellites, transparent satellites, or gNBs, using the AKA protocol. When it is necessary to handover satellites due to their movement, the satellites plan the handover strategy independently. This process is transparent to the UE. When the UE needs to roam between networks of the same operator or roam across the networks of different operators, they have to use the protocols of the presented roaming authentication phase according to the situation. The protocol architecture aims to address the required access methods and performance for heterogeneous terminals.

Security Requirement
The proposed protocol has the following security assumptions: • Assuming that the NCCs and 6GCs are trusted by UE, LEOs, and GSs. During th initialization phase, NCCs can send secret parameters for future use to the UE and LEOs over trusted channels (e.g., offline channels); • Assuming that during satellite authentication, the channels between NCCs and GSs GSs and LEOs, and NCCs and NCCs are trusted, it can be built using SSL or TLS While using AKA, the satellite channels from UE to gNBs are untrusted, and th channels between gNBs and 6GCs are trusted; • It is assumed that no trust relationship has been established between the UE and LEOs before access authentication; • It is assumed that in an unlinkable authentication scenario, regenerative LEOs may track the message of the UE and try to reveal its real information; • The proposed protocol also needs to meet the following security requirements: • Forward and Backward Secrecy: Due to the changes in the geographical location and requirements of UE, the proposed scheme should ensure forward and backward se curity; that is, an attacker cannot obtain the current session key through the infor mation of the previous session [34]. In addition, if the current session is compro mised, the attacker cannot affect the security of the previous channel [35]; • Mutual Authentication: The proposed scheme should satisfy mutual authentication that is, regenerative LEOs can detect and refuse access to an illegal UE. In addition, a UE can also know the legitimacy of access nodes in the system, to avoid potentia malicious attacks; • Key Establishment: The proposed scheme should ensure that the session keys nego tiated by the protocol are only shared between the UE and regenerative LEOs; • User Privacy: In the unlinkable authentication scenario, the UE requires unlinkabil ity; that is, others cannot know whether the information comes from the same UE. In the batch authentication scenario and roaming authentication phase, the UE is linka ble, but others will not be able to learn its identity information.

Security Requirement
The proposed protocol has the following security assumptions: • Assuming that the NCCs and 6GCs are trusted by UE, LEOs, and GSs. During the initialization phase, NCCs can send secret parameters for future use to the UE and LEOs over trusted channels (e.g., offline channels); • Assuming that during satellite authentication, the channels between NCCs and GSs, GSs and LEOs, and NCCs and NCCs are trusted, it can be built using SSL or TLS. While using AKA, the satellite channels from UE to gNBs are untrusted, and the channels between gNBs and 6GCs are trusted; • It is assumed that no trust relationship has been established between the UE and LEOs before access authentication; • It is assumed that in an unlinkable authentication scenario, regenerative LEOs may track the message of the UE and try to reveal its real information; • The proposed protocol also needs to meet the following security requirements: • Forward and Backward Secrecy: Due to the changes in the geographical location and requirements of UE, the proposed scheme should ensure forward and backward security; that is, an attacker cannot obtain the current session key through the information of the previous session [34]. In addition, if the current session is compromised, the attacker cannot affect the security of the previous channel [35]; • Mutual Authentication: The proposed scheme should satisfy mutual authentication; that is, regenerative LEOs can detect and refuse access to an illegal UE. In addition, a UE can also know the legitimacy of access nodes in the system, to avoid potential malicious attacks; • Key Establishment: The proposed scheme should ensure that the session keys negotiated by the protocol are only shared between the UE and regenerative LEOs; • User Privacy: In the unlinkable authentication scenario, the UE requires unlinkability; that is, others cannot know whether the information comes from the same UE. In the batch authentication scenario and roaming authentication phase, the UE is linkable, but others will not be able to learn its identity information.

The Proposed Scheme
In this section, we give a detailed description of the scheme, which consists of four phases: an initialization phase, anonymous authentication phase, roaming authentication phase, and user revocation phase. Without losing generality, and in order to be more intuitive, we will only focus on a certain set of UE and the corresponding LEOs.

Initialization Phase
In the initialization phase, the satellite core network servers (i.e., NCCs) first input the security parameter λ ∈ N and generate the system master key s ∈ Z * q . Then, the NCC generates (sk LEO , pk LEO ) for LEOs based on ECC. Moreover, the NCC outputs the public parameter params = q, G, G T , P, g,ê, H 1 , H 2 , where G is the addictive cyclic group with the generator element (P, g) and the order q, G T is the multiplicative cycle group with the same order q,ê is the bilinear pairingê : G × G → G T , and H 1 : q are hash functions. At the same time, the 6GC completes the initial key configuration with the UE. The detailed access authentication protocols for terrestrial networks are beyond the scope of this paper.
After generating the public parameter, the NCC implements Algorithm 1 to generate the group public key gpk : g, h, u, v, ω and group master secret key gmsk : ξ 1 , ξ 2 , in which gpk needs to be published in an open channel and gmsk needs to be kept secret by the NCC. For each UE i in the group, the NCC generates gsk i : ID i , ϕ i , A i and sends gsk i to the corresponding UE. The UE needs to use gsk i as its private key and not disclose it to anyone.

Algorithm 1: Initialization
Input: a group of user identity, a number of users N Output: Select random numbers u, v, h ∈ G 2: Select random numbers ξ 1 , Sets ω = γg 4: for all UE i with identity ID i do 5: Select a random number ϕ i ∈ Z * q 6: Additionally, the NCC generates the necessary parameters for batch authentication. The steps for batch authentication initialization are shown below: NCC selects a random number ε LEO ∈ Z * q for each LEO, and generates a batch master key BMK = s −1 P and batch public key BPK LEO = ε LEO P for LEOs. The LEOs should keep BMK and ε LEO secret.

2.
The NCC selects a random number x i ∈ Z * q for each UE i . Then, the NCC calculates the batch authentication key BK i = x i sP, RK i = e(x i P, P) for the UE. Therefore, the batch authentication key of UE i is buk i : BK i , RK i , and the UE should keep buk i secret.
Finally, the NCC sends (ε LEO , BMK, BPK LEO , sk LEO , pk LEO ) to the LEOs over a secure channel (e.g., offline channel). Additionally, the NCC sends (gsk i , gpk, buk i ) to the corresponding UE securely, and saves ID i and gsk i in a local user key list (UKL).

Anonymous Authentication Phase
In this section, we show two scenarios according to the different needs of the UE: an unlinkable authentication scenario and batch authentication scenario. Each UE gives all the key information required for the two scenarios during the initialization phase, so it can switch scenarios when needed, without reregistering.

Unlinkable Authentication Scenario
In this scenario, we refer to Boneh's [23] short group signature (SGS) algorithm, which is one of the most famous group signatures. The UE in SGS can randomly generate a temporary identity (TID) that is irrelevant to the real ID i . Owing to the unlinkable anonymity of SGS, the UE can use different TIDs in different sessions, and no other entity knows that these TIDs belong to the same UE. The specific protocol process is shown in Figure 3, and its steps are as follows: 1.
When the UE wants to access the NCC, the message M i = (TID i ||ID LEO ||g r 1 ||TS 1 ) needs to be constructed, where r 1 ∈ Z * q is a random number, g r 1 is part of the session key, and TS 1 is a timestamp that can resist reply attacks. Taking M i , gpk, and gsk i as input, the UE implements Algorithm 2 and obtains the signature can be calculated and stored in advance. When the UE needs to revote its secret keys, it needs to recalculatê e Â i , g andê(h,ω). After completing the construction of plaintext and signature, the UE sends (M i , σ i ) to an appropriate LEO.

2.
When receiving s request from the UE, the LEO first authenticates the timestamp TS 1 in the message. The LEO generates the current timestamp TS 1 and verifies where ∆T is adjusted according to different network conditions. If it does not meet the conditions, the LEO returns an error message. Otherwise, the LEO validates the accuracy of the signature using Algorithm 3. If the verification passes, the LEO selects the random number r 2 ∈ Z * q and calculates the session key SK = (g r 1 ) r 2 . If the verification fails, an error message is returned. The LEO signs the message M i = (TID i ||ID LEO ||g r 2 ||TS 2 ) using ECSign M i to obtain the signature σ i . Then, the LEO sends the message M i , σ i to the UE.

3.
After receiving the message, the UE first verifies the validity of the timestamp; that is, whether the timestamp satisfies TS 2 − TS 2 < ∆T. If it is valid, the message will be verified by the ECDSA. If verified, the UE calculates the session key SK = (g r 2 ) r 1 .
The key negotiation between the two sides is complete. In this scenario, we refer to Boneh's [23] short group signature (SGS) algorithm, which is one of the most famous group signatures. The UE in SGS can randomly generate a temporary identity (TID) that is irrelevant to the real . Owing to the unlinkable anonymity of SGS, the UE can use different TIDs in different sessions, and no other entity knows that these TIDs belong to the same UE. The specific protocol process is shown in Figure 3, and its steps are as follows: 1. When the UE wants to access the NCC, the message = ( || || || ) needs to be constructed, where ∈ * is a random number, is part of the session key, and is a timestamp that can resist reply attacks. Taking , , and as input, the UE implements Algorithm 2 and obtains the signature σ = , , , , , , , , , where ( , ) , (ℎ, ) and (ℎ, ) can be calculated and stored in advance. When the UE needs to revote its secret keys, it needs to recalculate ̂ , and (ℎ, ). After completing the construction of plaintext and signature, the UE sends ( , σ ) to an appropriate LEO. 2. When receiving s request from the UE, the LEO first authenticates the timestamp in the message. The LEO generates the current timestamp and verifies − < Δ , where Δ is adjusted according to different network conditions. If it does not meet the conditions, the LEO returns an error message. Otherwise, the LEO validates the accuracy of the signature using Algorithm 3. If the verification passes, the LEO selects the random number ∈ * and calculates the session key = ( ) .
If the verification fails, an error message is returned. The LEO signs the message = ( || || || ) using ( ′) to obtain the signature σ . Then, the LEO sends the message ( ′, ′) to the UE. 3. After receiving the message, the UE first verifies the validity of the timestamp; that is, whether the timestamp satisfies − < Δ . If it is valid, the message will be verified by the ECDSA. If verified, the UE calculates the session key = ( ) .
The key negotiation between the two sides is complete.

Batch Authentication Scenario
The traditional short group signature scheme uses a batch group signature (BGS) to complete batch authentication. However, due to the insufficient computing power of some devices in 6G heterogeneous networks and the massive terminals, we designed a novel batch authentication protocol to meet the needs of these terminals. In this scenario, users can generate a TID, but it is traceable. A set of UE send their batch authentication message to the LEO, which authenticates all parameters uniformly. If the first batch authentication is successful, the LEO authenticates them and continues the authentication process. If the first authentication fails, a rebatch is required. The specific protocol process is shown in Figure 4, and the detailed steps are as follows: 1.
The UE selects random numbers r 1 , . Then, the UE receives the signature of batch authentication σ i = (BAK i , RAK i ). After signing the message, the UE sends (M i , σ i ) to the target LEO; 2.
When the LEO receives (M i , σ i ) from the UE, it first checks the validity of the timestamp TS 1 . If TS 1 is legal, the LEO sets , then calculates the following equation: If Equation (1) is true, n UE in the batch authentication group is valid. Otherwise, it means that there are invalid messages in this group. Batch authentication has the advantage of reducing the computational overheads, but once an invalid request occurs in a batch, the authentication will fail. When a malicious attacker continuously sends invalid information to implement DoS attacks, users may be unable to complete authentication for a long time. Therefore, a rebatch is required to protect the UE's QoS. The algorithm of "divide-and-conquer" (BVDC) [25] can be used. The LEO can use dichotomous validation for a batch authenticated UE, to find the UE that failed validation and return error messages. Although the rebatch may bring computation overheads, it is helpful for improving the overall system efficiency and increasing the verification success rate.

3.
For UE that passes the authentication, the LEO constructs M i = (TID i ||ID LEO ||g r 2 ||TS 2 ), where TS 2 is a timestamp, g r 2 is a session key parameter generated by LEO, and r 2 ∈ Z * q is a number randomly generated. The LEO uses ECSign M i to generate the signature σ i and send M i , σ i to the UE.

4.
After receiving the message, the UE first verifies the validity of the timestamp. The message is then verified by ECVeri f y M i , σ i . If the verification is successful, the UE calculates the session key SK = (g r 2 ) r 1 , and the LEO calculates the session key SK = (g r 1 ) r 2 . The key negotiation between the two sides is complete. sends invalid information to implement DoS attacks, users may be unable to complete authentication for a long time. Therefore, a rebatch is required to protect the UE's QoS. The algorithm of "divide-and-conquer" (BVDC) [25] can be used. The LEO can use dichotomous validation for a batch authenticated UE, to find the UE that failed validation and return error messages. Although the rebatch may bring computation overheads, it is helpful for improving the overall system efficiency and increasing the verification success rate. 3. For UE that passes the authentication, the LEO constructs ′ = ( || || || ) , where is a timestamp, is a session key parameter generated by LEO, and ∈ * is a number randomly generated. The LEO uses

Roaming Authentication Phase
When the UE needs to roam across the network, due to changes in geographical location or network conditions, the roaming authentication phase can be completed. The proposed scheme designs a lightweight roaming authentication protocol to meet the needs of UE. For UE that need to change core network, they must be re-authenticated and negotiate a new session key. To reduce the overheads of roaming authentication, the UE should perform pre-negotiation after the initial authentication or the last roaming.
Pre-negotiation Phase: The UE first collects optional satellite information, and then sends its and to the source core network, namely sCN (i.e., NCCs or 6GCs) through the sLEO, to request roaming authentication tokens. After receiving the UE's request information, the sCN selects the generation key . Then, sCN calculates = ( ) ( || || || ), where (⋅) is a symmetric encryption function, (⋅) is a key derivation function, is a pre-shared key maintained between the CNs and LEOs, and is the expiration time of the token. A secure channel is established between the UE and sLEO during the authentication phase, and secure channels exist between core networks. The sCN encrypts ( , , ) using the key stored

Roaming Authentication Phase
When the UE needs to roam across the network, due to changes in geographical location or network conditions, the roaming authentication phase can be completed. The proposed scheme designs a lightweight roaming authentication protocol to meet the needs of UE. For UE that need to change core network, they must be re-authenticated and negotiate a new session key. To reduce the overheads of roaming authentication, the UE should perform pre-negotiation after the initial authentication or the last roaming.
Pre-negotiation Phase: The UE first collects optional satellite information, and then sends its TID i and ID tLEO to the source core network, namely sCN (i.e., NCCs or 6GCs) through the sLEO, to request roaming authentication tokens. After receiving the UE's request information, the sCN selects the generation key K 1 . Then, sCN calculates Ticket i = SENC KDF(psk) (TID i ||ID tLEO ||K 1 ||ET), where SENC(·) is a symmetric encryption function, KDF(·) is a key derivation function, psk is a pre-shared key maintained between the CNs and LEOs, and ET is the expiration time of the token. A secure channel is established between the UE and sLEO during the authentication phase, and secure channels exist between core networks. The sCN encrypts (Ticket i , K 1 , ET) using the key K 0 stored between sCN and UE, then returns the message to the UE. When Ticket i expires or the UE discovers new suitable LEOs, the UE needs to apply to the sLEO for new tokens. The LEO updates the token issued to the UE when the LEO or CN evaluates that it is necessary to change the psk. At the same time, if the tLEO does not belong to the sCN as Case ii, the sCN sends the TID i list to the tCN through the channel, then tCN sends TID i to tLEO. Otherwise, sCN sends the TID i list directly to tLEO as Case i. The specific negotiation process is shown in the upper part of Figure 5.

Roaming Authentication Phase:
When the UE needs to roam, the process is as show in the lower part of Figure 5. The following steps need to be completed:

Roaming Authentication Phase:
When the UE needs to roam, the process is as shown in the lower part of Figure 5. The following steps need to be completed:
Upon receiving the message, the tLEO first checks the timestamp then decrypts c 1 using its private key sk tLEO in order to obtain r UE and Ticket i . The tLEO decrypts Ticket i using KDF(psk) and checks the ID and ET in the token. If it does meet the conditions, the tLEO generates v 1 to verify whether it is equal to v 1 . If verified, tLEO generates a random number r tLEO and generates K 2 = KDF(K 1 ||r UE ). Then, the tLEO calculates c 2 = SENC K 2 (r tLEO ), where SENC(m) is a symmetric encryption algorithm. The tLEO selects a random number r 2 ∈ Z * q and sets g r 2 . Finally, the tLEO calculates v 2 = H 1 (ID tLEO ||g r 2 ||r tLEO ||K 2 ||c 2 ||TS 2 ) and sends the message M 2 = (ID tLEO ||g r 2 ||c 2 ||v 2 ||TS 2 ) to the UE, where TS 2 is a timestamp; 3.
While receiving the message, UE first checks the timestamp. If checks, UE calculates K 2 = KDF(K 1 ||r UE ). Then UE decrypts c 2 and gets r tLEO . UE calculates v 2 and checks whether v 2 = v 2 . If it does meet, the new conversation between UE and the tLEO is established. UE and the tLEO get their new session keys SK = (g r 2 ) r 1 and SK = (g r 1 ) r 2 .

User Revocation Phase
In the case that the UE needs to quit the group or the system needs to revoke the illegal UE authentication in the unlinkable authentication, the algorithm in the user revocation phase is needed. For an illegal UE, the NCC has the right to disclose their real ID and other information through signatures they send out. The private key of the illegal UE can be calculated through the group master key gmsk : ξ 1 , ξ 2 and (T 1 , T 2 , T 3 ) in the signature. The NCC can find the real ID i of the UE by comparing with the user information in UKL. For an illegal UE that requests to quit the group, the NCC performs the operations described above. After that, the NCC creates a revocation list (RL) that contains the key ϕ j , A j , RK j of the UE j to be revoked. The NCC sends the RL to each LEO. The LEOs save the RL and periodically broadcast the latest RL', which includes ϕ j , A j .
A UE that receives the RL' updates its private key according to Algorithm 4, where m is the total number of tuples in RL'. Unrevoked UE must run this algorithm until all UEs in RL' are revoked. After completing the above steps, the unrevoked UE needs to update the pre-stored parametersê Â i , g andê(h,ω). In addition, for offline UE, they need to request the latest RL' when they are online. Therefore, the revoked UE j cannot obtain a new gsk j . The authentication will fail when the UE j participates in group signature authentication again. When participating in batch authentication, UE j will also be detected by the LEO, thus prohibiting its access to the network.

Algorithm 4: Unrevoked User Update Parameters
Input: gsk i , RL = x j , A j 1 ≤ j ≤ m Output: ϕ i ,Â i 1: Update g asĝ = A * j = 1 ϕ j +γ g 2: Updateω = g − ϕ j · A j = γ ·ĝ 3: Update the secret key asÂ i = 1 The user revocation process can be carried out offline, which reduces the burden on the UE and prevents delays caused by the LEO checking the RL operation during authentication. The performance analysis of Yang et al. [30] showed that the revocation mechanism of SGS is effective. For the protocol that is unlinkable, this phase allows the UE to exit the group, better managing the network. Although user revocation brings additional computational overheads, it is acceptable and necessary.

Security Verification
In this section, we use the ProVerif tool to conduct formal verification of the protocol. Then, we complete an informal security analysis.

Formal Analysis Using ProVerif
We used the ProVerif tool to formalize the proposed protocol in two parts. ProVerif is an automated protocol verification tool that emulates protocols and validates secure protocols against known active and passive attacks. It can handle various encryption primitives, such as key exchange schemes, hash functions, asymmetric encryption, and symmetric encryption. Since the proposed scheme is based on bilinear mapping, we used equations in ProVerif to add specific rules to analyze the protocol more accurately.
The ProVerif code of the proposed scheme consists of two parts: unlinkable authentication verification and batch authentication verification. The roaming authentication phase is included in each part. All verification results are shown in Figures 6 and 7

Informal Security Analysis
In this section, we analyze important security characteristics of the proposed scheme. In the first four sections, we analyze the security characteristics of the proposed scheme. In the subsequent four sections, we analyze attacks that the proposed scheme can defend against.

Informal Security Analysis
In this section, we analyze important security characteristics of the proposed scheme. In the first four sections, we analyze the security characteristics of the proposed scheme. In the subsequent four sections, we analyze attacks that the proposed scheme can defend against.

Informal Security Analysis
In this section, we analyze important security characteristics of the proposed scheme. In the first four sections, we analyze the security characteristics of the proposed scheme. In the subsequent four sections, we analyze attacks that the proposed scheme can defend against.

Mutual Authentication and Key Establishment
In a SGIN, authentication passes through at least two interactions. In the first step, the UE sends a message to the LEO, and the UE is authenticated by the LEO. In the second step, the LEO returns the signature of the ECSDA to the UE, and the identity of the LEO is proven by the UE. This completes the process of mutual authentication between the UE and LEO. The keys of both the UE and LEO are issued by the trusted NCC during the initialization phase, and the authenticator holds the public keys of the target nodes, such as gpk and pk LEO . Therefore, the fake group members or LEOs cannot be authenticated by the legitimate node.

Session Key Security
In each phase of the proposed scheme, no matter in which scenario, the session key is calculated according to the Diffie-Hellman problem through two random numbers generated by the two entities (i.e., UE and LEO). Calculating the session key without knowing the two generators involves solving the discrete logarithm problem on an elliptic curve. At present, it is computationally infeasible to solve the discrete logarithm problem in polynomial time [36].

3.
Forward/Backward Security New session keys SK = (g r 1 ) r 2 and SK = (g r 2 ) r 1 are negotiated in both authentication and roaming authentication phases of the proposed protocol. There is no computable correlation between the new session key and the session key of other sessions. No entity other than the UE and LEO can calculate the new session key.

Privacy and Untraceability
In SGIN unlinkable authentication scenario, it is difficult for an attacker to know the real identity of a UE through the signature. Unless the attacker can obtain the UE's private key and the UKL stored in the NCC, it cannot reveal the UE's identity. Or in another case, the attacker obtains gmsk. But these are extremely difficult to do for the attacker. From another perspective, anonymity in the unlinkable authentication scenario is conditional. NCC has the right to recover the UE's private key A i of the signature through gmsk, so as to obtain the real identity of the UE. In addition, the anonymity is untraceable, and the UE can use different TID in different sessions, and the attacker cannot associate two different sessions of the same UE through signatures.
In the batch authentication scenario, the UE is traceable due to the existence of RK. However, it is difficult for the attacker to crack the real ID of the UE using the batch authentication key RAK. In addition, the UE in the unlinkable authentication scenario does not send information correlating to batch authentication. Even if the UE is changed, the attacker cannot associate the UE in batch authentication scenario with the UE in the unlinkable authentication scenario.

5.
Resistance to Replay Attacks In each scenario, the entity sends a message M that contains a timestamp TS. The integrity of the timestamp is protected by a signature, so it is difficult for an attacker to tamper with the timestamp. The other entity verifies the timestamp TS − TS < ∆T, where ∆T is the interval that matches the current network condition. Therefore, the authentication party can confirm the freshness of the message and distinguish whether it is under replay attack.

6.
Resistance of Impersonation Attacks Suppose an attacker tries to imitate a legitimate UE, it must have the UE's group private key gsk i , batch private key buk i , or roaming parameters in order to generate a valid signature. However, these private keys are only held by the UE and NCC. It is difficult for the attacker to obtain both private keys. The LEO's private key is only held by the LEO and NCC. If the attacker uses the wrong private key signature, the UE will verify the signature and the validation will fail. In the roaming authentication phase, the attacker needs to obtain the psk, modify the information in the token, and send the token to the UE through the established secure channel to complete the attack. This is also difficult for the attacker.

7.
Resistance to Man-in-the-Middle Attacks An attacker attempting a man-in-the-middle attack attempts to intercept the communication between the UE and LEO and imitate the other party in the conversation. However, due to the resistance of the protocol to impersonation attacks, it is difficult for the attacker to successfully achieve this goal, and they therefore cannot complete man-in-the-middle attacks.

8.
Resistance to Dos Attacks The traditional batch authentication protocol does not support a reauthentication algorithm. Therefore, when an attacker launches a DoS attack, the UE of the whole group cannot perform batch authentication. Thus, the LEO cannot know the specific UE who implemented the DoS attack. The batch authentication scenario of the proposed scheme supports the rebatch process. A legitimate UE can pass the authentication without reauthentication, and the LEO can also find the illegal UE that launched attacks. When the number of illegal operations performed by a UE reaches the threshold, the NCC can revoke them.

Performance Analysis
In this section, the computational complexity and communication overheads of the proposed scheme are analyzed.

Computational Complexity in the Unlinkable Authentication Scenario
In the unlinkable authentication scenario, we compared the protocol with the work of Feng et al. [37], Alamer [24], and Wasef et al. [12]. The operations involved in these protocols are shown in Table 2, where G symbolizes the addictive cyclic group of prime order q, and G T symbolizes multiplicative addictive cyclic group of the same order. Moreover, g 1 , g 2 , g T 1 , and g T 2 are generators, where g 1 , g 2 ∈ G and g T 1 , g T 2 ∈ G T . Parameters a and b are random numbers in Z * q . Table 2. Comparison of operation time overheads.

Operation Description Time Overload (ms)
T Pairing A bilinear pairingê : G × G → G T 1.108615 T Add 1 An addition operation a + b 0.000027 T Add 2 An addition operation g 1 + g 2 0.002787 T Mul 1 A multiplication operation ag 1 0.882037 T Mul 2 A multiplication operation g T 1 g T 2 0.000949

T Exp
An exponentiation operation g a T 0.148430 In order to analyze the performance of each architecture, we designed an experiment based on the OpenSSL library, GMP library, and PBC library and tested on an Ubuntu 20.04.3 64-bit 4 GB virtual machine with 16 GB memory and a 3.20 GHz 8 core AMD CPU hardware configuration. We tested each operation 10,000 times and calculated their average value. The specific cost of each operation is shown in Table 2. As can be seen from Table 2, T Pairing , T Mul 1 , T Exp , T Hash 2 , and T Hash 3 were more time-consuming for all operations. Therefore, in the following analysis of each scheme, attention was only paid to the impact of these five operations on the performance.
A comparison of related works in the unlinkable authentication scenario is shown in Table 3. It should be noted that although a group signature is used, the application scenarios and architectures of these works are different. We only compared the steps of the individual signature and verification. The initialization and registration steps take place before the entire system starts, and their overheads can be excluded from the authentication overhead. Table 3. Computational overloads in the unlinkable authentication scenario.

Signing Verifying
Feng et al. [37] 9T Alamer [24] 12T Mul 1 + 2T Pairing + 2T Exp + T Hash 2 = 15.075187 8T Mul 1 + 3T Pairing + 5T Exp + T Hash 2 = 13.100944 Wasef et al. [12] 11T In order to protect the unlinkability, the proposed protocol cannot directly use the UE's private key when the UE sends signatures to the LEO. Otherwise, other entities could verify the signature through the UE's public key and easily trace it. Since entities can know the identity of the satellite through analysis of the orbit of the satellite, there is no need to protect the privacy of the satellite node. Therefore, the LEO can use a signature algorithm with lower cost (i.e., ECDSA) when it sends signatures to the UE. The computational cost of the ECSDA is only the 1T Mul 1 operation for signature and 2T Mul 1 operations for verification, whose cost is small compared with other signature algorithms. As shown in Table 3, oneway authentication in the proposed scheme requires 19T Mul 1 , 2T Pairing , and 7T Exp . It takes about 20 ms for the signature and verification in the unlinkable authentication scenario, which is less time than the other schemes.

Computational Complexity in the Batch Authentication Scenario
Considering the large number of UEs in some scenarios, it is necessary to reduce the amount of authentication data and the processing time of authentication requests [16]. The batch authentication scenario in the proposed scheme can provide efficient services for these UE and lighten the LEOs' burden. We evaluated the cost of the first batch authentication and the rebatch authentication. We also estimated the computational complexity of the rebatch authentication.
In the evaluation of first batch verification, we compared the proposed scheme with the related works of Xue et al. [11] and Wasef et al. [12]. In order to contrast with the unlinkable authentication scenario, we compared with the work of Wasef et al. [12], based on a batch group signature (BGS). The cost of signing and verifying are shown in Table 4. Although the computational complexity of the signature of the proposed scheme was higher than that of Xue et al.'s work, Xue et al. [11] used a UE private key to complete the signature, and the LEO needs to use the UE's public key to verify the signature. This is detrimental to the privacy protection of the UE, as attackers can easily trace the UE through its public key. Therefore, based on security and privacy considerations, our scheme is more suitable for the proposed SGIN scenario. Additionally, Figure 8 shows that the verification cost of the three schemes varies with the increase in the number of authentication requests. It can be seen that the cost of the proposed scheme is significantly less than that required for BGS and the work of Xue et al. [11]. Table 4. Computational overload in the batch authentication scenario.
In terms of rebatch authentication, it is assumed that there is at most a 1% vulnerable UE in a group containing 1000 UE for batch authentication, then the maximum number of UEs breached in this group is = × 1% = 1000 × 1% = 10. Given that the number of request messages in a batch is , the probability that requests contain exactly invalid requests can be expressed using the hypergeometric distribution as Assuming that event means rebatch authentication is required to successfully verify valid requests, the probability of event can be expressed as According to Equation (3), when there are only one or two invalid requests ( = 1 or = 2) in a batch, the probability of rebatch authentication is extremely small. However, in the case of DoS attacks by malicious UEs, rebatch authentication can protect a legitimate UE from authentication failure for a long time.
The proposed scheme in the first authentication needs and 1 operation. The LEO calculates ℎ ⊕ ( || || ) for each UE in the first authentication phase, thus only the operation is required. Therefore, the computational cost of the worst and average cases of rebatch authentication is analyzed below: 1. Worst case: According to the rebatch algorithm proposed by Huang et al. [25], we assume that the worst case is where invalid requests are always in the detected batch. Assuming there are requests in a batch, it takes ⌈log ⌉ times the calculation in the worst case. Therefore, the worst-case total batch validation time for a valid request is Xue et al. [11], BGS [12].
In terms of rebatch authentication, it is assumed that there is at most a 1% vulnerable UE in a group containing 1000 UE for batch authentication, then the maximum number of UEs breached in this group is N ckd = N all × 1% = 1000 × 1% = 10. Given that the number of request messages in a batch is N req , the probability that N req requests contain exactly i invalid requests can be expressed using the hypergeometric distribution as Assuming that event A means rebatch authentication is required to successfully verify valid requests, the probability of event A can be expressed as According to Equation (3), when there are only one or two invalid requests (i = 1 or i = 2) in a batch, the probability of rebatch authentication is extremely small. However, in the case of DoS attacks by malicious UEs, rebatch authentication can protect a legitimate UE from authentication failure for a long time.
The proposed scheme in the first authentication needs nT Exp and 1T Pairing operation. The LEO calculates h i (RAK i ⊕ H 1 (B i ||U i ||TS 1 )) for each UE in the first authentication phase, thus only the T Pairing operation is required. Therefore, the computational cost of the worst and average cases of rebatch authentication is analyzed below: 1.
Worst case: According to the rebatch algorithm proposed by Huang et al. [25], we assume that the worst case is where invalid requests are always in the detected batch.
Assuming there are n requests in a batch, it takes log 2 n times the calculation in the worst case. Therefore, the worst-case total batch validation time for a valid request is where T wst is the time required for the worst case, T f st is the time required for the first batch verification, and T reb is the time required for completion of the rebatch algorithm.

2.
Average case: Calculating the total validation cost in all cases divided by the number of possible cases gives the validation time required for the average case: T ave = T f st + 1 Figure 9 shows the total validation complexity for the worst case, average case, and first batch authentication with 0 to 1000 UE requests. As can be seen from the figure, although the complexity of rebatch authentication in the worst case is relatively high, the cost of rebatch authentication in the average case is close to the complexity of the initial batch authentication, and the computational complexity does not increase rapidly with the increase of the number of requests. Considering the possibility of DoS attacks leading to large-scale UE authentication failure, rebatch authentication is necessary. where wst is the time required for the worst case, fst is the time required for the first batch verification, and reb is the time required for completion of the rebatch algorithm. 2. Average case: Calculating the total validation cost in all cases divided by the number of possible cases gives the validation time required for the average case: (5) Figure 9 shows the total validation complexity for the worst case, average case, and first batch authentication with 0 to 1000 UE requests. As can be seen from the figure, although the complexity of rebatch authentication in the worst case is relatively high, the cost of rebatch authentication in the average case is close to the complexity of the initial batch authentication, and the computational complexity does not increase rapidly with the increase of the number of requests. Considering the possibility of DoS attacks leading to large-scale UE authentication failure, rebatch authentication is necessary.

Computational Complexity in Roaming Authentication
In the process of roaming authentication, we use symmetric encryption to ensure the efficiency of the scheme. The AES CBC algorithm was tested using OpenSSL library in the same environment. We tested the symmetric encryption and decryption algorithms 10,000 times and took their average values: the encryption algorithm costs 0.000112 ms, and the decryption algorithm costs 0.000110 ms. Assuming that the times required for symmetric encryption of the AES algorithm are and , and compared with the overheads in Table 2, they are negligible. In order to be consistent with the anonymous authentication phase, roaming authentication uses the same session key generation method. The proposed roaming authentication protocol involves 2 operations to negotiate the session key. It was assumed that the time required for the encryption algorithm in asymmetric encryption is and the time required for the decryption algorithm is . After 10,000 calculations using the OpenSSL library, the average value was obtained: = 0.015079 ms, = 0.028344 ms. Then the computational cost required for the UE to send a message to LEO was = 0.148430 ms. The computational cost for the LEO to send a message to the UE was + = 0.176774 ms. It was shown that the total roaming authentication calculation cost is far less than the cost of re-authentication.

Communication Overhead Analysis
According to the simulation results, the size of elements and in and * are both 16 bytes. Assuming that the identity length and time message length are both 12 bytes. The hash function length is 32 bytes.

Computational Complexity in Roaming Authentication
In the process of roaming authentication, we use symmetric encryption to ensure the efficiency of the scheme. The AES CBC algorithm was tested using OpenSSL library in the same environment. We tested the symmetric encryption and decryption algorithms 10,000 times and took their average values: the encryption algorithm costs 0.000112 ms, and the decryption algorithm costs 0.000110 ms. Assuming that the times required for symmetric encryption of the AES algorithm are T senc and T sdec , and compared with the overheads in Table 2, they are negligible. In order to be consistent with the anonymous authentication phase, roaming authentication uses the same session key generation method. The proposed roaming authentication protocol involves 2T Exp operations to negotiate the session key. It was assumed that the time required for the encryption algorithm in asymmetric encryption is T aenc and the time required for the decryption algorithm is T adec . After 10,000 calculations using the OpenSSL library, the average value was obtained: T aenc = 0.015079 ms, T adec = 0.028344 ms. Then the computational cost required for the UE to send a message to LEO was T Exp = 0.148430 ms. The computational cost for the LEO to send a message to the UE was T aenc + T Exp = 0.176774 ms. It was shown that the total roaming authentication calculation cost is far less than the cost of re-authentication.

Communication Overhead Analysis
According to the simulation results, the size of elements L G and L Z in G and Z * q are both 16 bytes. Assuming that the identity length L ID and time message length L T are both 12 bytes. The hash function length L H is 32 bytes.
In the unlinkable authentication scenario, the UE needs to send an LEO signature of 3L G + 6L Z = 144 bytes and plaintext of 2L ID + L G + L T = 52 bytes. When the LEO completes authentication, 84 bytes of information will be returned. The signature information for the schemes of both Feng et al. [37] and Wasef et al. [12] was 3L G + 6L Z = 144 bytes, while the schemes of Alamer [24] required 6L G + 6L Z = 192 bytes. Since other SGS-based schemes have different architectures from the proposed scheme, we tried to unify their certification scenarios and situations for a better analysis. It was assumed that at least the ID and time stamp are required in these schemes. The trust value of the scheme of Feng et al. [37] was 4 bytes according to their article. A comparison of communication overhead from the UE to the access point is shown in Figure 10. As can be seen from the figure, the communication overhead of the proposed scheme was slightly smaller than the schemes of Alamer [24] and Wasef et al. [12], while it was equal to Feng et al. [37]. In the unlinkable authentication scenario, the UE needs to send an LEO signature of 3 + 6 = 144 bytes and plaintext of 2 + + = 52 bytes. When the LEO completes authentication, 84 bytes of information will be returned. The signature information for the schemes of both Feng et al. [37] and Wasef et al. [12] was 3 + 6 = 144 bytes, while the schemes of Alamer [24] required 6 + 6 = 192 bytes. Since other SGS-based schemes have different architectures from the proposed scheme, we tried to unify their certification scenarios and situations for a better analysis. It was assumed that at least the ID and time stamp are required in these schemes. The trust value of the scheme of Feng et al. [37] was 4 bytes according to their article. A comparison of communication overhead from the UE to the access point is shown in Figure 10. As can be seen from the figure, the communication overhead of the proposed scheme was slightly smaller than the schemes of Alamer [24] and Wasef et al. [12], while it was equal to Feng et al. [37]. In batch authentication, the UE needs to send a 4 + 2 + = 64 bytes message to the LEO, and the LEO returns a message of 84 bytes. A comparison was made with the communication overheads of the authentication protocol of Xue et al. [11] and Wasef et al. [12]. The results are shown in Table 5. According to the analysis results, the overall message length of the proposed scheme is shorter than that of the other related works. Assuming that the plaintext length is 16 bytes (i.e., is divisible by 16), then the ciphertext length is 16 bytes in AES encryption. If the plaintext length is 16 + bytes and < 16 , the ciphertext length is 16( + 1) bytes. In the roaming authentication phase, is key with a length = 16 bytes, and the size of is = 16 * ⌈(2 + + )/16⌉ = 64 bytes. Due to the use of symmetric encryption for key negotiation, we needed to calculate its communication cost separately. The size of sent by UE to LEO is = 16⌈( + )/16⌉ = 80 bytes, and the total message length is + + + + = 152 bytes. The size of is = 16 * ⌈( + )/16⌉ = 32 bytes, the message size sent by the LEO to the UE is + + + + = 104 bytes. Despite In batch authentication, the UE needs to send a 4L G + 2L ID + L T = 64 bytes message to the LEO, and the LEO returns a message of 84 bytes. A comparison was made with the communication overheads of the authentication protocol of Xue et al. [11] and Wasef et al. [12]. The results are shown in Table 5. According to the analysis results, the overall message length of the proposed scheme is shorter than that of the other related works. Table 5. Communication overhead comparison in the batch authentication scenario.

Scheme
Message Length (Bytes)

UE to LEO LEO to UE
Xue et al. [11] 2L ID + 2L T + 2L G + L Z + 2L ID + L G = 144 L T + 2L ID + 3L G + L Z = 100 Wasef et al. [12] 2L ID + 4L G + 6L Z + L T = 166 2L ID + L T + L G + 2L Z = 84 Proposed 4L G + 2L ID + L T = 64 2L ID + L T + L G + 2L Z = 84 Assuming that the plaintext length is 16n bytes (i.e., n is divisible by 16), then the ciphertext length is 16n bytes in AES encryption. If the plaintext length is 16n + m bytes and m < 16, the ciphertext length is 16(n + 1) bytes. In the roaming authentication phase, K 1 is key with a length L r = 16 bytes, and the size of Ticket i is L ticket = 16 * (2L ID + L r + L T )/16 = 64 bytes. Due to the use of symmetric encryption for key negotiation, we needed to calculate its communication cost separately. The size of c 1 sent by UE to LEO is L c 1 = 16(L r + L ticket )/16 = 80 bytes, and the total message length is L ID + L G + L c 1 + L H + L T = 152 bytes. The size of c 2 is L c 2 = 16 * (L ID + L r )/16 = 32 bytes, the message size sent by the LEO to the UE is L ID + L G + L c 2 + L H + L T = 104 bytes.
Despite the higher communication overheads of roaming authentication, it drastically reduces the computational latency, which is acceptable.

Conclusions
In this paper, we investigated on-demand access and roaming authentication protocols in a multi-operator heterogeneous scenario in a satellite-ground integrated network. We have proposed a scheme that includes anonymous unlinkable and batch authentication protocols, as well as fast roaming authentication. Specifically, users with higher privacy requirements are suitable for the unlinkable authentication scenario, where the scheme can provide anonymity and unlinkability; a large number of users with higher efficiency requirements are suitable for the batch authentication scenario, where the scheme provides traceable anonymity. In addition, for users who need to switch between multi-operator networks, this scheme provides a cross-domain fast roaming authentication solution. The proposed protocol delegates the authentication task to the satellite, which significantly reduces the transmission delay in the SGIN. We performed a formal analysis using ProVerif and an informal analysis to prove the security of the scheme. In addition, we evaluated the performance of the scheme and the results showed that our scheme is effective.
To enhance our research, we intend to study short group signature algorithms in more depth in our future work and propose more secure and more efficient protocols for unlinkability authentication scenarios based on zero-knowledge proofs. In addition, the application scenario of 6G will be more complex than 5G, and it is a challenge to cope with the fair billing of multiple operators and balance their interests. Especially, the introduction of eSIMs brings novel security risks and conflicts of interest. Thus, in the future, we will further consider the interests of multi-operator scenarios and try to find a suitable solution to authentication.