A Novel Lightweight Block Cipher-Based Mutual Authentication Protocol for Constrained Environments

The communication security of constrained objects such as radio frequency identification (RFID) tags and wireless sensor network (WSN) is very challenging because it is not always possible to use the conventional on-the-shelf solutions for them, due to their limited available power and computational capabilities. To deal with this demand, many security protocols have been developed by the researchers so far. However, in many cases, the later analyses that have been carried out on these protocols have shown that they are vulnerable to one or few attacks, which could be enough to eliminate any application for such protocols. Following this direction, in this article, we analyze the security of four recent ultra-lightweight/lightweight protocols, by presenting important attacks including secret disclosure attack and desynchronization attack against them. To address the shortcoming of the previous protocols, we present a new security protocol based on lightweight block ciphers name it LBCbAP. In this protocol, we use CRAFT as the core security primitive. CRAFT is a tweakable block cipher which has been recently proposed and independent security analysis confirmed its security. Our detailed security analysis of LBCbAP, which is performed both informally and formally through the GNY logic and the Scyther tool, demonstrates its security against various types of attacks including secret disclosure and desynchronization attacks. The cost analysis of the designed protocol and comparison with the related lightweight protocols show that LBCbAP is cost efficient.


I. INTRODUCTION
Internet of Things (IoT) can be used to control a device through an Internet connection. IoT covers a wide range of applications at large and small scales. IoT technology has already been used in many applications including smart homes, smart cities, wearable technology, and smart cars. For example, a wearable gadget includes a series of sensors and The associate editor coordinating the review of this manuscript and approving it for publication was Weizhi Meng . uses special software to collect its user's data; these gadgets ultimately analyze aggregated data such as health and fitness and report the results to the user. The IoT technology also has extensive application in vehicular system, smart grid and so on.
An important issue that has always been raised about the IoT is its security issue. Since this technology connects a lot of devices through the Internet, hacking them can have irreparable losses, such as losing sensitive personal and economic information. Therefore, a research challenge in this field is to ensure users' privacy and the confidentiality of their information by developing suitable software and hardware, to be used in Internet-based products. On the other hand, one of the solutions for implementing the IoT connection in the edge devices is the use of Radio Frequency Identification (RFID). Many solutions around the world generally use available components of RFID technology. RFID is used for security purposes mainly in the field of trade and warehouse logistics. Compared to other security technologies, RFID offers much greater potential than just for security itself, and so this technology is often deployed where monitoring is needed [1], e.g. patient medication safety [2]. However, RFID based devices are very constrained and cannot support conventional security solutions, which raises the security concerns of the related applications.

A. RELATED WORK AND MOTIVATION
IoT has brought the new potential to the Internet by enabling smarter communication between objects and man [3]. As stated in [3], these days the increasing amount of cyber attacks is a limit of IoT's current paradigm, which is to connect any object anywhere. A factor that can help to expand the IoT is to ensure users of this technology in terms of maintaining their privacy and security, because if there is no proper security in this infrastructure, damage to IoT-based equipment, the possibility of losing personal information, the loss of privacy, and even the disclosure of economic and other data, are highly likely. Ronen et al. in [4] pointed out that if security is not taken into account in the IoT-based infrastructure, the technology will threaten the future of the world as a nuclear bomb. Hence, analyzing the proposed mechanisms from security aspect and designing new security modules that are compatible with IoT-based devices are also very important. Given that an IoT system can include many objects with limited resources, it requires special protocols to ensure that privacy and security of participants are guaranteed. Therefore, with the further development of IoT, its security concerns are expected to receive more attention. So far, several many protocols have been proposed to ensure IoT security, e.g. [5]- [9], however, most of them have failed in providing their security goals [10]- [13] and various attacks, such as the protocol's secret values disclosure, desynchronization, traceability, impersonation were reported against those protocols. For example, Lee et al. proposed a new authenticated group key agreement protocol for imbalanced wireless networks [14]. However, later Cheng et al. showed that an active adversary can impersonate a mobile user efficiently [15]. Some other solutions proposed multi-factor authentication [16], [17] which may not be applicable in many RFID based applications, because in this case it is not practical to request the tagged object to do login operation by for example contributing its username and password. These attacks on the previous protocols resulted in a boost among protocol designers' that are attempting to design protocols resilient against the published attacks and also compliant with more applications. However, there are still attacks against newly designed protocols. In addition, it would not be reasonable to trust any newly designed security protocol as far as it has not been enough analyzed by independent researchers. Hence, to address this demand, in this article we examine the security of four recent lightweight/ultra-lightweight protocols, to determine their pros and cons. It must be noted, although the proposed attacks are theoretical and have not been implemented against any real application, demonstrating different methods for attacking security protocols also helps the designers to consider those new lessons in their later designs to avoid past mistakes. The system model of our target application is represented in Figure 1. It is clear form this figure we consider the edge layer of a network where a reader communicating to tags over public channel. In this model, the adversary can control the communication between the reader and the tags passively or actively.
Two of the attacked protocols belong to ultra-lightweight protocols. This type of protocols, attempts to design a secure protocol for constrained environments with very simple functions such as bit-wise operations. There are many examples for such designing, e.g. SASI [18], RAPP [19] and SecLAP [20], and the later related third parties analysis [10], [21]- [23]. In the line of designing ultra-lightweight protocols, in [11], Wang et al. cryptanalyzed the Tewari and Gupta [24] protocol and also proposed an improved version of it. This protocol later analyzed by Khor and Sidorov [25], where they also proposed an improved protocol following the same designing paradigm. In this article, we consider the security of this improved protocol which has been proposed by Khor and Sidorov, and for simplicity, we call it KSP (stands for Khor and Sidorov protocol). We show that KSP is vulnerable to desynchronization attack and also secret disclosure attack.
As a new emerging technology, blockchain is believed to provide higher data protection, reliability, transparency, and lower management costs compared to a conventional centralized database. Hence, it could be a promising solution for large scale IoT systems. Targeting those benefits Sidorov et al. recently proposed an ultra-lightweight mutual authentication RFID protocol for blockchain-enabled supply chains [26]. Although they have claimed security against various attacks, we present an efficient secret disclosure attack on it. For the sake of simplicity, we call this protocol SOVNOKP.
Similar to SOVNOKP paradigm, Jangirala et al. also recently designed LBRAPS protocol [27] which is a lightweight blockchain-enabled RFID-based authentication and key agreement protocol. We also evaluate the security of this lightweight protocol.
Recently, Xiao proposed a mutual authentication protocol based on lightweight block cipher SKINNY [28] and named it LRSAS protocol [29]. Although they claimed optimal security, we present an efficient desynchronization attack against it which can be extended to traceability attack.

