On the Security of a PUF-Based Authentication and Key Exchange Protocol for IoT Devices

Recently, Roy et al. proposed a physically unclonable function (PUF)-based authentication and key exchange protocol for Internet of Things (IoT) devices. The PUF protocol is efficient, because it integrates both the Node-to-Node (N2N) authentication and the Node-to-Server (N2S) authentication into a standalone protocol. In this paper, we therefore examine the security of the PUF protocol under the assumption of an insider attack. Our cryptanalysis findings are the following. (1) A legitimate but malicious IoT node can monitor the secure communication among the server and any other IoT nodes in both N2N authentication and N2S authentication. (2) A legitimate but malicious IoT node is able to impersonate a target IoT node to cheat the server and any other IoT nodes in N2N authentication and the server in N2S authentication, respectively. (3) A legitimate but malicious IoT node can masquerade as the server to cheat any other target IoT nodes in both N2N authentication and N2S authentication. To the best of our knowledge, our work gives the first non-trivial concrete security analysis for the PUF protocol. In addition, we employ the automatic verification tool of security protocols, i.e., Scyther, to confirm the weaknesses found in the PUF protocol. We finally consider how to prevent weaknesses in the PUF protocol.


Introduction
In recent years, the Internet of Things (IoT) has been growing rapidly and all kinds of IoT devices are often present in our personal lives in the form of various applications, such as smart homes, smart transportation, and smart cities. Figure 1 depicts the communication scenario between the IoT server and devices (nodes). However, security is one of the major challenges when IoT enters sensitive fields, e.g., a smart street light monitoring system. Unlike traditional networks, IoT consists of a large number of complex, heterogeneous, and interoperable IoT devices [1]. Hence, under a hostile environment, IoT devices are often vulnerable to attacks and therefore require stronger security techniques to overcome their potential security weaknesses, such as counterfeit identity and sensitive data leakage. Authentication and key exchange protocols can provide the service of authentication and secret session key establishment between various IoT devices. Here, the session key is used to support confidential data transfer between IoT devices.
However, designing authentication and key exchange protocols is an intractable task for IoT applications. Firstly, there is a huge number of IoT devices, but their computing and storage resources are usually limited. Therefore, lightweight protocols are urgently needed to realize efficient interaction between devices without overloading their performance. Secondly, IoT devices are often deployed in complex, heterogeneous network environments and can be connected to and accessed by multiple unknown and untrusted devices, leading to extreme security challenges. Robust authentication and key exchange protocols should satisfy all strict requirements from IoT devices and their applications. untrusted devices, leading to extreme security challenges. Robust authentication and key exchange protocols should satisfy all strict requirements from IoT devices and their applications. The physically unclonable function (PUF) [2] can help build robust security protocols. PUF is regarded as a basic security primitive for resource-constrained IoT devices. PUF generates a unique digital fingerprint from micro-variations in physical devices. This fingerprint is unable to be cloned and is sensitive to being tampered with. PUF generates an unpredictable output (i.e., response) for corresponding input (i.e., challenge). The process is irreversible and is independent of storage memory. PUF is realized in various scenarios, such as field programmable gate array (FPGA) [3], cloud storage, and IoT, to protect data from unauthorized access and attacks. The advantage of PUF is that resource-constrained devices do not require the maintenance of the secret key [4]. Moreover, it reduces the risks associated with key transmission, storage, and management to a greater extent than other common cryptographic techniques. Therefore, PUF is as a promising alternative to designing lower-cost authentication and key exchange protocols.
On the one hand, PUF has advantages in efficiency and security compared with cryptographic algorithms. Hence, it is expected to design more practical authentication and key exchange protocols for IoT. On the other hand, PUF-based authentication and key exchange protocols are relatively new, compared with the protocols using purely cryptographic algorithms and/or smart cards. And there are still many security issues in its designs, which should be addressed. Hence, in this paper, we investigate the PUFbased authentication and key exchange protocol for IoT devices.

