SELAMAT: A New Secure and Lightweight Multi-Factor Authentication Scheme for Cross-Platform Industrial IoT Systems

The development of the industrial Internet of Things (IIoT) promotes the integration of the cross-platform systems in fog computing, which enable users to obtain access to multiple application located in different geographical locations. Fog users at the network’s edge communicate with many fog servers in different fogs and newly joined servers that they had never contacted before. This communication complexity brings enormous security challenges and potential vulnerability to malicious threats. The attacker may replace the edge device with a fake one and authenticate it as a legitimate device. Therefore, to prevent unauthorized users from accessing fog servers, we propose a new secure and lightweight multi-factor authentication scheme for cross-platform IoT systems (SELAMAT). The proposed scheme extends the Kerberos workflow and utilizes the AES-ECC algorithm for efficient encryption keys management and secure communication between the edge nodes and fog node servers to establish secure mutual authentication. The scheme was tested for its security analysis using the formal security verification under the widely accepted AVISPA tool. We proved our scheme using Burrows Abdi Needham’s logic (BAN logic) to prove secure mutual authentication. The results show that the SELAMAT scheme provides better security, functionality, communication, and computation cost than the existing schemes.


Introduction
The Internet of things (IoT) has gained tremendous popularity in the last decade with the advent of many powerful, low-cost devices such as sensors, RFIDs, etc., coupled with various communication media. Recently, the implementation of IoT in industries with Cyber-Physical System (CPS) as a part of the world of production and network connectivity is known as Industrial IoT (IIoT) [1]. The integration combines industrial devices equipped with communication, sensors, and Internet-connected actuator modules [1]. The devices are responsible for sensory data capture, environmental and industrial conditions tracking, and raw goods transport. However, it is estimated that the industrial IoT market will hit $123.89 billion by 2021 [2]. Industrial IoT (IIoT) can significantly enhance communication, efficiency, scalability, time savings, and cost savings for industrial sectors. Interoperability between devices and machines using different protocols with different architectures and the security of such protocols and data generated with these devices is the primary concern for IIoT [2][3][4]. As has been stated, industrial devices capture, store, transmit, or exchange large amounts of highly sensitive consumer information. The attacker can intercept and alter this transmitted data. These attacks threaten confidentiality in the information collected Fog providers may be different parties because of various deployment solutions; the existing infrastructure for fog can be used for wireless carriers (e.g., GSM) that control home or cellular base stations. Fog infrastructure can also be developed by cloud service providers needing their cloud services to the network edge. Because of the lack of authentication services, a rogue fog node/service will be a fog device or fog instance, which claims to be legitimate and attempts to control edge's fog nodes [10]. For example, a fog administrator may permit an insider attack not to instantiate a legitimate attack but to instantiate a rogue fog instance. For example, in an insider attack, a fog administrator can handle fog instances but can instead instantiate a rogue fog instance [9]. After communication, an adversary can manage incoming or outgoing user or cloud requests, capture or control user data stealthily, and initiate further attacks quickly. A fake fog node or server is a serious threat to the security and privacy of user data. Likewise, in 2012, Fire-base Google was launched to allow a front-end application to connect directly to a back-end database. However, they discovered that the Fire-base is vulnerable to the Stuxnet attack due to the absence of authentication and authorization [11]. Thus, due to an exposed interconnection between the edge devices and the fog node, authenticating users/devices and ensuring platform security becomes a huge challenge. The devices often have a low computational capacity and low power consumption, particularly in the IoT system, which requires reducing authentication and encryption costs while ensuring information security [12]. Therefore, cross-platform authentication in cloud computing has not been considered before, and this gives rise to the problem of trustiness between cross-platforms in fog computing. Cross-platforms are places where multiple fog nodes authenticate mutually and exchange data [13][14][15][16][17]. Hence, developing lightweight cryptographic protocols to protect Industrial IoT devices against vulnerable attacks and satisfying device constraints are needed.
Thus, we propose a secure and lightweight multi-factor authentication scheme for cross-platform Industrial IoT systems (SELAMAT). The scheme intends to improve the security and establish secure communication between the edge devices and fog nodes. The SELAMAT scheme uses the AES-ECC algorithm to design an efficient key management system. AES (Symmetric Key Encryption Scheme) for the ECC Message Encryption (A-Symmetric Key Encryption Scheme) for the Secure Key Management mechanism is used in combination with data hiding to provide strong encryption and decryption requirements by using the advantages of both the cryptographic schemes. With our multi-factor authentication (MFA), three types of factors are used: Username/Password (something you know), smart card (something you have), and biometric (Fingerprint). Our MFA secures the user information from password guessing attacks, session attacks, and impersonation attacks. It provides layered security, making access in the fog node more difficult for unauthorized users to a target such as the physical location, device, network, application, or database.

Industrial IoT Security Requirements and Issues
The industrial Internet of things improves the efficiency, scalability, and security of the industrial environment applications. In such sensitive applications, introducing the resource-constrained IoT devices might bring essential security and privacy concerns.

Security Requirements
Several types of research [18,19] have underlined security requirements that must be considered in IIoT, particularly fog nodes and sensors. We further identify the most critical security and privacy requirements: • Availability: The network infrastructure, devices (e.g., sensors), and fog nodes that handle the control and optimization queries should be continually available. Besides, unauthorized users should not deny allowing authorized users to handle queries. • Confidentiality: The data and queries between edge nodes and fog nodes exchanged are confidential and must not be revealed by unauthorized third parties. • Integrity: The type of data sharing between edge devices and fog nodes improves energy transmission decision making. For better decision-making, the integrity of these data is fundamental. We also need to deal with injection attacks that aim to inject false measures into the fog computing infrastructure that could interrupt decisions. • Authenticity: Authentication of ubiquitous IoT connectivity is based on the nature of Industrial IoT environments in which communication between equipment and equipment Machine-to-Machine (M2M), between man and device, or between user and other would be possible. The authorizations property allows only authorized entities (any authenticated entity) to carry out certain network operations. It is necessary to design a secure authentication scheme to prevent unauthorized users from accessing the nodes. • Non-repudiation: Any party in the system between the utilities' fog node servers and the edge nodes must not deny that they subsequently have not received such data or control commands. • Privacy: Fog computing infrastructure information includes fine-grained data about users and even industrial machines. These data reveal information about the activities of customers in industries and companies. It is compulsory to encrypt and make these data untraceable.