B. THE PAPER CONTRIBUTION
We can summarize the contributions of this article as below: • We present the first third party analysis on two ultra-lightweight protocols, i.e. KSP and SOVNOKP, to the best of our knowledge. For example, we present efficient secret disclosure attack against these protocols. Following the proposed attacks in this article, one can extract whole secrets of those protocols with the complexity of only eavesdropping two sessions of each protocol between the tag and a legitimate reader, with negligible computational complexity. It is worth noting that an early draft of these attacks is also available in arxiv [30].
• We present the first third party analysis on two lightweight protocols, i.e. LBRAPS and LRSAS, to the best of our knowledge. In the case of LBRAPS, we present an efficient traceability attack and if the adversary could compromise a tag then it can also extract the secret of other tags. Our analysis for LRSAS is a very efficient desynchronization attack.
• We propose a new protocol and name it LBCbAP (Lightweight Block Cipher-based Authentication Protocol).
• Informally and also formally we provide the security proof of the proposed protocol using the GNY logic and the Scyther tool which show that LBCbAP provides desired security against different passive and active attacks such as secret disclosure attack, replay attack, and traceability attack.

C. PAPER ORGANIZATION
The rest of the paper is structured as follows: Section II is dedicated to a brief review of KSP, SOVNOKP, LBRAPS and LRSAS which are among recent proposals to provide security in the IoT/RFID environment. Our proposed secret disclosure attacks are applied to these protocols in Section III. We also proposed a secure protocol called LBCbAP in Section IV and its security proof is explained in Section V. The comparison of the proposed protocol with the related protocols is provided in Section VI. Finally, the paper is concluded in Section VII.

II. DESCRIPTION OF THE ATTACKED PROTOCOLS
To describe the protocols, we use the notations that are represented in Table 1. The notations are also used through the other parts of the paper.

A. KSP
Khor and Sidorov [25] proposed a new improved protocol which we call it KSP and runs as follows: 1) The reader R starts the authentication phase of the protocol by sending Hello and a random number r to the tag T i . 2) T i , when receives the message, generates a random number q and computes M 1 = Rot(q⊕r, wt(q)), M 2 = IDS new ⊕ r ⊕ q and M 3 = Rot(IDS old ⊕ IDS new , wt(q)) and sends {M 1 M 2 M 3 } to R. 3) Upon receipt of the message, R does as follows: • It does an exhaustive search to find wt(q) to obtain a record of its database that satisfies the received M 1 and M 2 , where R will be able to find IDS old also, given M 3 , to authenticate T i .
• R generates two new random numbers m and n and computes M 4 = m ⊕ n ⊕ q, M 5 = Rot(n, wt(K )) and M 6 = Rot(Rot(K ⊕ m, wt(n)), wt(K ⊕ n)) and sends them to T i . 4) Once T i receives the message, it: • Extracts n and m and verifies the messages integrity based on M 6 to authenticate R.
• If R has been authenticated, T i and R will update their new parameters as IDS new = Rot(IDS new ⊕ q, wt(n)) ⊕ Rot(q, wt(m)) and K new = Rot(K new ⊕ q ⊕ n, wt(m)) ⊕ Rot(m, wt(n)).

