Lightweight Authentication Protocol for M2M Communications of Resource-Constrained Devices in Industrial Internet of Things

The Industrial Internet of Things (IIoT) consists of sensors, networks, and services to connect and control production systems. Its benefits include supply chain monitoring and machine failure detection. However, it has many vulnerabilities, such as industrial espionage and sabotage. Furthermore, many IIoT devices are resource-constrained, which impedes the use of traditional security services for them. Authentication allows devices to be confident of each other’s identity, preventing some security attacks. Many authentication protocols have been proposed for IIoT; however, they have high computing requirements not viable to resource-constrained devices, or they have been found insecure. In this paper, an authentication protocol for resource-constrained IIoT devices is proposed. It is based on the lightweight operations xor, addition, and subtraction, and a hash function. Also, only four messages are exchanged between the principals to authenticate. It has a low execution-time and communication-cost. Its security was successfully assessed with the formal methods Automated Validation of Internet Security Protocols and Applications (AVISPA) tool and Burrows–Abadi–Needham (BAN) logic, together with an informal analysis of its resistance to known attacks. Its performance and security were compared with state-of-the-art protocols, resulting in a good performance for resource-constrained IIoT devices, and higher security similar to computational expensive schemes.


Introduction
Internet of Things (IoT) is a technology where physical objects are empowered with a virtual representation, allowing them to exchange contextual information to coordinate actions, have a prompt and better response to environmental changes, and use their resources efficiently. Additionally, it enables the user to make informed decisions [1,2]. Many applications are looking forward to the benefits of IoT environments, such as those in industry, smart cities, connected medical services, smart farming, smart retail, and smart homes. [3]. IoT devices are composed of sensors and actuators to have awareness and to respond in their environment, and have a method of communication to interact with other devices [4]. These physical objects have a connection to the Internet, directly or through another device, making them available any time and from everywhere in the world to their service clients. However, this connectivity makes them also accessible to adversaries from any place, who can attack a device to access private information such as location, medical, and financial, and use actuators to perform actions that could damage the system or even be a threat to the user's welfare [5][6][7].
The rest of the paper follows this organization: Sections 2 and 3 contain related work and preliminaries, respectively. In Section 4 the proposed LAKD protocol is described. Security analysis is presented in Section 5. Performance and security evaluation is done in Section 6. Section 7 presents the discussion. Finally, Section 8 contains the conclusions.

Related Work
In this section, current proposals of authentication protocols for IIoT and IoT are briefly analysed. An authentication protocol for ad hoc wireless sensor networks (WSN) is proposed in [31]; it uses hash functions and xor operations, and considers a heterogeneous environment with two or more types of nodes: tiny resource-constrained sensor nodes, and more powerful gateways. The scheme is examined in [32] and it is found vulnerable to off-line identity guessing, off-line password guessing, stolen smart card, and impersonation attacks. Then, a modified version was proposed, which was analyzed in [33], revealing it does not achieve mutual authentication and does not resist session key disclosure, tracking, and node and user forgery attacks. In [34] the protocol in [31] is also inspected, showing it does not provide user anonymity, and if a node is compromised, it allows the adversary to obtain the session key between the user and another node. Then, they proposed an authentication protocol for ad hoc WSN. The proposal is lightweight because it only relies on xor and hash functions. However, in [35] the authors examine the scheme and show that it is vulnerable to unknown key-share attack, node capture attack, and node information secrecy. Afterward, they propose an authentication protocol for IIoT, which is also lightweight. The scheme does not use any timestamp because of the challenge of synchronizing time in distributed networks; however, in [28] impersonation and DoS attacks are achieved because of the independence of time in an authentication protocol.
Two protocols for ad hoc WSN are proposed in [36]. One of them is lightweight, and the other is more complex because it uses public-key cryptography and it was proposed for hostile environments with a high probability of node capture attacks. In [37], an analysis of both schemes is presented, demonstrating that they do not achieve a proper mutual authentication; the identity of the user is not verified; thus, the protocol is executed even if he/she inputs a wrong identity, and they are vulnerable to stolen smart card and tracking attacks. Then, they propose an authentication scheme for IIoT to resolve the security weakness, achieve resistance to mobile device loss attack, and have user anonymity. The protocol uses encryption, and public-key cryptography on the user's mobile device; thus, it is not proper for resource-constrained systems [15,16].
In [38], an authentication, authorization and accounting (AAA) system for IIoT is proposed. It is based in the Next Generation Access Control (NGAC) standard [39], a flexible infrastructure to provide access control in different environments. The system provides access control to IIoT devices in a local cloud with security and interoperability, and allows the integration of the inherently heterogeneous IoT devices. Their authentication mechanism uses X.509 certificates, which makes the solution prohibitive for resource-constrained devices, because the complex validation of the public keys exhaust the limited resources of the devices, and the public-key certificate management causes performance bottlenecks [40].
The previous schemes were examined when developing this work to try to achieve a protocol that does not have the aforementioned security issues, and with computing requirements that are not prohibitive to resource-constrained devices. The proposed protocol uses only simple operations to be lightweight. And for security, every transmitted message uses confidential and integrity mechanisms, such as xor-ing and hashing, keeping the secrecy of the transmitted data and resisting malicious modifications.

