ASAP-IIOT: An Anonymous Secure Authentication Protocol for Industrial Internet of Things

With the increasing demand for a digital world, the Industrial Internet of Things (IIoT) is growing rapidly across various industries. In manufacturing, particularly in Industry 4.0, the IIoT assumes a vital role. It encompasses many devices such as sensing devices, application servers, users, and authentication servers within workshop settings. The security of the IIoT is a critical issue due to wireless networks’ open and dynamic nature. Therefore, designing secure protocols among those devices is an essential aspect of IIoT security functionality and poses a significant challenge to the IIoT systems. In this paper, we propose a lightweight anonymous authentication protocol to preserve privacy for IIoT users, enabling secure IIoT communication. The protocol has been validated to demonstrate its comprehensive ability to overcome various vulnerabilities and prevent malicious attacks. Finally, the performance evaluation confirms that the proposed protocol is more effective and efficient than the existing alternatives.


Introduction
The Industrial Internet of Things (IIoT) is the incorporation of IoT technologies into industrial sectors, linking an extensive array of industrial sensors, devices, and user endpoints to generate significant volumes of industrial data [1,2].The amount of data produced in the IIoT is directly linked to the growing number of internet-connected devices [3][4][5].Typical application scenarios encompass smart manufacturing, logistics management, and remote equipment maintenance.These typical application scenarios represent critical components of modern industrial systems, where ensuring secure and efficient communication between devices has become paramount.The primary application scenario for our protocol is in smart manufacturing, specifically for supervisorial management of production lines.An observation system for managing production lines is the subject of investigation, encompassing various devices such as sensors, application servers, and users.Within this system, numerous sensors, integrated into a production line, gather data on operational parameters and status, transmitting this information to the corresponding application server.The manager of production lines is a user in the system monitoring the operation of some production lines by retrieving the operation information stored at the corresponding application servers.Throughout the overarching management procedure, to uphold accountability and privacy, the system must guarantee that only authorized managers can access information pertaining to specified production lines.Unauthorized users are barred from accessing any server information.Furthermore, only servers supervised by a particular authenticated user are accessible for data retrieval.Of course, this system can also be utilized in logistics management and remote equipment maintenance.
Within the IIoT realm, wireless sensor networks (WSNs) play a primary role in connecting extensive sensor nodes.Besides key management, user authentication serves as a fundamental security mechanism to confirm the user's validity in WSNs [6,7].For applications requiring swift data collection, like remote pipeline monitoring, application servers gather data from sensing devices, enabling users to access these data through mobile devices.A recent study conducted by Sobin [8] underscores that scalability, the standardization of architectures and protocols, energy efficiency, and security and privacy remain unresolved challenges that impede the widespread implementation of an IIoT system.The study in [9,10] emphasizes that IoT systems face numerous privacy and security issues due to their resource-constrained devices, heterogeneous deployments, and dynamic nature.Secure and dependable authentication protocols are demanded for the establishment of mutual trust between the users and servers [11].
Ensuring the confidentiality, availability, and integrity of critical data while securing and maintaining reliable IIoT operations remains a top priority.Several protocols have emerged to complete secure IIoT authentication.A secure ECC-based authentication protocol for IoT edge devices (ECCbAP) has been introduced in [12] to secure the connectivity between edge devices and cloud servers.The results show that the ECCbAP scheme provides a high level of security and is also more resource-efficient.However, it has not proved its ability against replay attacks.Adversaries could potentially compromise systems by repeatedly forwarding the stolen messages, leading to resource exhaustion.In [13], a lightweight wireless sensor network (WSN) authentication protocol with user anonymity has been proposed, offering numerous security features with high efficiency.However, some design vulnerabilities under the desynchronization and smart card stolen attacks still exist, which could result in privacy violations.A provably secure and efficient identity-based anonymous authentication scheme for mobile edge computing (AASM) has been developed in [14], which may introduce excessive latency in IIoT settings despite its demonstrable security functionality.The protocol achieves mutual authentication in only a single message exchange round, as well as ensuring both user anonymity and untraceability.An ECC-based protocol for WBAN systems (ECCPWS) has been introduced in [15] to secure wireless body area network (WBAN) communications, but its registration is too idealistic without the feasibility for implementation and an absolutely secure channel for registration.In [16,17], two bilinear pairing-based protocols have been presented to address the privacy concerns in IIoT, but they come with significant computational complexity.A lightweight AES encryption algorithm to safeguard sensing data transmitted through the Internet from potential attacks has been proposed in [18,19]; however, these protocols are vulnerable to impersonation attacks.A secure authentication protocol for IoT and cloud servers (SAPIC) based on elliptic curve cryptography (ECC) has been designed in [20], which has demonstrated its robustness by the extended Canetti-Krawczyk adversary model.However, the protocol exhibits the absence of perfect secrecy and faces challenges related to clock desynchronization.Furthermore, a massive IoT device attestation protocol has been proposed in [21] leveraging reputation and physically unclonable functions, which is not suitable to work in IIoT with user terminals.A secure mutual authentication protocol for the IoT environment (ASMAP) has been introduced in [22]; this protocol is capable of resisting impersonation attacks, replay attacks, and password-guessing attacks.However, it is susceptible to modification attacks.
The advantages and disadvantages of the most relevant authentication schemes for the proposed protocol are summarized in Table 1.
In summary, the above-mentioned solutions exhibit vulnerabilities to replay attacks and traceability attacks without privacy protections.Additionally, they suffer from superfluous parameters and other deficiencies.The existing protocols struggle to achieve a balance among authentication efficiency, security, and anonymity.To overcome those shortcomings, in this paper, we design a novel secure authentication protocol to enhance security functionality and authentication efficiency in an IIoT scenario, where a production line manager monitors the operation of a few production lines by accessing the data collected and stored at the corresponding application servers.The primary contributions produced in this paper can be summarized as follows.
• An anonymous secure authentication protocol for IIoT (ASAP-IIOT) to implement mutual authentication between the application servers and users.
• The ASAP-IIOT provides the capability to ensure user anonymity in secure communication.It utilizes both asymmetric and symmetric encryption to ensure the secure reception of user information by servers.• The ASAP-IIOT has demonstrated its logic correctness by using BAN Logic and been formally verified for its security functionality by using Scyther Tool.Moreover, it outperforms some existing solutions in terms of computational costs, communication costs, and total authentication overhead evaluated by simulation experiments.Affected by modification attacks.
The remainder of this paper is structured as follows.In Section 2, the system model under study is introduced.In Section 3, the preliminaries relevant to this work are introduced, and Section 4 delineates the details of the proposed ASAP-IIOT.In Sections 5 and 6, the security evaluation and performance evaluation are presented, respectively, with their results to show the advantages of the ASAP-IIOT.Finally, Section 7 concludes the paper with a summary.