Related Work
Cryptographic algorithms are widely used in security protocols. According to the type of cryptographic algorithm, we divide PUF-based authentication and key exchange protocols into two categories as follows: • The PUF-based authentication and key exchange protocols using public key algorithms. The public key algorithms have high key management flexibility. This is because the communicating parties have two different keys, one of which is kept as a secret and the other is made public. There is no need to share the secret key as in symmetric key algorithms. The PUF-based protocols using public key algorithms inherit this feature. The physically unclonable function (PUF) [2] can help build robust security protocols. PUF is regarded as a basic security primitive for resource-constrained IoT devices. PUF generates a unique digital fingerprint from micro-variations in physical devices. This fingerprint is unable to be cloned and is sensitive to being tampered with. PUF generates an unpredictable output (i.e., response) for corresponding input (i.e., challenge). The process is irreversible and is independent of storage memory. PUF is realized in various scenarios, such as field programmable gate array (FPGA) [3], cloud storage, and IoT, to protect data from unauthorized access and attacks. The advantage of PUF is that resource-constrained devices do not require the maintenance of the secret key [4]. Moreover, it reduces the risks associated with key transmission, storage, and management to a greater extent than other common cryptographic techniques. Therefore, PUF is as a promising alternative to designing lower-cost authentication and key exchange protocols.
On the one hand, PUF has advantages in efficiency and security compared with cryptographic algorithms. Hence, it is expected to design more practical authentication and key exchange protocols for IoT. On the other hand, PUF-based authentication and key exchange protocols are relatively new, compared with the protocols using purely cryptographic algorithms and/or smart cards. And there are still many security issues in its designs, which should be addressed. Hence, in this paper, we investigate the PUF-based authentication and key exchange protocol for IoT devices.

Related Work
Cryptographic algorithms are widely used in security protocols. According to the type of cryptographic algorithm, we divide PUF-based authentication and key exchange protocols into two categories as follows:

•
The PUF-based authentication and key exchange protocols using public key algorithms. The public key algorithms have high key management flexibility. This is because the communicating parties have two different keys, one of which is kept as a secret and the other is made public. There is no need to share the secret key as in symmetric key algorithms. The PUF-based protocols using public key algorithms inherit this feature. Yilmaz et al. [5] applied the RSA algorithm in the lightweight PUF-based authentication protocol. Chatterjee et al. [6] developed an authentication and key exchange protocol combining PUFs, identity-based encryption (IBE), and the keyed hash function. Chuang et al. [7] designed a PUF-based authenticated key exchange protocol for IoT devices without verifiers and an explicit challenge-response pair (CRP). Using certificateless public key cryptography (CL-PKC), Li et al. [8] proposed a PUF-based end-to-end mutual authentication and key exchange protocol for IoT devices. Chaterjee et al. [9] proposed a private PUF-based anonymous authentication protocol. Siddiqui et al. [10] proposed a PUF-based authentication protocol, which is dependent on two certificate authorities of the cloud IoT system. Harishma et al. [11] proposed a PUF-based operationally asymmetric mutual authentication and key exchange protocol for secure communication. Qureshi and Munir [12] introduced a lightweight CRP obfuscation mechanism using XOR and shuffle operations and further used it to design the PUF-based key exchange protocol.