Preliminaries
In this section, the network architecture considered in the proposal is described, which follows a vision of energy efficiency in the sensor nodes. Also, the threat model in which the protocol must be secure is presented.

Network Architecture
The network architecture follows the perspective of IIoT presented in [41,42]. The architecture is illustrated in Figure 1, and it consists of a sensing domain, RESTful services, cloud server, and user applications. The sense domain comprises three layers: sense, gateway, and control. The sensor nodes in the sensing layer are resource-constrained devices responsible for collecting and sending contextual data to its gateway. The gateways store the received data in buffers and forward them to control nodes, which aggregate the information of different gateways and redirect it to networks with RESTful services. These networks act as a bridge between the physical objects in the sense domain and their virtual representation in the cloud. Through organizing the sense domain in the hierarchical framework of three layers, the traffic load and energy consumed by the massive number of sensor nodes can be balanced, increasing the lifetime of the whole IIoT system. The perspective of the architecture is energy efficiency, to achieve a green IIoT [41]. This work centers on the resource-constrained devices of the sensing layer, which are unable to use traditional security services to protect their communication with the gateway. Due to the sensing domain consisting of a massive number of sensing nodes, the IIoT system may consume a considerable amount of energy. Through optimizing the sensing, processing, and communicating tasks of the sensing devices, the consumed energy can be reduced [41]. The proposed protocol follows the perspective of low computing-resource usage (low processing-time and communication-cost) on the sensor devices, decreasing the energy cost of the IIoT system and prolonging the battery life of the sensor devices.

Threat Model
The following assumptions about security properties and adversary abilities are made. The notation A represents the adversary.
1. The private channel used for registration is secure. 2. The one-way hash function is collision-resistant. 3. The gateway and sensor node have protection against tampering. 4. A cannot guess random numbers and keys in polynomial time. 5. Replay attack: A can capture messages from old authentication sessions and replay them in the current session. 6. Modification attack: A can tamper intercepted messages. 7. Tracking attack: A can trace the sensor node behind authentication sessions. 8. Impersonation attack: A can pretend to be a legitimate gateway or sensor node. 9. Injection attack: A can send counterfeit messages.

LAKD Protocol
The proposed protocol consists of two phases: (1) registration, where sensor node and gateway exchange secrets that they will later use to prove their identities, and (2) mutual authentication, where they authenticate and generate a session key. The notation used in the description of the protocol are presented in Table 1.

Registration
In this procedure, the sensor node and gateway exchange secrets that they will later use in the authentication process to prove their identities. First, a sensor node chooses its first pseudonym AID; then, using a secure channel, the sensor node and gateway do the following: 1. The sensor node selects a random number r 0 and computes: b0 = h(ID s ||k s ||r 0 ). Then, it sends to the gateway: AID, r 0 , and b0. 2. Gateway selects a random number r 1 and computes: b1 = h(ID g ||k g ||r 1 ). It selects a key pool KP, whose size will depend on the resource capacity of the sensor node; a KP of three keys could be suitable for resource-constrained devices. Then to the sensor node it sends: b1 and KP. 3. The sensor node and gateway store the values {b0, b1, KP} in a secure manner.
The reason why the sensor node sends r 0 to the gateway is that there could exist an authentication server who knows all the sensor nodes that are valid in the system. Then, the gateway sends r 0 and b0 to the authentication server, which computes a b0 for each of the valid sensor nodes, using their ID s and k s that it knows, and the received r 0 , until a match between b0 and b0 is found. If it does not occur, the authentication server will indicate to the gateway not to register that sensor node in its network because it is not valid.