System Model of the Proposal
The system under study is an observation system for production line management with multiple types of devices including sensors, application servers, and users.In the system, multiple sensors equipped with a production line collect information on the parameters and status of the operation and send the information to the associated application server, which controls the operation of the production line and keeps the complete information of the production line.There could be multiple such production lines existing in the system.The manager of production lines is a user in the system monitoring the operation of some production lines by retrieving the operation information stored at the corresponding application servers.The manager needs to react to some faults that occur in the system.In the overall management process, to preserve responsibility and privacy, the system should ensure that only the valid manager can access the information on the operation of some specified production lines.Invalid users should not be able to obtain any information on any server.Moreover, only the servers supervised by a particular authenticated user should be accessed by him for the retrieval of data.To achieve this goal, mutual authentication is highly demanded.
With this consideration, we design our detailed system model as shown in Figure 1.In the model, the major components include the application server S j , the user U i , and the authentication server AS.
any information on any server.Moreover, only the servers supervised by a particular authenticated user should be accessed by him for the retrieval of data.To achieve this goal, mutual authentication is highly demanded.
With this consideration, we design our detailed system model as shown in Figure 1.In the model, the major components include the application server Sj, the user Ui, and the authentication server AS.Application Server, Sj: Each Sj controls all of the sensors in one production line.The information collected by the sensors will be stored and primarily processed by the server for further analysis and retrieval.The information on the production line may include system parameters, production volumes, the overall length of the production period, the amount of products, etc. Sj should be registered or pre-authenticated to the system by the AS before offering services to ensure their validity.
User, Ui: The Ui is a supervisor of one or a few production lines who is able to access the real-time information of the production lines collected and stored by the sensors at particular servers.A specific Ui can access one or more specific Sj.The Ui should be registered or pre-authenticated on the system by the AS before starting the function to ensure their validity.
Authentication Server, AS: The AS works for the system authentication purposes responsible for the pre-authentication of users and application servers when they are connected to the system before they function.The AS will generate and distribute necessary confidential information such as keying materials for each user and each application server.Application Server, S j : Each S j controls all of the sensors in one production line.The information collected by the sensors will be stored and primarily processed by the server for further analysis and retrieval.The information on the production line may include system parameters, production volumes, the overall length of the production period, the amount of products, etc. S j should be registered or pre-authenticated to the system by the AS before offering services to ensure their validity.
User, U i : The U i is a supervisor of one or a few production lines who is able to access the real-time information of the production lines collected and stored by the sensors at particular servers.A specific U i can access one or more specific S j .The U i should be registered or pre-authenticated on the system by the AS before starting the function to ensure their validity.
Authentication Server, AS: The AS works for the system authentication purposes responsible for the pre-authentication of users and application servers when they are connected to the system before they function.The AS will generate and distribute necessary confidential information such as keying materials for each user and each application server.
The communication between the AS and users as well as between the AS and application servers for the pre-authentication is achieved by the long-term evolution (LTE) of 4G wireless communication technology and the Internet, while the communication between users and servers for the mutual authentication and information retrievals is completed by the device-to-device communication in the 4G wireless networks.

Adversary Model
In this study, the widely adopted Dolev-Yao [23] adversary model is leveraged to present the capacity of the adversary in the system, whereby communication between entities over an insecure channel with untrustworthy end devices is presumed.Under this model, adversary A is posited to have the capabilities to fully control the communication channel.Succinctly, A can intercept, alter, retransmit, fabricate, and erase any data conveyed over the insecure network.

Preliminaries
This section provides a brief overview of fundamental concepts and technical preliminaries utilized in crafting the proposed protocol, including ECC and the Burrows-Abadi-Needham (BAN) logic.

Elliptic Curve Cryptography
The ECC [24,25] works based on algebraic concepts related to elliptic curves.Let q > 3 be a prime over the prime finite fields Z q = {0, 1, . . . ,q − 1}; the elliptic curve y 2 = x 3 +ax + b is the set of E q (a, b) of solutions (x, y) ∈ Z q × Z q to the congruence y 2 = x 3 +ax + b (mod q), where a, b ∈ Z q are constants with the non-singularity of the elliptic curve property 4a 3 +27b 2 ̸ = 0 (mod q).This equation is the Weierstrass equa- tion [26][27][28].
The security of ECC relies on the intractability of the elliptic curve discrete logarithm problem (ECDLP).Let P, Q ∈ (a, b) be two points such that Q = k • P, where k is a positive integer.In fact, the smallest positive integer k with this property is called the discrete logarithm Q at base P [28,29].For the ECDLP, given k and P, computing Q is computationally facile.But determining k given Q and P is infeasible for sufficiently large q.In other words, an adversary would expend substantial computational time and resources to leverage points P and Q to derive k.
Building upon elliptic curves and the ECDLP, the security of ECC can be characterized by the elliptic curve computational Diffie-Hellman problem (ECCDHP).Let GE be the cyclic group generated by the base point G and the operation rules of Abelian groups on the elliptic curve E(a, b).Generally, elliptic curve points denote public keys, while positive integers signify private keys.To conserve memory and bandwidth, point compression techniques should be contemplated.

