Abstract

Currently, space information network (SIN) has become an increasingly important role in real life. As a large heterogeneous wireless network, SIN can better provide global mobile services to users anytime and anywhere, even in extreme geographic environments. In addition, there is no need to build the communication base-stations every few kilometers on the ground to ensure high service quality, which greatly reduces the construction costs and can be used as an economical communication method in sparsely populated areas. So there is a trend that more and more end users are more likely to get SIN services than traditional terrestrial cellular networks. However, due to the openness and publicity of the satellite wireless channel and the limited resources of the satellite nodes, the privacy and security cannot be perfectly guaranteed and may even be vulnerable to attacks initiated by the adversary such as replay attacks, impersonation attacks, and eavesdropping attacks. To improve the access security of SIN, researchers have proposed a series of authentication protocols based on different cryptographic assumptions. Nevertheless, existing research shows that these protocols cannot meet the requirements of higher and higher security and short authentication delay. In addition, these protocols are mainly based on public key cryptography mechanisms such as DLP and ECDLP, which can be solved by postquantum computers in polynomial time, so these protocols will no longer be secure. To solve the vulnerability of these protocols, in this paper, we propose a new RLWE-based anonymous mutual authentication and key agreement protocol, which guarantees higher security with low computational overhead even in the postquantum era. Detailed security analysis shows that our protocol meets security requirements and is resistant to a variety of known attacks. Besides, combining security comparison and performance analysis, our proposed protocol is more practical than other protocols in SIN.

1. Introduction

With the continuous development of globalization, users are increasingly demanding communication and are required to establish high-quality communication connections with others. In this context, SIN is proposed to meet the needs of users for reliability and availability globalization services [1]. As a large heterogeneous network covering the globe, SIN includes various satellite constellations to provide navigation, communication, weather, reconnaissance, and other services for numerous users. In the future, SIN will not only serve the Earth users, but also serve space satellites and interstellar spacecraft with advanced space technology [2]. Compared with traditional terrestrial cellular networks, SIN has the following three characteristics [3]. First, SIN covers a wider range and can provide the stable signal in cities, villages, and even extreme environments. Second, as long as the device has the ability to communicate with satellites, it can join SIN as an end user or service provider anywhere in the world, which greatly improves scalability. Third, SIN does not require the laying of large amounts of ground facilities like a terrestrial network, and the signals are not affected by the terrain. SIN is a scarce resource for present and future, so the United States and Europe have carried out a series of key national research projects such as Thuraya [4], MUOS [5], ISICOM [6], and TSAT [7].

As a key communications architecture in marine, aerospace, military, and remote IoT applications, confidential and internal information will be transmitted to each other through SIN wireless channels [3]. Because security is not a primary concern when initially deploying SIN, the current research on security is still insufficient. At present, researchers have begun to shift from researching the functional requirements to the security requirements, and access authentication is the focus of their research [8, 9]. Accessing authentication is the first step for the end user to apply for service to the satellite node; it is even more necessary to take some light mechanisms to ensure the security and the quality of service (QoS). There are two key factors affecting the security and performance of the authentication protocol: one is the openness of the satellite wireless channel, the public channel will result in data being easily captured by adversaries, and the cryptographic mechanism should be used to resist the attack initiated by the malicious node. The other is the authentication delay caused by messages transmission and computing overhead. For delay-sensitive users who require real-time communication, the authentication delay should be as small as possible, even if the signal delay caused by satellites located 500 to 3,000 kilometers above the ground is unavoidable.