Authentication
The authentication procedure allows the sensor node and gateway to identify each other and have the confidence that they believe in each others' identities. It consists of five steps, as is described in Figure 2.

Sensor node Gateway
Select: r 1 and T 1 Compute:

Security Analysis
In this section, the security of the proposed protocol is analysed through formal and informal methods. The formal methods consist of AVISPA tool and BAN logic. Both are broadly-accepted instruments to analyse the accomplishment of mutual authentication and resistance to known attacks, and they have been used to assess the security of many protocols, including [43][44][45]. The informal method consists of analysing the security properties achieved by the proposal, and its resistance against known attacks, as was also done in the above-cited works.

Formal Verification with AVISPA
A formal security verification was performed on LAKD protocol using the SPAN+AVISPA tool. The AVISPA tool is an automated verification tool for cryptographic protocols. It supports four back-ends that search for attacks on the security properties of the protocol under verification. They are On-the-fly Model-Checker (OFMC), Constraint-Logic-based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC), and Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP) [46]. For the verification, the protocol has to be described using the High-Level Protocol Specification Language (HLPSL). It is a role-based language, where each role describes the information a principal can use initially, such as preshared keys and cryptographic algorithms, the initial state, requirements for state transitions, and specifications concerning how the roles interact with one another [47]. The SPAN tool is a protocol animator for HLPSL specifications which allows interactively building message sequence charts of the protocol and attacks that are found [48].
The AVISPA tool implements a communication channel controlled by a Dolev-Yao intruder, which means that the adversary can intercept, decompose, reassemble or modify the transmitted messages; however, because perfect cryptography is assumed, the adversary can analyze intercepted messages only if he/she possesses the decryption keys [49,50]. Three verifications are performed by the AVISPA tool. The first verification is the executability of a non-trivial HLPSL specification, which ensures that the protocol executes to completion; thus, it can reach a state where possible attacks can be found. The second is the verification of replay attacks, where the back-ends give the intruder the knowledge of regular sessions between legitimate agents, verify if legitimate participants can execute the protocol by searching for a passive intruder, and determine whether a replay attack exists. The third verification is Dolev-Yao checking, where back-ends verify if a MITM attack is possible. After the verifications, the AVISPA tool outputs whether the protocol is concluded safely or unsafely against MITM and replay attacks, or if the analysis is inconclusive [51].
The security goals specified in the HLPSL modeling of LAKD protocol were mutual authentication and secrecy of the session key SK. The first involves that an agent is correct in believing the aimed principal is in the current session, has reached a particular state, and agrees on some value that cannot be used twice with the same participants. If the mutual authentication goal is violated or the intruder learns a secret value, the tool concludes the protocol as unsafe, indicates which goal was unsatisfied, and provides an attack trace which shows the sequence of messages resulting in an attack.
In the verification of LAKD, CL-AtSe and OFMC back-ends were used because of their support of the xor operation [52]. In Figure 3 the verification results are shown; as can be seen, both back-ends concluded that LAKD protocol is safe against replay and MITM attacks, and the secrecy and mutual authentication goals were achieved.

Formal Verification with BAN Logic
BAN logic is a formal logic for analyzing the security properties of a protocol. It consists of a set of rules and postulates to reason about what principals believe about whom. BAN logic allows verifying whether the exchanged information on an authentication protocol is trustworthy [27]. Its notations and inference rules are introduced in Tables 2 and 3, respectively.
The security goals LAKD protocol has to satisfy to achieve mutual authentication are the following. GW represents the gateway, and SN the sensor node.
The idealized form of LAKD protocol is as follows: The assumptions about the LAKD protocol initial state are the following: The BAN logic proof demonstrating that LAKD protocol achieves the mutual authentication goals is presented in Appendix A. It consists of applying the BAN logic rules to the idealized form of the protocol and initial assumptions. Table 2. Burrows-Abadi-Needham (BAN) logic notation.

Symbol Description
Encryption key. P |≡ X P believes X. P X P sees X. P |∼ X P once said X. P ⇒ X P has jurisdiction over X. (X) X has not be sent in a previous protocol execution (it is fresh). P K ←→ Q P and Q may use key K in their communication.
X is a secret which is known only by P and Q, and possibly by principals that they trust.
where Y is a secret which proves the identity of the one who sent it. Table 3. BAN logic rules.