BAN Logic
BAN logic has emerged as a routine and efficacious methodology for analyzing authentication protocols.Underpinned by logical rules, this approach can ascertain the trustworthiness of exchanged information against malicious nodes.Generally, the inference process in BAN logic encompasses four key steps: (1) idealize the protocol model, (2) develop the initial assumptions, (3) set the specific test goals, and (4) employ the initial hypotheses and logical rules to execute the formal analysis.The notations used in the BAN logic are as follows: P|≡ X: Principal P believes a statement X, or P is entitled to believe X. #(X): Formula X is fresh.P|⇒ X: P has jurisdiction over a statement X.P X: P sees X, the principal P receives the message containing X, and P can read or repeat X.
P|∼ X: P once said X; the principal P sent a message containing X at some time.(X, Y): The formula X or Y is one part of the formula (X, Y). {X} K : The formula X is encrypted using the key K. P K ↔Q: P and Q may use the shared key K to communicate.The key K is good in that it will never be discovered by any principal except P and Q. P K ⇌ Q: K is a shared secret key between P and Q.

Rules of BAN Logic
The BAN logic holds 19 logical rules.Here, we only list six rules used in this paper.Rule 1: Message Meaning Rule This rule states that if P believes that the key K is the public key of Q and sees X encrypted under Q's private key, then P believes that Q once said X.
Rule 2: Nonce Verification Rule This rule states that if P believes that X is fresh and that Q once said X, then P believes that Q believes X.
Rule 3: Jurisdiction Rule This rule states that if P believes that Q has jurisdiction over X and P trusts Q on the truth of X, then P believes X.
Rule 4: Freshness Rule This rules states that if P believes that one part X of a formula is fresh, then the entire formula (X, Y) must also be fresh. Rule This rules states that if the agent P believes the messages X and Y distinctly, then P believes the combined formula (X, Y).
Rule 6: Send Rules This rule states that if P believes the agent Q said (X, Y), then it is deduced that P also believes the agent Q once said X.

The ASAP-IIOT
The survey on the existing literature reveals that certain referenced authentication protocols exhibit vulnerabilities to passive insider secret disclosure and replay attacks.Additionally, these protocols overlook privacy protections and remain susceptible to traceability incursions.Through further investigation, superfluous parameters and other deficiencies across different phases of an authentication process can be identified.Therefore, in this research, a new lightweight authentication protocol is designed to overcome the above-mentioned shortcomings.It cannot only provide security protection but also hold authentication efficiency.
The proposed ASAP-IIOT works in four phases, including initialization, pre-authentication of servers, pre-authentication of users, and authentication.During the initiation of the system, an initialization phase is necessary to publish protocol parameters.When a new production line has been installed, pre-authentication of the server is required to prevent malicious servers from stealing user information.Similarly, when a new manager joins, pre-authentication of the user is required to ensure a valid user.When a user accesses server information, mutual authentication is required to ensure a valid user only accesses the servers under his supervision, resulting in the generation of temporary session keys.A summary of the notations used in this paper is provided in Table 2.The session key between U i and S j ∆T Maximum communication transmission delay T1, T2, T3, T4 The current timestamps K US The shared secret key between the U i and S j (SK AS , PK AS ) Private/public key pair of authentication server (SK S , PK S ) Private/public key pair of application server (SK U , PK U ) Private/public key pair of user A Adversary

Initialization Phase
Before the system works, the AS needs to perform the necessary parameter initialization operations.In this phase, the AS publishes protocol parameters, which are listed in Table 2, by performing the following steps.

1.
The AS selects a hash function such as The AS selects its private/public keys as (SK AS , PK AS ), where Finally, the AS generates and publishes the protocol parameters, i.e., {G E , G, h, PK AS }.

4.
The user U i selects its private/public keys as (SK U , PK U ), where The S j selects its private/public keys as (SK S , PK S ), where PK S = SK S • • • G.

Pre-Authentication of Server Phase
According to the ASAP-IIOT scheme, each server of a production line must be registered on the AS before service.This step ensures the legitimacy of the S j .The pre-identity verification of servers guarantees the validity of the servers.The pre-identity verification of the servers is completed through the following steps, as illustrated in Figure 2: 1.
The server S j chooses its SID j and public key PK S .Then, the S j generates a random number M 1 to randomize its SID j and calculates PSID, A 3 , and A 4 , where Then, the S j sends the request {PSID, PK S , A 3 } to the AS via an open channel.

2.
Once the request message is received, the AS calculates A 4 and SID j according to Then, the AS verifies the validity of the message SID j and picks out a random number M 2 ∈Z q *.Next, it computes ), and w = ySK AS + M 2 , and selects number k, which is a value generated by the AS known only to the preauthenticated application servers and users during the authentication process.The AS calculates SE j = h(SID j ) and encrypts SInd j , w, and k with SE j by ESI = SInd j ⊕ SE j , Ew = w ⊕ SE j , and Ek = k ⊕ SE j .Finally, the AS sends {ESI, Ew, Ek} to the server S j over a public channel.

