IoT Device Security: Challenging "A Lightweight RFID Mutual Authentication Protocol Based on Physical Unclonable Function".

With the exponential increase of Internet of things (IoT) connected devices, important security risks are raised as any device could be used as an attack channel. This preoccupation is particularly important with devices featuring limited processing power and memory capabilities for security purposes. In line with this idea, Xu et al. (2018) proposed a lightweight Radio Frequency Identification (RFID) mutual authentication protocol based on Physical Unclonable Function (PUF)-ensuring mutual tag-reader verification and preventing clone attacks. While Xu et al. claim that their security protocol is efficient to protect RFID systems, we found it still vulnerable to a desynchronization attack and to a secret disclosure attack. Hence, guidelines for the improvements to the protocol are also suggested, for instance by changing the structure of the messages to avoid trivial attacks. In addition, we provide an explicit protocol for which our formal and informal security analysis have found no weaknesses.

1. Introduction

The Internet of things (IoT) concept finds its roots in the early 1990s with the vision of ubiquitous computing [1] and the underlying idea that any object can be equipped with technology to become a computing device. This path to digital transformation is now possible as any object can communicate electronically and interact autonomously in real time, with its environment. In fact, the IoT landscape is rapidly changing with an increasing number of vertical applications moving “from experimentation to business scale” [2].

As the IoT market opens up multiple business opportunities, it also introduces a wealth of problems among which security issues usually top the list. This concern will keep increasing exponentially, as the worldwide number of connected devices is expected to jump by 12% on average annually, up to 125 billion connected devices in 2030 [3]. This will lead to important security issues as the ecosystem of connected devices is getting more complex and fragmented. Accordingly, experts anticipate that “by 2020, more than 25% of identified attacks in enterprises will involve the IoT, although the IoT will account for less than 10% of IT security budgets” [4]. The authors raise the fact that the IoT introduces new challenges (e.g., complexity in solution design architecture, implementation process and integration) as well as a wide range of new security risks “to the IoT devices themselves, their platforms and operating systems, their communications and even the systems to which they’re connected”. For instance, they suggest that any IoT device could be used as an attack channel.

Therefore, understanding how to build low-cost-high-security IoT devices becomes critical. This awareness is of a particular importance since IoT devices have become “so seamlessly integrated into everyday life, that often the end users are completely unaware of the presence of these devices around them” [5]. This is especially true for low-cost connecting devices in the IoT ecosystem, such as (battery-less) passive Radio-Frequency Identification (RFID) tags, that are powered by the interrogator’s radio waves, i.e., by transmitting their signal upon request, when interrogated by a reader. For instance, while passive Ultra High Frequency (UHF) tags are increasingly used in a variety of applications (e.g., identifying products and assets in logistic applications as well as participants in event management), these tags feature limited processing power and memory capabilities for security purposes (i.e., 16-bit cyclic-redundancy check (CRC)) [6].

In a report from the NIST (National Institute of Standards and Technology) [7], the authors present specific recommendations to address potential RFID security risks, including firewalls that separate RFID databases, encryption of radio signals, authentication of approved users, shielding of a reading zone to prevent unauthorized access, logging and time stamping to help in detecting security breaches, etc. Another way of securing RFID tags to support authentication applications is to create hardware security at the silicon level, by using a unique digital signature for RFID silicon chips based on how electrons flow through different paths of the chip, creating a silicon “fingerprint”. This approach, firstly introduced by Gassend et al. [8] at the Computer and Communication Security Conference in 2002, was put into practice in 2008 [9], when Verayo, an MIT spinout company, proposed “unclonable” HF tags which included small electronic circuits called PUFs (Physically Unclonable Functions). PUFs take advantage of variations in how silicon Integrated Circuits (ICs) are produced to create a unique digital signature for each chip, similar to biometrics measures, where the “identifiers” cannot be cloned. This allows a challenge–response authentication process that takes into account each tag unique identity based on its IC/transistor random electric properties.