P|≡Q⇒X,P|≡Q|≡X P|≡X
Jurisdiction rule. (4) If one part of a formula is fresh, then the entire formula is fresh.

Informal Security Analysis
In this section, we provide an analysis of the security properties achieved by LAKD protocol and its resistance against known attacks.

Confidentiality
All information which has to be kept confidential between a gateway and sensor node is sent ciphered through an xor, or masked using random numbers and a one-way hash function. To send r 1 with confidentiality, it is ciphered through an xor with h(AID||b1||T 1 ). The value b1 is a secret between sensor node and gateway; therefore, the adversary cannot compute h(AID||b1||T 1 ) to obtain r 1 ; additionally, it cannot invert the hash function to obtain b1. The use of T 1 and AID causes the hash value to be different in each protocol execution, preventing the adversary to reuse old values of h(AID||b1||T 1 ) seized by him/her. In a similar manner, r 2 is sent ciphered with h(r 1 ||T 2 ), and idx with h(b1||r 2 ). The values r 1 and r 2 become session secrets. They are used to mask long-term secrets, such as b0, b1, and KP(idx), make messages dependent to the current session, make messages different and unpredictable between sessions, and construct the session key SK. Together with the hash function, they prevent the adversary from discerning secrets from the transmitted messages.

Data Integrity
The following scenarios describe what would happen if a message were to be modified during transmission. In all of them, the receptor can detect a data integrity violation. Consequently, it aborts the communication.
• If T 1 , AID, or D 1 is modified, the verification of digest value D 2 = h(r 1 ||T 1 ||b0) will not be true due to it is created with T 1 , r 1 , which the gateway derive from D 1 , and b0 which is selected according to the value of AID. Even if only one of T 1 , AID, or D 1 is altered, it will cause r 1 to be different from that originally sent, resulting in D 2 verification being false. Also, it is infeasible the adversary be able to fabricate a valid D 2 to hide its modifications, because its construction uses b0, which is a secret between sensor node AID and the gateway. • If T 2 , D 3 , or D 4 is modified, the verification of digest value D 5 = h(idx||r 2 ||b0||r 1 ) will not be true because it is created with r 2 and idx, which the gateway tries to derive from D 3 and D 4 , respectively. Concerning T 2 , it is used in D 3 ; thus, its alteration also affects r 2 . Even if only one of T 2 , D 3 , or D 4 is modified, it will result in different values of r 2 and idx from the sent by the gateway, causing the verification of D 5 to be false. Also, it is infeasible the adversary be able to fabricate a valid D 5 , because it uses b0. • If T 3 or D 6 is modified, the verification of digest value D 6 = h(b1||r 1 ||T 3 ||r 2 ||KP(idx)) will be false, because it is constructed with T 3 . It also uses KP(idx), which is the key from KP selected by gateway through idx in D 4 . It is infeasible the adversary be able to fabricate a valid D 6 , because he/she does not know the secret keys. • If T 4 or D 7 is modified, a similar situation to that previously described will happen, due to D 7 depends on T 4 and KP(idx).

Mutual Authentication
In the registration phase of LAKD protocol, the gateway and sensor node construct and exchange in a secure manner, the values b0 = h(ID s ||k s ||r 0 ), b1 = h(ID g ||k g ||r 1 ), and KP. The knowledge of b0, b1, and KP demonstrates to the gateway that an agent is the sensor node, and vice versa. Gateway authenticates the sensor node by verifying that M 1 was constructed using b0 and b1, and M 3 with b1 and KP(idx). The sensor node authenticates the gateway by confirming M 2 was created with b0 and b1, and M 4 with b0 and KP(idx). Therefore, both principals authenticate each other.

Sensor Node Anonymity
After each authentication session, the sensor node pseudonym AID is updated, and because random numbers are used in its modification, its new value is unpredictable. Therefore, an adversary can neither know the specific node behind some action nor keep a record of the activities performed by the same node.

Perfect Forward and Backward Secrecy
If the adversary obtains the current session key SK, he/she cannot derive older or futures SKs from it, because there is no relationship between them, since each key is constructed with values specific to the session it belongs. SK is constructed using ephemeral random values sent during the current session, the current AID of the sensor node, and the key KP(idx) selected in the current session. Even if the adversary obtains long-term keys, he/she will not be able to generate older SKs because of the ephemeral random numbers. Therefore, a sensor node can only access information which was transmitted when it was part of the network, neither the previous nor the future one.