Currently, hardware technology is developing rapidly, and satellites can already carry more complex computing devices [10]. The three-party or two-party authentication protocols proposed in other research areas can provide a reference for designing authentication protocols suitable for SIN but cannot be directly applied. For example, in mobile pay-TV systems, [11] proposes a time slot-based key distribution mechanism that divides 24 hours by 45 minutes and arranges them in a binary tree. Service providers can provide up to 16 communication keys for a single user. However, when the number of users increases, it will occupy a lot of storage space of the service provider, which is not suitable for satellite with shortage of resources. In global mobility networks, [12] proposed a roaming authentication scheme based on the chaotic map-based discrete logarithm problem (CMBDLP). When a user and the foreign agent authenticate with each other, they need to transfer information four times with the participation of home agent, which increases the user's waiting time, and this does not meet the SIN low-latency requirement. Other scholars have also proposed many authentication protocols based on difficult problems such as elliptic curve discrete logarithm problem (ECDLP) [13], discrete logarithm problem (DLP) [14], large integer factorization problem (LIFP) [15, 16], and hash function [17], but these protocols still cannot be directly applied to SIN unless high security and efficiency are not considered. Furthermore, with the advent of the postquantum era, most authentication protocols that rely on public key cryptography have the potential to be resolved in polynomial time. So these authentication protocols may present security risks in the future. Therefore, this paper proposes a novel RLWE-based anonymous mutual authentication protocol for space information network, which can meet the requirements of high security and efficiency. In our protocol, LEO satellites serve as nodes that end users want to access. Terrestrial control station (TCS) provides system registration services for end users and LEO satellites. In the process of mutual authentication between the end user and the LEO satellite, the temporary identity is used so that the true identity is not revealed, and TCS does not participate in the authentication process as an offline node, which greatly reduces the authentication delay. In addition, the authentication protocol is based on the RLWE assumption which has been shown to be as difficult as the worst-case problem in the ideal lattice [18] and is also resistant to quantum computing with less computational overhead [19]. It is worth mentioning that our proposed protocol has the following main contributions:(1)We propose a novel RLWE-based anonymous mutual authentication protocol that enables both the end user and the LEO satellite to authenticate each other. In addition, TCS does not participate in the authentication process, which greatly reduces the communication delay to better meet the needs of delay-sensitive users.(2)This is the first anonymous authentication protocol for antiquantum computing in SIN. Moreover, in this paper, detailed security analysis proves that our protocol can meet the security requirements based on the well-known Dolev–Yao threat model [20] and resist various attacks by adversaries.(3)Considering the linkability of the user identity may be known by the adversary with background knowledge during the temporary identity transmission process, our protocol allows the end user to apply for a new temporary identity from TCS in the public channel, which enhances anonymity and unlinkability.

The rest of this paper is organized as follows: in Section 2, we first briefly discuss related work. Then we show the background information related to the protocol in Section 3. In Section 4, we describe the proposed protocol in detail. Detailed analysis of the security and performance of the proposed protocol is provided in Sections 5 and 6, respectively. Finally, Section 7 presents the conclusion of this paper.

In recent years, researchers have been enthusiastic about security and privacy issues in the authentication protocol for space information network (SIN). In 1996, Cruickshank [21] proposed the first authentication protocol in satellite networks using the public key cryptosystem to authenticate the legitimate identity of the end user and the satellite, respectively, and uses the symmetric key system to encrypt the communication data. However, the protocol requires terrestrial control station (TCS) to participate during the authentication process, which results in a large delay in the authentication process, and the use of four complicated encryption and decryption operations results in large computational overhead. Then Hwang et al. [22] proposed an authentication protocol that uses the symmetric key to encrypt the message transmission in the mutual authentication phase without the need for a public key mechanism. Although the computational overhead is reduced, the shared key in each authentication is only determined by the TCS, and the end user does not participate in generating the shared key, without enabling the end user to trust the security of the shared key. To overcome the weaknesses in [22], Chang and Chang [23] proposed an authentication scheme with only hash functions and XOR operations. This scheme greatly reduces the computational complexity and ensures that the shared key is jointly generated by both parties, but still cannot overcome the problem of TCS participating in the authentication process which will result in the increase of TCS computing load and a large delay of authentication. In 2012, Zheng et al. [24] proposed a more effective protocol to reduce the computational complexity of TCS, but proved in [25] that [24] cannot resist the denial of service (DoS) attack and the identity spoofing attack. Recently, Yang et al. [10] proposed a new anonymous fast authentication protocol based on the q-SDH problem and elliptic curve digital signature algorithm (ECDSA) for authenticating roaming users in foreign domains. In the authentication stage, the protocol does not compromise the anonymity of the user’s identity and can resist replay attacks, man-in-the-middle attacks, and modification attacks. Unfortunately, the protocol does not have user login authentication, which will result in that if the user’s device is stolen, the adversary can use the user's device to impersonate as a legitimate user. Besides, in the postquantum era, the difficult problems that [10] relies on have been proven to be resolved in polynomial time, and the anonymity and communication security will be invalid. Feng et al. [26] first proposed an anonymous authentication protocol based on ideal lattices and resistant to quantum computing. However, there are two defects in [26] that cannot be applied. First, when the adversary intercepts the message sent by the user in authentication phase and the message is directly replayed or modified, then the server will spend a lot of computational overhead to check whether it is a legitimate message. If the adversary sends a large number of forged authentication messages, it will consume a lot of system resources. Secondly, server provides both registration and user authentication functions, while satellite nodes in SIN cannot simultaneously undertake heavy computing and storage tasks due to limited resources. In summary, previous authentication protocols based on hash or classic hard problems cannot meet the anonymity, security, and low-latency requirements. Therefore, in this paper, we design an access authentication and key agreement protocol, which can guarantee the anonymity of users and has lower transmission delay.