•
The PUF-based authentication and key exchange protocols using symmetric key algorithms.
The advantage of symmetric key algorithms is low computational cost. These algorithms are therefore well suited for authentication and key exchange protocols for resource-constrained IoT devices and help to reduce the computational burden of these IoT devices. In the PUF-based protocols using symmetric key algorithms, shared keys are generated by PUFs and hash functions are commonly used to authenticate messages. The researchers [13,14] proposed PUF-based mutual authentication protocols for IoT systems. Their protocols are presented for two scenarios, that is, device-to-device communication and device-to-server communication. Qureshi and Munir [15] presented a PUF-based identity-preserving protocol. During the authentication run of their protocol, the server does not store, generate, transmit, or receive complete devices' CRPs. Lounis and Zulkernine [16] proposed PUF-based Thingto-Thing (T2T) architectures, where devices autonomously authenticate each other without any human intervention involved. Nimmy et al. [17] proposed a protocol that avoids explicit storage of CRPs for verification by using geometric threshold secret sharing. Zheng and Chang [18] proposed a new lightweight PUF-based mutual authentication and key exchange protocol for two PUF-embedded IoT devices. Wang et al. [19] leveraged PUFs to generate symmetric shared keys in the lightweight protocol. Ebrahimabadi et al. [20] designed an authentication protocol to thwart modeling attacks for PUF-based IoT devices. Zerrouki et al. [21] proposed a mutual authentication and session key establishment protocol for IoT devices based on PUFs. Sun and Tian [22] further gave security analysis and improvements to this protocol and suggested the idea of a key compromise to evaluate other novel PUF protocol designs. Wang et al. [23] introduced a supplementary sub-protocol to the PUF-based authentication protocol for the purpose of enhancing resistance to desynchronization attacks. Park and Park [24] employed PUFs to realize an improved authentication and key agreement protocol for cloud-enabled IoT devices. To achieve decentralization and security, Aseeri et al. [25] introduced a secure, lightweight, cost-efficient reinforcement machine learning framework (SLCR-MLF) with PUFs. In addition, some researchers [26][27][28] proposed PUF-based two-factor authentication mechanisms.

Our Motivations and Contributions
In IEEE Internet Things J. 2023, 10, 8547-8559, Roy et al. [29] proposed a PUF-based authentication and key exchange protocol. Roy et al.'s protocol is interesting because it tries to leverage cryptographic XOR operation and hash function for traditional secure communication and PUF for preventing physical attacks. Moreover, this standalone protocol can perform device-to-device and device-to-server authentication, eradicating the need for disparate protocols. In addition, using the Scyther verifier tool, the security of Roy et al.'s protocol is evaluated by the formal method.
Due to their inherent vulnerability, IoT devices (nodes) are easily compromised by insider attackers. Therefore, in this paper, we carefully study the security of Roy et al.'s protocol under the assumption of an inside attack. Our results are summarized as follows: (1) A legitimate but malicious IoT node can monitor the secure communication among the server and any other IoT nodes, because the malicious IoT node can reveal their secret session key. The only requirement of the malicious IoT node is to observe the

Basic Knowledge of PUF
PUFs make use of the intrinsic random variability in the physical microstructure of integrated circuits (ICs) to produce a unique n-bit response R i to an m-bit challenge C i for any i∈N. We can write a PUF's instance as follows.
where C i ∈{0,1} m and R i ∈{0,1} n . PUF has the following safety features: • Uniqueness: PUFs cannot output the same response for different input challenges, while different PUFs output different responses for the same input challenge. For two different C i and C j , with i, j∈N, and any two different PUF instances f A PUF and f B PUF , the uniqueness expression is as follows.
• Reliability: This feature measures the reproducibility of a PUF response under different operating conditions for a given challenge. The reliability expression of the PUF instance for different time periods t 1 and t 2 is: In fact, the PUF response is sensitive to various noise elements, such as temperature, voltage, and other environmental changes. Under the same challenge, the noise can cause the PUF to give an erroneous response, which is different from the original one. To eliminate the effects of such noise, Roy et al. [29] considered the use of lightweight error-correcting algorithms (ECAs) to stabilize the noisy PUF response and thus improved its reliability.

Review of Roy et al.'s Protocol
The one-time enrollment phase is responsible for enrolling the new IoT nodes in the server. The authentication and key exchange phase realizes mutual authentication between the server and the node(s). To maintain consistency, we employ the same notions of [29] and write them in Table 1. Table 1. Used notation and symbols.

Notation Description
Random number T AB ,T CB Secret sharing key between A and B, secret sharing key

One-Time Enrollment Phase
This phase is run in a secure environment without the attacker. After completing this phase, the IoT nodes can be deployed in the IoT network. When any A wants to enroll in the server, the server randomly generates an input C Ai (i.e., challenge) for A's PUF and collects its output R Ai (i.e., response), where R Ai = f A PUF (C Ai ). Then, the server stores A's ID-CRP {id A , C Ai , R Ai } in its secure database. The server only maintains one ID-CRP record for each IoT device.