Security Issues
Fog computing should withstand some security challenges in the Industrial IoT setting. We present the relevant ones as follows: • Limitations of information system technology: The number of attacks is increasing because many industries are interconnected with cloud computing, which may affect the fog computing network's availability. The integrity of data, confidentiality, and privacy; spoofing servers; injection; DoS/DDoS attacks; impersonation attacks; and replay attacks, among others, are just some examples of attacks. • Data sensitivity and privacy: The information shared between the network node and other fog nodes involves sensitive customer-specific information such as object tracking, power consumption, real-time data streaming, and performance monitoring.
Neighbors should not leak this information while keeping it exploitable across fog nodes. • Lack of Authentication: Fog computing nodes must be securely designed. They must verify information from a known source and ensure that it was not corrupted to avoid introducing some threats. The weak authentication mechanism for industrial sectors might allow attackers to impersonate a legitimate user. For example, an adversary may execute a password guessing attack, man-in-the-middle, or replay attack to access the targeted node. Therefore, a secure authentication scheme must be designed to prevent such attacks. • Lack of data transmission encryption: The data exchange between edge devices and fog nodes is typical, not encrypted, and transmitted through a public channel. In this case, the attacker can still capture the network's data by using a simple network sniffer to monitor the connection between the user and the IIoT device. The attacker also can record the message and obtain the edge device information to perform a replay attack. The non-encrypted form allows the attacker to gather information about the targeted node, such as its database used by the node/device. • Complexity: Researchers have proposed several authentication schemes for the IIoT environment, but those schemes are mostly based on cryptographic techniques requiring a high computational cost. Some of the cryptographic techniques use an extensive operation, such as the identity-based verification and multiplication operation. Since industrial IoT devices are limited resources with low power, a lightweight authentication scheme must be designed for IIoT suitability.

Related Works
Many researchers recently focused on providing secure authentication for industrial IoT systems. However, Chen et al. (2020) proposed a fog node Authentication Secure Authenticated Key Exchange Scheme [20]. Moreover, the proposed scheme uses only such basic operations because of limited resources of fog nodes and users, such as multiplication of elliptic curve cryptography point operations, bit-wise exclusive OR, and hash-only functions, instead of other complex algorithms. They argued that their system overcomes the risk of a temporary secret leakage attack. They proposed a three-step authentication system of: (1) the user registration phase, (2) fog server registration phase, and (3) login and authentication phase. However, due to a large amount of computation and communication, it involves heavy calculations due to public cryptography and signature algorithms or other time-consuming calculations (e.g., bilinear pairings). Munir et al. (2018) [21] proposed a biometric smart card authentication scheme based on pin and fingerprint identification in fog computing. In Phase 1, the user enters his information in two phases. Simultaneously, the pin is encrypted with DES and the fingerprint, which uses a robust mathematical algorithm that is not invertible and where both are stored on the fog server and smart card. In Phase 2, the user inserts the card and receives the verified information. The unauthorized individual has access to these data if some government or other source leaks the biometric data. However, privacy issues have been increased because an individual's unique identity is a biometric blueprint. Since the template cannot be decoded back to biometric data, it can be used to track individuals if a database links the user to a specific biometric prototype, so the user's operation can be tracked unlawfully. Such threats must be tackled, and cancellable biometrics are a potential solution.
Rahman et al. (2019) [22] suggested that an enhanced mutual authentication security scheme be addressed based on an advanced encryption protocol and hashed message authentication code for fog computing. The authors tried to avoid the mid-attack in interactions between the fog user and registration authority. The attacker compromises the user's identity by sending the identity to the registering authority as fog users obtain from the registering authority the master secret key. However, this work still built session keys with a long-term master secret. A different scheme of mutual authentication is proposed for fog-based computer environments with constrained devices [23]. The proposed scheme, called Octopus, needs a long-lived secret key to authenticate with any fog server. However, it is about setting up and resuming the session. Session hijacking on the transport layer will result in a DoS attack. An attacking node may individually identify the victim node to continue between the two nodes. The nodes that are communicating may need to re-transmission messages by altering sequence numbers [22,24,25]. In [26], the authors provided secure key management and user authentication scheme called the SAKA-FC. It is defined as a secure communication protocol that supports fog and uses a one-way hash function and XOR that is bitwise supported by IoT-resource-driven devices. The scheme suffers from controlling the privileged insider attack and cannot provide a secure environment to compromise the attack. It should be noted that the authentication of users and binding agreements are not secured against future attacks. The scheme is not as lightweight as it requires more complex computing and communication. As a result, the scheme proposed for this environment will not correctly authenticate users in cloud-driven IIoT environments [27].
Similarly, Wang et al. [12] designed an anonymous lightweight authentication protocol for multi-level architecture fog-based applications. The protocol dynamically updates both sides of the session keys and ensures anonymous user authentications. The scheme proposed a key group protocol for management. The server can share with a specific attribute the key to desired communication nodes, and a private key between the two fog nodes can be created and updated without having to leak keys on the servers. However, the available group key management systems are not enough for mobile devices and require time-consuming computations. Moreover, He et al. [28] presented a new Mobile Healthcare Social Networks (MHSNs) handshake scheme. The scheme is based on hierarchical identity-based cryptography. The system consists of three tiers, while the highest level is a trusted authority using the Schnorr signature scheme to generate private keys to participating health centers. The second level is registered health centers with the Schnorr signature system, responsible for generating private keys. The third level is machine patients performing symptoms matching the cross-domain handshake. The system's goal was to allow two users registered in separate healthcare centers to conduct a symptom-matching cross-domain handshake. However, the scheme requires more computational effort because of its identity-based cryptographic technologies and lack of reliability due to resource-constrained devices (such as the elliptic curve) being more time consuming as they come with some operations [29,30].
In 2019, Jia et al. [31] proposed an AKE Scheme for an IoT-based fog computing health care system. Compared to conventional medical systems, data from consumer devices and sensors are transmitted via fog nodes in the fog layer instead of via the cloud. Fog nodes process, transfer, and store data to the end-user and return results. However, we found that this AKE device is vulnerable to a temporary secret attack [20]. M. Akram et al. [32] enhanced the security features by proposing an anonymous three-factor authentication scheme for multi-servers. The scheme designed was based on the elliptic curve cryptography, and the biometric information is verified by the user and the server separately. The registration center in their scheme is involved in the authentication phase and has separate responsibilities with the server. Likewise, H. Tan et al. [33] designed a pairing-free homo-graphic authentication and key management scheme for VANET dynamic cross-platform authentication. The scheme used certificateless cryptography for mutual authentication and homomorphic key management. On each active validation, dynamic updating to anonymous vehicle identity is performed to achieve privacy preservation. It mainly focuses on solving the heavy bandwidth consumption and high latency. However, their scheme is vulnerable to specific passive and active attacks such as server spoofing attacks and DoS attacks.
Venčkauskas et al. (2019) [34] presented the secure Self-Authenticable Data Transfer Protocol to address the issue of secure communication between resource-constrained devices. The authors proposed a new lightweight, secure, and authenticable transfer protocol for communication between the edge nodes and the fog nodes. Instead of UDP (User Datagram Protocol) and DTLS (Datagram Transport Layer Security) protocols, the primary purpose of the proposed protocol is to use CoAP (Constrained Application Protocol) as a secure transport. SSATP only uses primitive symmetric cryptography, allowing small devices with memory and low-end processing capacities to be easily implementable. However, DTLS must be excluded from the critical quality to suit the smart cities' resource-intensive sensor nodes [12,35,36]. From the discussion above, we can see that most of the authentication schemes are still not satisfying the fog computing requirements. Thus, a lightweight and secure authentication scheme for the fog computing architecture is urgently needed. The comparison of the related authentication scheme is illustrated in Table 1.