3.
After the message {ESI, Ew, Ek} is received, the S j calculates SE j = h(SID j ) first.Then, it computes SInd j and w as SInd j = ESI ⊕ SE j , w = Ew ⊕ SE j , and k = Ek ⊕ SE j .The server S j further computes PS j = SK S • SInd j and y = h(PS j , SInd j ).After that, the server

Pre-Authentication of User Phase
According to the ASAP-IIOT scheme, every user Ui must be registered on the AS before accessing information from the application server Sj.This step ensures the legitimacy of Ui and enables the pre-authentication of the user to be conducted through a public channel.The pre-authentication of the user phase is completed through the following steps as depicted in Figure 3: 1.The user Ui chooses its IDi and public key PKU.Then, the Ui generates a random number N1 to randomize its IDi and calculates PID, A1, and A2, where • PKAS, and PID = IDi ⊕ A2.Then, the Ui sends the request {PID, PKU, A1} to the AS via an open channel.

Pre-Authentication of User Phase
According to the ASAP-IIOT scheme, every user U i must be registered on the AS before accessing information from the application server S j .This step ensures the legitimacy of U i and enables the pre-authentication of the user to be conducted through a public channel.The pre-authentication of the user phase is completed through the following steps as depicted in Figure 3: 1.
The user U i chooses its ID i and public key PK U .Then, the U i generates a random number N 1 to randomize its ID i and calculates PID, A 1 , and A 2 , where Then, the U i sends the request {PID, PK U , A 1 } to the AS via an open channel.

2.
Once the request message is received, the AS calculates A 2 and ID i according to Then, the AS verifies the validity of the message ID i and picks out a random number N 2 ∈Z q *.Next, it computes and selects the number k, which is a value generated by the AS known only to the pre-authenticated application servers and users during the authentication process.The AS calculates E i and encrypts Ind i , v, and k with E i by EI = Ind i ⊕ E i , Ev = v ⊕ E i , and Ek = k ⊕ E i .Finally, the AS sends {EI, Ev, Ek} to the user U i over a public channel.
After the message {EI, Ev, Ek} is received, the U i calculates E i = h(ID i ) first.Then, it computes Ind i and v as Ind i = EI ⊕ E i , v = Ev ⊕ E i , and k = Ek ⊕ E i .The user U i further computes PU i = SK U • • • Ind i and x = h(PU i , Ind i ).After that, the user If they are equal, the user U i stores the message {Ind i , v, k} in its database safely and then computes K US = kSK U • PK S , where K US is the shared secret key between the user U i and the S j .It is obvious that the S j computes this session key as K' US = kSK S • • • PK U , which is equal to the computed key on the user side.

Authentication Phase
When the user Ui wants to access data from the Sj, the user and server need to complete mutual identity authentication and key negotiation.The authentication phase is

Authentication Phase
When the user U i wants to access data from the S j , the user and server need to complete mutual identity authentication and key negotiation.The authentication phase is completed in the following steps as depicted in Figure 4.If a manager is in charge of m production lines, he needs to perform this mutual authentication for m rounds.

1.
The user U i selects a random number N 3 ∈ Z q *, calculates Q, R, and c, and then computes E U = E Kus (c, PU i , Ind i , T1).Next, it sends the message of authentication request {E U , R, T1} to the server S j .2.
After the message {E U , R, T1} is received by the server S j at time T2, the server S j checks the timestamp T1 using the inequality |T2 − T1| ≤ ∆T.If it is not established, the S j will reject the request.Otherwise, the S j approves T1 and goes to the next step to compute Q ′ , K ′ US , and {c, PU i , Ind i , T ′ 1}.Then, the server S j checks whether T1 = T ′ 1.If it is not equal, the session will end.Otherwise, the S j recognizes the user U i as a valid user to compute x = h(PU i , Ind i ) and verifies whether c•G = xPK AS + R + PK U + Ind i .If the equation does not hold, the session will end.Otherwise, the S j selects a random number N 4 ∈ Z q * and calculates F = N 4 • G, SU = N 4 • PK U , Ah = h(PU i , Q, F, T3), and SK ij = h(Ah, PU i , SU) as the session key.Finally, the server S j sends the {Ah, F, T3} to the U i in response to the authentication request.

3.
After the message {Ah, F, T3} is received by the U i at time T4, the user U i checks the inequality |T4 − T3| ≤ ∆T.If it does not hold, the user U i will reject the response of the server S j .Otherwise, the U i computes Ah ′ = h(PU i , Q, F, T3).Then, it verifies whether Ah ′ = Ah.If yes, the U i finds the server S j as a valid server and computes SU = SK U • • • F and SK ij = h(Ah ′ , PU i , SU) as the session key.Since , it is obvious the generated session key on the U i side is equal to the generated session key on the S j side.

Security Evaluation
In this section, we commence with a logical correctness proof to assess the ASAP-IIOT scheme by using BAN logic.Subsequently, the ASAP-IIOT is formally verified by using the Scyther tool.Finally, a qualitative security analysis of the proposed protocol is performed to demonstrate its success in meeting the security objectives.

The Logic Correctness Proof by BAN Logic
In this subsection, we use BAN logic to prove the logic correctness of the ASAP-IIOT scheme.Due to the similarity between the pre-authentication of user and the preauthentication of server, and considering that user entry and exit from the system are more frequent, we will only prove the pre-authentication of user process and the mutual authentication process in this context.The two authentication processes are idealized in BAN logic first.Then, reasonable assumptions are made with expected security goal setting.And finally, we reason and infer whether these security goals can be achieved.