B. SOVNOKP
SOVNOKP [26] follows the KSP designing paradigm and it is based on almost similar components and runs as follows: 1) The reader R starts the authentication phase of the protocol by sending Hello and a random number r to the tag T i . 2) T i , when receives the message, generates a random number q and computes M 1 = Rot(IDS ⊕ r, wt(q)), and M 2 = Rot(IDS, wt(r)) ⊕ Rot(K ⊕ r, wt(q)) and sends {M 1 M 2 } to R. 3) Upon receipt of the message, R forwards r M 1 M 2 to the supply chain node. 4) Upon receipt r M 1 M 2 , the supply chain node does as follows: • It does an exhaustive search to find wt(q) to obtain a record of its database that satisfies the received M 1 , where R will be able to find IDS and K to verify the received M 2 to authenticate T i .
• Based on the H (IDS K ), it can check and track the product history together with permission level by reading the data from the blockchain. If the product has a correct history record in terms of ownership, timestamp, location, and product status, the supply chain node can authenticate T i .
• Once T i has been authorized, the supply chain node generates a random number m and computes M 3 = Rot(r, wt(IDS) ⊕ wt(K )) ⊕ Rot(m, wt(K )), and M 4 = Rot(m, wt(IDS)) ⊕ Rot(r, wt(K )) and sends • Extracts m from M 4 and verifies the messages integrity based on M 4 to authenticate the reader/supply chain node.
• If the reader/supply chain node has been authenticated and wt(m) is even, T i will update its parameters as IDS new = Rot(IDS ⊕ K , wt(r)) ⊕ Rot(K ⊕ wt(q), wt(IDS)) and K new = Rot(K , wt(r)) ⊕ Rot(r ⊕ q, wt(K )).

C. LBRAPS
LBRAPS [27] is a lightweight blockchain-enabled RFID-based authentication and key agreement protocol designed by Jangirala et al. This protocol uses hash function and also ultra-lightweight components such as rotation and XOR to provide a secure authentication between the tag, the reader and the supply chain node. In the initialization phase of the protocol, the reader and the tag are sharing their identifiers with the supply chain node and they consider their identifiers as the passwords. This protocol includes several steps but we only represent the first two steps of the authentication and key agreement phase of the protocol, which include a challenge-response communication between the reader and the tag, as follows: 1) The reader starts the authentication phase of the protocol by generating a random number r at time TS R and computing M 1 = Rot(r ⊕ ID T ⊕ TS R , TS R ⊕ ID T ) and We do not represent the rest of the protocol because it has no effect on the proposed analysis. Bal new is the new balance related to the blockchain. Interested readers can find a full description of this protocol in [27].

D. LRSAS
LRSAS [29] is a recently proposed RFID authentication protocol based on a lightweight block cipher SKINNY [28], designed by Xiao et al. In the initialization phase of this protocol, the tag's identifier ID i , pseudonym IDS i and key K i are shared with the reader. The mutual authentication phase of the protocol is as follows: 1) The reader R starts the authentication phase by sending a request to the tag T i . 2) As the response, T i sends its IDS i to R. 3) Given IDS i , R finds related (ID i , K i ), generates a random number r and computes M 1 = IDS i ⊕ r and The tag, when receives the message, extracts r as M 1 ⊕ IDS i and verifies whether M 2 = M 1 and uses the SKINNY tweakey schedule to compute K new i (its details has no effect on the proposed analysis). It also sends an OK command to T i . 6) Once received the OK command, T i updates its pseudonym as IDS new i = M 1 and uses the SKINNY tweakey schedule to update its K new i .

LRSAS
Although the designers of KSP and SOVNOKP argued their protocol's security formally, it is easy to show that these VOLUME 8, 2020 protocols are as vulnerable to different attacks as their predecessor rotation-based protocols. Designers of LBRAPS claimed its security in the Canetti and Krawczyk's adversary model (CK-adversary model) [31]. This protocol uses a hash function in calculating some messages, however, parts of the transferred messages are generated using ultra-lightweight operations including XOR and rotation. We use these parts to attack this protocol. Regarding LRSAS, although designers argued its security formally, we show that it does not provide the expected security.