Known Session Key Security
Each execution of a key agreement protocol should provide a unique session key. As a result, if the adversary learns some, he/she is not able to generate others [53]. In the proposed protocol, SK is constructed using two random numbers (r 1 and r 2 ), which are ephemeral and different per session. The AID of the sensor node is also used, which changes after each authentication session, and for its modification uses the secret b0 unknown to the adversary. Therefore, the adversary is not able to create SKs even if he/she learned some old ones due to the unpredictable changes.

Resistance to the Tracking Attack
In this attack, an adversary intercepts messages of different sessions and tries to find a relationship between them to determine if they belong to the same sensor node [54,55]. In LAKD protocol, the principals never use their identities. To authenticate, they use the secrets b0 and b1, which are the hash outputs of their identities, keys, and random numbers. Thus, the adversary cannot invert them to know the specific node behind a message. Also, every message is constructed using random numbers. Because they are different per session, messages between sessions are different and unpredictable. Finally, in each session, a different KP(idx) is selected, which contributes to the unpredictability among sessions. Consequently, an adversary cannot track a node from captured messages.

Resistance to the Offline Identity Guessing Attack
In this attack, the adversary tries to guess the sensor node or the gateway identity off-line. In the proposed protocol, only the values b0 and b1 contain the identities of the sensor node and the gateway, respectively. The values are not invertible because they are the result of a hash function. Also, they are never sent in cleartext, when used they are masked with timestamps and unknown random numbers to the adversary, and then input to a hash function. As a result, it is infeasible to obtain the identities or even b0 or b1 from the messages.

Resistance to Impersonation Attack
Every message sent in LAKD protocol uses at least one secret: b0, b1, or KP(idx). They belong to sensor node AID. It is not feasible that an adversary fabricates valid messages (M 1 , M 3 ) to impersonate sensor node AID, or (M 2 , M 4 ) to impersonate the gateway, due to the secrecy of b0, b1, and KP(idx), and because of the value AID changes unpredictably in each authentication session. Additionally, in every protocol execution, a different KP(idx) is selected from the key pool. This makes the impersonation even less possible, because the adversary is also required to know all the keys of KP.

Resistance to the Injection Attack
In this attack, an adversary fabricates and sends counterfeit messages to legitimate nodes. The proposal resists this attack like how it does to impersonation attack. Every transmitted message uses at least one shared secret between sensor node and gateway. It is infeasible than an adversary fabricates valid messages without knowing them. Additionally, every message contains a digest of the data in it. Therefore, the sensor node and gateway can easily detect counterfeit, replayed, or modified messages. The digest consists of the timestamp, random numbers, and shared secrets input to a hash function. The adversary cannot invert the function to fabricate a valid digest, also cannot modify the hash output in a deterministic manner to make it valid to his/her counterfeit data.

Resistance to the MITM Attack
In this attack, an adversary deceives agents into thinking their communication is secure, while he/she is in the middle of maliciously modifying and relaying messages. In the LAKD protocol, it is not feasible that the adversary modifies or fabricates messages without the sensor node and gateway detecting it, as described in subsections Data Integrity and Resistance to the Injection Attack. Also, it is not feasible he/she obtains secret values, such as identities, keys, b0, b1, or KP(idx) from the messages sent, because they are masked with random numbers, timestamps, and hash functions. Finally, the adversary is not able to obtain SK, because it is constructed using secret random numbers and the selected KP(idx) in the current protocol execution.

Resistance to the Privileged Insider Attack
In this attack, a privileged insider (e.g., a system manager with access to the gateway) tries to impersonate a node when accessing other servers where that node is registered, using the node's credentials of its system [56]. In the proposal, the gateway does not know the ID s and k s of the sensor node, and the sensor node does not know the ID g and k g of the gateway. During the registration phase, the principals share those values masked with random numbers and hash functions. Therefore, none of them can invert the operations and obtain the original values to use them to impersonate the node in other systems.