Preliminaries
This section introduces important cryptographic principles and basic knowledge. The elliptic cryptosystem (ECC) and AES-ECC encryption and decryption are specified. Related notes, system models, security requirements, and network assumptions are then specified.

The Elliptic Curve Cryptography
Let p > 3 be the large prime and F p be the finite field with order p, where a, b ∈ F p satisfy the following equation: 4a 3 + 27b 2 (modp) = 0. The elliptic curve E p (a, b) over the finite field F p is defined with the following equation: where (x, y) ∈ F p . The additional operation on the curve is known as the doubling point of the two points. The addition of point is otherwise specified. All points on the curve and the point at infinity are a group of abelites E(F p ) additives. Please note that ∞ = (−∞) performs as the identity element.
Definition 1 (Computational Diffie-Hellman Problem (CDHP)). Given P, aP, bP ∈ G 1 for a, b ∈ Z * q where P is a generator of G 1 , the advantage in computing ab P to solve the CDHP problem for any probabilistic polynomial-time (PPT) algorithm A is negligible, which can be defined as: Definition 2 (Elliptic Curve Discrete Logarithm Problem (ECDLP)). Given P, Q ∈ G 1 , where Q = aP. The advantage in finding the integer a ∈ Z * q to solve the ECDLP problem for any probabilistic polynomial-time (PPT) algorithm A is negligible, which can be defined as:

AES-ECC Encryption/Decryption
In this section, we explain the process of the AES-ECC algorithm for efficient key generation and secure user data transmission. The ECC is utilized to encrypt and transfer the Private Keys as AES Private Keys while AES encrypts the plain text (communication data). The process is applied when an entity needs to encrypt/decrypt the message [37,38]. The encryption/decryption processes are shown in Figure 2, and the steps are explained as follow: 1.
Data are the users' information, i.e., their identities, passwords, and biometrics.

2.
SHA-2 is used to produce a data summary. 3.
ECC-related sender private key and ECDSA module are used to produce a digital signature.

4.
According to the AES encryption module (AES private key), digital signature encryption and data to be submitted are encrypted. Then, the ciphertext data and ciphertext signature are encrypted.

5.
The AES private key is encrypted by the ECC encryption module, and then the key-ciphertext is generated. 6.
All the ciphertexts are packed and sent via the cross-d system network to the receiver. 7.
Therefore, the sender uploads the ciphertext to the authentication server. 8.
When the receiver receives the ciphertext, the receiver uses its private key to decrypt the AES key, and then decrypts the AES key data-ciphertext and signature-ciphertext. He/she uses the public key to check the signature, digest the message, and then get the plaintext by using the SHA-2 algorithm. If the message digest and plaintext are the same, the data are valid and available; otherwise, they are invalid.

SELAMAT Scheme
This section proposes a multi-factor authentication scheme for industrial IoT (IIoT) to establish secure communication between the edge devices and the fog node. The system backend architecture is shown in Figure 3; our scheme is based on a smart card, username/password, and a biometric (fingerprint). The scheme adopts the combination of the AES-ECC algorithm for secure key management. It provides a secure mutual authentication among the edge and the fog server; the mutual authentication diagram is illustrated in Figure 4. The proposed scheme comprises five phases, i.e., the setup phase, user registration phase, fog node registration phase, login phase, and the authentication phase. We explain the scheme phases as follows.

Setup Phase
The Cloud Provider Server (CPS) selects a κ-bit prime number p and an elliptic curve E/F p . The generated elliptic curve group G has a generator P. Then, CPS selects a random integer S ∈ Z * q as the system master key and calculates the system public key accordingly PK = S.p. After that, CPS choose asymmetric encryption/decryption pairs E{.}/D{.}, and cryptographic collision-resistant hash function H(.). Note that the AES shared private key is used to encrypt and decrypt the user information while being transmitted among the entities. CPS later publishes the system public parameters {G, p, q, PK, H(.)} and keep the system master key S secretly. Moreover, when the user enters his/her information, it is then encrypted using the AES symmetric algorithm. The AES key is a shared private key between the sender and the receiver, which is used to encrypt the user information, and then it is encrypted with the ECC public key shared earlier with the user. The cipher-text is then transmitted to the AS in the CPS for verification. The used notions in the proposed scheme are shown in Table 2.    The non-zero integers modulus p.

PK
The public key of the server. S The secret key of the server.

Auth u
The authenticator of the user U i .

ks u→tgs
A key session between User and TGS. tgs sk Secret key of the TGS. tgs id Ticket granting server identity. f n id Identity of the Fog node. tgs tkt Ticket granting server ticket. ks u→ f n S Key session between User and FN. f n tkt Fog Node ticket. Concatenation operation. ⊕ XOR operation.

User Registration Phase
In this phase, the user must register himself/herself at the cloud provider server to access the data that he wants to use. After that, the user Ui is issued a smart card; the authentication server (AS) in the CPS stores the user has protected biometric information Ui in its database. The registration is transmitted securely to obtain the smart card SC.
The user is not required to send his/her information in plaintext because the proposed scheme utilizes asymmetric encryption/decryption pair in which the information will be encrypted. In addition, that transmitted information is sensitive and will be handed to the server in a masked manner using the hash function for other security matters to prevent an insider attack. The user will firstly select his/her unique identity and password and input his/her biometric information. Upon receiving the request, the authentication server will decrypt the message and verify the given information whether he/she already exists in the server database or not. If U i already exists at the server, it will inform the user that the identity exists and choose another. Otherwise, the AS will start user registration by performing the following steps, as shown in Figure 5: The user inserts his/her smart card and then selects a unique user identity u id and a user password u pw and inputs his biometric information u bi . Then, the user randomly chooses an integer u sk ∈ Z * q as user private key and calculates his/her public key u pk = u sk .p. • In addition, user Ui generates a random number r1 and a process to compute bio i = H(U Bi ⊕ r 1 ) and calculates and then it uses the AES key to obtain the user information µ k {u id u pw bio i m i }. The AS verifies the received information with the one in the database. If the user exists, the AS will notify the U i to choose another identity; otherwise, the AS computes a i = H(u id s), F i = H(bio i s) and calculates Next, the authentication server AS will embed the calculated parameters {x i , n i , r i , H(.), q, p} onto the smart card SC and will send it to the U i . Those parameters will also be stored in the database and recorded as an enrolled user. Now, AS sends the parameter to the U i via a secure channel. • The user U i receives the embedded smart card SC and writes the parameters Msg.2: {x i , n i , r i , H(.), q, p} into the smart card and stores r 1 in the memory.