1.
Establishment of the idealized protocol model In order to idealize the ASAP-IIOT scheme into a BAN logic model, irrelevant components should be ignored.In the model, U i , S j , and AS are considered the principal U i (1 ≤ i ≤ n), S j (1 ≤ j ≤ m), and AS, respectively.The generic forms of ASAP-IIOT are provided below: Message 1: Message 3: U i → S j : {E U , R, T1}.Message 4: S j → U i : {Ah, F, T3}.

Establishment of the initial assumption
By analyzing the ASAP-IIOT, some initiative assumptions can be obtained.All of these assumptions are based on factual knowledge and are able to facilitate key agreement verification.According to Equation ( 5), we apply Rule 6 to deduce the following:

Hypothesis 3: U
According to Equation ( 5), we apply Rule 6 to deduce the following: According to Hypothesis 6 and Equation ( 9), we apply Rule 2 to deduce the following: According to Hypothesis 7, Equations ( 8) and ( 10), we apply Rule 2 and Rule 3 to deduce the following: According to Hypothesis 8 and Equation ( 11), we deduce the following: According to Hypothesis 9 and Equation ( 7), we apply Rule 2 to deduce the following: According to Hypothesis 10 and Equation ( 13), we apply Rule 3 to deduce the following: According to Hypothesis 11, 12, Equations ( 10)-( 12) and ( 14), we apply Rule 5 to deduce the following: According to Hypothesis 13 and Equation (10), we deduce the following: According to Equation (7) and Equation ( 16), we deduce the following: which satisfies Goal 2.
According to Message 3, we obtain the following: According to Hypothesis 14, 15, and Equation ( 18), we apply Rule 2 to deduce the following: According to Equation ( 19), we apply Rule 6 to deduce the following: According to Hypothesis 16 and Equation ( 20), we apply Rule 3 to deduce the following: According to Hypothesis 12, 17-19 and Equation ( 21), we apply Rule 5 to deduce the following: According to Equation (7) and Equation ( 16), we deduce the following: which satisfies Goal 3.

Formal Verification by Scyther Tool
The Scyther tool [30] is an automated, remarkable formal verification tool for inspecting protocol security against identity attacks.The standard version works based on the Dolev-Yao model [23].As such, it probes protocol security by harnessing security assertions.Moreover, it corroborates all security assertion categories in the protocol, graphically engendering any incursions per assertion.The Scyther tool employs the security protocol description language (SPDL) for describing the model of the protocol under investigation.
Scyther also provides a graphical user interface.After the security claims, roles, and protocol have been specified, security validation begins by executing the authentication command.One important assumption of the model is that it espouses a black-box cryptographic model.With this tool, protocols are modeled based on role definition.Leveraging Scyther, both the correctness and the authenticity of security protocols can be examined.We therefore modeled the proposed protocol according to the SPDL to verify protocol claims.
The ASAP-IIOT is modeled according to the definition of the role of participants in the protocol and then these roles communicate to each other through recv and send channels.In this section, only the pre-authentication of user process and the mutual authentication process are verified because the process of the pre-authentication of server is similar to that of the pre-authentication of user.The verification results are shown in Figures 5 and 6.The result for each claim is either valid with OK or invalid with Fail.For both user and server roles, all claims return OK without attacks found.For example, the validation of non-injective agreement (Niagree) ensures that the user and server agree on the content of exchanged messages, while the validation of non-injective synchronization (Nisynch) is a claim to ensure that the user and the server communicate following the same order of exchanged messages.The final result shows that the proposed ASAP-IIOT guarantees the secrecy of sensitive parameters like N 1 , x, and Ind i.In summary, these results show that the ASAP-IIOT scheme is secure to meet most of the security properties.

Security Analysis
This section provides an informal analysis of the security aspects of the proposed scheme.A summary of the security assessments for the ASAP-IIOT, in comparison to other relevant schemes, is presented in Table 3.

Replay attacks
In the ASAP-IIOT scheme, the U i and S j leverage random values including N 3 , N 4 , and timestamps to uphold message freshness among the participants in each session.It can circumvent clock asynchronization predicaments while fostering resilience against replay attacks.

Impersonation attacks
In order to impersonate the S j , the attacker A has to create a valid response as an authentication response {Ah, F, T3}, where Ah = h(PU i , Q ′ , F, T3).Since attacker A cannot compute Ah without having the secret values of Q ′ = SK S • • • R, T3, and U i , which are generated through decryption of E U by the key of K ′ US = SK S • • • PK U , A has to generate a valid authentication request {E U , R, T1} to forge the identity of the user U i , where R = N 3 • • • G, E U = E Kus (c, PU i , Ind i , T1), and c = v + N 3 + SK U .However, A is not able to calculate valid corresponding c and E U because it lacks cognizance of SK U .Therefore, the S j can detect impersonation attacks by validating c.If G = x• • • PK AS + R + PK U + Ind i , it is verified.So, the ASAP-IIOT demonstrates comprehensive resilience against U i and S j impersonation assaults.

Modification attacks
In the authentication phase, if the AS sends {Ah, F, T3} to the U i and the attacker A changes the message {Ah, F, T3}, the U i can recognize this change by checking whether Ah ′ = Ah.Since Ah ′ is computed as Ah ′ = h(PU i , Q, F, T3), where PU i = SK U • • • Ind i, and it is seen that the PU i can affect the value of Ah ′ , the ASAP-IIOT scheme has full capacity resistance to modification or manipulation attacks.
Sensors 2024, 24, x FOR PEER REVIEW 14 of 23 channels.In this section, only the pre-authentication of user process and the mutual authentication process are verified because the process of the pre-authentication of server is similar to that of the pre-authentication of user.The verification results are shown in Figures 5 and 6.The result for each claim is either valid with OK or invalid with Fail.For both user and server roles, all claims return OK without attacks found.For example, the validation of non-injective agreement (Niagree) ensures that the user and server agree on the content of exchanged messages, while the validation of non-injective synchronization (Nisynch) is a claim to ensure that the user and the server communicate following the same order of exchanged messages.The final result shows that the proposed ASAP-IIOT guarantees the secrecy of sensitive parameters like N1, x, and Indi.In summary, these results show that the ASAP-IIOT scheme is secure to meet most of the security properties.Man-in-the-middle attacks Due to its capacity against modification or manipulation attacks, the ASAP-IIOT scheme has full ability to resist man-in-the-middle attacks.Since every party verifies the integrity of exchanged messages, any alterations will be discernible to the recipient.