While using chips “digital fingerprint” to build more secure tags, not all proposed PUFs are “unclonable”. For instance, in a previous paper entitled “A Lightweight RFID Mutual Authentication Protocol Based on Physical Unclonable Function”, Xu et al. [10] examined Kulseng et al.’s [11] proposal of a lightweight mutual verification protocol for RFID systems. Xu et al. found shortcomings in this protocol, making it vulnerable for a desynchronization attack. They hence proposed a security protocol for ensuring mutual tag-reader verification and preventing clone attacks. While the authors claim that their three-stage protocol (tag recognition, mutual verification and update) is efficient to protect RFID systems, we found that Xu et al.’s protocol is still vulnerable to a desynchronization attack and to a secret disclosure attack since the mutual verification process has flaws. These topics and arguments are addressed in this article.

The structure of this paper is as follows: the IoT and related security issues are raised in Section 2. RFID authentication protocols using PUF are discussed in Section 3, and in Section 4 Xu et al.’s protocol will be described. In Section 5, we will then evaluate the security level of the protocol and show its vulnerability. After that, we will present an improved protocol in Section 6 and finally we will conclude in Section 7.

2. The Internet of Things: Infrastructure and Security Issues

The International Telecommunication Union (ITU) defines the IoT as “a global infrastructure enabling advanced services by interconnecting physical and virtual things (i.e., living and non-living entities) based on existing and evolving interoperable information and communication technologies” [12]. The IoT, as a new technological paradigm that aims “to connect anything and anyone at any time and any place”, [13], is a vision becoming reality with burgeoning IoT enabled applications which open up to multiple business opportunities [14] and lead to new business models [15].

Figure 1 illustrates the IoT reference model ( [16]) comprised of seven levels, starting with Level 1: physical devices and controllers that might control multiple devices equipped with various technologies such as Radio Frequency Identification (RFID) tags, Bluetooth Low Energy (BLE) devices, Ultra Sound Identifications (USID), etc. Level 2 represents the communications and connectivity between devices and across networks. Level 3, called Edge (Fog) Computing, allows the conversion of network data flows into suitable information “for storage and higher level processing”. This happens at Level 4 (data accumulation), where event-based data is converted into query-based processing. Level 5 is then required to facilitate the integration with back end systems and “render data and its storage in ways that enable developing simpler, performance-enhanced applications”. It is at Level 6 (Application) that information interpretation takes place to automate or support decision-making in vertical markets’ applications. Level 7 hence represents empowered people and business processes using IoT enabled information to trigger action.

Figure 1

IoT reference model ([16]).

Since security issues can be raised for each level and for the movement of data between levels (e.g., physical cloning at Level 1, unauthorized access at Levels 2 and 3, data manipulation at Levels 4 and 5, and denial of service at Level 6), it goes without saying that security measures must pervade the entire model by (i) securing each device or system (ii) providing security for all processes at each level. Indeed, IoT security requires a multi-level approach.

3. RFID Authentication Protocols Using PUF

In this paper, we will focus on level of one of the IoT Reference Model, a level referred by Qi et al. [17] as “the sensing layer” or by Bendavid [18] as “the data capture layer”. At this level, one method to increase the security and to prohibit unauthorized access in IoT applications is to perform tag-reader mutual authentication protocol [19,20,21,22]. Various security techniques can be applied in order to transfer data securely such as cryptosystems. These cryptosystems are commonly divided into two groups: one-way and two-way [23]. In one-way systems, data is encrypted and there is no module for decrypting, such as Hash or PUF. In two-way systems, data is encrypted and decrypted by a cryptographic algorithm. Furthermore, within one-way systems, Hash, as a function, does not have the capability to detect physical attacks. On the other hand, PUF has an unclonable function that utilizes physical features to improve the security and resist against physical threats.