Authentication and Key Exchange Phase
This phase has two communication models, i.e., Node-to-Node (N2N) communication and Node-to-Server (N2S) communication. N2N communication aims to provide the mutual authentication and key establishment of any two IoT nodes. Meanwhile, N2S communication realizes the mutual authentication and key establishment between any one IoT node and the server.

N2N Communication
Assume that two nearby A and B nodes want to authenticate each other and establish their session key. As shown in Figure 2, A, B, and the server perform the following steps.
Step 1. A sends a connection request {id A } to B. Upon receiving this request, B sends the N2N connection establishment request {id A , id B } to the server.
Step 2. The server fetches corresponding ID-CRPs {id A , C Ai , R Ai } and {id B , C Bi , R Bi } from its secure database and generates two random numbers RN and T AB . The server computes: To authenticate the server, A then checks whether H A is equal to H* A and H B is equal to H* B . If any verification fails, A terminates the session. Otherwise, A further calculates: Finally, A sends {T B } to B.
To authenticate the server, B checks H A and H B using H* A and H* B just like A. If any verification fails, B also terminates the session. Moreover, B evaluates: Now, B checks whether R Bi is equal to R* Bi . If the verification is incorrect, B terminates the session; otherwise, B computes: A checks whether RAi is equal to R*Ai. If the verification is incorrect, A terminates the session; otherwise, A computes:  Step 5. Upon receiving the message {T A }, A computes: Sensors 2023, 23, 6559

of 21
A checks whether R Ai is equal to R* Ai . If the verification is incorrect, A terminates the session; otherwise, A computes: A then sends {M SA , H SA } to the server.
Step 6. Upon receiving the messages {M SA , H SA } and {M SB , H SB }, the server computes: The server then checks whether H SA is equal to H* SA and H SB is equal to H* SB . If any verification is incorrect, the server terminates the session; otherwise, the server computes: Now, the server updates After the successful completion of above steps, T AB is used as the secret session key for subsequent secure communication between A and B. Clearly, T AB gets updated in every new session.

N2S Communication
Assume that B wants to authenticate the proximity server and establish a session key with the server. As shown in Figure 3, B and the server perform the following steps.
Step 1. B sends the N2S connection establishment request {id B } to the server.
Step 2. The server fetches the corresponding ID-CRP {id B , C Bi , R Bi } from its secure database and generates a random number RN. The server computes: The server then sends the message {C Bi , M B , H B } to B.
Step 3. Upon receiving the message {C Bi , M B , H B }, B computes: To authenticate the server, B then checks whether H B is equal to H* B . If any verification fails, B terminates the session. Otherwise, B further computes: Finally, B sends {MSB, HSB} to the server.
Step 4. Upon receiving the message {MSB, HSB}, the server computes: The server then checks whether HSB is equal to H*SB. If the verification is incorrect, the server terminates the session; otherwise, the server computes: Now, the server updates {idB, CBi, RBi} to {idB, C*B(i+1), R*B(i+1)} in its secure database.  Step 4. Upon receiving the message {M SB , H SB }, the server computes: The server then checks whether H SB is equal to H* SB . If the verification is incorrect, the server terminates the session; otherwise, the server computes: Now, the server updates {id B , C Bi , R Bi } to {id B , C* B(i+1) , R* B(i+1) } in its secure database.
Once the above authentication procedure is completed, B and the server share R B(i+1) as their secret session key. This key is updated in every new session establishment.

Insider Attack on Roy et al.'s Protocol
Let A be an insider attacker. It means that A has a legitimate ID-CRP record {id A , C Ai , R Ai } in the server's secure database but attempts to sabotage the server and other IoT nodes. When both A and B run the N2N communication model with the server, A executes the steps as described in Figure 2. At the same time, A as an insider further performs the following operations. Based on above, A can compute B's C B(i+1) by evaluating C Bi ⊕R Bi , because it knows R Bi (see Equation (12)) during Step 3. And A can correctly recover B's R B(i+1) by calculating M SB ⊕RN. Here, we know that A also computes the correct RN (see Equation (11)