Traceability attacks
In traceability attacks, messages with constant values may reveal the context or patterns of the communication.Thwarting such attacks necessitates message randomization via pseudorandom number integration.The proposed scheme incorporates ephemeral random secrets N 3 and N 4 to induce requisite message randomness on a per-session basis, thereby mitigating traceability incursions.

The property of non-traceability
Since attacker A cannot obtain any identifying information about the participants by listening to the messages delivered over the wireless channels in the pre-authentication phase, and the messages exchanged over the wireless channels in the authentication phase remain protected by the ECC and hash functions, the adversary is incapable of gleaning the information of the participants in the communication.Consequently, in the ASAP-IIOT scheme, the adversary tracing of the U i and S j could be prevented.

Security Analysis
This section provides an informal analysis of the security aspects of the proposed scheme.A summary of the security assessments for the ASAP-IIOT, in comparison to other relevant schemes, is presented in Table 3.
Table 3. Security feature comparison of the ASAP-IIOT with other protocols.

7.
The property of user anonymity In the proposed ASAP-IIOT scheme, an adversary cannot extract any static information pertaining to user U i ′ s identity, namely, U i and Ind i .Since the authentication request {E U , R, T1} comprises Indi and U i encrypted symmetrically by K US, and the adversary lacks cognizance of SK U , SK S , and K US for decrypting E U and faces the ECCDHP for computing K US , user anonymity properties can be upheld by the ASAP-IIOT scheme.

8.
The property of clock synchronization According to the ASAP-IIOT, the U i and S j utilize random values and timestamps to ensure the freshness of exchanged messages within each session.By incorporating these random values and timestamps in the exchanged messages, the ASAP-IIOT effectively mitigates desynchronization issues, thereby circumventing problems associated with clock desynchronization.

9.
The property of perfect secrecy In the ASAP-IIOT, the session key generated by user U i during the authentication phase is represented as SK ij = h(Ah ′ , PU i , SU).Even if an attacker captures long-term keys like K US , they are unable to compute session keys used in previous sessions or those intended for future sessions.This is because the value of the session key depends on random values associated with the current session, such as N 3 and N 4 .Attackers cannot retrieve N 3 and N 4 separately from R and F through ECCDHP, ensuring both forward and backward secrecy features for the session key.Therefore, the ASAP-IIOT exhibits complete confidentiality, as concluded from the aforementioned context.

Performance Evaluation
In this subsection, the performance of the ASAP-IIOT scheme is evaluated and compared with those of other state-of-the-art schemes including the ECCbAP scheme in [12], the AASM scheme in [14], the SAPIC scheme in [20], and the ASMAP scheme in [22] in terms of performance metrics such as computation costs, communication costs, total authentication overhead, and energy overhead.The performance evaluation is only conducted on the mutual authentication process to disclose the real-time features of the security schemes under the study.The results of these comparisons are shown in Table 4, Table 5, Figure 7, Figure 8, Figure 9, and Figure 10, respectively.

Computation Costs
We have established a testing environment to simulate the computational overhead of the cryptographic operations required in the ASAP-IIOT scheme and the other three schemes mentioned above.
The simulation experiments are conducted using the C/C++ OPENSSL library [31] and are performed on an Intel(R) Core (TM) i5-8300H with a CPU 2.30 GHz as the Ui; it is assumed that the computational speed of the Sj is twice of that of the Ui.The execution times of the single bilinear function (Tbp), the pairing hash function (Th), the symmetric encryption and decryption (Ts), the scalar point multiplication based on ECC (Tm), the multiplicative inverse operation (Ti), the modular exponentiation operation (Te), and the   Figure 10.Energy consumed during a successful execution.

Computation Costs
We have established a testing environment to simulate the computational overhead of the cryptographic operations required in the ASAP-IIOT scheme and the other three schemes mentioned above.
The simulation experiments are conducted using the C/C++ OPENSSL library [31] and are performed on an Intel(R) Core (TM) i5-8300H with a CPU 2.30 GHz as the Ui; it is assumed that the computational speed of the Sj is twice of that of the Ui.The execution times of the single bilinear function (Tbp), the pairing hash function (Th), the symmetric encryption and decryption (Ts), the scalar point multiplication based on ECC (Tm), the   Figure 10.Energy consumed during a successful execution.