In recent years, many researchers have proposed more secure authentication protocols based on PUF technology [23,24]. For example, Sadeghi et al. presented an efficient privacy-preserving protocol based on rooted on PUF and claimed that their protocol was cost-efficient and provided an acceptable level of security and privacy [25]. However, despite Sadeghi et al.’s claim, Kardas et al. proved that the recommended protocol was vulnerable to the impersonation, as an attacker could trace the communication of a tag [26]. In addition, Kardas et al. analyzed another PUF-based authentication protocol that has been endorsed by Akgun et al. [27] and showed that the protocol was vulnerable and could not guarantee the security of the system [26]. Akgun et al. presented another authentication protocol by using PUF technology, but their protocol was still to be found insecure and could not provide forward secrecy support [28]. In order to solve the controversy surrounding these issues, Kardas et al. also presented another PUF-based protocol that was unfortunately not resistant against Denial of Service (DoS) attacks [29].

While most PUF based protocols were initially planned for an ideal environment with limited applicability in real situations, some researchers proposed authentication protocols for real and noisy environments [30,31,32,33]. For example, Ray et al. [34] released a PUF based protocol for object tracking in IoT application in real environments. In addition, Huth et al. proposed a protocol that can resist against noisy environment [33]. Nevertheless, their protocol needs an extra channel for transferring data and they use an exhaustive search in the database to retrieve the tag’s information. However, in their defense, most PUF protocols suffer the extra load of exhaustive search.

Recently, Kulseng et al. also disclosed a lightweight mutual verification protocol [11]. In order to implement a lightweight protocol, they utilized a PUF and Linear Feedback Shift Register (LFSR) instead of complex functions. However, while the proposed protocol was suitable for low-cost and large-scale systems, it could not comply with the security requirement of RFID systems. Xu et al. analyzed Kulseng et al.’s protocol and proved that it was vulnerable to the desynchronization attack and data confidentiality [10]. The authors presented a new PUF-based protocol and claimed that this improved protocol solved the security issues of the previous one and was robust against RFID threats. Before demonstrating its weaknesses, we will elaborate on Xu et al.’s protocol in more detail in Section 4.

4. Xu et al.’s Protocol

In this section, we explain the PUF-based lightweight authentication protocol that has been proposed by Xu et al. The order of transferred messages is illustrated in Figure 2 and the used notations are listed in Table 1.

Figure 2

Time sequence diagram of Xu et al.’s protocol for single tag authentication.

Table 1

The notations used in the Xu et al.’s protocol.

Notations
FID	Fake tag ID
PUF()	Physical Unclonable Function
ID	The tag’s ID number
TID	Pseudo ID of the tag
P_n	The tag’s secret value
K_n	The shared secret value of the tag and the reader
⋘	The left rotation operator
&	The AND operator
||	The concatenation operator
r_i	A random number
⊕	XOR function
X_i	Denotes the ith bit of the string X, where X_0 is the most right bit

This protocol consists of four phases: Registration, Tag verification, Mutual verification and Update process. In the registration phase, the initial values of the parameters are stored in the tags and in the database. The database stores two sets of values for each tag: the current values () and the old values (). If an authentication process is done completely and a tag updates its parameters successfully, the database uses the current values; otherwise, it will use the old values.

4.1. Tag Verification Phase

At the first of verification phase, the reader starts the process and sends a search request to the tag and receives the tag’s response as and . The reader looks up in the new fields and old fields. Finally, if the appropriate is not found, the reader terminates the session; otherwise, it continues the process.

4.2. Mutual Verification Phase

In this phase, the reader generates randomly and computes A and B as:

It concatenates A and B and transfers the combination message to the tag.

Upon receiving the message from the reader, the tag computes D and E as follows:

In addition, it calculates by the receiving messages to recalculate as:

The tag checks . If the equation does not hold, it means that the reader is not valid and the session is terminated. Otherwise, the tag verifies the reader and continues the process.