A. SECRET DISCLOSURE ATTACK ON KSP
To analyze KSP, we follow the same adversary model as its designers, when they analyzed Wang et al.'s protocol [25, Sec.II, page 92], where ''adversary is able to eavesdrop, intercept, block, and modify messages sent during communication between the reader and a tag''. Given the target tag, the attack procedure will be as follows: 1) The adversary eavesdrops a session of the protocol between the target tag and a legitimate reader, where, the reader generates an arbitrary nonce r and sends it to the tag, along Hello.
2) The tag, when receives the message, generates a random number q and computes M 1 = Rot(q ⊕ r, wt(q)), which is eavesdropped by the adversary. 3) Upon receipt of the message, the reader does as follows: • It does an exhaustive search to find wt(q) to obtain a record of its database that satisfies the received M 1 and M 2 , where the reader will be able to find IDS old also, given M 3 , to authenticate the tag.
• The reader generates two new random numbers m and n and computes M 4 = m ⊕ n ⊕ q, M 5 = Rot(n, wt(K )) and M 6 = Rot(Rot(K ⊕ m, wt(n)), wt(K ⊕ n)) and sends them to the tag, which is eavesdropped by the adversary. 4) The adversary terminates the protocol. 5) Given that the tag has not received M 4 M 5 M 6 , it will not update its records, i.e. IDS new , K new , IDS old and K old . 6) The adversary waits for another session between the target tag and a legitimate reader, where, the reader generates an arbitrary nonce r and sends it to the tag, along Hello. 7) The tag, when receives the message, generates a random number q and computes to the reader, which is eavesdropped by the adversary. 8) Upon receipt of the message, the reader does as follows: • It does an exhaustive search to find wt(q ) to obtain a record of its database that satisfies the received M 1 and M 2 , where the reader will be able to find IDS old also, given M 3 , to authenticate the tag.
• The reader generates two new random numbers m and n and computes M 4 = m ⊕ n ⊕ q , M 5 = Rot(n , wt(K )) and M 6 = Rot(Rot(K ⊕ m , wt(n )), wt(K ⊕ n )) and sends them to the tag, which is eavesdropped by the adversary. 9) Given that M 2 ⊕M 2 = q⊕r ⊕q ⊕r , the adversary finds two offset values c and c , respectively as wt(q) and wt(q)). 11) The adversary finds three offset values c 1 , c 2 and c 3 , respectively as wt(K ), wt(n) + wt(K ⊕ n) and Following the above attack, the adversary extracts whole shared parameters between the tag and the reader with the complexity of eavesdropping two sessions of the protocol, blocking a message, and doing polynomial computations. It is clear that M 2 ⊕ M 2 = q ⊕ r ⊕ q ⊕ r . Now the adversary can also compute the updated values of IDS new and K new as IDS new = Rot(IDS new ⊕ q, wt(n)) ⊕ Rot(q, wt(m)) and K new = Rot(K new ⊕ q ⊕ n, wt(m)) ⊕ Rot(m, wt(n)). Remark 1: It should be noted the adversary can use other metrics to filter possible wrong guesses, e.g., c 1 , c 2 and c 3 should be respectively equal to wt(K ), wt(n) + wt(K ⊕ n) and wt(n ) + wt(K ⊕ n ).
Given that the adversary has whole secret parameters, applying any other attack will be trivial, e.g., reader/tag impersonation, desynchronization, and traceability attacks. Given the target tag, the attack procedure, which is almost similar to the attack against KSP, will be as follows: 1) The adversary eavesdrops all transferred messages over a session of the protocol between the target tag and a legitimate reader, i.e., r, 2) The adversary blocks M 3 M 4 , sent from the reader to the tag. Hence, the tag will not update its secrets, i.e., IDS and K .
3) The adversary waits for another session between the target tag and a legitimate reader, where, the reader generates an arbitrary nonce r and sends it to the tag, along Hello. 4) The adversary again eavesdrops all transferred messages over a session of the protocol between the target tag and a legitimate reader, i.e., r , IDS ⊕r ⊕IDS ⊕r = r ⊕r and r and r are transferred over insecure channel, which is eavesdropped by the adversary, the adversary extracts IDS and K as follows: i)⊕r, i and j respectively as IDS, wt(q) and wt(q ).
6) Given r, r , IDS, wt(q) and wt(q ), the adversary extracts K as RRot((M 2 ⊕Rot(IDS, wt(r))), wt(q))⊕r. 7) The adversary can use other metrics to filter possible wrong guesses, e.g., M 2 , M 3 , M 3 , M 4 and M 4 . 8) The adversary calculates the updated parameters as Following the attack, the adversary extracts whole shared parameters between the tag and the reader with the complexity of eavesdropping two sessions of the protocol, blocking a message and doing polynomial computations. In this case also, since the adversary has whole secret parameters, applying any other attack will be trivial, e.g., reader/tag impersonation, desynchronization and traceability attacks.

C. SECURITY ANALYSIS OF LBRAPS
Designers of LBRAPS claimed its security in the Canetti and Krawczyk's adversary model (CK-adversary model) [31], which is a stronger adversary model compared to the Dolev-Yao (DY)-adversary model [32]. In the DY-adversary model, an adversary has full control over the transferred messages over the public channel and can eavesdrop, modify or delete the communicated messages among the various instances, or insert fake messages in between the communication. In the CK-adversary model, beside his/her abilities in the DY-adversary model, the adversary can also compromise the session states along with secret information, including secret keys. Thus, assuming the session states along with secret information are compromised in a particular session, this revealed information must not lead to compromise the secrecy of other parties [27].

1) SECRET DISCLOSURE ATTACK ON LBRAPS
In this section, we first extract a part of information related to the tag which can be used to trace it in a later session, in the DY-adversary model. Next, we extend the attack in the CK-adversary model to compromise the protocol's security. Given a target tag T i which is communicating with the supply chain node (S) through the reader R, the attack procedure will be as follows: 1 value of ID T ⊕ ID S . Following the above attack, which is in the DY-adversary model, the adversary could extract ID T ⊕ ID S which is expected to be confidential. This information is enough to trace T i , as long as it is in communication with the same S. Next assume to follow the CK-adversary model, which has been used by the designers of LBRAPS. We assume that the adversary compromised a tag T i and achieved its identifier ID i . Given the above attack, the adversary can also extract ID S . On the other hand, given ID S , the adversary can extract ID j for any other tag T j , applying the given attack. It shows that in the CK-adversary model it is possible to retrieve the identifier of any tag, which contradicts the designers' claim. Given the identifier of the tag, which is its password also, it is also possible to extract r and other shared values in each session, which have been considered secure in this protocol.