Surveillance Exploiting N2S Communication
A is able to monitor the session run of the N2S communication model between B and the server. As shown in Figure 5, A can perform the following operations to reveal the secret session key RB(i+1) shared by B and the server. Comments. According to above surveillance, in the initial stage, the insider attacker needs to collect information about the target IoT node (i.e., B) by running a session with the target IoT node. Afterwards, the insider attacker can expand their surveillance to other IoT nodes (e.g., C), which run the sessions with the target IoT node. Meanwhile, the insider attacker no longer needs to participate in those session runs and still obtains those secrets. This effectively hides the insider attacker and reduces the probability of the insider attacker being identified. Moreover, the insider attacker can establish a surveillance network of the selected IoT nodes based on our proposed attack.

Surveillance Exploiting N2S Communication
A is able to monitor the session run of the N2S communication model between B and the server. As shown in Figure 5, A can perform the following operations to reveal the secret session key R B(i+1) shared by B and the server.

IoT Node Impersonation Exploiting N2N Communication
In N2N communication, A can imitate B run with any C, when A obtains a legal {idB, CBi, RBi}. As shown in Figure 6, A replaces B to perform B's following steps during the run of N2N communication.

IoT Node Impersonation Exploiting N2N Communication
In N2N communication, A can imitate B run with any C, when A obtains a legal {id B , C Bi , R Bi }. As shown in Figure 6, A replaces B to perform B's following steps during the run of N2N communication.    Herein, A randomly generates R B(i+1) instead of B's R B(i+1) outputted by the valid PUF to evaluate M SB and H SB in Step 4. A can still pass the server's authentication, because the server never checks the PUF validness of its receiving R B(i+1) in Step 6. If A wants to continuously impersonate B, A further uses the new {id B , C B(i+1) , R B(i+1) } to replace the old {id B , C Bi , R Bi } for B's next session. In addition, A can also employ a similar attack to Comments. After A completes above impersonation, B will no longer be able to successfully run the authentication and key exchange phase with the server and other IoT nodes. In this situation, we know that the server updates its is randomly generated by A. When B runs the authentication and key exchange phase, the server should use the random R Bi to generate M B (see Equation (6)) and send it to B in Step 2. However, in Step 4, B retrieves its local R Bi by invoking f B PUF (C Bi ) (see Equation (17)). Clearly, the server's R Bi and B's R Bi are always not equal because of the PUF's safety feature. Hence, B should recover an incorrect RN using Equation (18) and fail the subsequent authentication and key exchange procedure with the server and the counterpart IoT node. Therefore, B suffers from a denial of service attack due to A's impersonation.

IoT Node Impersonation Exploiting N2S Communication
In N2S communication, A can impersonate B to cheat the server, when A obtains B's {id B , C Bi , R Bi }. As shown in Figure 7, we demonstrate A's operations as follows. Comments. After A completes above impersonation, B will no longer be able to successfully run the authentication and key exchange phase with the server and other IoT nodes. In this situation, we know that the server updates its {idB, CBi, RBi} to {idB, CB(i+1), RB(i+1)}, where RB(i+1) is randomly generated by A. When B runs the authentication and key exchange phase, the server should use the random RBi to generate MB (see Equation (6)) and send it to B in Step 2. However, in Step 4, B retrieves its local RBi by invoking f B PUF(CBi) (see Equation (17)). Clearly, the server's RBi and B's RBi are always not equal because of the PUF's safety feature. Hence, B should recover an incorrect RN using Equation (18) and fail the subsequent authentication and key exchange procedure with the server and the counterpart IoT node. Therefore, B suffers from a denial of service attack due to A's impersonation.