Based on D, E and calculated , the tag computes F and then H as:

It concatenates F and H as and sends this message to the reader.

When the reader receives the tag’s response, by local parameters, it recalculates , and as:

Then, it checks . If the equation does not hold, the tag is not valid and the reader aborts the session. Otherwise, it verifies the tag and continues the process.

4.3. Update Process Phase

After the verification phase, the variables should be updated. At first, the database updates its parameters, and then it sends a signal to the tag to inform it that the update process was done. If the tag receives the signal in the acceptable time range, it also updates its local parameters. Before updating in the database, the reader checks in the tag verification phase. If it has used , the reader does not need to update the parameters, but if has been used, the reader updates the database as:

If the tag receives a message (positive signal) from the reader in the acceptable time range, it also updates the parameters as:

5. Security Analysis of Xu et al.’s Protocol

While Xu et al. claimed that their security protocol is efficient to protect RFID systems, we found that their protocol is still at risk of being exposed to a desynchronization attack and to a secret disclosure attack. In this section, we will explain how these attacks can strongly jeopardize the security of the system.

5.1. Desynchronization Attack

The goal of a desynchronization attack is to change the integrity and synchronization of stored data in the tag and in the reader [35]. The main observation in the proposed attack mentioned in this section is the fact given ; any modification on a bit of A has no effect on the result C with the probability of . More precisely, we assume that , where denotes the bit of the string B, , for any value of . Following this observation, the attack procedure, which is a desynchronization attack when the adversary is modeled as a man in the middle, works as presented in the following steps:

On a legitimate session between the target tag T and the reader R, the reader starts the process and sends a search request to the tag.

Upon receiving the request, the tag generates randomly and transfers and to the reader.

The adversary intercepts the sent message from the tag to the reader and replaces with .

When the reader receives , it utilizes it as a search key in the database and seeks to find an equal in the field. We assume that the comparison holds, meaning that the tag belongs to the system and the reader uses for the next phase.

The reader generates randomly and computes A and B as:

It concatenates A and B and transfers the combination message to the tag.

The adversary intercepts the sent message from the reader to the tag and replaces A with .

Upon receiving the message from the reader, the tags computes D and E as follows:

In addition, it calculates by the receiving messages to recalculate as:

The tag checks . If the equation does not hold, it means the reader is not valid and the session is terminated. Otherwise, the tag verifies the reader and continues the process.

Based on D, E and calculated , the tag computes F and then H as:

It concatenates F and H as and sends this message to the reader.

When the reader receives the tag’s response, by local parameters, it recalculates , and as:

Then, it checks . If it does not hold, the tag is not valid, and the reader aborts the session. Otherwise, it verifies the tag and continues the process.

Based on the assumption in Step 4, in the update process phase of the protocol verification phase, the database updates its parameters and then sends a signal to the tag to inform it that the update process is completed. The reader updates the database as follows:

When the tag receives the success signal from the reader in the acceptable time range, it also updates the parameters as:

It is clear that the above attack succeeds if:

In light of these findings, the probability of the above equality is . Given that the only impact of is on the calculation of , if the above equality is satisfied, T and R authenticate each other successfully and the adversary is not recognized. However, the tag updates its values with while the reader uses in the update process. Hence, the tag’s records of secret parameters do not match the records of the reader and they will be desynchronized with the probability of almost , while the complexity of the attack method is just intercepting two steps of a session of the protocol between T and R.

5.2. Secret Disclosure Attack

The main observation which is used in the proposed secret disclosure attack is the fact that and , for any value of . Following this observation, the attack procedure, when the adversary is modeled as a man in the middle, works as follows:

On a legitimate session between the target tag T and the reader R, the reader starts the process and sends a search request to the tag.

Upon receiving the request, the tag generates randomly and transfers and to the reader.

The adversary intercepts the sent message from the tag to the reader and just replaces by 0 and stores .