Resistance to the Replay Attack
To perform this attack, the adversary intercepts valid messages and maliciously delays or repeats them, faking ownership over them. LAKD protocol resists this attack in two ways. The first one is using timestamps for the verification of the transmission delay. Messages from an old session will have a transmission delay longer than the allowed. This will be detected by the gateway in D 2 , and by the sensor node in D 5 . Therefore, the receptor will not accept the messages, and it will abort the communication. The second form of resistance against this attack is using the ephemeral random numbers r 1 and r 2 , and a different KP(idx) key per session. If the adversary replays old messages from the gateway, sensor node will detect in D 5 = h(idx||r 2 ||b0||r 1 ) that r 1 is not the one it sent in M 1 . Similarly, if the replayed messages are from the sensor node, the gateway will detect in D 6 = h(b1||r 1 ||T 3 ||r 2 ||KP(idx)) that r 2 is not the one it sent in M 2 , and KP(idx) is not the one it selected. Therefore, LAKD protocol is resistant to replay attacks.

Resistance to the Known Session-Specific Temporary Information Attack
In this attack, the session key secrecy is compromised of the exposition of session-temporal secrets, such as random numbers. The adversary can perform the attack because random numbers are not usually stored in protected memory, as is done with keys and other long-term secrets. If after the session execution, the random numbers are not correctly deleted from memory, or the adversary controls the random number generator, he/she can obtain them and use them to generate the session key [53,57]. LAKD protocol is resistant to this attack, due to SK being constructed using the secret key KP(idx). Even if the adversary obtains the random numbers r 1 and r 2 , he/she will not be able to generate SK because he/she does not have access to the key pool.

Resistance to the DoS Attack
LAKD protocol can detect intent to perform a DoS attack from the first transmitted message. If M 1 is a replay message, the gateway will detect that the cleartext T 1 is not within the allowed transmission-delay. If T 1 was modified to make it look as valid, then the verification of the digest D 2 = h(r 1 ||T 1 ||b0) will be false. The adversary cannot construct a valid D 2 because he/she does not know b0. If M 1 is not a replay but a fresh and valid message originated by the adversary, the gateway will detect the malicious behavior when receiving many messages with the same AID. If the adversary modifies the cleartext AID to pretend that the message is from a different source, then the verification of D 2 will be false, because the adversary does not know the b0 of that AID node.

Resistance to the Desynchronization Attack
In this attack, the adversary tries to impede the communication between two legitimate nodes through de-synchronize them in the values required for the authentication [58]. In LAKD protocol, the only value that is updated after an authentication session is the pseudonym AID. In its modification r 1 , r 2 , b0, and the current AID are used . Before updating, the principals verify the identities of each other, and the correctness of the random numbers. The gateway confirms in M 3 that the sensor node is the real AID, because that message proves that the sensor node knows b0, b1, and KP(idx). It also confirms that the sensor node has the correct r 1 and r 2 . Similarly, the sensor node confirms in M 4 the identity of the gateway and the accuracy of the random numbers. As can be seen, the principals prove their identities and validate the data trustworthiness before using it to update AID, preventing this type of attack.

Resistance to Key Disclosure Attack
Resistance to long-term key disclosure attack: The long-term key of the sensor node k s , of the gateway k g , and the shared key between them KP(idx), are never sent in cleartext, ciphered with an xor, or transformed in another invertible way. Keys k s and k g are only used to construct b0 and b1, after hashing them with random numbers. Similarly, b0, b1, and KP(idx) are sent in the public channel only after hashing them with the secret random numbers r 1 and r 2 . Therefore, because it is infeasible to invert the hash output, the adversary cannot obtain or construct k s , k g , and KP(idx).
Resistance to the Session-Key Disclosure Attack: The session key is never sent in a message. It is constructed by the principals using r 1 , r 2 , and KP(idx), which are unknown to the adversary. The random numbers r 1 and r 2 are sent in the public channel using the hashed b0 and b1 to cipher them. Thus, the adversary cannot obtain them. Additionally, the key KP(idx) is sent only after hashing it with r 1 , r 2 , timestamps, b0, and b1. Therefore, the adversary can neither obtain nor construct the session key.

Performance and Security Evaluation
In this section, a performance analysis of LAKD protocol is presented. Five authentication protocols with similar architectures to the proposed scheme were used for comparison. The followed methodology is similar to the work in [59], where the performance was based on the execution-time and communication-cost of the protocols. The next two subsections present the execution-time and communication-cost analysis, respectively.