D. DESYNCHRONIZATION ATTACK ON LRSAS
In this section, we present our analysis on LRSAS. The main drawback of this scheme is lack of session randomizing by T i . Hence, it is possible to desynchronize the tag and the reader following the procedure described in [10] against other protocols. Therefore, we just present a brief description of the attack as follows: 1) The reader R starts the authentication phase of LRSAS by sending a request to the tag T i . 2) As the response, T i sends its IDS i to R.
3) Given IDS i , R finds related (ID i , K i ), generates a random number r and computes M 1 = IDS i ⊕ r and Hence, the protocol is terminated and the reader is expected to start another session. 5) R starts the authentication phase by sending a request to T i . 6) As the response, T i sends its IDS i to R. 7) Given IDS i , R finds related (ID i , K i ), generates a random number r * and computes M * 1 = IDS i ⊕ r * and M * 2 = E K i (IDS i ⊕ ID i ⊕ r * ) and sends{M * 1 , M * 2 } to T i . 8) The tag, when receives the message, extracts r * as M * 1 ⊕ IDS i and verifies whether M * 2 ?
= E K i (IDS i ⊕ ID i ⊕r * ) to authenticate R, which is authenticated and T i computes M * 3 = E K i (M * 2 ⊕ r * ) and sends it to R. 9) R verifies whether M * 3 ? = E K i (M * 2 ⊕ r * ) and authenticates T i . Next it assigns (IDS i , K i ) to (IDS old i , K old i ) and IDS new i = M * 1 and uses the SKINNY tweakey schedule to compute K new i and sends an OK command to T i , which is blocked by A and T i does not update its record. 10) A impersonates R by sending a request to T i . 11) As the response, T i sends its IDS i .

IV. LBCbAP: A SECURE LIGHTWEIGHT PROTOCOL
In the previous sections, we pointed out the security pitfalls of four ultra-lightweight protocols, which beside other related studies demonstrates the shortcoming of this approach to design a secure protocol. On the other hand, many lightweight block ciphers have been proposed in recent years. The lightweight block ciphers CRAFT [33], GIFT [34], SKINNY [28] and SIMON [35] or some proposed modes of operation to guarantee both the confidentiality and message integrity such as IAR-CTR and IAR-CFB [36] are some examples. It is worth noting that most of those block ciphers can be implemented even in passive RFID tags, based on their reported implementation results. For example, the unprotected version of CRAFT, which has been recently proposed, requires only 949 Gate Equivalents (GE) [33, P.30, Table  6]. Besides, recently NIST is organizing a competition for lightweight cryptography [37] which already has announced its second-round candidates also. Hence, thanks to the recent advances in lightweight ciphers, to provide a secure protocol for the constrained environments, such as RFID tags and IoT edge devices, we propose a new authentication protocol based on lightweight block ciphers. In this section, we propose LBCbAP, a lightweight block cipher-based authentication protocol. As the main building block, we use CRAFT block cipher [33], which has been proposed in FSE'19 by Beierle et al.. CRAFT is a tweakable block cipher, which maps a 64-bit plaintext to a 64-bit cipher using a 128-bit secret key K = K 0 K 1 and a 64-bit tweak T . It is worth noting that a tweakable block cipher [38] not only accepts the usual plaintext and secret key but also a third input which is known as the ''tweak'', which serves much the same purpose that an initialization vector does for CBC (Cipher Block Chaining) mode of block ciphers or stream ciphers. The best-known distinguisher for this cipher in single tweak mode covers 14 rounds [39] out of 32 rounds. It shows that, although the cipher is very lightweight, it provides good security also. Details of this cipher can be found in [33]. It is worth noting that the current distinguishers are in the known/chosen plain text modes which are not practical in many protocols because the adversary has no access to the input plaintext in general. Hence, it should be possible to achieve desired security using a reduced round version of the block ciphers.
LBCbAP has oracle access to CRAFT as C = E K ,T (P) or P = E −1 K ,T (C), where E, E −1 , P, C, T and K respectively denote encryption, decryption, plaintext, ciphertext, public tweak and secret key. LBCbAP includes three parties, a tag T i , a reader R and a trusted database. The channel between the tag and the reader is public while the channel between the reader and the database is secure. We assume that in the initialization phase, the database stores the tuple < ID i , K i , IDS i > as the identifier, the shared secret key and the pseudonyms of T i in the tag securely. It could be equivalent to programming the tag in the factory. These parameters are also stored in the trusted database as In addition, acceptable threshold for challenge-response time is also set for R and T i respectively as T R and T T . The mutual authentication phase of LBCbAP between R and T i is depicted in Figure 2 and runs as follows: 1) At the time TS R , the reader R starts the authentication phase by generating a random number r and sending it with the Hello message to the tag. 2) The tag T i , when receives the Hello message and r, generates a random number q and computes M 1 = E K i ,q (ID i ⊕r) and sends {IDS i , M 1 , q} to R. It also runs a timer TS T initiated by zero.
whether TS R − TS R ≤ T R to avoid relay attacks; otherwise terminates the protocol. Next, given IDS i , R finds related secrets < K i , ID i > (looks at the new records first and then at the old records) and verifies the received M 1 to authenticate T i . 4) R stores the used