When the reader receives , it utilizes it as a search key in the database and seeks to find an equal in the field. We assume that the comparison holds, meaning that the tag belongs to the system and the reader uses for the next phase.

The reader generates randomly and computes A and B as:

The adversary stores and blocks it, where and is the tag’s secret value and .

The adversary waits until the reader starts the process and sends a search request to a tag.

Upon receiving the request, the adversary sets and transfers the stored and to the reader.

When the reader receives , it utilizes it as a search key in the database and seeks to find an equal in the field. Based on the assumption of Step 4, the comparison holds, meaning that the tag belongs to the system and the reader uses for the next phase.

The reader generates randomly and computes and as:

The adversary stores and blocks it, where . Given from Step 6, the adversary extracts as and as .

On the basis of these elements, the probability of success of the adversary to retrieve the tag’s secret value is 1, while the complexity of the attack method is just intercepting a step of the sessions of the protocol between T and R and eavesdropping the transferred values over a public channel. It should also be noted that, given and , the adversary can impersonate the reader and communicate with the tag to extract the rest of the secret parameters as follows:

The adversary impersonates the legitimate reader and sends a search request to the target tag.

Upon receiving the request, the tag generates randomly and transfers and to the reader (adversary).

The adversary generates randomly and computes and as follows and sends them to the tag:

Upon receiving the message, the tag computes and , verifies the received to validate the reader and continues the process.

Based on D, E and calculated , the tag computes F and then H as:

It concatenates and as and sends this message to the reader (adversary).

When the adversary receives the tag’s response, it extracts , sends a signal to the tag to inform that the update process was done, and does the following updates in the stored information related to the target tag:

When the tag receives the success signal from the reader (adversary) in the acceptable time range, it also updates the parameters as:

From now on, the adversary is in possession of all the tags secrets and has also desynchronized the tag and the reader. Hence, it is only the adversary who can communicate with the victim tag. The probability of success of the attack is 1 and the complexity of the attack method is negligible. One may argue that, in order to patch the given secret discourse attack, the reader shall refuse trivial values as , e.g., it should reject any value which does not sound like it is random such as and . However, this approach does not rule out the projected attack, although it can slightly increase the complexity of the attack. In this case, the scenario of an attack could be as follows:

In a legitimate session between the target tag T and the reader R, the reader starts the process and sends a search request to the tag.

Upon receiving the request, the tag generates randomly and transfers and to the reader.

The adversary intercepts the sent message from the tag to the reader and just replaces by 0 and stores .

When the reader receives , it utilizes it as a search key in the database and seeks to find an equal in the field. We assume that the comparison holds, meaning that the tag belongs to the system and the reader uses for the next phase.

The reader generates randomly and computes A and B as:

The adversary stores and blocks it, where, for any , we have and is the tag’s secret value and .

The adversary waits until the reader starts another session of the protocol and sends a search request to a tag.

Upon receiving the request, the adversary sets and transfers the stored and to the reader.

When the reader receives , it utilizes it as a search key in the database and seeks to find an equal in the field. We again assume that the comparison holds, meaning that the tag belongs to the system and the reader uses for the next phase.

The reader generates randomly and computes and as:

The adversary stores and blocks it, where, for any . Combining these bits of with the bits retrieved in Step 6, the adversary has a whole .

The adversary waits until the reader starts the next process and sends a search request to a tag.

Upon receiving the request, the adversary generates a random value as , transfers and the stored to the reader.

When the reader receives , it utilizes it as a search key in the database and seeks to find an equal in the field. Based on the assumption of Step 4, the comparison holds, meaning that the tag belongs to the system and the reader uses for the next phase.

The reader generates randomly and computes A and B as:

The adversary stores and blocks it, where, for any we have and . Given that the adversary has , , and , it can extract for any j that .

The adversary waits until the reader starts another session of the protocol and sends a search request to a tag.