Computation Costs
We have established a testing environment to simulate the computational overhead of the cryptographic operations required in the ASAP-IIOT scheme and the other three schemes mentioned above.
The simulation experiments are conducted using the C/C++ OPENSSL library [31] and are performed on an Intel(R) Core (TM) i5-8300H with a CPU 2.30 GHz as the Ui; it is assumed that the computational speed of the Sj is twice of that of the Ui.The execution times of the single bilinear function (Tbp), the pairing hash function (Th), the symmetric encryption and decryption (Ts), the scalar point multiplication based on ECC (Tm), the P1, P2, P3, and P4 is 1024 bits in length, and E SK [H(SK)] requests 320 bits in length.The transmission delay of the user is 0.04736 ms, while the communication cost of the user is 0.05076 ms.The transmission delay of the server is 0.04096 ms, causing the communication cost of the server to be 0.04426 ms.The total transmission delay is 4 ECC + ESK[H(SK)] = 0.08832 ms, while the total communication cost is 0.09342 ms.In the ASMAP scheme, the user transmits an authentication message {P 1 , P 2 , EI i , V i } to the server with 960 bits of information.The transmission delay of the user is 0.0192 ms, causing the communication cost of the user to be 0.0226 ms.Then, the server transmits a message {P 3 , P 4 , T ′ i } to the user of 800 bits in length.The transmission delay of the server is 0.016 ms, causing the communication cost of the server to be 0.0177 ms.Consequently, the total transmission delay is 0.0352 ms, while the total communication cost is 0.0403 ms.
In the ASAP-IIOT scheme, the user transmits {EU, R, T1} to the server, where R constitutes elliptic curve group elements encapsulating 1024 bits of information, T1 occupies 32 bits, EU = EKus(c, Ui, Indi, T1) with Ui = N2• • • PKU, and Indi is elliptic curve group points of 1024 bits each, while c ∈ Zq* occupies 128 bits.Consequently, this request holds 3264 bits of information.Therefore, the transmission delay of the user is 0.06528 ms, causing the communication cost of the user to be 0.06698 ms.Additionally, the server returns an authentication response {Ah, F, T3} to the user, where Ah = h(Ui, Q ′ , F, T3) requests 160 bits, F spans 1024 bits, and T3 occupies 32 bits, adding up to (160 + 1024 + 32 = 1216) bits.Therefore, the transmission delay of the server is 0.02432 ms, causing the communication cost of the server to be 0.02602 ms.The total transmission delay is 0.0896 ms, while the total communication cost is 0.093 ms.

Authentication Overheads
Authentication overhead is normally the sum of the computation cost and communication cost.However, any protocol may face various types of attacks, broadly categorized as known and unknown attacks.The known attacks are the attacks which have been ascertained to be thwarted by a security scheme and their occurrence cannot break the operation of the protocol without an impact on the protocol's execution time.On the other hand, unknown attacks have the potential to disrupt the protocol's operation and produce negative impacts on the execution time of a security protocol because they could be new malicious attacks or they are not necessarily prevented by a security protocol.With the consideration of coexistence of the known and unknown attacks, a performance evaluation on the robustness of the four protocols in comparison has been conducted following the method reported in [33][34][35].Analyzing the impact of these unknow attacks, it is assumed that the probability of an unknown attack occurring at the i-th step is q = 1 n , where n represents the total number of operational steps in a protocol.Therefore, the average time required for a successful execution of the protocol can be calculated as follows: where p represents the proportion of unknown attacks to total attacks, t suc represents the time cost when no attack occurs, and t fail_i indicates the total time cost before an attack occurs in the i-th step.As shown in Figure 9, as the proportion of unknown attacks gradually increases, there is a rising trend in the average time required for successful execution of the protocol.Compared to the ECCbAP scheme, the AASM scheme, the ASMAP scheme, and the SAPIC scheme, the ASAP-IIOT scheme takes the lowest average time to successfully complete an authentication process under known and unknown attacks.Moreover, as the proportion of unknown attacks increases, the ASAP-IIOT solution exhibits a relatively small variation in the average time required for a successful execution.

Energy Overhead
The energy is utilized based on the formula E = V * I * T, where voltage (V), current drawn (I), and the operation time (T) are the contributing factors.In our system, V = 220 V and I = 1.6 A. Figure 10 illustrates the energy consumed during a single successful execution of the protocol between the proposed scheme and the corresponding existing scheme.The highest energy overhead is that of the ECCbAP scheme at 5.84 J.The energy consumption of the SAPIC scheme is 5.03 J, the AASM scheme consumes 4.9 J, and the ASMAP scheme consumes 4.04 J.The proposed scheme incurs the lowest energy overhead of 3.73 J for the IoT device.

Further Discussions
The proposed protocol has advantages in both security functionality and system performance.It is a lightweight solution compared with other benchmark protocols.The ASAP-IIOT exhibits the best performance in the scenarios with or without network attackers compared to other protocols.The study results demonstrate that ASAP-IIOT's overhead is more favorable than alternative protocols.
However, implementing the ASAP-IIOT scheme may present another challenge.While we have tested the robust performance of our protocol under simulated attacks, considering the infrastructure of real-world networks that connect a large number of devices, whether frequent user data storage poses certain security risks requires extensive testing and simulation.Additionally, the security of the proposed protocol depends on the robustness of the cryptographic key exchange function ECDLP.The emergence of quantum computing attacks poses a threat to the security of traditional encryption algorithms, including ECDLP.Therefore, future research needs to focus on developing post-quantum cryptographic techniques to resist quantum computing attacks.
Furthermore, the proposed ASAP-IIOT scheme works at the data link layer to protect the operations of the IIoT systems from various malicious protocol attacks.However, in the implementation of this scheme, there could be some physical layer attacks to impair the communication among the devices in the system.Those possible physical layer attacks may include side-channel attacks (SCA) on the ECC, simple power analysis (SPA) on the ECC, and differential power analysis (DPA) on the ECC, aiming to exploit various leaked information generated during hardware execution to obtain ciphertext information.We are fully aware of the severe threats generated by those physical layer attacks on the operation of the IIoT systems.Since the proposed ASAP-IIOT solution cannot resist the physical layer attacks, some existing solutions can be found in [36,37] to eliminate them.