3. Preliminaries

In this section, we give a review of background information and the notations on RLWE and then briefly describe the system model and threat model that the protocol relies on. Finally, the security requirements are presented.

3.1. Ring Learning with Errors

Let , where . The rings of polynomials over and , respectively, are denoted by and , where is an odd prime number and . Consider the two rings and . For any polynomial element in or , denote it by its coefficient vector in and , respectively. Given a fixed positive real , the discrete Gaussian distribution over is denoted by . We refer to [19, 27, 28] for a more description of RLWE with the following lemmas.

Lemma 1. For any two elements , there exist and .

Lemma 2. Given any positive real , the [29].

For an odd prime , let and the subset as the middle set of . For any , the characteristic function of the set complement is defined as

The auxiliary modular function is defined as , where and , with the following lemma for these two functions.

Lemma 3. Given an odd prime number , we have two ring elements , such that . Then, the equation holds, where .

The two functions and can be extended to the ring by applying coefficients to ring elements and can also follow the lemmas mentioned above. Given a ring element and , we have and . Then, for , we have , where the absolute value of each element in is less than [30].

Definition 1. Ring learning with errors (RLWE) assumption: let and be defined as above. , are randomly selected from and , respectively. The RLWE assumption states that it is hard for any algorithm to distinguish from the uniform distribution on . The hardness of the RLWE assumption can be reduced to the Shortest Independent Vectors Problem (SIVP) over ideal lattices [31].

3.2. System Model

As shown in Figure 1, SIN contains a total of three types of entities: terrestrial control station (TCS), satellite node, and end user. The following details describe the functions of each entity.(i)TCS is a control center to provide registration services to end users and satellite nodes. Moreover, TCS is considered a trusted entity with the highest level of firewall and intrusion detection system. Any attack can be detected and taken with corresponding security measures to prevent attacker from intruding into TCS.(ii)Satellite node is the service provider for end users in SIN. In order to reduce the delay of users accessing SIN, LEO satellites that are closer to the ground are usually used. LEO satellites are not all legal service providers, and there may be some LEO satellites controlled by malicious adversaries.(iii)End user is user with the smart device and has the ability to compute, store, and communicate with satellites. The end user will request access to the SIN to get the subscribed service. It needs to be reminded that the smart device is at risk of being lost or stolen.

3.3. Threat Model

In our protocol we make use of the Dolev–Yao threat model, which means that the adversary will control all openness and public channels in SIN. The adversary can arbitrarily monitor, intercept, modify, and replay messages transmitted between nodes and has unlimited storage space to store all the information monitored. The protocol we designed is to allow legitimate nodes to authenticate each other’s identity, deny illegal access, and ensure that secrets are not obtained by adversaries under the Dolev–Yao threat model.

3.4. Security Requirements

According to the characteristics of the previously proposed authentication protocol in SIN, a well-designed protocol should meet the following security requirements.

3.4.1. Mutual Authentication

Satellite nodes should have the ability to verify the legal identity of the end user and prevent access by nonlegitimate users. Similarly, the end user should also have the same ability to verify access to legitimate satellites.

3.4.2. Identity Anonymity

The identity of the end user should remain anonymous, and no one other than TCS and the end user himself can know the true identity of the user.

3.4.3. Key Establishment

After successful mutual authentication of the satellite and the end user, they should jointly construct a shared key to protect future communication.

3.4.4. Perfect Forward Secrecy

The authentication protocol also needs to meet the requirement that the shared key leakage does not lead to the previous and future session key leaks.

3.4.5. Attack Resistance

In the authentication process, in order to ensure the accuracy and security of authentication, the protocol should be able to withstand various attacks initiated by the adversary such as replay attack, modification attack, eavesdropping attack, and impersonation attack.

4. Our Proposed Protocol