Upon receiving the request, the adversary sets and transfers the stored and to the reader.

When the reader receives , it utilizes it as a search key in the database and seeks to find an equal in the field. We again assume that the comparison holds, meaning that the tag belongs to the system and the reader uses for the next phase.

The reader generates randomly and computes and as:

, we have and . Given that the adversary has , , and , it can extract for any j that . Combining these bits of with the bits retrieved in Step 16, the adversary has a whole .

It is clear that, in the given attack, the probability of success of the adversary to retrieve the tag’s secret value is 1, while the complexity of the attack method is just intercepting/eavesdropping four sessions of the protocol between T and R. Even if the reader stores the history of all transferred random values between the tag and the reader, it is possible to adapt the given attack to deceive the reader and extract the secret parameters, although we may require a few extra number of sessions. It should be noted that we did not use the tag responses, i.e., F and H, in the proposed secret disclosure attacks. For example, in Xu et al.’s protocol, and F are also transferred over a public channel and:

Hence, the adversary can easily extract from the available information. Given and and , where: and

The adversary can easily extract and . Given and and F, the adversary can extract E. Hence, the adversary extracts all secret parameters passively. The probability of success of this attack is also 1. However, it necessarily requires eavesdropping F and H.

6. Improved Protocol

To avoid trivial attacks, it is possible to design a new protocol based on Xu et al.’s protocol by changing the structure of the messages programmed. For instance, any transferred information should be masked. Therefore, it is better to transfer instead of the plain or use to generate the new rather than the itself, which is known by the adversary. Furthermore, considering the fact that the output of operation is ‘0’ with the probability of , one should avoid it and try to use which is a balanced bitwise operation. However, all things considered, the history of many easily broken ultra-lightweight protocols in literature shows that even such an improved protocol may not be that secure, not to mention that we use enough nonlinear and complicated functions, instead of just a few bitwise operations. Under the circumstances, it could be better to use available well-known lightweight primitives such as SIMON [36], Skinny [37], NORX [38] and SPONGENT [39]. For example, it is possible to implement SPONGNET in an area equal to 738 NAND gate [40]. Based on this observation, we propose in this section an improved authentication protocol apart from PUF, which uses a cryptographic hash function as the core of security. It should be noted many lightweight hash functions have already been introduced in literature, e.g., PHOTON [41], Quark [42] and SPONGENT [39]. A comprehensive comparison of those primitives can be found at CryptoLUX [40].

6.1. The Proposed Protocol

The proposed protocol, as it is depicted in Figure 3, includes two phases: the registration phase over a secure channel and the authentication phase over a public channel.

Figure 3

The improved PUF-based protocol.

Registration Phase:

In this phase, the tag is registered into the reader as follows:

The reader sends a registration request command to the tag.

The tag generates a random number , calculates and as follows and sends them to the reader:

The reader calculates a temporary identifier for the tag and sends to it, where is the secret parameter of the reader.

It also updates as and creates a record in its database for this tag, including .

Given , the tag calculates . It stores .

Authentication Phase:

In this phase, the tag and the reader R are mutually authenticated as follows:

The reader sends an authentication request command along a random number to the tag.

The tag generates a random number , calculates and sends tuple to the reader.

Given , the reader finds the related record in its database, i.e., . Then, the reader verifies whether to authenticate the tag. If the tag is authenticated, then the reader calculates and . Next, it sends B to the tag.

The tag also calculates and verifies whether , to authenticate the reader. If the reader is certified as valid, the tag does the following calculations:

Next, the tag sends to the reader and updates its records as .

Once the reader received , it verifies whether , to authenticate the tag and the received data. If it is authenticated, then the reader updates its records as follows:

If the tag has not been authenticated based on and , it assumes that the last session was not finished successfully and the tag tries to be authenticated based on and .

6.2. Security Evaluation of the Proposed Protocol