Conclusions
In this paper, a lightweight ECC-based authentication and key agreement protocol ASAP-IIOT has been developed for mutual authentication between users and application servers.The logical correctness of the protocol has been proven by BAN logic, while the security functionality of the ASAP-IIOT scheme has been validated by using the Scyther tool, corroborated by qualitative security analysis.It has been demonstrated that compared to other relevant schemes, the ASAP-IIOT scheme can overcome most security vulnerabilities with reasonable computational, communication, and authentication costs.The overhead analysis indicates that among the referenced schemes compared, the ASMAP scheme shows the lowest overhead, while in comparison to the ASMAP scheme, our proposed solution demonstrates reductions of 0.31 J in energy and 0.8773 ms in authentication overheads.It shows that the ASAP-IIOT scheme is more suitable and feasible to be deployed in future IIoT systems.
they are equal, the server S j stores the message {SInd j , w, k} in its database safely and then computes K US = kSK S • • • PK U , where K US is the shared secret key between the user U i and the server S j .users during the authentication process.The AS calculates SEj = h(SIDj) and encrypts SIndj, w, and k with SEj by ESI = SIndj ⊕ SEj, Ew = w ⊕ SEj, and Ek = k ⊕ SEj.Finally, the AS sends {ESI, Ew, Ek} to the server Sj over a public channel.3.After the message {ESI, Ew, Ek} is received, the Sj calculates SEj = h(SIDj) first.Then, it computes SIndj and w as SIndj = ESI ⊕ SEj, w = Ew ⊕ SEj, and k = Ek ⊕ SEj.The server Sj further computes PSj = SKS • SIndj and y = h(PSj, SIndj).After that, the server Sj checks whether w • G = y • PKAS+ SIndj.If they are equal, the server Sj stores the message {SIndj, w, k} in its database safely and then computes KUS = kSKS • PKU, where KUS is the shared secret key between the user Ui and the server Sj.

2 .
Once the request message is received, the AS calculates A2 and IDi according to A2 = SKAS • A1, and IDi = PID ⊕ A2.Then, the AS verifies the validity of the message IDi and picks out a random number N2∈Zq*.Next, it computes Indi = N2 • G, PUi = N2 • PKU, x = h(PUi, Indi), and v = xSKAS + N2, and selects the number k, which is a value generated by the AS known only to the pre-authenticated application servers and users during the authentication process.The AS calculates Ei and encrypts Indi, v, and k with Ei by EI = Indi ⊕ Ei, Ev = v ⊕ Ei, and Ek = k ⊕ Ei.Finally, the AS sends {EI, Ev, Ek} to the user Ui over a public channel.3.After the message {EI, Ev, Ek} is received, the Ui calculates Ei = h(IDi) first.Then, it computes Indi and v as Indi = EI ⊕ Ei, v = Ev ⊕ Ei, and k = Ek ⊕ Ei.The user Ui further computes PUi = SKU • Indi and x = h(PUi, Indi).After that, the user Ui checks whether v • G = x • PKAS + Indi.If they are equal, the user Ui stores the message {Indi, v, k} in its database safely and then computes KUS = kSKU • PKS, where KUS is the shared secret key between the user Ui and the Sj.It is obvious that the Sj computes this session key as K'US = kSKS • PKU, which is equal to the computed key on the user side.

Figure 3 .
Figure 3. Pre-authentication of user by the ASAP-IIOT.

Figure 3 .
Figure 3. Pre-authentication of user by the ASAP-IIOT.

Sensors 2024 ,
24,  x FOR PEER REVIEW 10 of 23 completed in the following steps as depicted in Figure4.If a manager is in charge of m production lines, he needs to perform this mutual authentication for m rounds.

Figure 4 .
Figure 4. Authentication phase of the ASAP-IIOT.1.The user Ui selects a random number N3 ∈ Zq*, calculates Q, R, and c, and then computes EU = EKus (c, PUi, Indi, T1).Next, it sends the message of authentication request {EU, R, T1} to the server Sj. 2. After the message {EU, R, T1} is received by the server Sj at time T2, the server Sj checks the timestamp T1 using the inequality |T2 − T1| ≤ ∆T.If it is not established, the Sj will reject the request.Otherwise, the Sj approves T1 and goes to the next step to compute Q′, K′US, and {c, PUi, Indi, T′1}.Then, the server Sj checks whether T1 = T′1.If it is not equal, the session will end.Otherwise, the Sj recognizes the user Ui as a valid user to compute x = h(PUi, Indi) and verifies whether c•G = xPKAS + R + PKU + Indi.If the equation does not hold, the session will end.Otherwise, the Sj selects a random number N4 ∈ Zq* and calculates F = N4 • G, SU = N4 • PKU, Ah = h(PUi, Q, F, T3), and SKij = h(Ah, PUi, SU) as the session key.Finally, the server Sj sends the {Ah, F, T3} to the Ui in response to the authentication request.

Figure 5 .
Figure 5. Verification of security claims between Ui and AS.

Figure 5 .
Figure 5. Verification of security claims between U i and AS.

23 Figure 6 .
Figure 6.Verification of security claims between Ui and Sj.

Figure 6 .
Figure 6.Verification of security claims between U i and S j .

Figure 9 .
Figure 9. Average time taken for one successful protocol execution.

Figure 10 .
Figure 10.Energy consumed during a successful execution.

Figure 9 .
Figure 9. Average time taken for one successful protocol execution.

Figure 9 .
Figure 9. Average time taken for one successful protocol execution.

Figure 9 .
Figure 9. Average time taken for one successful protocol execution.

Figure 10 .
Figure 10.Energy consumed during a successful execution.

Table 1 .
Summary of relevant authentication protocols.

Table 2 .
The notations used.

Table 3 .
Security feature comparison of the ASAP-IIOT with other protocols.

Table 4 .
Comparison of computational costs.

Table 5 .
Comparison of communication costs.