In this section we present a novel RLWE-based anonymous authentication protocol. The detailed protocol description will be introduced in the order of system initialization phase, registration phase, authentication phase, password update phase, and temporary identity update phase.

4.1. System Initialization Phase

In the system initialization phase, TCS generates the master key pair and some system public parameters according to the following steps:(1)TCS sets system security parameters (2)TCS chooses an odd prime number and an integer , where is a power of and (3)TCS chooses a discrete Gaussian distribution and a random ring element , where is a fixed positive number and (4)TCS randomly samples and computes the master public key , where is the master private key(5)TCS chooses a security hash function (6)TCS publishes the system parameters to the public and securely stores the master private key

The system initialization phase is performed once when the system is laid out and not during other phases. Since it is only executed once, the computational overhead of the system initialization phase can be considered negligible.

4.2. Registration Phase

The registration phase is the process by which TCS interacts with trustworthy end users and satellite nodes. In this phase, the satellite and the end user need to submit the true identity and other necessary parameters to TCS. It is worth noting that end users also need to generate the temporary identity that masks the true identity during the authentication phase. Then TCS generates the parameters needed for mutual authentication in the future for the end user and the satellite node, respectively. We briefly show this process in Figure 2 and the more detailed steps will be described in Algorithm 1 and the rest of this section. We assume that the satellite set is with satellites and the end user set is with users. For a clearer presentation, in the following description, we simplify the system model with only one end user , one satellite , and TCS. Besides, it is necessary to note that the messages in this phase are transmitted in the secure channel.(1) generates the true identity and computes the master public key , where and are randomly sampled from . is assumed to be the master private key and is stored securely by . Finally, sends the message to TCS. It needs to be reminded that the identity of the satellite node is not private, so there is no need to anonymize it.(2) generates the true identity , temporary identity , and password and then chooses the satellite node which it wants to communicate with. The function of is used for login verification and it will be required in authentication phase, password update phase, and temporary identity update phase. Next, computes the master public key , where and are randomly sampled from . is assumed to be the master private key and is stored securely by . Then computes , which is to protect the from being known by the TCS. Finally, sends the message to TCS.(3)TCS computes , , and after receiving the registration message of . Then TCS sends the messages to and to . is used to check if the temporary identity and password entered are correct when logs into the smart device. The function of the is to enable to update the password as wishes and detailed in the password update phase. The function of is to prevent from changing by himself. If is free to update the temporary identity , the legal identity of cannot be distinguished during the authentication phase. By binding the master private key of the TCS to , even if attempts to update , it cannot change , , and without TCS. Finally, TCS stores and .(4) stores the message .(5) stores the message .

(1):
(2) Generates the true identity ;
(3) Randomly samples and computes the master public key ;
(4) Stores the master private key ;
(5) Submits to TCS;
(6) END
(7):
(8) Generates the true identity , temporary-ID , password and chooses the satellite node ;
(9) Randomly samples , and computes the master public key ;
(10) Computes ;
(11) Submits to TCS;
(12) END
(13):
(14) Computes , , ;
(15) Transmits to and to ;
(16) Stores and ;
(17) END
(18) stores ;
(19) stores ;
4.3. Authentication Phase

As shown in Figure 3, in this phase, and mutually authenticate each other's legal identity in accordance with the following steps and negotiate a shared session key to encrypt future communications. It is worth noting that the three interactive messages are transmitted in the public channel and the messages are transmitted in plaintext.(1) needs to input the temporary identity and password to login the smart device before requesting authentication. The device computes , . Then it checks whether . If they are not equal, the access request is terminated immediately; otherwise the following steps are continued according to the protocol. This process is to prevent the device from falling into the adversary and being disguised as . Next, the smart device computes , , , and . Finally, sends the message to . is the timestamp used to prevent the replay attacks by the adversary. The rest of the timestamps in this paper have the same function as .(2)After receiving the message , first checks the timestamp and compares it with the current time to see if it is within the time allowed. If the timestamp is not within the allowed range, the access request is denied; otherwise computes , , and . Then it checks whether . If they are not equal, the end user who sent the access request is not legitimate and rejects the access request; otherwise the next steps of the authentication protocol are continued. Next, computes and , where and are randomly sampled from . Finally, sends the message to .(3)After receiving the message , first checks the timestamp and compares it with the current time to see if it is within the time allowed. If the timestamp is not within the allowed range, the access request is denied; otherwise computes . Then checks whether . If they are not equal, will assume that the satellite requested to access during the authentication phase is not the true and actively stops the access request; otherwise it continues to compute , , , , , and the final session key . Finally, sends the message to .(4)After receiving the message , performs the same timestamp check process as steps 2 and 3. If the timestamp is not within the allowed range, the access request is denied; otherwise computes , , . Then checks . If they are not equal, the received message is not sent by the real or modified by malicious nodes, and then the access request is immediately terminated; otherwise it computes and the final session key .