Ui AS
Ui insert SC, Selects UID, UPW, and imprints UBi. Generates a random number r1, Verify user info, if so; Store . . Figure 5. User registration phase.

Fog Node Registration Phase
This phase requires the fog node Fn i to register itself into the CPS. As shown in Figure 6, a fog node Fn i performs the following steps: • The Fn i firstly selects an identity f n id and sends f n id it to the AS in the CPS via a secure channel. • AS receives it and checks whether the identity exists or not by comparing f n id = f n id stored in the database; after verification, AS generates its own random number r f ;

Login Phase
When user U i wants to access the data stored on the cross-platform fog server, she/he inserts her/his smart card into the terminal and performs the following steps to log into the system. Figure 7 shows the process of the login and authentication phases.

•
The user U i inserts her/his identity u id and password u pw ; inputs his/her biometric information; and extracts the random number and the information stored in the smart card SC.
Then, based on the stored parameters, it will calculate Next, the smart cart computes an authentication message encrypted with the AES private key and the ECC public key Auth u = E PK {ξ k {u id x i bio i tgs id TS 1 }}, where the TS is the current user timestamp. Then, U sends the Msg.1 to the AS. • Upon receiving the authentication request message Msg.1, the server decrypts the message utilizing its private key to decrypt the message Auth u = d PK { k {u id x i bio i tgs id TS 1 }}, and then the encrypted message with the AES key decrypts the parameters with the same key to obtain the information µ k {u id x i bio i tgs id TS 1 }. • After that, AS checks the timestamp to see if it is similar to the server timestamp, extracts the u id , and verifies x i = x i whether it is valid or not; if not, the session is terminated. Otherwise, AS proceeds generating a random integer number r 2 and computes the key sessions known to protect the communication between the user and the ticket-granting service. It is only known to the U i and AS. • Next, AS computes the key session ks u→tgs = H(u id a i r 2 ) and generated another random number tgs sk ∈ Z * q as the TGS secret key is known to AS and TGS only. AS then forwardd the TGS secret key to the TGS along with X i , Bio i to the TGS. • Then, AS prepares the message Msg.2: u id tgs id k {ks u→tgs TS 2 tgs tkt }, where tgs tkt = E tgs sk {u id ks u→tgs TS 2 x i bio i } is the Ticket. The tgs tkt cannot be decrypted but the TGS only. It then sends the messages Msg.2 to the user to enable her/him to authenticate the TGS.
Ui insert SC, Inputs UID, UPW, and imprints UBi. Generates a random number r1,

