## 6 Performance Analysis
### Computational Complexity Analysis  
#### 6.1.1 Computational Complexity in the Unlinkable Authentication Scenario  
In the unlinkable authentication scenario, we compared the protocol with the work of [PERSON] et al. [37], [PERSON] [24], and [PERSON] et al. [12]. The operations involved in these protocols are shown in Table 2, where \(\mathbb{G}\) symbolizes the addictive cyclic group of prime order \(q\), and \(\mathbb{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}\in\mathbb{G}\) and \(g_{T_{1}},g_{T_{2}}\in\mathbb{G}_{T}\). Parameters \(a\) and \(b\) are random numbers in \(Z_{q}^{*}\).  
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  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Operation** & **Description** & **Time Overload (ms)** \\ \hline \(T_{Pairing}\) & A bilinear pairing \(\varepsilon:\mathbb{G}\times\mathbb{G}\rightarrow\mathbb{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 \(g_{1}\) & 0.882037 \\ \(T_{Mul_{2}}\) & A multiplication operation \(g_{1}g_{T_{2}}\) & 0.000949 \\ \(T_{Exp}\) & An exponentiation operation \(g_{1}^{\mathrm{d}}\) & 0.148430 \\ \(T_{Hash_{1}}\) & A hash function \(\{0,1\}*\to Z_{q}^{*}\) & 0.000258 \\ \(T_{Hash_{2}}\) & A hash function \(\{0,1\}*\rightarrow\mathbb{G}\) & 1.976653 \\ \(T_{Hash_{3}}\) & A hash function \(\{0,1\}*\times\mathbb{G}\to Z_{q}^{*}\) & 0.030638 \\ \hline \hline \end{tabular}
\end{table}
Table 2: Comparison of operation time overheads.  
take place before the entire system starts, and their overheads can be excluded from the authentication overhead.  
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, one-way 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.