(1)Input
(2);
(3);
(4)ifthen
(5) Deny the password update;
(6)else
(7)Input
(8);
(9);
(10);
(11) Smart device stores ;
4.4. Password Update Phase

When wants to change the old password to the new password , an attempt as shown in Algorithm 2 is made to perform the password update phase. Firstly, needs to input the temporary identity and the correct old password . Then the smart device computes , and checks whether . If they are not equal, the password update phase is terminated immediately. Otherwise, inputs the new password and the smart device computes , , and . Use and to replace and , where will be used as the new verification value of the login device in the future. Finally, the smart device stores .

4.5. Temporary Identity Update Phase

This phase is only performed when the previous temporary identity is no longer sufficient for their identity anonymity and security requirements. As shown in Figure 4, finally obtains a new legal temporary identity through two message exchanges and updates the parameters associated with the temporary identity such as , , , and . We note that all messages between TCS and are transmitted in the public channel.(1) needs to input the correct and . After the verification is successful, chooses a new temporary identity and then computes , , , , and . Finally, sends the message to TCS.(2)After receiving the message , TCS first checks the timestamp and compares it with the current time to see if it is within the time allowed. If is valid, TCS computes , , , and . Then TCS checks whether . If the check is valid, TCS can not only know the legal identity of the end user, but also know the new temporary identity that wants to update. Next, TCS continues to compute , , and . Finally, TCS sends the message to and the message to which updates the association between and . The message transmits between and TCS in the secure channel.(3)After receiving the message , also needs to first check if is within the time allowed. If the check is valid, computes . Then checks whether . If the check is valid, the entity communicating with it can be identified as TCS. Next continues to compute , , and . Finally, updating allows to input the and can login the device correctly.

5. Security Analysis

In this section, we analyze and discuss the security requirements of our protocol and prove that our protocol is sufficiently secure to resist insider attacks, replay attacks, modification attacks, eavesdropping attacks, and impersonation attacks. As shown in Table 1, we also compared the security attributes with other related protocols.

5.1. Mutual Authentication

In step 2 of authentication phase, authenticates the legal identity of by checking , where . Since has securely stored the temporary identity and the public key in registration phase, only the user whose temporary identity is and has the public-private key pair can compute the same as and then can pass the check. No one can compute the matching private key by and unless the SIVP assumption can be solved with algorithm. Similarly, in step 3 of authentication phase, authenticates the legal identity of by checking , where . Since has securely stored the and the public key , the adversary can only disguise as if it solves the SIVP assumption in polynomial time. In addition, as [26], the secure hash function is used to ensure the integrity of the messages in the public channel transmission. Therefore, the authentication protocol can meet the security requirements of mutual authentication.

5.2. Identity Anonymity

In the whole system, only and TCS know the true identity . Whether in the authentication phase or in the temporary identity update phase, the temporary identity is transmitted in the public channel. has no relevance to and cannot be inferred from . The adversary can only obtain the true identity of the user from TCS which preserves the relationship between and . However, the highest level of security protection of TCS makes it impossible for adversary. Therefore, the authentication protocol can meet the security requirements of identity anonymity.

5.3. Key Establishment

In step 3 and step 4 of authentication phase, and independently generated the final shared session key , where nonpublic parameters and require both parties to participate to compute and avoid the shared key being determined by the single party. Moreover, the adversary cannot guess from the public key unless there is a more efficient algorithm to solve the SIVP assumption. Therefore, the authentication protocol can meet the security requirements of key establishment.

5.4. Perfect Forward Secrecy

In our protocol, the shared key negotiated by the two parties is , except for , , and , which are parameters that can be directly intercepted in the public channel. and can be regarded as long-term secrets of and . In addition, is generated by and randomly sampled from at each authentication. Even if long-term secrets are captured by the adversary, due to the randomness of and , the adversary cannot know the previous session key. Therefore, the authentication protocol provides perfect forward secrecy.

5.5. Login Authentication

