|Computers, Materials & Continua |
Robust Authentication and Session Key Agreement Protocol for Satellite Communications
1Department of Computer Engineering, Ferdowsi University of Mashhad, Mashhad, 9177948974, Iran
2Faculty of Mathematics and Science, Universitas Padjadjaran, Jatinangor, 45363, Indonesia
3Faculty of Computer Science, Universitas Mercu Buana, Jakarta, 11650, Indonesia
*Corresponding Author: Rahmat Budiarto. Email: firstname.lastname@example.org
Received: 17 September 2021; Accepted: 08 December 2021
Abstract: Satellite networks are recognized as the most essential communication infrastructures in the world today, which complement land networks and provide valuable services for their users. Extensive coverage and service stability of these networks have increased their popularity. Since eavesdropping and active intrusion in satellite communications are much easier than in terrestrial networks, securing satellite communications is vital. So far, several protocols have been proposed for authentication and key exchange of satellite communications, but none of them fully meet the security requirements. In this paper, we examine one of these protocols and identify its security vulnerabilities. Moreover, we propose a robust and secure authentication and session key agreement protocol using the elliptic curve cryptography (ECC). We show that the proposed protocol meets common security requirements and is resistant to known security attacks. Moreover, we prove that the proposed scheme satisfies the security features using the Automated Validation of Internet Security Protocols and Applications (AVISPA) formal verification tool and On-the fly Model-Checker (OFMC) and ATtack SEarcher (ATSE) model checkers. We have also proved the security of the session key exchange of our protocol using the Real or Random (RoR) model. Finally, the comparison of our scheme with similar methods shows its superiority.
Keywords: Satellite communications; authentication; session key agreement; secure communication; security protocols; formal verification
Nowadays, mobile satellite networks are used to provide advanced personal communication services. These services complement terrestrial networks, providing benefits such as global coverage and increasing mobility and reliability for users. Satellite communications are valuable in an emergency and when other networks are unable to operate. Users can use satellite phones anytime and anywhere, including seas, islands, and high mountains, where land-based networks cannot provide services [1–3]. Furthermore, multicast applications delivery such as multimedia content distribution is perfectly performed by satellite systems [4,5].
While there are many different types of satellites, Low-Earth-Orbit (LEO) satellites are used more in mobile communications. These satellites are at shorter distances from Earth, so they have higher signal strength and lower latency [6,7]. However, unlike the Geosynchronous-Equatorial-Orbit (GEO) satellite, which alone covers the entire surface of the earth, several LEO satellites are required for this purpose .
The LEO satellite is a land-based satellite located less than 2000 km above the earth, which enables communication between mobile devices and the network control center through gateways [8,9]. Fig. 1 illustrates a general overview of satellite communications. The four basic components of these communications are mobile users, the network control center (NCC), LEOs, and gateways. Mobile users need to register with NCC to use the services. Gateways communicate between LEOs and the NCC.
Because satellite communications are more susceptible to security attacks due to their broadcast nature, these communications need to be secure. Therefore, a session key is required for each communication session to encrypt the messages. There is also a need for strong authentication of both parties.
In recent years, various protocols for securing satellite communications have been proposed, most of which have security flaws. In particular, some authentication and key management protocols have provided ECC-based solutions leveraging the elliptic curve discrete logarithm problem (ECDLP) [10–14]. In this paper, we examine Qi et al.'s work  and show its security vulnerabilities. We propose a secure and robust protocol for key exchange in satellite communications, which is resistant to known security attacks and satisfies the security requirements. Further, a thorough analysis of the proposed protocol shows that it performs better in terms of security than other ECC-based protocols.
The contributions of this paper are as follows:
• Analysis of key exchange protocol introduced by Qi et al.  and security vulnerabilities are revealed.
• A secure ECC-based authentication and key exchange protocol that resists common attacks and meets common security requirements.
• A thorough security analysis of the proposed protocol and its resistance to various types of attacks.
• Formal security verification of the proposed protocol on AVISPA tool, considering different model checking techniques that the proposed protocol meets different security requirements.
• The proof of security of the proposed key exchange protocol using the RoR model.
The rest of the paper is structured as follows: In Section 2, some essential related works are discussed. Section 3 provides background information on elliptic curve cryptography and the threat models. Section 4 describes Qi et al.'s protocol  and analyzes its security. Section 5 describes the proposed authentication and key exchange protocol for satellite communications. The security analysis of the proposed method is described in Section 6. In Section 7, the proposed protocol is compared with other similar protocols in terms of time complexity, communication cost, and security features. Finally, Section 8 is devoted to the conclusion.
2 Related Works
To provide satellite communications over unsecured networks, Cruickshank  developed the first satellite communication protocol in 1996. Since then, many protocols were introduced to secure satellite communications, and later on, other researchers take turns finding out weaknesses and flaws in those protocols and propose improved protocols.
Chen et al.  proposed an authentication mechanism for mobile satellite communication systems. Later on, Lasc et al.  showed that Chen et al.'s protocol was not resistant to the Denial of Service (DoS) attack and then suggested an improvement. Next, Chang et al.  revealed that Lasc et al.'s protocol was susceptible to impersonation attack through a stolen smart card. Then they proposed an authentication protocol for satellite communications. The newly proposed protocol was claimed to be resistant to all kinds of attacks. However, Zhang et al.  showed that the protocol proposed by Chang et al. was not resistant against the DoS attack and the impersonation attack.
Lee et al.  introduced an authentication and key exchange protocol for mobile satellite communications systems and claimed that it is resistant to all kinds of attacks. Later, Zhang et al.  revealed that Lee et al.'s protocol was not resistant against replay attacks, DoS attacks, and attacks from a stolen smart card. Then they developed a new protocol for satellite communication authentication. In 2018, Qi et al.  stated that Zhang et al.’ protocol was insecure against the stolen-verifier attack and DoS attack. Then they proposed an ECC-based protocol for satellite communication authentication. In 2019, Ostad-sharif et al.  showed that Qi and Chen's protocol could not meet the security requirements of perfect forward secrecy and did not resist the ephemeral secret leakage attack.
Liu et al.  proposed a Lightweight protocol for satellite communications authentication. Later on, Qi et al.  showed that the protocol proposed by Liu et al. does not meet the perfect forward security requirement. Then they introduced an authentication protocol based on ECC. In this paper, we prove that the protocol of Qi et al. is not resistant to Known-session-specific temporary information attacks and insider attacks.
Altaf et al.  proposed an authentication and key agreement scheme which is based on the (ECDLP problem. Then, Chen and Chen  proved that Altaf et al.'s protocol does not provide perfect forward secrecy. Moreover, we found that their scheme is vulnerable to DoS attack. The attacker can resend the request message to the NCC many times and force it to do the time-expensive point multiplication operation many times and thus overwhelms the NCC. Furthermore, Hosseini-Seno et al.  have proposed an authentication and key management protocol to provide patient privacy in Tele-medical information system. The proposed protocol cautiously considers all aspects of security requirements including the perfect forward secrecy.
3.1 Elliptic Curve Cryptography (ECC)
ECC uses the elliptic curve over the finite field , where p is a prime number with typically 256-bit (or more) length. All operations in the filed are in the modular form. Therefore, the ECC is defined as (1):
where , , and is the point at infinity.
The ECC is an Abelian group with addition as the group operation. Therefore, the addition of every two points on the curve leads to a new point on the curve. We can simulate scalar multiplication using the addition operation. The multiplication of scalar k in point R is k.
The building block for elliptic curve cryptography is the elliptic curve discrete logarithm problem: Given two points R and S over , find k such that . If the parameters of the elliptic curve are properly chosen, the ECDLP is believed to be infeasible with current technology .
To select a suitable elliptic curve, in addition to determining the values of a, b, and p, we should also define the generator G. In some elliptic curves, all points on the curve () can be generated with a single G. In this case, the curve has only one subgroup (). Sometimes, the curve has several subgroups (), and it is necessary to find a separate generator for each one. In the proposed method, we use ECCs with , such as secp192r1 . Therefore, the ECC parameters in the proposed method are shown with a five-tuple .
3.2 Threat Models
The most popular threat model is the Dolev-Yao model , which is an abstract model of agents’ capabilities. The Dolev-Yao model strips away the extraneous details of communications and shows a simple view of exchanged messages. The Dolev-Yao model presents term of algebra and models the protocol messages as terms. It presents some term derivation rules which define how agents can build new terms from the old ones.
Suppose , , and represent the set of agents, keys, and nonces, respectively. We define the set of basic terms as . We denote the public key and private key of the agent using and , respectively. Moreover, for we use to denote the shared symmetric key between them. The inverse of each is defined in (2)--(4).
The term syntax in Dolev-Yao model is defined in (5).
where and .
The intruder in the Dolev-Yao model is one of the agents and has access to the hash function, public keys of all agents, his private key, and his shared key with other entities. Moreover, the intruder has full control over all communication messages between agents. He can eavesdrop, intercept, or replay the messages . However, in examining the strength of security protocols, a stricter threat model such as the Canetti–Krawczyk (CK)  model is usually used. The attacker in the CK model not only has complete control over communications but also has the ability to obtain secret data in the system's memories. Therefore, the adversary may access private keys of parties or session-specific temporary keys. We consider the CK treat model in the analysis of our protocol.
4 Review and Analysis of Qi et al. Protocol
This section analyzes the protocol introdued by Qi et al. . The protocol consists of four phases, namely, 1) initialization, 2) user registration, 3) login and authentication with key agreement, and 4) password update. In the registration phase, each user firstly selects his ID and password (), and sends them to the NCC with via a secure channel .
When the message is received, the NCC checks that the selected does not belong to a duplicate user. It then performs the operations in the registration phase and finally delivers the smart card to the user. During the login and authentication phase, the user enters his smart card into the card reader and then inputs the user and password (). If it is determined that the smart card belongs to the person, the user and the NCC agree on a shared key of by transmitting messages to each other. So, from now on, the user and the NCC can communicate using the shared key.
We demonstrate that the protocol proposed by Qi et al. is vulnerable against attacks, as follows.
Known Session-Specific Temporary Information Attack
If the random parameters generated in a protocol are captured by the attacker, the session key should not be revealed. However, in the Qi et al.'s protocol, the session key is generally made up of random numbers α and β and a base point, which is considered general. So, by revealing random numbers, the attacker gains the key to the session.
It is assumed that the internal attacker (here NCC) tries to obtain the password of each user. Since the user sends the and to the NCC, and the password is usually short, the internal attacker on the NCC side can guess the password using the hash table.
5 The Proposed Protocol
The proposed protocol uses elliptic curve encryption and consists of initialization, registration, and authentication and key agreement steps. Tab. 1 shows the symbols used in the proposed protocol.
5.1 Initialization Phase
In this phase, the NCC sets some parameters to be used in authentication and key management. As explained in the previous section, to use the ECC cryptosystem, the NCC needs to set the five-tuple . Besides, the NCC chooses a random number and computes its related public key . Moreover, the NCC needs to choose the hash function .
5.2 Registration Phase
To use the NCC services, the user needs to register first. The steps of user registration are depicted in Fig. 2 and are as follows:
Step 1. The user first asks the NCC via a secure channel to send him the initialized parameters, .
Step 2. After receiving the necessary parameters, the user chooses an ID and password. He also selects a random number as the private key and calculates his public key . The user then calculates his masked password to hide his password from the NCC. The masked password is defined in (6).
Finally, he sends the triple through the secure channel to the NCC.
Step 3. Upon receiving , the NCC checks the validity of . If the ID is legitimate, the NCC computes , which is a combination of the user's identity, the NCC's identity, and the NCC's private key as defined in (7).
Then, the NCC performs the XOR operation on and to calculate as defined in (8).
Finally, the NCC sends to via the secure channel.
Step 4. The user calculates the hash of his identity, his password, and his private key as defined in (9).
Finally, he stores in his mobile device.
5.3 Authentication and Key Agreement Phase
Upon completion of the registration, the user and the NCC start a two-way authentication and key exchange process to communicate with each other via an insecure channel. A complete description of this phase is given in Fig. 3 and is described in the following steps:
Step 1. The user enters his identity and password (). Here, the ID and password are shown using the prime symbol to indicate that these values are re-entered in this step and may differ from the ID and password values in the previous phase. Then is extracted from the mobile device memory. After that, is calculated and checked to see if this value is the same as in the device memory (10).
(10)If these two values are not the same, the user does not enter the correct ID and password, and the session ends. Here again, the primed form is used to indicate the recalculation of the variable in this step. Then the user's mobile device calculates the masked password and in (11) and (12).
(12)It then selects a random number as the ephemeral private key of the session and calculates the ephemeral public key of the session . The user also calculates another ephemeral secret () as defined in (13).
Then the mobile device calculates the masked identity of the user for this session as defined in (14).
The mobile device then sets the timestamp and calculates as defined in (15).
Finally, the mobile device sends the four-tuple to the LEO. Upon receiving the four-tuple, the LEO adds its own identity to it and forwards the five-tuple to the NCC.
Step 2. Upon receiving the message , the NCC checks the validity of the LEO. Then it verifies the freshness of the message by checking that the difference between receiving time () and the timestamp is less than . Afterward, it calculates as defined in (16).
Moreover, the NCC computes as defined in (18), and it aborts the session if it is not valid.
Note that here we use the double prime symbol to indicate that the variables are calculated in a new step of the protocol.
Then the NCC calculates and as defined in (18) and (19).
Then the NCC selects the ephemeral private key of the session, , and computes the ephemeral public key, . Moreover, the NCC calculates another secret, , as defined in (20).
The NCC then sets the timestamp and calculates the session key, , and the verifier, , as defined in (21) and (22).
Finally, the NCC sends the four-tuple to the LEO, and the LEO forwards the triple to the mobile device.
Step 3. The mobile device verifies the freshness of the received message by checking , and it ends the session if the message is not fresh. It then calculates and as defined in (23) and (24).
Then, the mobile device checks whether is equal to . If it is true, it calculates the shared session key as defined in (25).
Next, the mobile device computes and creates as defined in (26).
Finally, it sends to the LEO, and the LEO forwards to the NCC.
Step 4. The NCC authenticates the user by checking whether the received is equal to .
6 Security Analysis of the Proposed Protocol
In this section, we describe the security features, the robustness against several security attacks of the proposed protocol, and formally verify the correctness of the proposed protocol in terms of satisfying security features using AVISPA.
6.1 Security Features
6.1.1 Mutual Authentication
Key agreement protocols require the parties to authenticate each other. In our proposed method, the user selects the ephemeral private key and generates the ephemeral public key and the secret key . To request services, the user sends and some other messages to the NCC and keeps hidden. Except for the user, the only entity that can reproduce is NCC. The NCC reproduces the using and incorporates it into its authentication message (). On the other hand, the NCC selects the ephemeral private key , from which it generates the ephemeral public key and the secret key . The NCC sends the to the user and holds the secret key . Except for NCC, the only entity that can reproduce is the user. The user can regenerate and . If the reconstructed is equal to the sent , NCC will be authenticated to the user. The user then inserts in his authentication message () and sends it to the NCC. If is equal to , the user is authenticated for NCC.
6.1.2 Session Key Security
The session key generated in the proposed method is shared between the user and the NCC, and no other entity can access the session key. The session key on the server-side is calculated with , which requires knowing the ephemeral private key and the private key . The session key on the user side is calculated with and requires knowledge of the ephemeral private key , the private key , the password , and .
6.1.3 Perfect Forward Secrecy
The perfect forward secrecy guarantees the security of the session key, even though the long-term secret keys of parties are compromised. The proposed method preserves this feature because the session key is built using both long-term private keys and temporary secret keys. Even if the adversary gets access to and , he cannot guess the session key.
6.1.4 User Anonymity
The proposed method does not send the user identity in plain text over insecure channels, but the masked user identity, is sent. Only the NCC can calculate using and know the user ID. Therefore, user anonymity is preserved against other entities.
6.2 Security Attacks
6.2.1 Replay Attack
Our proposed method is resistant against the replay attack because, in addition to sending the timestamp explicitly, we also embed it in the message. So, if the adversary updates the timestamp to and resends the message , the NCC detects the attack by checking . Also, if the attacker repeats the message by changing the timestamp , the user will notice the attack by checking .
6.2.2 Man-in-the-Middle Attack
If the adversary interrupts the communication between the valid user and the NCC, he should be able to send legitimate message to the NCC. However, to build a valid , the adversary has to know the password and the private key of .
6.2.3 Insider Attack
The user does not send the password to NCC in the registration phase explicitly but sends it in hidden form, Since the NCC does not know the user's private key , it cannot guess the user's password.
6.2.4 Impersonation Attack
If the adversary wants to impersonate the user, he must be able to forget the request message . Assuming that the adversary is one of the users, he can generate a random number and the secret key and create by accessing the user ID. He can also generate and , but he cannot generate without , and knowing relies on knowing and the user password or knowing the NCC's private key, .
6.2.5 Known-Session-Specific Temporary Information Attack
If the attacker accesses the temporary session parameters in any way, he should not be able to access the session key. Since the session key, in our scheme is composed of both temporary and long-term parameters, it is resistant to this attack.
6.2.6 Smart Card Loss Attack
If the user's mobile device (or smart card) is stolen, the adversary should not be able to impersonate the user. Our proposed method is resistant to this attack because even if the adversary access smart card information , he cannot impersonate the user without the correct ID and password.
6.2.7 Stolen Verifier Attack
In our proposed method, NCC does not store any information about users other than their ID. Therefore, if the adversary accesses the NCC database, it will not receive any additional information.
6.2.8 DoS Attack
Denial of Service attacks can be done on satellite communications entities, including the users and the NCC. By persuading the NCC to perform a large number of heavy-weight point multiplication operations on the elliptic curve, the attacker causes the NCC to crash and makes it impossible to provide services to authorized users. Our proposed protocol is resistant to this attack because if one of the users wants to carry out this attack against the NCC, he himself will suffer the same heavy-weight operations. Also, due to the resistance of the proposed method to replay attacks, the adversary is not able to resend the request message to the NCC. For the same reason, it is not possible to perform this attack on system users.
6.3 Formal Security Analysis with AVISPA
AVISPA is a role-based language that provides a formal language for specifying protocols and security properties and uses several back-ends to analyze them [29,30]. Each participant in the protocol is represented by a role, which communicates with other roles by channels. The HLPSL specification is translated to an intermediate format, which is then analyzed by some back-ends. The four back-ends used by AVISPA include Tree Automata-based Protocol Analyzer (TA4SP), OFMC , Constraint Logic-based Attack Searcher (CL-ATSE) , and satisfiability-based Model-Checker (SATMC) .
We have implemented our protocol in the HLPSL language. We have defined a role for the user, role_Ui, and a role for the NCC, role_NCC. We have also defined a session role that specifies a session of the protocol. In addition, we have considered an environment role and defined three sessions in it. The first session is between the user and the NCC. In the second session, the intruder impersonates the user, and in the third session, the intruder impersonates the NCC. In addition, we have defined the intruder's knowledge and the security goals.
The goal of secrecy_of sec_1 examines the confidentiality of for the user. If the goal is satisfied by the protocol, the secrecy of is guaranteed. Similarly, the goal of secrecy_of sec_2 checks the confidentiality of for the NCC. Moreover, the goal of secrecy_of sec_3 examines that the is confidential between the user and the NCC, and the attacker cannot access it. Besides, the goals authentication_on auth_1 and authentication_on auth_2 examine the mutual authentication of the user and the NCC. The goal predicates request(Ui, NCC, auth_1, Eis) in role_Ui and witness(NCC, Ui, auth_1, Eis’) in role_NCC are used to declare the authentication of the user by NCC. Similarly, request(NCC, Ui, auth_2, Enccs) in role_NCC and witness(Ui, NCC, auth_2, Enccs’) in role_Ui are used to examine the authentication of NCC by the user. To check whether these goals are satisfied by our protocol, we use OFMC and ATSE. The results in Figs. 4 and 5 show that both of these model checkers find our protocol safe, which means that our protocol meets the secrecy of the session key and the mutual authentication of parties.
6.4 Proving the Security of Proposed Key Exchange Protocol Using RoR Model
We examine semantic security of the session key of the proposed protocol using the Real-or-Random model [34,35]. In this model, adversary A obtains a session key or a random value by querying protocol participants. The adversary must guess whether the output returned to him is a real key or a random value. For this purpose, we introduce various concepts such as participants, participant instances, oracles available to A, queries to these oracles, and the concept of partnering.
Participants. The two disjoint sets of our proposed protocol participants are U and . We represent the set of all participants with . Moreover, we represent the j th participant of the protocol with .
Participant Instances. During the execution of the protocol by the adversary, several instances of each participant may be executed. The instance i of the participant is denoted by and is called an oracle.
Long-Lived Keys. Each participant has a secret key .
Ephemeral Keys. Each participant in a session s has an ephemeral key .
Acceptance. To simulate the protocol, first, a user instance, , sends a message, and an NCC-instance, , responds with another message. This process continues until both instances are terminated. At this point, each instance enters the accepted mode and has a session ID (), a session key (), and a partner ID ().
Partnering. Two oracles and which are in accepted mode are partners if both have the same session keys, , the same session IDs, , and , and .
Protocol Execution. A protocol indicates how participant instances behave in response to signals received from the environment . Intending to break the protocol security, the adversary sends signals to the instances of the participants (oracles) and receives a response according to the rules of the protocol. In fact, the adversary sends queries to oracles, and these queries model the attacker's ability in a real attack. Types of queries include:
• Execute(). With this query, the adversary models a passive attack in which the adversary eavesdrops on messages exchanged between the i th instance of U, , and the jth instance of , .
• Send(). With this query, the adversary models an active attack. The adversary sends the message m to oracle , and the oracle responds according to the protocol.
• Reveal(). If oracle is in accepted mode (has a session key), this query will reveal the session key to the adversary . The session key may be revealed for a variety of reasons, such as hacking a participant. Of course, disclosing the key of one session does not break other sessions. If a Reveal() query is asked by , the oracle is opened.
• Corrupt(). Using this query, the adversary can access the long-lived key of the oracle . This query lets us examine the forward secrecy requirement of the protocol.
• Test(). This query measures the semantic security of the session key (if any) of the oracle . If the session key is not defined for , is returned. Otherwise, coin c is tossed first. If , then the session key is returned to , and if , a random value (with the same distribution as the valid session keys) is returned.
Freshness. An oracle is fresh if it is in the accept mode, and and its partner are not open (by Reveal query).
Semantic Security of A Key Exchange Protocol. Suppose adversary executes the key exchange protocol PRO and has access to Execute, Send, Reveal, Corrupt, Corrupt_Ephemeral, and Test queries. The adversary can ask the Test query up to one time for each fresh oracle. Suppose the adversary's guess for the Test query is . The adversary wins the game if , where c is the value of the coin set before the game. The protocol PRO is secure if the advantage of the probabilistic polynomial-time adversary in breaking the session key is negligible, as shown in (27).
Theorem 1. Suppose adversary can execute a maximum of Hash query, Send query, and Execute query to break our proposed key exchange protocol, PRO_SAT. The advantage of in breaking the PRO_SAT protocol is given in (28):
where is the range space of the Hash oracle, is the size of the password dictionary, and p is the prime number in .
Proof. To prove Theorem 1, we define a six-step game: G0 to G5.
G0. Game 0 is the real attack of against our proposed protocol, PRO_SAT. Intuitively, the adversary can win the game with the probability of . The advantage of the adversary to break the semantic security of PRO is , where is the event in which guesses the coin correctly and wins the game. Rescaling it, we can define the advantage of A as (29).
G1. In this game, we simulate passive attacks by the adversary. The adversary eavesdrops on messages between oracles and with an Execute query. The adversary then decides with the Test query that the session key returned to him is real or random. To create a session key in the proposed protocol, the ephemeral keys of the user and NCC, as well as long-term keys of both parties are needed. To be more precise, the session key is made in the client using the long-term key and the ephemeral private key . It is made in NCC using the long-term key and the temporary private key . The adversary cannot gain access to any of these keys by simulating eavesdropping attacks, and his advantage in violating the security of the session key does not increase, as shown in (30).
G2. In this game, in addition to simulating eavesdropping attacks, active attacks are also simulated with the Send query. Active attacks by the adversary can be one of three attacks: replay attack, man-in-the-middle, or impersonation attack. As stated in sections 6.2.1, 6.2.2, and 6.2.4, the proposed method is immune to these attacks. Therefore, the advantage of in this game does not increase. Therefore, we have:
G3. In this game, the adversary queries the Hash oracle times to find collisions. The birthday paradox states that the probability of collisions in the output of the Hash oracle is at most . Moreover, since , , , and are randomly selected from , the probability of collision in the Send and Execute oracles is at most . So, we have:
G4. This game simulates the smart card loss attack. If the mobile device (or smart card) of the user is stolen, may try to guess the password using an online dictionary attack. Since the number of password failures is limited by the protocol, we have:
G5. In this game, the adversary asks the Corrupt query and gets the oracle's long-lived key in response. Of course, to get the session key, needs the long-lived keys of both oracles in communication. Also, to create the session key, needs to have access to ephemeral keys for each session. To access the one-time keys of each session, the adversary must be able to solve the ECDLP problem. If the advantage of for breaking the ECDLP is , we have:
Given that , we can calculate the advantage of using (29) to (34), as shown in (35).
7 Performance Analysis and Comparison
In this section, we examine the computational complexity of the proposed method. The messages in the proposed protocol are obtained by combining xor, hash, and scalar multiplication on the elliptic curve. In calculating time complexity, we ignore the xor time execution, and we calculate the time required for hash and scalar multiplication based on the time reported in . The computation times of various cryptographic operations, reported by Xu et al. , are as follows:
• is the time of the one-way hash function, which is 0.0004 ms.
• is the time of scalar multiplication on elliptic curves, which is 7.3529 ms.
• is the time of modular exponentiation, which is 1.8269 ms.
• is the time of symmetric encryption/decryption, which is 0.1303 ms.
The time complexity of our protocol includes the time spent by the user's mobile device and the time spent by the NCC. The time spent by the mobile device is and the time consumed by the NCC is , and the total time is , which is equal to 58.8284 milliseconds.
To measure the communication cost of the proposed method, we need to measure the size of the messages exchanged between the different entities of the protocol. Messages consist of a combination of IDs, hash values, timestamps, and points on the elliptic curve. To calculate the communication cost, suppose each identifier is 64 bits long, the hash size is 256 bits, the timestamp is 64 bits, and the point size on the elliptic curve is 192 bits (due to secp192r1 selection).
To exchange the session key between the user and the NCC, it is necessary to send messages , , , and . Therefore, the communication cost of our protocol is bits.
At the end of this section, we compare the proposed method with several similar methods, which are all based on the ECDLP problem, in terms of security features and computational cost. As shown in Tab. 2, Tsai et al.'s protocol  does not satisfy perfect forward secrecy. Moreover, it is vulnerable to the known-session-specific temporary information attack and DoS attack. The protocol of Qi and Chen  does not meet the perfect forward secrecy and is not resistant against the known-session-specific temporary information attack. The protocol of Qi et al.  is vulnerable to insider attack and the known-session-specific temporary information attack. Finally, Altaf et al.'s protocol  is vulnerable to DoS attack and does not meet perfect forward secrecy. We see that our method, by spending a little more time, is resistant to the known attacks and meets security requirements. We also see that the communication cost of the proposed method is almost similar to other methods except  in which modular exponentiation are used.
8 Conclusion and Future Work
This paper contributes towards the widespread deployment of satellite applications by tackling one of the main challenges, i.e., security issues. This paper first analyzed the authentication protocol for satellite communications proposed by Qi et al. and proved its vulnerability to two kinds of security attacks. Then this paper presented a robust secure authentication and key agreement protocol based on elliptic curve cryptography for secure satellite communications. Moreover, a thorough security analysis of the proposed protocol was performed. The security analysis showed that it is resistant to all known attacks. Besides, the formal verification of the proposed method proved that it satisfies the security requirements.
As future work, the protocol performance can be improved in terms of time execution by reducing the number of scalar multipliers while preserving the security requirements. Implementation on application in blockchain  and software defined network  are also considered as future works.
Funding Statement: The authors received no specific funding for this study.
Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.
|This work is licensed under a Creative Commons Attribution 4.0 International License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.|