V. SECURITY ANALYSIS OF LBCbAP
Possible approaches to provide security proof of a cryptographic protocol are divided into formal and informal categories. Informal methods of security proof are based on analytical knowledge and are mostly based on cryptanalyst creativity, while formal methods, which are themselves divided into two categories of manual methods and automated methods, are either model checking based or Theorem prover based or logic-based such as the logic of belief. Tools such as Proverif [40], AVISPA [41] and Scyther [42] belong to automated formal methods while methods such as BAN logic [43], SVO [44], [45] and GNY logic [46] are among manual formal methods. In this section, beside informal security analysis, we prove the correctness of our proposal both informally and formally through the GNY logic and the Scyther tool.

A. INFORMAL SECURITY ANALYSIS
Our adversary model follows CK-adversary model, where the adversary can control the channel and if it compromises a tag then the security of the other tags should not be affected.

1) TRACEABILITY ATTACK
To perform the traceability attack on a protocol, the adversary tries to connect the transferred messages over different sessions or link them with the protocol's party. In the LBCbAP, transferred messages are r, Hello, ⊕ r)). Hello is a meaningless message VOLUME 8, 2020 for the adversary to be used for traceability. r and q are also fresh nonces that the adversary cannot control both. M 1 and M 2 are also randomized by r and q and sound random to A, assuming the used cipher is secure. The only parameter which could be used to trace the tag is IDS i . However, after a successful session of the protocol, this parameter is also updated and randomized by r and q. It is worth noting that in symmetric-crypto based protocols, if we aim to keep scalability, this type of traceability seems to be unavoidable. It is possible to mask IDS i for example by redefining M 1 as ⊕ r). However, then to find the tag, the reader should do the same calculation for any entry in its database and the complexity will be O(N ), where N is the number of tags with valid records, while in the current approach the complexity of finding the tag is O (1). Therefore, if the user traceability is very important, we suggest to use the revised M 1 , i.e. M 1 = IDS i ⊕ E K i ,q (ID i ⊕ r), in the cost of losing scalability.

2) SECRET DISCLOSURE ATTACK
In LBCbAP, sensitive data are included in M 1 and M 2 that are calculated using a secure symmetric cipher. Hence, the adversary cannot extract an information regarding ID i and K i in polynomial time. Hence, LBCbAP is secure against secret disclosure attack.

3) REPLAY ATTACK
Given that, in LBCbAP both the tag and the reader are contributing to the randomness of the transferred messages M 1 and M 2 , the adversary cannot replay the eavesdropped messages from an old session in a later one. Hence, LBCbAP is resistant against the replay attack.

4) IMPERSONATION ATTACK
Given that it is not practical to do a replay attack, to impersonate T i the adversary A should provide a valid response M 1 = E K i ,q (ID i ⊕ r) to the given challenge r by R. However, A does not have access to ID i and K i to compute the proper M 1 . In addition, it cannot return a previously stored value exclude that r has already been used by R, which has a small probability in our setting. On the other hand, to impersonate R the adversary A should provide a valid response M 2 to the given challenge q by T i . However, given that A does not have access to ID i and K i it has no chance to return correct M 2 directly. In addition, it cannot return a previously stored value exclude that q has already been used by T i , which has a small probability in our setting. Therefore, LBCbAP is resistant to the impersonation attack.

5) DESYNCHRONIZATION ATTACK
Desynchronization attack is an important attack against any protocol which can contradict the availability service [47]. To desynchronize T i , the adversary should do a successful impersonation attack or compromise the integrity of the transferred message without being detected by the receiver. However, neither of them is practical against LBCbAP because it is resistant against impersonation attack, and the integrity of the messages is checked on the receiver side. For example, if the adversary modifies any bit of M 1 then the output of the decrypted message will be random and the possibility of passing R's verification will be 2 −|r| , where |r| denotes the bit length of r. A similar argument is valid for M 2 . However, the adversary can block or modify M 2 such that R is updating its records but T i is not but in this way the current records in tag also exist in R, as the old record. Hence, R authenticates T i using its old records. Hence, LBCbAP is secure against desynchronization attack.

6) FORWARD SECRECY
As a requirement in the CK-adversary model security, assuming that the adversary compromised T i in time t and achieved its secrets at this time, i.e. ID i , K t i and IDS t i , it should not be capable to link them with the previously transferred data or compromise that data security. After each successful session of LBCbAP, IDS i and K i are updated as , IDS i , r and q, the adversary cannot determine whole K i if the used cipher is secure in known plaintext mode. Hence, the adversary cannot determine the key of the previous session given the key of the current session. Therefore, it will not be able to compromise the forward secrecy of the protocol and we conclude that LBCbAP is secure in the CK-adversary model.