IoT Node Impersonation Exploiting N2S Communication
In N2S communication, A can impersonate B to cheat the server, when A obtains B's {idB, CBi, RBi}. As shown in Figure 7, we demonstrate A's operations as follows.
(1) A sends the request {idB} to the server in Step 1. This node impersonation is similar to that of the impersonation discussed in Section 4.2.1. Clearly, the server should confirm the validity of A's HSB in Step 4, and therefore we omit this operation in Figure 7 for simplicity. The slight difference is that, after session run, A applies RB(i+1) as the secret session key instead of TCB as in Section 4.2.1.  (1) A sends the request {id B } to the server in Step 1. This node impersonation is similar to that of the impersonation discussed in Section 4.2.1. Clearly, the server should confirm the validity of A's H SB in Step 4, and therefore we omit this operation in Figure 7 for simplicity. The slight difference is that, after session run, A applies R B(i+1) as the secret session key instead of T CB as in Section 4.2.1.

Server Impersonation Exploiting N2N Communication
A can impersonate the server to cheat both C and B in N2N communication, if A obtains C's {id C , C Ci , R Ci } and B's {id B , C Bi , R Bi }. Figure 8 shows the process of A's server impersonation. A performs the following operations.  Figure 8 shows the process of A's server impersonation. A performs the following operations.   A finally shares the session key T CB with both C and B. Moreover, A still can reuse C's {id C , C Ci , R Ci } and B's {id B , C Bi , R Bi } to impersonate the server in the subsequent session, because C and B do not verify the freshness of C Ci and C Bi in each session run. Certainly, in Step 6, A can also compute R* C(i+1) ←RN⊕M SC , R* B(i+1) ←RN⊕M SB , C* C(i+1) ←C Ci ⊕R Ci , and C* B(i+1) ←C Bi ⊕R Bi . This means that A obtains new ID-CRPs for future attacks.

Server Impersonation Exploiting N2S Communication
When B wants to run N2S communication, A can make use of B's {id B , C Bi , R Bi } to impersonate the server. As shown in Figure 9, A executes the following operations to achieve it.  Figure 9, A executes the following operations to achieve it.

Discussion of Insider Attacker
We discuss how an IoT node practically becomes a malicious IoT node, i.e., an insider attacker. In general, the IoT system contains plenty of IoT nodes. And some of them are possibly manufactured and provided by third parties. From a third-party perspective, these IoT nodes may not only want to work properly in the IoT system, but also engage in malicious behaviors such as surveillance and impersonation. Clearly, in this situation, the malicious IoT nodes can enter the IoT system during the one-time enrollment phase of Roy et al.'s protocol.
After the deployment of the IoT nodes, physical attacks are very common for the IoT system. They typically require physical proximity to the IoT system and can involve actions that limit the efficacy of the IoT nodes. In order to turn benign IoT nodes into malicious IoT nodes, the physical attack can further inject malicious codes into benign IoT

Discussion of Insider Attacker
We discuss how an IoT node practically becomes a malicious IoT node, i.e., an insider attacker. In general, the IoT system contains plenty of IoT nodes. And some of them are possibly manufactured and provided by third parties. From a third-party perspective, these IoT nodes may not only want to work properly in the IoT system, but also engage in malicious behaviors such as surveillance and impersonation. Clearly, in this situation, the malicious IoT nodes can enter the IoT system during the one-time enrollment phase of Roy et al.'s protocol.
After the deployment of the IoT nodes, physical attacks are very common for the IoT system. They typically require physical proximity to the IoT system and can involve actions that limit the efficacy of the IoT nodes. In order to turn benign IoT nodes into malicious IoT nodes, the physical attack can further inject malicious codes into benign IoT nodes. These malicious codes include the logic that requires the IoT nodes to execute insider attacks in some cases. In addition, software attacks can be exploited to compromise the IoT nodes, that is, the attackers use the malware, such as viruses, worms, and Trojans, to manipulate the IoT nodes.
It is possible that malicious IoT nodes have limited resources and functionalities. This means that the malicious IoT nodes cannot handle and store the derived session keys for next session and for another IoT node, cannot intercept the transmitted messages over the public channel, cannot impersonate the server, and so on. To complete our insider attacks, the attacker can build a powerful auxiliary node to support malicious IoT nodes. Each malicious IoT node A merely outputs its {id A , C Ai , R Ai } to the auxiliary node. The auxiliary node can replace the malicious IoT node A to implement the insider attacks.