Authentication Phase
In this phase, the user will decrypt the message A to obtain the critical session and the parameters after successfully receiving the messages from the authentication server. The message B will be forwarded to the TGS. The steps of the authentication phase are given below: • The user decrypts message Msg.2 using the key µ k to get the critical session ks u→tgs and other information (u id tgs id µ k {ks (u→tgs) TS 2 tgs tkt }, and contains the Ticket granting service ticket tgs tkt and this message is encrypted by the tgs sk and the user cannot modify the Ticket in private. Therefore, U i will forward it to the TGS as message Msg.3. • It then computes an authentication message Auth u→tgs = E ks u→tgs {u id f n id TS 3 tgs tkt }, which contains the user identity, fog node identity, the current user timestamp, and the TGS ticket. The message is encrypted with the key session ks u→tgs that is shared to communicate U i and TGS. The user sends a request to the TGS to get permission to visit the fog node server. • Upon receiving the request from Ui, TGS decrypts the Ticket tgs tkt = D tgs sk {u id ks u→tgs TS 2 x i bio i } to obtain a key session and decrypts the authenticator message as well by using the shared key sessions Auth u→tgs = D ks u→tgs {u id f n id TS 3 tgs tkt }. • Next, it verifies the x i = x i that was received earlier from AS; if it is not equal, the session will be terminated; if yes, then the TGS will generate a random number f n sk ∈ Z * q as the fog node secret key that will be known to the TGS and the fog node server, and it will then be sent to the fog node along with < T 4 >. The user U i receives information from the TGS; it will firstly decrypt the message {u id f n tkt D ks u→tgs {tgs id ks u→ f n s TS 4 }} to get the shared session key, and the user cannot decrypt the fog node Ticket. • Next, the user generates an authenticator message Msg.5: Auth u→ f n s = E ks u→ f n s {u id TS 4 }, and composes the Ticket f n tkt = E f n sk {u id f n id ks u→ f n s TS 4 }. Then, it will send the messages to the fog node for mutual authentication. • The fog node server receives the message Msg.5, and it will decrypt the message from the secret key that it shared earlier from the TGS f n tkt = D f n sk {u id f n id ks u→ f n s TS 4 } to get a key session. • Then, the server decrypts the authenticator message using a shared key session Auth u→ f n s = D ks u→ f n s {u id TS 4 }, and checks the authenticator timestamp with a shared timestamp and if it is not equal, the server terminates the session; if yes, then the client can trust the server and can start issuing service requests to the server and send a successful message. The fog node server now provides the requested services to the user.

Security Analysis
The security analysis is carried out formally and informally in this section. The formal security analysis of the proposed scheme was conducted with the BAN logic (Burrows-Abadi-Needham), a formal model that aims to see how information exchange can be secured from eavesdropping. Informal security analysis ensures that, e.g., the proposed scheme prevents different kinds of known attacks. The following paragraphs provide details of the BAN logic.

Mutual Authentication Proof Using BAN Logic
We conducted a BAN logic analysis to verify the proposed scheme with secure mutual authentication. Table 3 specifies the BAN logic notations and postulates and describes the goals, assumptions, idealized version formulas, and confirms secure mutual authentication in the proposed scheme before performing a BAN logic analysis. Random numbers Timestamp.
K is the shared session key between X and Y.

Message Exchanges
This section illustrates an optimal way of the message exchanges for our proposed scheme.

1.
The authentication service exchanges: Firstly, the messages in the scheme are exchanged between the user and the authentication server (AS), also called the ticket exchange. The user applies for the ticket TGT to communicate with TGS and the session key from the Cloud Provider Server (CPS). The user needs to input his/her user identity and password to log into the network. The user sends a request message U_AS_REQ, and AS responds U_AS_REP.

2.
The authorization service exchanges: It is the process of the message's exchanges between the user and the TGS to get a ticket to communicate with the fog server. The user sends a request encrypted with a shared session key and for decryption as well.
The TGS exchange consists of two messages: U_TGS_REQ and U_TGS_REP.

3.
The user/fog server exchange: In this process, the user gets the Ticket and shared key session known to the user edge and fog node server f n. The user can now communicate to the f n using the received information and will consist of two messages: U_FN_REQ and U_FN_REP. U_FN_REP is only used when there is a need for two-way authentication, and the server wants to prove its identity to the client.

Goals and Assumptions
Initial assumptions: Hence, the authentication goals are given as follows: • Goal 1: Ui believes Ui pk − → AS.

BAN Logic Proof
Based on the logical assumptions, the authentication goals of the proposed scheme can be illustrated according to the BAN logic as follows: 1.
According to the message meaning rule (Rule 1): Ui believes the PK is a shared public key between Ui and AS. In addition, the Ui sees that Tiket U,TGS is encrypted with ks u−tgs , and then Ui believes that AS once said Ticket u,tgs .  The above demonstrates our authentication goal and proves that this scheme ensures that the user and the fog node are mutually communicated.

Informal Security Analysis
This section illustrates several security problems and shows that the proposed scheme is secure from various types of malicious attacks as follows: Theorem 1. The proposed scheme avoids the key escrow problem inherited by the Identity based cryptography (IBC).
Proof of Theorem 1. As mentioned above, a distinctive user identity is assigned as u id and biometric u bi , while the assigned secret key is u pk . Please note that u pk is stored in the SC record and shared between the user and the fog server. Subsequently, the user itself randomly generates its secret key u sk ∈ Z * q , which will later be kept a secret to AS. The secret key is generated based on the random number r 1 , and the server has no access to it. In this way, other entities cannot extract r 1 from the published bio i = H(u bi ⊕ r 1 ) or m i = H(u id ⊕ u pw ⊕ bio i ⊕ r 1 ). Similarly, the authentication request is encrypted with the user public key.

Theorem 2.
The proposed scheme is secure from a replay attack.

Proof of Theorem 2.
Assume that an adversary tries replaying the previously captured valid login and authentication messages < u id , x i , bio i , ts 1 >. The message is encrypted by using the server public key PK, and it takes a fresh timestamp ts n to validate a legitimate user. After the server decrypts the message to obtain user information, AS will verify the received timestamp TS1 with the server's current stamp TS , TS 1 = TS . Likewise, if the adversary tries to replay the authentication message by replaying TS 1 with TS 2 , it will not be able to pass because X i is encrypted using a one-way hash function x i = H(a i f i m i ) so, the AS can detect any changes in the message. Hence, the scheme is resistant to a replay attack.
Theorem 3. The proposed scheme is secure from the impersonation attack.
Proof of Theorem 3 . The adversary in this attack is trying to provide a login message by eavesdropping or computing a message to deceive the AS as a legal user. In the proposed scheme, if the adversary tries to replay the previous message or to impersonate < u id , x i , bio i , ts 1 >, the AS will validate the message by checking x i = x i . Moreover, the adversary cannot capture the valid x i , due to the lack of the user identity u id , user password u pw and user biometric info u bi . Therefore, a malicious user cannot impersonate a legitimate user to access the fog node.

Theorem 4. The proposed scheme is resistant to a man-in-the-middle attack.
Proof of Theorem 4 . Assume that the adversary intercepts the login and authentication messages successfully {u id x i bio i tgs id ts 1 }, {u id ks u→tgs ts 2 x i bio i }, and {u id f n id ts 3 tgs tkt }. The adversary will fail because there is a crucial session KS established between all the entities and shared after the mutual authentication is generated between them. In addition, the ticket-granting service is sharing the encrypted ticket tgs tkt = E tgs sk {u id ks u→tgs ts 2 x i bio i } using the TGS secret key and only can only be decrypted by it, which goes for the communication between TGS and FN. However, for the same reason mentioned above, the attacker cannot pass this process without knowing the patient's uid and the personal values x i and TS. Therefore, the adversary cannot cheat the user Ui to share a key session and believe that the key is shared with the authentication server AS, and this judgment also works on the FN. Therefore, the adversary cannot launch the man-in-middle attack successfully to cheat either the user or the servers in the proposed scheme.

Theorem 5. The proposed scheme withstands the known-key attacks.
Proof of Theorem 5 . The proposed scheme provides resistance against known-key session attacks according to the unique key session that has been generated between each entity. The key session in the proposed scheme is calculated based on < a i r 2 > that makes it unique because the random integer r is generated randomly and independently by the Ui, AS, and TGS. Since the r 1 , r 2 , and r 3 are different from each other, the critical session in each run is unique in the proposed scheme. Therefore, the proposed scheme is resisting this attack. Using a unique key session during every communication session allows achieving freshness of the key in the proposed scheme. The session keys are generated in AS ks u→tgs = H(u id a i r 2 ) and TGS ks u→ f n S = H( f n id a i r 3 ), differently and independently. Theorem 6. The proposed scheme withstands privileged insider attacks.
Proof of Theorem 6. Assume that the adversary attempts to obtain the legal user information u id and u pw , but he/she will fail to impersonate since he/she must provide the correct biometrics u bi of the targeting user. In addition, it will be difficult for the attacker to obtain the legal user information since the proposed scheme is performing a hash function on the user information H(u id ⊕ u pw ⊕ bio i ⊕ r 1 ) and contains a randomly generated number in it. The user biometric is protected as well in the hash formatting with the random number r 1 . The attacker cannot extract the stored parameters from the stored hash value successfully; thus, the proposed scheme works against any insider attack. Theorem 7. The proposed scheme withstands a stolen smart card attack.
Proof of Theorem 7. In this attack, the adversary attempts to extract the user information stored in the smart card. He/she will fail since the parameters {x i , n i , R i , H(.), q, p} are secured and the attacker cannot successfully compute H(a i f i m i ) = x i , f i ⊕ H(u id m i ) = n i , and a i ⊕ H(bio i m i ) = R i as they are secured using a collision-resistant oneway hash function H(.). Therefore, the attacker is unable to determine the user information u id and u pw . Therefore, the proposed scheme is resistant to the stolen smart card attack. Theorem 8. The proposed scheme is secure from a replay attack.
Proof of Theorem 8. The proposed scheme is resistant to a server spoofing attack. An adversary exploits a legitimate user's information to counterfeit as a server. To successfully impersonate as an authentication server AS, it cannot compute the (u id tgs id E u pk {ks ußtgs ts 2 tgs tkt }, and tgs tkt = E tgs sk {u id ks u→tgs ts 2 x i bio i }; to compute the correct values, a malicious server needs to know the critical session KS, timestamp TS, and the secret value Xi. The values are encrypted and cannot be decrypted by only using the secret server key that is shared earlier. As mentioned above, he/she will need to know the user identity u − id to compute critical sessions. Proof of Theorem 9. This attack can suspend services of the server by flooding the network, but the proposed scheme is resistant to this attack. Since the proposed scheme verifies the user identity u id and password u pw , it also verifies the secret value X i = X i so he/she fails. Moreover, the server will detect a false message sent to it by the adversary using the timestamp (TS1, TS2, and TS3). The authentication server AS and FN will only proceed if the login message passes the check (TS 1 − T curr ) ≤ TS, and the Ticket granting server (TS 2 − T curr ) ≤ TS. The FN will also not process the message only if the shared timestamp matches the shared timestamp TS3. In addition, the TGS will check the validity of the X i = X i after the AS. Theorem 10. The proposed scheme is secure from an offline password guessing attack.
Proof of Theorem 10. The user identity u id , password u pw , and the biometric u bi are secured using a one-way hash function H(u bi ⊕ R i ) = bio i , H(u id ⊕ u pw ⊕ bio i ⊕ r 1 ) = m i and contains a random number in it. In addition, any alteration in the login message will be detected after the server verification. The attacker can never validate the password with a stolen smart card SC. If the attacker intercepts the login message SC {X i , n i , R i , H(.), q, p} as a legitimate user, he/she will need to guess the user identity and password that server will validate the message after decrypting. Thus, the proposed scheme is highly secured against offline password guessing attacks.
Theorem 11. The proposed scheme facilitates user anonymity.
Proof of Theorem 11. Assume an adversary intercepts the message {u id x i bio i tgs id ts 1 }. The attacker cannot obtain the information because the authentication message is encrypted using the authentication server public key E PK {}. In addition, the server will check the validity of the user by extracting the original user's identity u id and the secret value x i = x i as well. The AS and TGS will generate a key session using a unique random number with every communication session. Moreover, the adversary cannot launch a guessing attack to obtain the user information, because with knowledge of x i , an adversary cannot compute H(u id ⊕ u pw ⊕ bio i ⊕ r 1 ) = m i successfully according to the using of a one-way hash function as well. Therefore, nobody will be able to know the real identity of the user, except the user himself and the server. Proof of Theorem 12. The proposed scheme protects the real user identity, and the transmitted message is changed by updating r during every session. The transmitted messages are different from one session to the other since there is a new key session. KS is computed based on a new random number when every new session begins. Therefore, the attacker cannot distinguish whether the intercepted messages belong to the same user or not. Therefore, the proposed scheme provides user untraceability. Theorem 13. The proposed scheme facilitates a mutual authentication property.
Proof of Theorem 13. The authentication scheme needs to allow all the considered entities in communication to verify the identity of each other mutually. The use of ECC is in providing mutual authentication. The user and the server can authenticate each other by checking session key freshness ks = H(u id a i r) in every session, and verifying the x i = x i with the timestamp, respectively, in the AS and the TGS. Therefore, the proposed scheme achieves mutual authentication. Theorem 14. The proposed scheme achieves perfect forward secrecy property.

Proof of Theorem 14 .
In the proposed scheme, the adversary cannot generate the key session ks u→tgs = H(u id a i r 2 ), ks u→ f n S = H( f n id a i r 3 ) because the adversary does not know the user identity. Therefore, the attacker cannot obtain the user/server identity. To successfully compute the key session, the attacker needs a secret value A i , and random number r, but he/she will fail because it is impossible to obtain the random number and the value A i is secured using the one-way hash function a i = R i ⊕ H(bio i m i ) In addition, it includes protected biometric. As a result, it is difficult to determine the information, and the proposed scheme is achieving forward secrecy.

Theorem 15. The proposed scheme achieves a biometric protection property.
Proof of Theorem 15. The user biometric u bi is highly protected by a high entropy random number integer r and one-way hash function bio i = H(u bi ⊕ r 1 ). Assume the adversary obtains the stored information on the smart card; but he/she cannot extract the User biometric u bi without the knowledge of the user identity u id and password u pw . Therefore, the proposed scheme of protects the user's biometric.

Formal Security Verification Using AVISPA Tool: Simulation Study
Simulations were carried out to test the proposed security framework using AVISPA [39], an extensively used security analysis model. It proves that the scheme avoids replay and man-in-the-middle attacks. This section includes a simple overview of the AVISPA tool [40]. It then shows the implementation code for the User (U), authentication server (AS), ticket-granting server (TGS), fog node (FN), session, goals, and the environment in High-Level Protocol Specification Language (HLPSL). Third, the simulation results are demonstrated.

AVISPA Tool Basic Explanation
AVISPA is a simulation verification tool to validate authentication schemes. Specification language (HLPSL) is used to implement the simulation code. AVISPA is a participantrelated program. Each participant is autonomous and has some knowledge across channels in the form of communication parameters. First, wrote the code into HLPSL in this tool, and then used hlpsl2if to translate it into an intermediate (IF) format. AVISPA is currently being introduced in four back ends: (a) CL-AtSe; (b) OFMC; (c) SATMC; and (d) TA4SP. AVISPA is implemented on a backend basis on-the-fly model checker (OFMC); the output format is generated and then represented based on these back-ends, confirming that the system is safe from active and passive attacks.

Discussion of Proposed Scheme in HLPSL
The role of user U in HLPSL is shown in Figure 8a. In the registration phase, U sends {u id , u pw , bio i , m i } to the authentication server AS using Snd() operation via a secure channel. The declaration channel (dy) is made for the Dolev-Yao threat model. Accordingly, two declaration secrets, i.e., (K_UG , sec_c_K_UG, AS, U, TGS), (K_US , sec_c_K_US, TGS, U, S) state that Bio, u pw is only known to U, D_S is only known by AS and U_ID is known to U, AS, and TGS. After that, U obtains the smart card having the values, i.e., x_i, N_i, R_i, from AS. In the login phase, the user further creates N2 , T , Mi , TGSid , Ri , Ni , Uid using a new (-) operation and transmitting (Uid .N2 . Uid .Bio .TGSid .U.T _K_UG ) to the AS via a public channel. The declaration witness (U, TGS, t1, T ) tells that U creates T for AS. In the authentication phase, U gets a reply message (U.TkT2 .S.K_US .Uid .Bio .Ts2 .Xi .Tse2 .N2_K_UG) from AS by using Rcv () operation. Further, the user creates T2 , TGSid , FNid , Uid and transmits the message Snd(TkT2 .U.T2 .Uid .TGSid .FNid _K_US ) to the TGS. The declaration request (U, TGS, k_cs1, K_US ) states that the user sends a request to the TGS for knowing K_US'. The declaration secret (K_US , sec_c_K_US, TGS, U, S) states that T is known to U, AS, and TGS. The user later receives a message (Uid .TkT1 T2_K_US) from the TGS. The user then messages to the fog node (TkT2 .U.T2 .Uid .FNid _K_US ). The declaration request (U, S, t2a, T2) states that the user sends a request to the fog node.     (FN, U, t2b, T2 ) states that the user sends a request to S for knowing the feedback of the fog node (Fail/Success). Moreover, the declaration secret (K_US , sec_K_US, TGS, U, FN) states that K_US is known to TGS, U, and FN. Figure 10 demonstrates the roles of session, goals, and environment in HLPSL.

Figures 11 and 12
show our proposed scheme's results with simulation results in OFMC and CL-AtSe back ends. These back-ends show that our scheme secure from active and passive attacks. The sequence diagram of the proposed scheme shown in Figure 13 is represented as user U, authentication server AS, ticket-granting server TGS, and fog node FN.    {nonce-15}_sk-12 Figure 13. The simulation sequence using AVISPA.

Security Features Comparison
The security features comparison is shown in Table 4. The schemes SAKA-FC [26] and AKA-FC [31] highly suffer from a key escrow problem and key encryption management. The scheme is also vulnerable to identity and password guessing attacks, replay Attacks, impersonation Attacks, insider Attacks, and DoS. Moreover, the cryptoanalysis shows that the scheme SAKA-FC [26] suffers from user anonymity and untraceability. The schemes SAKE [20] and AKA-FC [31] are vulnerable to stolen smart card attacks, offline password guessing attacks, and missing mutual authentications. The schemes SAKA-FC [26] and SAKE [20] do not facilitate perfect forward secrecy and biometric protection. Since the proposed scheme is validated using BAN logic, this ensures secure preservation of mutualauthentication and key session agreement. The proposed scheme is also simulated by the web tool AVISPA [40], whose simulation results indicate that it is defended against active and passive attacks. The proposed solution is protected against various security threats.

. Computation and Communication Costs
Here, we explain the comparison of the communication cost and the computation cost of the proposed scheme with other existing schemes [20,26,31,32] which are shown in Table 5. The performance metrics can be explained as follows.

Computation Cost
In this subsection, we analyze the computation cost of the related authentication schemes SAKA-FC [26], SAKE [20], AKA-FC [31], and AKA-MS [32] and our proposed scheme. The number of cryptographic operations involved in this study are counted. To represent the comparison, Table 6 shows the notations, description, and computed their approximate execution time for various cryptographic operations by using the PBC library reported by Jia et al. [41]. Specifically, the study employed a secure hash function, public-key-based encryption, symmetrical encryption, and symmetric decryption, which are, respectively, denoted as T H , T PE , T SE , and T SD . It is noted that the XOR operation and concatenates operation are ignored because their execution time is negligible. The proposed scheme's simulation was carried out on Intel Core™i7-5700HQ, CPU 2.70GHz platform using Java Pairing-Based Cryptography Library (JPBC) library. Figure 14 compares the proposed scheme's computation cost against SAKA-FC, SAKE, and AKA-FC.
Our scheme's computation cost is shown in Table 5 comparing it to other authentication schemes.

Description Time (ms)
Identity-based signature (T IDS ) 23.866 Identity-based signature verification (T IDV ) 5.8720 Asymmetric signature (T AS ) 3.8500 Asymmetric signature verification (T AV ) 0.1925 Public-key-based encryption (T PE ) 3.8500 Public key-based decryption (T PD ) 3.8500 symmetrical encryption (T SE ) 0.0046 Symmetric decryption (T SD ) 0.0046 Scalar multiplication (T (sm−ecc) ) in G 1 0.4420 Scalar multiplication (T sm ) 20 In SAKA-FC [26], three cryptographic operation are scheme, T sm , T h , and T mtp , respectively, as shown in Table 5. The execution times of these operations are 0.442, 1.709, and 4.406 ms, respectively. In the login phase, the user firstly needs to execute the Scalar multiplication (T sm ) six times, Map-to-point hash function (T mtp )one, and the hash operation (T h ) twenty-six times related to SAKA-FC to start login into the system, so the execution time of the phase costing nearly ≈ 35.595 ms. In the authentication phase, the user needs to execute the hash operations (T h ) nine times related to G 1 . Therefore, the execution time of the authentication process in SAKA-FC is ≈ 4.005 ms. Therefore, the total computation cost of their scheme is 39.595 ms. The computation of their scheme is computationally high due to the used multiplication operation in the scheme. In AKA-FC [31], there are three cryptographic operations related to ECC used in their scheme, ET sm , T h , and T P , respectively. Table 5 shows the estimated execution time of the performed operations individually. However, in the login phase, the user needs to perform the scale multiplication related Elastic compute service (ECS) 2ET sm twice, the hash function 4T h four times, and the bilinear pairing T P once. Therefore, the execution time in the login phase is 2ET sm + 4T h + T P = 9.251 ms. In the authentication phase, the scheme needs to perform the scale multiplication related Elastic compute service (ECS) 2ET sm three times, the hash function 4T h eleven times, and the bilinear pairing T P once; thus, the time cost for this phase is 3ET sm + 11T h + T P = 11.284 ms. Therefore, the total computational cost of AKA-FC is 20.535 ms. In SAKE [20], the scheme employed secure hash functions, multiplication, and fuzzy extractor operation are, respectively, denoted as T h , T pm , and T f e and are mainly related to fuzzy extractor algorithm. However, in the login phase, the user needs to execute point multiplication T pm twice, the hash function 8T h eight times, and the fuzzy extractor operations 2T f e twice. Consequently, the execution time in this phase is approximately 40.76 ms. In contrast, the authentication phase's execution time is ≈ 4.295 ms, since the utilized operations are T H and T pm . It is noted that the login phase takes longer than the authentication phase in this scheme under the usage of the multiplication operation. Therefore, the total execution time in the SAKE scheme is 45.055 ms. The AKA-MS scheme [32] uses two cryptographic operations: hash operation related to bilinear pairing H P and hash operation related to the group of ECC H M . The estimated execution times are 12.418 and 0.974 ms, individually. The user needs to execute the hash operations 8H P eight times in the login phase. In comparison, there is a need to execute the hash operations 7H P seven times and the hash operation 1H M once related to the ECC group in the authentication phase. The total computation cost is 8H M + 7H M + 1H p = 27.028 ms, while the proposed scheme applied a very lightweight operation T H , H M ,T PE , H P , T SE , and T SD . These operations' execution times independently are 12.4180, 0.9740, 0.9740, 3.8500, 0.0046, and 0.0046 ms. However, in the first phase, the user needs to perform the hash function five times, public key encryption one time, the symmetrical encryptions four times, and the symmetrical decryption described as 1H P + 1H M + 5T H + 1T PE + 4T SE twice. Therefore, the execution time of the login phase is nearly ≈ 17.2920 ms. In the authentication phase, the employed operations are T H , T AV , T SE , and T SD . The verification operation is included in this phase. However, the computation cost here is 2T H + T AV + 2T SE + 3T SD . Therefore, the execution time for user operation is ≈ 0.232 ms. Thus, the total execution time of the proposed scheme is 17.524 ms. Compared to SAKA-FC [26], SAKE [20], AKA-FC [31], and AKA-MS [32], the proposed scheme has less computation cost. According to utilizing the AES-ECC algorithm, this result was achieved due to the fast AES encryption speed that makes it suitable for encryption of long plain-text. The ECC solution also uses a smaller key size and low computational system requirements, making it faster and more efficient cryptographic keys.

Communication Cost
The number of message interactions measures the communication costs. To compute the communication cost, it mainly depends on how many messages are transmitted between the entities multiplied by the (bit) size. We assume that the user's identity can be represented by 32 bits, the secret value represented using 160 bits, the timestamp value is 24 bits, and the ticket value is represented as 128 bits. The communication cost of SAKA-FC [26], SAKE [20], AKA-FC [31], AKA-MS [32], and the proposed scheme are summarized in Table 5. The compassion of the proposed protocol's communication cost against the selected works is shown in Figure 15. In SAKA-FC [26], the scheme exchanging messages Msg.1 =< RID i , R u , a u , E u , F u , TS u >, needs (160 + 320 + 160 + 160 + 160 + 32) = 992 bits, while in the login and authentication phase exchange the message Msg.2 =< RID * i , RID k , G i , H j , P f , TS f > needs (160 + 160 + 160 + 160 + 320 + 32) = 992 bits. The message Msg.3 =< RID * k , M k , N k , P f , TS k > needs (160 + 160 + 160 + 320 + 32) = 832 bits. Therefore, the total communication cost of their scheme is 2 × (992 + 992 + 832) = 2816 bits. To evaluate the communication cost, the scheme AKA-FC [31] includes the length of the points in the group G 1 , which is 1024 bits, the output of the hash function 2|q|, which has the length of 160 bits, and the length of the timestamp, being 32 bits, which is denoted as |T|. Thus, the communication cost in the login phase is 1376 bits. In the authentication phase, the user performs the same length of messages, which is represented as |G1| + 2|q| + |T| and has the length of 1346. Therefore, the total communication cost of AKA-FC is 2752 bits. In SAKE [20], the initialization calculations on the user parameters set (TS i 2 , ID i RSU , O i , R i , Cert i RSU ). At this point, the total size of this message is calculated as 32 × 6 + 256 × 1 + 160 × 3 + 24 × 1 = 952 + 56 = 1008 bits. In the authentication phase, the server finally generates packet (TS i 4 , ID j 1 , Cert RSU , φ j ), Hence, the total communication cost for an individual user is (32 × 13) + (256 × 3) + (160 × 2 ) + (24 × 3) = 1576 bits. Therefore, the total communication cost for SAKE is 2584 bits.
In the AKA-MS scheme [32], the user exchanges the information (IDu, M, TW) with the registration center; hence, the total size is computed as (160 × 4)+ (256 × 1) + (32 × 1) = 928 bits. In the authentication phase, the user communicates with the server and finally exchanges M 1 = PID u , DID u , which needs (160 + 160) =320 bits. Then, the server sends message M 2 = Q uj , V j , which has the size of (256 + 256) = 512 bits. The user later sends M 3 = Z uj that needs 160 bits. Thus, the total communications cost of AKA-MS is 1920 bits.
In the proposed scheme, there are two interacting messages between the user and the authentication server in the login phase. The user first sends an initialization authentication request Msg1.Auth u = E pk {u id X i Bio i tgs id TS 1 }; the size of the message is calculated as 32 + 160 + 32 + 32 + 24 = 248 bits. The AS sends the second message to the user as Msg.2 : (u id tgs id E u pk {ks (u→tgs) TS 2 tgs tkt }; the size of the message is computed as 32 + 32 + 128 + 24 + 160 = 376 bits. Therefore, the total communication cost in the first phase is (248 + 376) = 624 bits. In the authentication phase, there are three messages which are shared between the user and the AS. The user sends a message to the TGS Msg.3 : Auth u→tgs = E ks u→tgs {u id f n id TS 3 tgs tkt }, with the size of length computed as (32 + 32 + 24 + 160) = 248 bits. Then, the TGS response to the user is calculated as Msg. 4 : u id f n tkt E ks u→tgs {tgs id ks u→ f n s ts 4 }, with size (32 + 160 + 32 + 128 + 24) = 376 bits. The user requests access to the fog node Msg. 5 : Auth u→ f n s = E ks u→ f n {u id TS 4 f n id }; the message size is calculated as (32 + 24 + 32) = 88 bits. Therefore, the total communication cost of the proposed scheme is (624 + 248 + 376 + 88) = 1336 bits. In our proposed scheme, the used operations are lightweight compared to the other schemes. Table 5 shows that the proposed scheme has a less communication cost compared to the others.

Conclusions
This paper proposes a lightweight multi-factor authentication scheme for crossplatform industrial IoT systems, SELAMAT. In SELAMAT, we use the AES-ECC algorithm for efficient and secure key management encryption mechanisms in the cloud provider server that acts as a trusted authority. Furthermore, the scheme adopts the Kerberos workflow due to the wide acceptance of the protocol in real-life applications. The designed algorithm offers secure communication between the edge devices and the fog node servers when the messages are transmitted via a public network. The proposed scheme enables edge devices to access any fog server in the fog computing network and improves the efficiency of the system by reducing the computation and communication cost to avoid a network burden.
The results show that the SELAMAT scheme reduces the communication and computation cost compared to the SAKA-FC, SAKE, AKA-FC, and AKA-MS schemes. This extensive comparison of the scheme efficiency shows that the proposed scheme can achieve better performance than the existing scheme. The AVISPA tool is used to verify the security of the scheme. The SELAMAT scheme provides robust security against attacks (replay attack, impersonation attack, man-in-the-middle attack, known-key attack, insider attack, server spoofing attack, etc.), and it was evaluated by using the formal and informal security analyses. In addition, the mutual authentication of the proposed scheme was proven by using the BAN logic. As mentioned above, the advantages pave a path for IIoT usability and suit the IIoT resources-constrained devices. In the future, the proposed scheme can improve the performance and the security of industrial hardware.