7) MAN IN THE MIDDLE ATTACK
To provide security against man in the middle relay attacks, R and T i are counting the message travel time. In addition, any modification in the transferred messages are detected by the receiver of the message because M 1 and M 2 have built in integrity checking mechanisms, e.g. any modification in M 1 leads to random output and pass the R checking of the correct r, as its challenge, with the probability of 2 −|r| . Hence, LBCbAP is resistant against man in the middle attacks.

B. FORMAL SECURITY ANALYSIS
In this section, we formally prove LBCbAP satisfies the security goals of the protocol by using GNY logic [46]. The security proof of LBCbAP through GNY logic is explained as follows: 1) Expression of LBCbAP messages as mathematical equations: in this step, LBCbAP is explained as below: 2) Expression of LBCbAP messages based on GNY logic notations: in this step, we express the protocol messages using GNY logic notations which are represented in Table 2 as below. It must be noted that because of the ease of analysis, the messages transmitted in the protocol are written as a function of their inputs. M 1 : T i * Hello, * r; Idealizing LBCbAP's messages: in this step, we remove the messages that do not increase confidence, as follows:

) Define security assumptions and security goals of
LBCbAP: in this step, we express the assumptions and also the security goals of LBCbAP as follows: Protocol assumptions: A1 : R| ≡ r; A2 : R r; A3 : R| ≡ φ(r); Retrieving LBCbAP security goals: in this step, we obtained the protocol security goals using the messages and assumptions of the protocol according to the GNY logic rules as follows: Given A1, based on F1 we get D1 : R| ≡ (F 3 (ID i , r, q)); With D1 and A14 and based on F2 we deduce that D2 : R| ≡ ({F 3 (ID i , r, q)} K i ); Considering A3 and based on R1, we get D3 : R| ≡ φ(F 3 (ID i , r, q)); Given IM 1, A14, A8, D3 and D2, based on I 1 rule of GNY logic, we get D4 : which is the G1 security goal.
With A4, then based on F1 rule of GNY logic, we get D5 : Based on the previous result, i.e. D5 and A13, and based on F2 we get D6 : Given A6 and R1 rule we get D7 : Following IM 2, A13, A7, D7 and D6 and based on I 1 rule we get D8 : which is the G2 security goal.
As you can see, the security objectives of the protocol are achieved through D4 and D8 which indicate that the adversary has no control over the values transmitted in the protocol and also the adversary cannot change the protocol messages, without the receiver realizing, or cannot impersonate the identity of one protocol's party to participate in the authentication protocol in such a way that his/her identity is confirmed as a legal protocol's party.

C. Formal VERIFICATION OF LBCbAP security
The Scyther tool is a Python based on-the-shelf tool which is used to verify the security of cryptographic protocols [42].
To analyze a protocol using this tool, the target protocol should be modeled using the Security Protocol Description Language (SPDL) and then the Scyther tool is applied to verify the security claims of the protocol.
To verify the security of LBCbAP, we modeled it using SPDL as described in Figure 3. In our modeling, we defined two entities tag and reader. The verification result using the Scyther tool is depicted in Figure 4. This result shows that the Scyther tool could not find any attack within bounds on LBCbAP, which proves our security claims for LBCbAP.

VI. COMPARISON
In this section, we compare LBCbAP with KSP, SOVNOKP, LBRAPS and LRSAS from security and efficiency perspectives. Through our analysis we target 64-bit security, although the secret key length could be higher. Hence, the input/output length of each call of the block cipher is 64 bits, the output length of H (.) is 128 bits, the random numbers and the length of other parameters such as ID and IDS are also 64 bits. The length of timestamp is 32 bits.

A. SECURITY COMPARISON
In subsection III-B and subsection III-A, we respectively described the full secret disclosure attack on SOVNOKP and KSP protocols. It is clear given the secret parameters of a protocol, it will be easy to do any other attack, e.g. impersonation a protocol's party or trace it. Hence, as it is depicted in Table 3, these protocols suffer from any attack in that comparison table. The proposed security analysis of LBRAPS in subsection III-C could discover a part of the protocol's secret parameters which could be used to trace the tag. However, it is not enough to impersonate it. In addition, the protocol does not update any parameter. Hence, it does not suffer from desynchronization attack. In section V, we provided detailed security analysis of LBCbAP against different attacks and have shown informally and also formally that it provides desired security against different attacks. For example, in subsections V-A5, V-A4, V-A2 and V-A1 we argued the security of LBCbAP respectively against desynchronization attack, impersonation attack, secret disclosure attack and traceability attack. A summary of the security comparison of LBCbAP versus other protocols are provided in Table 3. It can be seen LBCbAP provides better security compared to the  analyzed protocols. While these results are almost expected for KSP and SOVNOKP, because they are ultra-lightweight, however, LBRAPS and LRSAS could do better because they use hash function or block cipher. On the other hand, it shows that LBCbAP, based on a lightweight block cipher, is secure against the attacks presented in this article and other known active and passive attacks. Table 4 represents the computational comparison of LBCbAP and analyzed protocols, also depicted in Figure 5. Through the analysis, we only report the costs of the tags, because the reader and the server/database/supply chain have fewer concerns for resources, compared to the tag, and also the connection with server/database/supply chain are not identical for all protocols, that channel in some protocols is insecure while in some it is secure. Through a session of LBCbAP, the tag first computes M 1 = E K i ,q (ID i ⊕ r) and sends {IDS i , M 1 , q} to R. It also runs a timer TS T initiated by zero. Then the reader sends M 2 IDS new