Execution-Time Analysis
In the execution-time calculation, what is contemplated is the cost of executing hash functions and cipher algorithms; the cost of very lightweight operations, such as xor, addition, and subtraction is considered negligible. Two metrics were used for the hashing and encrypting/decrypting cost, similar to [59]. They are described in Table 4. The first metric, denominated Case 1, corresponds to the work in [21]. The second metric, named Case 2, is from [33].
The execution-cost of LAKD protocol is presented in Table 5, together with that of protocols [22,[60][61][62][63], which were also designed for M2M communication. Concerning the Case 1 measurement, the proposal has less execution-time than the other protocols, except for the schemes of Esfahani et al. [22] and Joshitta et al. [63]. The cost difference between LAKD and Esfahani et al. is of just one more hash execution in the sensor node in LAKD, and for Joshitta et al. the difference is of 48.07% less cost in the medical device compared to the sensor node of LAKD, and 23.07% less in the authentication server compared with the gateway of LAKD. For Case 2, only Esfahani et al. has less execution-time, because of the additional hash execution in the sensor node of LAKD. Table 4. Execution-time comparison criteria. The cost is presented in milliseconds (ms). T h represents a hash function execution, and T e the AES encryption/decryption execution.

Case 1
T h 0.0051700 T e 0.0214800 The proposed protocol was designed to achieve two goals: proper security and computational-cost for resource-constrained IIoT devices. As can be seen in Table 5, the proposal has a proper execution-cost when comparing it with other schemes. Some protocols have less cost; however, they do not achieve all the security properties that LAKD protocol does. Two of them even have serious security issues, such as key disclosure, as is described in the subsection Attack Resistance Comparison.

Communication-Cost Analysis
The communication-cost was analyzed according to the number of bits that have to transmit the principals to authenticate, as in [44,59,64,65]. To compute the communication-cost, the size of each transmitted datum in the protocol was obtained and added to get the total amount of transmitted bits. Two metrics were used to obtain the size of the transmitted data, similarly to the methodologies in [44,59]. They are described in Table 6. In the first metric, denominated Case 1, it is considered that hash outputs, random numbers, timestamps, identities, and keys are 128 bits long, and for Case 2 they are 256 bits long. In both cases, the encryption output is of 128 bits per block [59]. The sizes of 128 and 256 bits of the metrics follow the conventional size of data in security. Table 7 presents the communication-cost of LAKD protocol and the comparison schemes. Three protocols have less communication-cost than the proposal, which are Esfahani et al., Han et al., and Joshitta et al., with differences of 33.33%, 41.67%, and 50% (54.17% for Case 2), respectively. The proposed protocol requires sending only four messages to achieve mutual authentication, and they contain timestamps, xor-ciphered random numbers, and message authentication codes (MACs) from a hash function. Sending this information prevents attacks such as modification, replay, DoS, and impersonation [28]. The protocols that have less communication-cost do not send all this information; consequently, they have been found vulnerable to some of the attacks, as can be seen in has a proper cost for IIoT, and it does achieve more security properties than the protocols with less cost. We developed our proposal giving security more priority than saving a few bits in the transmission.

Attack Resistance Comparison
The security properties of LAKD protocol and the other schemes for M2M communication were analyzed to obtain their attack resistance. Furthermore, articles that have a security analysis of the comparison schemes were reviewed to complete the information, such as [28][29][30]. In Table 8 is summarized the analysis results of common attacks, as was done in [44,45,64,65]. Through analyzing the attack resistance of an authentication protocol, researchers and developers can decide its best application area, and they can be aware of its limitations and how to handle them.
As can be seen in Table 8, schemes with less execution-time and communication-cost have security vulnerabilities that our proposal does not. Take Esfahani et al.'s protocol, for example. It has been found vulnerable to modification, session and long-term key disclosure, privileged insider, impersonation, DoS, and tracking attacks in [28][29][30]. Concerning Joshitta et al., some of its security vulnerabilities are the use of the same session key between sessions, and its disclosure.
The protocol is resistant to the attack. x: The protocol is vulnerable to the attack.

Discussion
In this paper, an authentication protocol called LAKD is proposed for IIoT devices. It aims for low computing requirements to enable its implementation in highly resource-constrained devices, such as those of Class 0 in the RFC 7228 classification. To accomplish it, the protocol does not use any public-key cryptography, because using it has a high impact on the device's resources [15,16]. Additionally, it does not use encryption algorithms; instead, it is based only on simple operations such as xor, addition, subtraction, and a hash function. According to the measurements in [21], the hash function has 75.93% less execution-time than an encryption algorithm, and in [33] it had 99.85% less.
LAKD protocol uses the xor operation to cipher session random numbers, and a hash function to generate MACs to have integrity of the transmitted data. The use of these lightweight operations makes the protocol have a low impact on the resources of the devices, and still achieves the security properties required for IIoT. As was described in section Security Analysis, the security of the protocol was formally and informally analyzed. One formal analysis was presented using the AVISPA tool, a well-known instrument that has been used in many protocols to assess their security. It considers a Dolev-Yao channel where the adversary can intercept, reassemble, and modify any message, which represents real adversary capabilities. In that scenario, LAKD protocol was concluded to be safe against replay and MITM attacks, which are the verifications the tool performs. Another formal analysis was done using BAN logic. The authentication was complete when the next goals were accomplished: And a strong authentication was achieved when the following goals were met [66]: An informal analysis was also presented, demonstrating the accomplishment of the security properties of confidentiality, integrity, mutual authentication, sensor node anonymity, perfect forward and backward secrecy, and known session key security, and its resistance against known attacks. Table 8 is an attack-resistance comparison between the proposal and protocols for M2M communication with similar architecture. It showed that LAKD protocol achieves security similar to schemes that require more computational resources, such as Qiu et al., which is resistant to many attacks but at the cost of a high execution-time and communication-cost.
Of the security properties achieved by the proposed protocol, sensor node anonymity and tracking resistance have special importance in IoT. If an adversary can know the node or user behind some activities, private information can be exposed, such as medical situations, work routines, living habits, etc. This information can be used from targeted marketing to extortion. The LAKD protocol accomplishes anonymity and tracking resistance through working with pseudonyms in the sensor node instead of its identification, and by changing the pseudonym in each session to prevent the adversary from associating activities to a specific node, similarly to Qiu et al. Additionally, the use of random numbers makes messages different and unpredictable in each session, which impedes the adversary in finding a relationship between them.
Security and performance in terms of execution-time and communication-cost were contrasted. In Table 9 are the differences in the percentages of execution-times of the schemes against LAKD, and in Table 10 of the communication-cost. As can be seen, secure proposals such as Qiu et al. have higher execution-times and communication-costs. Comparing the proposal to Qiu et al., the sensor node, which is the most constrained device, has 63% less execution-time for Case 1, and 99.69% for Case 2. Also, it transmits 71.43% fewer bits. These savings are significant for resource-constrained devices, where the limited resources have to be shared between the IoT application, and the network and security services.
As with every protocol, there are limits in LAKD. Its main limitation is that it is required that the gateway store a key pool for each sensor node in its network. Usually, the gateway is a device with plenty of computational resources. However, if its network is very large, the storage cost can be significant. An approach to managing this for large networks is having an authentication server that stores all the key pools. Then, when a sensor node starts the communication with the gateway, the latter retrieves from the authentication server the sensor node's key pool to perform the authentication. The gateway could store some key pools of sensor nodes that frequently communicate with it, similarly to the cache memory proposed in [67], to prevent delays in their communication.

Conclusions
In this work, the LAKD authentication protocol for M2M communication in IIoT has been presented. It intends for a low computational-cost to be suitable for resource-constrained IIoT devices. To achieve it, the proposal is based on the lightweight operations xor, addition, and subtraction, and a hash function. The security of the protocol was assessed with the AVISPA tool and BAN logic, which confirmed its mutual authentication goal, and its resistance against replay and MITM attacks. Also, the accomplishments of confidentiality, integrity, mutual authentication, perfect forward and backward secrecy, and known session key security were informally analyzed. Additionally, its resistance to known attacks was checked. The performance of the proposal was analyzed and compared to schemes for M2M communication with similar architecture. It resulted in a good execution-time and communication-cost for IIoT. When comparing the security, LAKD resulted in higher attack resistance, its security being similar to schemes with more computational requirements.
The high security and low computational-cost of LAKD protocol allow resource-constrained IIoT devices to be capable of implementing a security service to protect data privacy and industrial secrets, and prevent threats such as device impersonation, data disclosure, and MITM attacks, which can disrupt the system operation, and even threaten the user's welfare.

Conflicts of Interest:
The authors declare no conflict of interest.
Step 14: From Step 10, applying Rule 4 and the assumption SN |≡ r 1 because it is its originator, we get: SN |≡ GW r 2 SN r 1 .
Step The four security goals that LAKD protocol has to satisfy to have mutual authentication are achieved.