Only after entering the correct temporary identity and password can the user perform the access authentication in accordance with the steps. When the user’s device is lost, the adversary cannot use the device, which avoids the security threat of the adversary pretending to be a legitimate user. Moreover, it can not only deny malicious access directly at the device side, but also reduce the computational cost of SIN.

5.6. Resistance of Insider Attacks

Although TCS is a trusted entity in the SIN, it is inevitable that the possibility of insiders stealing the user’s password exists. During the registration phase, the user did not submit the password directly to TCS but . Due to the one-way security of the hash function , insiders cannot get from . Therefore, the authentication protocol can meet the security requirements of resistance of insider attacks.

5.7. Resistance of Replay Attacks

It is noted that each message transmission contains a timestamp , which is hashed with . can only be known by both parties to the authentication and the adversary cannot know, which ensures that the message cannot be modified. So even if the adversary replays the authentication message, the user or satellite node can check whether it is the replay attack in two steps. First, check if the timestamp is within the allowed range; then compute the hash value of the message and compare it with sent by the other party. Even if the adversary modifies the timestamp in the message and passes the first step of checking but cannot get , it is impossible to forge the correct hash value with the modified . Furthermore, parameters are randomly sampled, which results in different public keys and hash values for each session. and can also detect replay attacks by verifying these parameters. Therefore, the authentication protocol can meet the security requirements of resistance to replay attacks.

5.8. Resistance of Modification Attacks

During the authentication phase, each step contains a final message hash which is the hash value of the message transmitted this time and some key data previously negotiated. For example, the message is transmitted by to in the second step, where . contains not only the message and the timestamp but also the previously negotiated parameters , , and . Due to the security features of the hash function , any changes to the message can be verified. Therefore, the authentication protocol can meet the security requirements of resistance of modification attacks.

5.9. Resistance of Eavesdropping Attacks

In our whole protocol, the adversary can only obtain data such as , , , , , and a series of hash values and timestamps. Due to the security of the hash function, the adversary cannot get any useful information from the hash value. In addition, the final shared key is , where and cannot compute by the known parameters such as , , , , unless the SIVP assumption is solved. Therefore, the authentication protocol can meet the security requirements against eavesdropping attacks.

5.10. Resistance of Impersonation Attacks

An adversary may impersonate a legitimate user or satellite node to submit or respond to access requests. However, the adversary can only obtain the public key of both parties, but cannot obtain the private key for authentication and negotiation of shared key, so it is impossible to forge hash values to pass authentication. Therefore, the authentication protocol can meet the security requirements of resistance to impersonation attacks.

6. Performance Analysis

In this section, we present the performance analysis of the protocol for authentication delay and communication overhead. Because our proposed protocol is the first postquantum anonymous authentication scheme for SIN, we just choose to compare it with the classic authentication scheme [23] and the latest proposed protocol [10]. Furthermore, to make the comparison more intuitive and consider the practicality of the protocol for smart devices, we set the parameters in the protocol as [19]. The integer is 1024 and the odd prime number is 12289. For discrete Gaussian distribution parameter is set to . Finally, choose the secure hash function SHA3 with output of 512 bits.

6.1. Authentication Delay

Authentication delay refers to the sum of the total computing time and the transmission time of both devices from the beginning to the end in the mutual authentication phase. Before discussing the authentication delay of our proposed protocol in detail, we need to use the following symbols to represent the average time overhead caused by different operations. is used to represent the sampling time from the discrete Gaussian distribution . and represent multiplication with scalar and multiplication time in , respectively. represents the time of the multiplication and addition operation in . indicates the time when the function is executed once. is the time when the SHA3 hash function is executed once. To better analyze the performance of our proposed protocol, we quote the overhead time of various computation operations in [26]. The satellite node and the end user in the proposed protocol correspond to the server and the mobile device in [26], respectively. The machine is equipped with 3.4 GHz Intel Core i7-6700 processor and 8 GB RAM as the satellite node and the end user with 1.4 GHz Quad-core Exynos 4412 processor and 1 GB RAM. Both parties used the LatticeCrypto library and the MIRACL library when implementing the protocol. The experimental results are shown in Table 2 and it is worth mentioning that the computation overhead of function is small enough to be neglected. In addition, since LEO satellites are usually located 500 km–3000 km from the ground, it is reasonable to set the single message delivery time to . The following is the analysis of the computing time according to the steps in the authentication phase.