B. COMPUTATIONAL COST COMPARISON
to the tag. The tag next verifies whether TS T ≤ T T to  avoid relay attacks and computes M 2 IDS new ⊕ r)). If the received M 2 is valid then T i authenticates R and sets (K 0 ) new  Table 4 shows that the computational complexity of LBCbAP is much lower than LBRAPS but higher than KSP and SOVNOKP. However, those two protocols, i.e. KSP and SOVNOKP, are ultra-lightweight and do not provide enough security. LRSAS computational cost is lower than LBCbAP. However, all those protocols are insecure. Hence, the higher cost of LBCbAP compared to lighter protocols is the cost we should pay to provide the desired security. It should be noted to reduce the tag's cost we designed messages such that it only needs encryption function and does not need access to the decryption function while LRSAS needs both encryption and decryption functions. Table 5 represents the communication comparison of LBCbAP and analyzed protocols. To provide a fair comparison, we only counted the communication cost from the tag to the reader and vise versa, i.e. we eliminated possible communication from the reader to the database for all protocols. Through a session of protocol, the tag first computes M 1 and sends {IDS i , M 1 , q} to R, where its bit-length is 64 + 64 + 64. It also runs a timer TS T initiated by zero. At the first, R starts the authentication phase by generating a random  number r and sending it with the Hello message to the tag. Eliminating the bit length of Hello because it is a wake-up signal, in this stage the reader transferred 64 bits and the tag received 64 bits. Next, the tag sends {IDS i , M 1 , q} with the length of 64+64+64 to the reader. Hence, in this stage, the tag transferred 192 bits and the reader receives 192 bits. Finally, the reader sends M 2 to the tag that is 64 bits. Hence, in this stage, the reader sends 64 bits and the tag receives 64 bits. All in all, the tag has received 128 bits of data and transferred 192 bits of data and the reader has received 192 bits of data and transferred 128 bits of data. Following this computation and the same computation for other protocols that are provided in Table 5, also depicted in Figure 6, LRSAS has the lowest communication cost among the compared protocols and after that LBCbAP, SOVNOKP, KSP and LBRAPS respectively provide less communication costs. Among these protocols, LBRAPS has the highest communication cost.

VII. CONCLUSION
In this article, we have shown that four recent proposed security protocols for IoT and RFID systems (i.e. KSP, SOVNOKP, LBRAPS and LRSAS) are vulnerable against secret disclosure attack and desynchronization attack. We presented attacks with the complexity of mostly eavesdropping only two sessions of each protocol and negligible computational complexity. For an attack on LBRAPS which is presented in the Canetti and Krawczyk's adversary model, we need to compromise a tag also. Besides, we presented LBCbAP, a new secure protocol based on lightweight block ciphers, supported by formal and informal security proof.
The presented attacks on KSP and SOVNOKP again highlight that when we aim to design a secure protocol, we must not only focus on boosting the performance by limiting the operations at the expense of weakening the very basic principles of security, this weak approach will only lead to secret disclosure attacks as we have presented. On the other hand, the presented attacks on LBRAPS and LRSAS show that employing a secure component such as one-way hash functions or block ciphers in a protocol does not guarantee its security, if the transferred messages are not designed properly.
Some directions for future works are also presented here. For each analyzed protocol, the proposed attacks are the first attacks against each of these protocols to the best of our knowledge. Although the proposed attack against each protocol is enough efficient to rule out any real application for that protocol, however, it does not rule out further analysis of those protocols. For example, in the case of LRSAS, we are only able to present desynchronization attack. Although this attack is enough to contradict the designers' security claim but it does not mean that some one cannot propose a secret disclosure attack for example by finding a weakness in the used block cipher (SKINNY). Hence, we suggest to investigate the possible application of the previous cryptanalysis of that block cipher, e.g. [48]- [51], on the security of the protocol. While we analyzed the protocol in an ideal cipher model, this type of analysis has not received enough attention in literature and we believe it provides better understanding of the protocol's security in a real application. In LBCbAP, we have not considered a separate database and assumed that the reader is enough safe. However, in some applications such as mobile readers, this assumption does not hold. In such an application it is not reasonable to store the tag secrets directly in the reader, due to the risk of stolen reader attack, which can be addressed in future works. Besides, if we consider a system with multiple readers, we need a database to support all those readers to keep the updated key and IDS of the tags; otherwise, it will be desynchronized in the current form. Hence, designing an RIFD system based on LBCbAP that supports multiple readers is also an interesting target for future works. In that research, the challenges such as how the reader initializes its database, can the communication be restored if the reader's database is lost and how the tag can communicate with multiple readers and stay synchronous and anonymous could be answered. Last but not least, the proposed protocol is still under evaluation (not yet implemented in real environment) and still there is a need to be further analyzed by the community before possible deploying in any operational environment.