Experimental Verification of Proposed Insider Attacks
Scyther is a formal analysis tool for automatic verification of security protocols based on the security protocol description language (SPDL). Scyther can analyze protocols that contain multiple subjects, infinite session interaction, and the use of random numbers. We therefore use Scyther to confirm our insider attacks on Roy et al.'s protocol. We implement experimental verification on the 64-bit Windows 10 operating system, Graphviz v2.50, and Python v2.7 using the Compile-0.9.2 version of the Scyther tool.
When using the Scyther tool to verify Roy et al.'s protocol, we write secret PUF responses, XOR-encrypted messages, etc., into the SPDL script to model the protocol. The details of the Scyther tool parameter settings are shown in Table 2. Here, the attacker can obtain the secret PUF responses and furthermore derive the session key and random numbers. This is consistent with the capabilities of the malicious IoT nodes assumed in Section 4.  Figure 10 shows Scyther's verification results for N2N communication (see Figure 10a) and N2S communication (see Figure 10b). The results show that both N2N communication and N2S communication do not meet Scyther's automatic declaration requirements of Alive, Weakagree (weak agree), Nisynch (noninjective synchro-nization), and Niagree (noninjective agreement). Moreover, the results also indicate that the secret session key T AB in the N2N communication and the secret session key R B(i+1) in the N2S communication are both insecure. Hence, we conclude that the process of the authentication and key exchange in Roy et al.'s protocol is insecure and is subject to insider attacks on the IoT nodes and the server.

Suggestion for Preventing Insider Attacks
We know that A is required to recover B's RBi (see Equation (12)) to verify B (see Equation (14)) in the N2N communication of Roy et al.'s protocol. Similarly, B needs to recovering A's RAi (see Equation (19)) to verify A (see Equation (20)). However, we know

Suggestion for Preventing Insider Attacks
We know that A is required to recover B's R Bi (see Equation (12)) to verify B (see Equation (14)) in the N2N communication of Roy et al.'s protocol. Similarly, B needs to recovering A's R Ai (see Equation (19)) to verify A (see Equation (20)). However, we know that both R Ai and R Bi are the secrets of A and B, respectively. It means that A and B obtain each other secrets after Step 4 of the N2N communication, which incurs the secure breach. In fact, these verifications conducted by A and B are unnecessary because both A and B believe the server. Therefore, one suggestion is to cancel the verifications, that is, the server does not send M B and H B to A and M A and H A to B during Step 2 of the N2N communication.
Moreover, we find that both A and B share a random number RN in the N2N communication. RN is used to encrypt their all secrets. Because of sharing the RN, the malicious IoT node can decrypt other IoT node's secrets. Hence, another suggestion is that the server must randomly select two random numbers instead of just one RN, that is, one random number for A and the other one for B.
The above two suggestions may defend against our proposed insider attacks. However, accurate security results for improvements require formal security models, security assumptions, security definitions, and reductions. We keep these for future work.

Conclusions
In the N2N communication of Roy et al.'s protocol, the IoT node requires the counterpart IoT node's secret output of the PUF to verify it. More importantly, the malicious IoT node can derive the counterpart IoT node's next output of the PUF if it eavesdrops on the message transmitted to the server. These defects have led to our insider attacks on Roy et al.'s protocol. Moreover, in the cases of the N2N communication and the N2S communication, we must point out that once the attacker stole the session keys, i.e., T AB or R B(i+1) , he can always impersonate not only the IoT node to cheat other IoT nodes or the server but also the server to cheat the IoT nodes in the subsequent sessions. The secure communications between the server and the corresponding IoT nodes are also possibly under the attacker's surveillance. This means that Roy et al.'s protocol fails to provide the known key security. Our security analysis results indicate that designing PUF-based authentication and key exchange protocols for IoT remains a challenging task.

Data Availability Statement:
No new data was created or analyzed in this study. Data sharing is not applicable to this article.