(1)In the first step, after and entered by , the device performs two hash operations to check whether they are correct. If the verification passes, also needs to perform one multiplication operation in , one function in , and one hash operation. Therefore, the total computing time overhead of is .(2)In the second step, after receiving the message, first needs to perform one multiplication operation in and one hash operation to check the validity of the message. If the verification passes, it also needs to continue to perform two random sampling operations in , one multiplication with scalar in , one multiplication and addition operation in , and one hash operation. Therefore, the total computing time overhead of is .(3)Next, after receives the response message from , first performs one hash operation to check the validity of the message. If the verification passes, also needs to perform two sampling operations in , one multiplication with scalar in , one multiplication and addition operation in , one multiplication time in , one function in , and three hash operations. Therefore, the total computing time overhead of is .(4)Finally, after receives the response message from , it first performs one multiplication operation in and one hash operation to check the validity of the message. If the verification passes, also needs to continue to perform two hash operations. Therefore, the total computing time overhead of is .

In general, the two parties of authenticating the identity and building the session key need to execute 2523.008 ns at the end user and 220.917 ns at the satellite node, respectively. The total computing time required for the protocol is 2743.925 . Besides, the three messaging times required for the authentication phase are . So the authentication delay of our proposed protocol is 15.003  and the computing time is only a small part of the authentication delay.

In [23], the computing time depends on the maximum number of accesses and the access. In order to achieve the shortest time, we set , . Therefore, both the end user and the satellite node of the authentication process need to perform four hash operations and the computing times aare and , respectively. Besides, the five messaging times required for the authentication phase are . So, the authentication delay of [23] is 25.001 . However, in general, in order to reduce the computational task of TCS, is set to a larger value which makes the authentication delay greatly increase and the performance of the protocol degrade.

In [10], the protocol is based on the Diffie–Hellman problem [32] where the execution of the protocol requires pairing operation, multiplication operation, and exponentiation operation in the additive cyclic group. The experimental results of these operations in [26] are as described in Table 3. In the authentication phase, the end user needs to execute the total of nine multiplication operations, three exponentiation operations, two pairing operations, and one hash operation, so the computing time of end user is . The satellite node executes five multiplication operations, four exponentiation operations, two pairing operations, and one hash operation, so the computing time of satellite node is . The total computing time required for the protocol is 133.687 . Besides, the two messaging times required for the authentication phase are . So, the authentication delay of [10] is 143.687 .

Table 4 shows the comparison of the authentication delays of our proposed protocol with the other two protocols. It can be seen from the table that the authentication delay of our proposed protocol is significantly lower than [10, 23], which is a more effective authentication scheme.

6.2. Communication Overhead

According to the security of the protocol and the support for the device mentioned earlier, we set the size of elements in to 4096 bits, the output of the SHA3 function is 512 bits, and the length of the identity and the timestamp is 100 bits. There are three message transmissions in the mutual authentication phase of our protocol. First, sends to . Then, responds to . Finally, sends a confirmation message to the . Therefore, the total communication overhead of the protocol is bits.

In [23], both parties need to transmit six hash values and six identity messages, so the total transmission overhead is bits. In [10], assume that the length of element in cycle group and all signatures is 160 bits. Therefore, according to the communication overhead in [10], it can be concluded that the total of 2480 bits of messages needs to be transmitted during the authentication phase.

It is worth noting that the communication overhead of the proposed protocol is greater than other protocols because the protocol is based on RLWE, and a common flaw in the ring is that the key size is larger than the traditional encryption system. Considering that satellite network bandwidth has grown significantly and the authentication delay is small enough for delay-sensitive users, so we believe that our proposed protocol is a practicable scheme which is superior to other protocols.

7. Conclusion

In this paper we propose a novel RLWE-based anonymous mutual authentication protocol for SIN which is an antiquantum computing protocol. In the security analysis, we elaborated that the proposed protocol can meet the security requirements of SIN access authentication and compare the security with other related protocols. The analysis results show that our protocol is more secure than other protocols. Moreover, in the performance analysis, it is further stated that the authentication delay of our proposed protocol is very small. Although the communication overhead is slightly larger, the protocol we proposed under the trade-off communication delay and communication overhead is practical for SIN in the future.

Data Availability

The data used to support the findings of this study are included within the paper.

Conflicts of Interest

The authors declare no conflicts of interest.

Acknowledgments

This paper was supported by the National Natural Science Foundation of China (Grant no. 61672092).