In this section, we evaluate the security of the proposed protocol informally and formally. For this purpose, we considered an active adversary, which is able to eavesdrop on any transferred messages over the public channel at different stages of the procedure, e.g., authentication phase of the proposed protocol, modify/block messages or initiate a session to impersonate the reader/tag. However, we specify that the adversary cannot influence or access the transferred messages over a secured channel, e.g., registration phase of the proposed protocol. In addition, we assume that the embedded PUF behaves randomly from a tag to a tag and on different inputs, i.e., and , where , n is the output length of and is the PUF which is integrated in the tag .

6.2.1. Informal Analysis

Traceability Attack: To trace a tag/reader and to compromise the protocol’s anonymity, the adversary should be able to link transferred messages between the tag and the reader to their identity or to the previous transferred messages. On the other hand, on each run of the protocol, the transferred messages include , , , , and , where . and are fresh random values generated in each session and they cannot be used to trace the tag/reader. is the pseudo identity of the tag which is updated at the end of each successful run of the protocol. Moreover, the tag keeps its record up to the next successful run of the protocol. Although the record can be used to trace the tag even after one successful run of the protocol, it is impossible to employ it later.

More precisely, an adversary who eavesdropped on a session of the protocol between the tag and the reader and who missed two consecutive successful runs of the protocol after that will not be able to use the eavesdropped value of to trace the target tag. It should be noted that it is possible to fix this problem by masking the transferred pseudo-identity, for example as . However, in doing so, the reader needs to search through its entire database to find the tag that compromises the protocol’s scalability. Other solutions, such as encrypting by the public key of the reader, are also possible, but it increases the computational complexity of the protocol. The rest of the messages are randomized by random values contributed by both the tag and the reader and a secure hash function. Hence, even an adversary who is impersonating the reader or the tag cannot control the random numbers generated by the other party and cannot predict the transferred messages from one session to another session.

Secret Disclosure Attack: The main secret parameters that are shared with the reader are and . They are used in generating different messages that are transferred between the tag and the reader, i.e., A, B, C and D. However, they are mainly used as the input of a hash function that is not possible to invert efficiently. The only way to achieve such an inversion should be to use to determine . However, it is randomized by for which the adversary has no knowledge and cannot control. Hence, the adversary cannot efficiently determine and .

Impersonation Attack: Given the fact that the adversary cannot determine and , to impersonate a tag to the reader, the adversary should at least generate a valid A. However, to produce it, the adversary ought to appreciate the knowledge of , since the previously eavesdropped messages cannot be used also due to the fresh and that are generated in each new session, the adversary cannot do this attack efficiently. A similar argument is also valid and relevant for the reader to the tag impersonation attack.

Replay Attack: Considering the fact that all messages that are critical to authenticate the tag by the reader or the reader by the tag are randomized by both parties, it is not possible to apply a replay attack against the proposed protocol.

Tag Cloning Attack: Assuming that the used PUF behaves randomly, it is impossible to clone a tag even when the adversary compromises the tag to access , and . The reason for this comes from the fact that it is not possible to implement identical PUF in different tags.

Desynchronization Attack: To desynchronize the tag and the reader, the reader should be able to impersonate the reader to the tag or the tag to the reader, which is not possible. Another approach would be by blocking the last message sent from the tag to the reader. In this way, the tag has updated its records but not the reader. However, given that the tag also keeps a record of the old data; in this case, it can be synchronized based on them.

Forward/Backward Security: Given that the tag and the reader share two parameters and and since, in each round, only one of them is changed while the tag keeps a history of old parameters, we define our forward security model as the case when the adversary has all parameters of session x, misses two successful sessions and aims to recover parameters in the session. It is clear that, in two consecutive sessions, both and are changed through PUF randomly, and, without them, the adversary has no advantage over a blind adversary. Hence, the adversary will not be able to determine and . A similar reasoning applies to the backward security of the protocol.

6.2.2. Formal Verification Using a Scyther Tool

Scyther [43] is a widely accepted tool to evaluate the security correctness of a protocol. It provides a graphical user interface to facilitate the analysis of complex attack scenarios on the target protocol. We applied the Scyther tool to verify whether our security assertions for the proposed protocol holds or not. We defined two identities over the protocol, i.e., tag and reader in Scyther. Then, we implemented each role with its corresponding task, followed by the implementations as represented in Appendix A. It is worth noting that we fixed the number of protocol runs 100 times and also fixed the search pruning to “Find all attacks“ and the matching type of Scyther tool to “Find all type flaws”.

We made our Secret claims on every message that was sent and received on both ends. According to Table 2, the Scyther tool could not find any attack within bounds, thus establishing that our security allegations were founded.

Table 2

The proposed protocol verification results using the Scyther tool.

Claim				Status	Comments
improved	R	improved,R1	Secret ID	OK	No attacks within bounds.
		improved,R2	Niagree	OK	No attacks within bounds.
		improved,R3	Nisynch	OK	No attacks within bounds.
		improved,R4	Alive	OK	No attacks within bounds.
		improved,R5	Weakagree	OK	No attacks within bounds.
	T	improved,T1	Secret PIDi	OK	No attacks within bounds.
		improved,T2	Secret PIDip1	OK	No attacks within bounds.
		improved,T3	Niagree	OK	No attacks within bounds.
		improved,T4	Nisynch	OK	No attacks within bounds.
		improved,T5	Alive	OK	No attacks within bounds.
		improved,T6	Weakagree	OK	No attacks within bounds.

In terms of a tag’s weight and hardware complexity of the improved protocol, the protocol could belong to lightweight protocols. Accordingly, because PUF and hash functions have been used in the design of our proposed protocol, we can control the number of gates in the range of lightweight tags. Since a tag with less than 3000 GE [44] is lightweight, by utilizing a SPONGNET hash function with around 800 GE and some bitwise functions such as XOR, the total number of gates is less than 3000 and the proposed tag can satisfy the limitation of lightweight protocols. In addition, in terms of the security level, we compared the improved protocol with some other protocols in Table 3. The results show that our protocol could address the security issues of other protocols and is resistant against IoT attacks.

Table 3

The security comparison of the improved protocol to other protocols against IoT attacks.

Protocols	Impersonation	Traceability	Disclosure	Desynchronization
Sadeghi et al. [25]	×	×	✓	✓
Aysu et al. [32]	✓	×	×	✓
Van Herrewege et al. [30]	✓	✓	×	✓
Kulseng et al. [11]	✓	✓	×	×
Xu et al. [10]	✓	✓	×	×
Improved Protocol	✓	✓	✓	✓

✓: Resistant    ×: Non-resistant.

7. Conclusions

With the exponential increase of IoT connected devices, the importance of security risks is raised by the academic and professional community as any connected object becomes a computing device and a potential target for an attack. In developing strategies to identify and prevent intrusions and threats, which are more likely to increase, researchers around the word are working on securing all the layers of the IoT infrastructure. Along these trends, since the commercial introduction by Verayo in the early 2008 of the first silicon chips equipped with PUF, the market has seen some growth with other companies (e.g., Intrinsic ID, Quantum Trace, Invia) now developing in this marketplace. While there are no doubts that PUF constitutes a very promising avenue to ensure device security, caution should always be brought to constantly evolving security protocols. In line with this issue, Xu et al. proposed a lightweight RFID mutual authentication protocol based on PUF, for ensuring mutual tag-reader verification and preventing clone attacks. While the authors claimed that their protocol was efficient to protect RFID systems, we found it to still be vulnerable and presented how a desynchronization attack and several secret disclosure attacks could be performed on Xu et al.’s protocol. Finally, we discussed why it is better to try to employ secure lightweight encryption functions in designing secure protocols rather than ad hoc designs, by proposing a secure hash based protocol.