PUFTAP-IoT: PUF-Based Three-Factor Authentication Protocol in IoT Environment Focused on Sensing Devices

In IoT-based environments, smart services can be provided to users under various environments, such as smart homes, smart factories, smart cities, smart transportation, and healthcare, by utilizing sensing devices. Nevertheless, a series of security problems may arise because of the nature of the wireless channel in the Wireless Sensor Network (WSN) for utilizing IoT services. Authentication and key agreements are essential elements for providing secure services in WSNs. Accordingly, two-factor and three-factor-based authentication protocol research is being actively conducted. However, IoT service users can be vulnerable to ID/password pair guessing attacks by setting easy-to-remember identities and passwords. In addition, sensors and sensing devices deployed in IoT environments are vulnerable to capture attacks. To address this issue, in this paper, we analyze the protocols of Chunka et al., Amintoosi et al., and Hajian et al. and describe their security vulnerabilities. Moreover, this paper introduces PUF and honey list techniques with three-factor authentication to design protocols resistant to ID/password pair guessing, brute-force, and capture attacks. Accordingly, we introduce PUFTAP-IoT, which can provide secure services in the IoT environment. To prove the security of PUFTAP-IoT, we perform formal analyses through Burrows Abadi Needham (BAN) logic, Real-Or-Random (ROR) model, and scyther simulation tools. In addition, we demonstrate the efficiency of the protocol compared with other authentication protocols in terms of security, computational cost, and communication cost, showing that it can provide secure services in IoT environments.


Introduction
The rapid development of wireless networks and the Internet of Things (IoT) has created opportunities to communicate with things over the Internet. Wireless sensor networks (WSN), a combination of wireless networks and IoT sensors, are garnering increasing attention worldwide as an exciting new paradigm of IoT in various fields, such as smart home, smart city, smart transportation, and smart agriculture [1][2][3]. In this IoTbased environment, data are collected through various sensors and sensing devices, and users can access them through a gateway node. Through WSN, users can use convenient services in real-time through IoT devices in an IoT-based environment. For example, with their IoT devices, users can remotely operate the lights in their house or sprinklers in their garden.
However, because this convenient service is provided through a wireless network, it is vulnerable to illegal access by malicious attackers [4,5]. This can harm the convenience of IoT, such as invasions of user privacy and eavesdropping on privacy. Malicious attackers can also be insiders or outsiders seeking to breach network security and falsify data integrity. Moreover, problems of node and link failures (i.e., cascading failures) can occur due to the • We prove the vulnerabilities of protocols by Chunka et al. [16] and Amintoosi et al. [18], which are two-factor authentication protocols, and Hajian et al. [27], which is a three-factor authentication protocol. • PUFTAP-IoT adopts PUF [29] and honey_list [30,31] technology to be safe against various attacks. In addition, to solve the resource problem of sensors and sensing devices, only XOR and hash functions excluding elliptic curve cryptography (ECC) functions are used to lighten the protocol. • Informal (non-mathematical) analysis and formal analysis are performed to prove the security of the proposed PUFTAP-IoT. Formal analysis uses the widely adopted Burrows Abadi Needham (BAN) logic [32] and Real-Or-Random (ROR) model [33]. We also use the scyther simulation tool [34] to show that PUFTAP-IoT is secure in networks over public channels. • We compare PUFTAP-IoT with other authentication protocols in terms of computation cost, communication cost, and security to analyze its efficiency.
The remainder of this paper is organized as follows: Section 2 reviews two-factor and three-factor-based authentication protocols in IoT and WSN environments. Section 3 outlines the proposed system model, attacker model, PUF, fuzzy extraction, and honey list. We analyze the protocols of Zou et al., Amintoosi et al., and Hajian et al. to demonstrate security vulnerabilities. Section 5 describes PUFTAP-IoT, and the safety of PUFTAP-IoT is analyzed in Section 6. We also analyze the efficiency of the protocol in Section 7. Finally, Section 8 concludes the paper.

Related Works
Lamport [35] first proposed a password-based authentication protocol in 1981. Since then, many related studies on password-based, two-factor authentication protocols have been proposed in various network environments to protect users' privacy. In 2009, Das [8] proposed a two-factor authentication concept using a smart card with password in an IoT-based WSN environment. Das argued that the proposed scheme has a security advantage in that it uses only a hash function to reduce communication overhead and resist various attacks. However, He et al. [9] proved [8]'s authentication protocol is vulnerable to insider attacks along with impersonation attacks in 2010. In addition, He et al. presented an improved protocol as a countermeasure against these attacks. Unfortunately, it was found by Kumar and Lee [10] that He et al.'s protocol also does not guarantee mutual authentication and cannot generate a session key. Turkanović et al. proposed a new authentication and key agreement method in the WSN environment, focusing on heterogeneous IoT. The proposed scheme allows users to negotiate session keys securely with sensor nodes using the authentication protocol. However, Amin and Biswas [12] demonstrated that the protocol of Turkanović et al. is not secure against impersonation, identity guessing, and password guessing attacks. Moreover, they showed that their scheme has an inefficient authentication phase. Amin and Biswas proposed a protocol that compensated for these problems. However, Wu et al. [13] found that the protocol of Amin and Biswas are also vulnerable to sensor capture and guessing and spoofing attacks. Shuai et al. [14] suggested an authentication protocol for smart homes in 2019. In their protocol, they use Elliptic Curve Cryptography (ECC) for efficient and anonymous authentication. They demonstrate that their protocol is secure against a variety of attacks, including desynchronization and verification table stolen attacks. However, Zou et al. [15] proved Shuai et al.'s protocol is insecure against perfect forward secrecy, node capture attack, and impersonation attacks. Moreover, they proposed more secure user authentication schemes for smart homes. In 2021, Chunka et al. [16] point out the problems with the authentication protocol for WSN environment proposed by Kalra and Sood [17]. They pointed out that the protocol proposed by Kalra and Sood is vulnerable to sensor node capture attacks and cannot provide perfect forward secrecy. In 2022, Amintoosi et al. [18] proposed a two-authentication-based authentication and key agreement protocol to ensure the privacy and security of patients' health-related data. They claim that their protocol is safe from various attacks and is a lightweight protocol using only hash and XOR functions.
According to [19,20], people tend to choose ID/password pairs that are easy to remember. As a result, ID and password pairs are chosen from a small dictionary space. This allows an attacker to guess a user's ID and password in polynomial time [21]. Many researchers have proposed a secure three-factor authentication scheme to prevent simultaneous ID and password pair guessing attacks.
In 2016, Amin et al. [22] proposed a three-factor authentication protocol for WSN. They designed an anonymity-preserving authentication scheme for WSN and proved that their proposed protocol is secure against multiple attacks and is more efficient than other protocols. However, Jiang et al. [23] showed that the protocol of Amin et al. is insecure against replay attacks and does not provide complete forward secrecy. To solve this security flaw, Jiang et al. presented an authentication protocol based on the Rabin cryptosystem for WSN. However, Ostad-Sharif et al. [24] demonstrate that the Jiang et al. protocol also does not provide perfect forward secrecy. In 2019, Mo et al. [25] proposed a secure three-factor-based key agreement and user authentication protocol for WSN. They presented a protocol based on ECC. They demonstrated that their protocol is able to provide security against untraceability and user anonymity. However, Yu and Park [26] pointed out that the protocol of Mo et al. is not safe for impersonation, replay, and session key disclosure attacks. Unfortunately, Hajian et al. [27] proved that the protocol proposed by Ostad-Sharif et al. [24] and Yu et al. [26] is also vulnerable to some attacks. To prevent security problems, Hajian et al. proposed a lightweight authentication protocol for IoT environments. They argued that the proposed protocol can defend against multiple attacks. In 2022, Amintoosi et al. [18] pointed out the security vulnerabilities of the authentication protocol for e-health proposed by Aghili et al. [28]. They proposed a lightweight authentication protocol for smart healthcare services that solves the security vulnerabilities of Aghili et al.'s protocol.
However, we prove that some schemes [16,18,27] are vulnerable to security attacks. We found that Chunka et al. [16] protocol is vulnerable to known session-specific temporary information, ID/password pair guessing, and impersonation attacks. Additionally, we prove that Amintoosi et al.'s protocol [18] cannot withstand identity and password guessing attacks and smart card stolen attacks. Finally, Hajian et al.'s protocol [27] is vulnerable to device capture and session key disclosure attacks.

Preliminaries
This section introduces the PUFTAP-IoT system model and an adversary model for security analysis of authentication protocols. In addition, we briefly describe PUF, fuzzy extraction, and honey_list, which are the security technologies adopted in the proposed IoT-TFBAP.

The Proposed System Model
The system model of PUFTAP-IoT is shown in Figure 1. PUFTAP-IoT consists of following three entities:  Figure 1 include smart agriculture, vehicles, smart doors, and smart watches. They collect data and provide it to users, and users can use the data to execute any commands they want. Sensing devices also have limited computational power. • Gateway: All service users and sensing devices must be registered with the gateway. A gateway is a trusted entity that is responsible for the process and regulates authentication requests between users and sensing devices. Users must first register with the gateway when they want to communicate with a sensing device. The gateway stores relevant data from users and sensing devices, and controls communication between users and sensing devices. PUFTAP-IoT consists of a registration phase, login and authentication phase, and password and biometrics update phase. In the registration phase, users and sensing devices are registered with the gateway through secure channels. During the login and authentication phase, the user, gateway, and sensing device authenticate each other and generate a session key for communication.
In the future, the user can safely communicate with the sensing device using this session key. In the password and biometrics update phase, users can update their passwords and biometrics if desired. To defend against malicious adversaries' ID/password guessing attacks and brute-force attacks, the gateway creates and stores honey_list. In addition, the sensing devices have built-in PUF technology to protect them from physical capture attacks.

The Adversary Model
We adopt the "Dolev-Yao (DY) adversary model" [36] to analyze the proposed protocols [15,18,27] and the IoT-TFBAP. The DY adversary model is a widely adopted model to analyze the security of wireless networks and assumes the following: • The adversary can learn messages by intercepting messages delivered over insecure, public wireless channels. Through the learned message, the adversary can create a valid message and insert and modify it. • The adversary can obtain stored values by stealing a valid user's smart card and sensing device [37]. • The adversary can guess the user's ID/password pair in polynomial time [21]. • The adversary can perform guessing, impersonation, known session-specific temporary information, and session key disclosure attacks using the acquired values.

Physical Unclonable Function
We adopt PUF technology to securely store secret parameters in the sensing device. PUF can be described as "the representation of the unique, non-replicable, instance-specific functionality of a physical entity" [29]. The randomness and uncertainty in integrated circuit fabrication is less likely to create duplicates, making PUFs increasingly visible in the security realm. PUF receives the challenge C and obtains its response R through the physical properties of C and the integrated chip (IC). Since both the accepted C and the generated R are strings of bits, PUF is expressed as R = PUF(C) and can be considered as a one-way function. In an ideal situation, a one-to-one correspondence exists between a challenge-response pair and a PUF, where if a challenge is assigned to the same PUF multiple times, the generated response is the same, and when the same challenge is given to different PUFs, the response obtained is different. PUF also has the following characteristics: • It is impossible to clone PUF to create the same device [38]. • Any attempt to change the device containing the PUF will change the PUF's behavior and destroy the PUF [39]. • In real-world manufacturing circuits, the difference between mapping input and output functions is fixed and unpredictable. In this respect, the hardware is equivalent to a one-way function [40].
However, due to environmental and circuit noise, PUFs always output varying responses with some margin of error in Cs. To solve this problem, PUF is being applied with fuzzy extractor technology [41].

Fuzzy Extraction
To solve the problem of noisy PUF, we introduce fuzzy extraction technology [41]. Moreover, we can use fuzzy extraction to solve the noise that can occur in the biometric input. The fuzzy extractor consists of the GEN function and the REP function.
The GEN function is for generating key information corresponding to the entered value. Entering the data D i into the GEN function outputs the secret key data R i , which is a uniform random string. The GEN function also outputs the string P i , which helps to remove the noise and recover the key value.
The REP function restores the secret key R i . Enter the data D i and the helper string P i into the REP function. At this time, D i may generate noise. For this, P i helps to output the correct R i . To recover the same R i , the metric space distance between D i and D i must be within the specified tolerance.

Honey List
Assume that attackers attempt to obtain useful data by performing brute-force and online-guessing attacks. In this case, honey_list prevents the algorithm "Honey Encryption (HE)" [30,31] from attempting to obtain data by guessing the password. If an adversary attempts attacks with the wrong password, HE uses an algorithm to generate fake valid messages, "Honey words". [42] has more details on the honey word generation algorithm.
Various methods have been used to resist brute-force or online-guessing attacks using honey_list at the login and authentication phase. Out of all of them, PUFTAP-IoT calls honey_list by adopting the following method. If an attacker tries to login using the guessing password, the login proceeds as usual, but the gateway monitors the attacker's login source for intrusion detection. The gateway also kills the session "when the number of entries in honey_list exceeds a predefined threshold" and notifies the user to update their password.

Cryptanalysis of Authentication Protocols
This section shows the analysis of various authentication protocols using sensor or sensing devices in an IoT environment. A review of each protocol is omitted, and for convenience of explanation, S (sensor) of Chunka et al. and Amintoosi et al. and S (sensing device) of Hajian et al. are all denoted as SD (sensing device). The rest of the notation is the same as that of each authentication protocol. Table 1 shows the notations used in this paper.

Notations
Meanings The hidden password of i-th user Bi The challenge/response pair GEN, REP Generation and reproduction algorithm of fuzzy extractor Pseudo-identity of U i and SD j TH ID i Temporary user identity U i Skey Session key || Data concatenation operator ⊕ Bitwise exclusive-or operator h( * ) Collision-resistant one-way hash function

Cryptanalysis of Chunka et al.'s Protocol
We prove that Chunka et al.'s protocol [16] is not safe against known session-specific temporary information attacks and does not provide perfect forward secrecy.

Known Session-Specific Temporary Information Attacks
Suppose that the adversary Adv obtains a session-specific temporary information r 1 . Then, Adv is able to compute the legitimate session key. The detailed steps are as follows: Step 1: Adv computes h(α i ⊕ k) = r 1 ⊕ MID i , since MID i is public parameter. Then, Adv can obtain P i , where P i is obtained through an insecure channel. Step which is transmitted to the public channel.
Step 3: Finally, Adv can compute the legitimate session key

Off-Line Guessing Attacks
According to the adversary model in Section 3.2, the adversary Adv can guess the ID/PW pair in polynomial time. The detailed steps are as follows: Step } stored on the smart card via smart card stolen attacks. Then, Adv picks ID a /PW a and computes r a = X i ⊕ h(ID a ||PW a ).
Step 2: Adv calculates Z i a = h(ID a ||PW a ||r a ) and checks if Z i a = Z i .
Step 3: If they are the same, Adv has successfully guessed the correct ID/password pair for the user. Otherwise, Adv repeats Steps 1 and 2.

Impersonation Attacks
After off-line guessing attacks, Adv can impersonate the valid user. The detailed steps are as follows.
Step 1: Through guessing attacks, Adv computes h(ID i ||r). Then, Adv can compute Step 2: Then, Adv generates a random nonce r 1 a and computes Step 3: Finally, Adv sends the message {P i , MID i , N i }. Thus, Adv can impersonate the legitimate user.

Cryptanalysis of Amintoosi et al.'s Protocol
This section shows that Amintoosi et al.'s protocol [18] is not secure to smart card stolen, off-line guessing, and impersonation attacks.

Off-line Guessing Attacks
The adversary Adv can obtain the sensitive information stored in the smart card. Then, Adv can guess the ID/password pair in polynomial time. The detailed steps are as follows: Step 1: Adv can obtain values {b i , A i , B i , a i } stored on the smart card. Then, Adv picks ID a /PW a and computes p a = h(ID a ||PW a ||a i ), N a = A a ⊕ p a , and bID a = h(b i ||ID a ). Step Step 3: If they are the same, Adv has successfully guessed the correct ID/password pair for the user. Otherwise, Adv repeats Steps 1 and 2.

Impersonation Attacks
After guessing the legitimate user's ID/password pair, the Adv computes {M1 i , M2 i , T 1 , b i , M2 i } can be masquerading. The detailed steps are as following.
Step 1: After off-line guessing attacks, Adv obtains valid values M i and N i . Then, Adv can compute Step 2: Then, Adv also can compute M2 i = h(M i ||N i ||d i ).
Step 3: Therefore, Adv can compute M1 i , T 1 , b i , and M2 i . This means that Adv can impersonate the valid user. So, we can say that Amintoosi et al.'s protocol is not secure against impersonation attacks.

Cryptanalysis of Hajian et al.'s Protocol
In this section, we show that Hajian et al.'s protocol [27] is vulnerable to device capture attacks, device impersonation attacks, and session key disclosure attacks.

Device Impersonation Attacks
The adversary Adv can obtain the {SID j , x j , f j } stored in SD through a device capture attack. After that, Adv can impersonate as a valid SD by generating a message using the obtained values. After the device capture attacks, the detailed steps of the Adv's device impersonation attack are as follows: Step 1: Adv obtains the values {M 2 , T 1 } via the message sent to the public channel. Then, Adv can obtain K j through computing Step 2: Adv can compute the legitimate . Finally, Adv can compute the valid response message {M 2 , V 2 }. Thus, we can say that Adv can conduct device impersonation attacks.

Session Key Disclosure Attacks
After Adv conducts device impersonation attacks, Adv obtains x j , f j , and K j . Adv can calculate the session key using these values. Therefore, an attacker can perform session key disclosure attacks, and the detailed steps are as follows: Step 1: Adv can learn values M 1 and M 5 through the message sent over the open channel. Then, Adv can compute Step 2: Then, Adv can obtain K i and TID new i .
Step 3: Therefore, Adv can compute the session key Thus, we can say that Hajian et al.'s protocol is not secure against session key disclosure attacks.

The Proposed PUFTAP-IoT
In this section, we describe the proposed PUFTAP-IoT. In the proposed protocol, we adopt PUF technology to withstand device capture attacks. Additionally, we also apply the user's biometrics and honey_list to prevent online-guessing and brute-force attacks. Accordingly, our protocol is observed to be secure against various attacks. Finally, we propose a lightweight protocol using XOR and hash functions to consider the resource limitations of sensing devices and to prevent system down.

Registration Phase
In order for a service user to use IoT services through a sensing device in an IoT environment, first, he/she must register his/her information in the gateway. Moreover, the sensing device also registers its information in the gateway. The registration phase for service users and sensing devices is shown in Figure 2, and the detailed registration phase is described below.

Service User Registration Phase
Service users create their own information through ID, password, and biometric information and register it with the gateway, and the gateway issues a smart card. Here are the detailed steps: Step 1: The service user U i inputs his/her identity ID, password PW i , and imprints his/her biometrics B i . Then, U i generates α and R u and computes Gen( Step 2: After receiving the registration request message, GW checks the uniqueness of H ID i . If it has the uniqueness, GW generates a random nonce R gw and GW computes Then, GW generates the temporary service user's identity TH ID i and stores {(HID i , TH ID i ), R gw , honey_list = null} in its secure database. GW issues the smart card SC = B i , C i , TH ID i to U i via a secure channel.
Step 3: Then, U i deletes B i and C i in SC and stores L i , B i , and C i in SC.

Sensing Device Registration Phase
The sensing device SD j utilizes the PUF function for registration and registers its own information with GW. The detailed registration steps are as follows: Step 1: SD j picks its identity SID j and PUF's challenge C j . SD j generates a random nonce R sd and computes Req j = SID j ⊕ h(R sd ), R j = PUF(C j ), Gen(R j ) = SDR j , SDP j , and HSID j = h(SID j ||SDR j ). After that, SD j transmits Req j , R sd , HSID j , C j to GW through a closed channel.
Step 2: GW computes SID j = Req j ⊕ h(R sd ) and GW generates a random secret key RK j . GW also computes PSID j = h(HSID j ||RK j ) and SI j = h(PSID j ||h(K gw ||RK j ). Finally, GW stores {(HSID j , PSID j ), RK j , C j } in its database and transmits PSID j , SI j to SD j through a closed channels.
Step 3: After receiving the message, SD j stores {SID j , PSID j , SI j , SDP j }.

Login and Authentication Phase
U i sends an authentication request message to GW after login through his/her smart card and credential information. After confirming this, GW sends an authentication message to the corresponding SD j , and each entity authenticates the response message. When authentication is completed, U i , GW, and SD j agree on a session key Skey, and secure communication can be guaranteed later through Skey. In addition, U i and GW update TH ID i to TH ID inew when authentication and key agreement are successful. The detailed formula is as follows, and the entire steps are summarized in Figure 3: Step 1: The service user U i inserts SC and inputs ID i , PW i , and B i . Then, SC computes If it is correct, SC generates a random nonce N u and timestamp T 1 . After that, SC computes Step 2: When GW receives the request message, GW checks |T 1 − T * 1 | < ∆T. GW retrieves H ID i corresponding to TH ID i and GW computes If it is not same, GW inserts A * i into honey_list. Otherwise, GW retrieves (C j , RK j ) corresponding to PSID j . GW generates a random nonce N g and timestamp T 2 and computes SI j = h(PSID j ||h(K gw ||RK j )), ) ||T 2 || HSID j ||C j ||SI j ). After computing, GW sends Msg 2 , V 2 , V 3 , T 2 ) to SD j via an open wireless channel.
Step 3: If it is the same, SD j generates a random nonce N sd and timestamp T 3 and SD j computes a session key Skey = h(N sd ||K gs ). SD j also computes V 4 = Skey ⊕ h(HSID j ||SI j ||C j ||T 3 ) and Msg 3 = h(C j ||HSID j ||Skey). After that, SD j sends the response message Msg 3 , V 4 , T 3 to GW.
Step 5: After receiving the response message, U i computes a session key If it is correct, the session key is authentic, and U i and GW update TH ID inew .

Service User Password and Biometrics Update Phase
Assume that the service user U i wants to use SC to change to a new password and biometrics. Specifically, this phase runs locally without any additional connections to GW, reducing computation and communication overhead. The following steps are the password and biometrics update process: Step 1: The service user U i inputs his/her identity ID and password PW i and imprints his/her biometrics B i . Then, SC computes Rep(B i , If it is valid, SC asks U i to enter the new password and biometrics. Step 2: U i enters a new password PW inew and new biometrics B inew . SC proceeds to compute parameters GEN(B inew ) = (R inew , P inew ), Then, SC replaces L i , B i , and C i with L inew , B inew , and C inew .

Security Analysis
In this section, we analyze the security of PUFTAP-IoT. We first show that the protocol is safe against various attacks through informal analysis. In addition, we prove that mutual authentication and session key agreement of the protocol can be safely achieved through the universally used BAN logic and ROR model. Finally, we demonstrate the security of PUFTAP-IoT on a wireless network using the scyther simulation tool.

Informal Security Analysis
Here, we perform an informal (non-mathematical) security analysis to show that PUFTAP-IoT is safe against various attacks and also provides various security features.

Offline and Online-Guessing Attacks
Assume that the adversary Adv obtains the U i 's SC and attempts an offline-guessing attack using parameters {L i , B i , C i , TH ID i } in SC. However, since Adv is the value that R i should be calculated as, the biometric of U i , R u = L i ⊕ h(ID i ||PW i ||R i ) could not be calculated. Moreover, Adv tries an online-guessing attack for obtaining U i 's sensitive information. Unfortunately, the attacker does not know if the correct ID and password were guessed because of the honey_list stored on the gateway system. Moreover, PUFTAP-IoT is safe from online-guessing attacks because the session is terminated when the threshold of honey_list is exceeded. Therefore, PUFTAP-IoT is safe against offline-and online-guessing attacks.

Service User Anonymity
If Adv steals U i 's SC and obtains values stored in SC, Adv tries to obtain U i 's real identity, pseudo-identity or temporary identity. However, Adv cannot obtain the ID of U i and H ID i because H ID i is masked by the hash function and R i . Although TH ID i is transmitted through the public channel, TH ID inew is updated by GW when authentication and key agreement are successful. In addition, TH ID inew is masked with N u and N g , and these values change every session. Therefore, PUFTAP-IoT can safely guarantee the anonymity of service users.

Impersonation Attack
In order for Adv to disguise U i , GW, and SD j , Adv must be able to compute the messages sent to the public channel. Messages sent from PUFTAP-IoT to public channels change per session due to random values N u , N s , and N sd and timestamps. In addition, TH ID i is also updated to TH ID inew when the authentication is successful, so Adv cannot calculate the correct message. Therefore, PUFTAP-IoT is resistant to impersonation attacks.

Sensing Device Physical Capture Attack
When Adv performs a physical capture attack on SD j , Adv can obtain {SID j , PSID j , SI j , SDP j } stored in SD j . However, Adv cannot calculate the correct session key through these parameters. In order for Adv to calculate the session key, K gs (= h(h(N u ||A i )||h(N g ||SI j ))) = V 3 ⊕ h(HSID j ||C j ||SI j ) must be calculated. However, since Adv cannot obtain R j , Adv cannot compute SDR j . Therefore, Adv is not able to compute HSID j = h(SID j ||SDR j ). This is because R j is a value created by the PUF function, and the PUF is a function that is a physically unclonable circuit and cannot be duplicated. Therefore, PUFTAP-IoT is safe against sensing device physical capture attacks.

Replay and Man-in-the-Middle Attack
We assume that Adv obtains messages transmitted over a public channel and information of U i 's SC and SD j . However, Adv cannot compute U i 's valid message as mentioned in Section 6.1.3. Additionally, Adv also cannot generate SD j 's valid messages according to Section 6.1.4. Additionally, every message changes with N u , N g , andN sd and timestamps every session. Therefore, we can say that PUFTAP-IoT is secure against replay and man-inthe-middle attacks.

Stolen Verifier Attack
Suppose Adv obtains the GW verification tables {HID i , TH ID i , R gw , honey_list = null} and {HSID j , PSID j , RK j , C j } to compute the session key Skey or perform impersonation attacks. However, Adv cannot compute A i = h(H ID i ||K gw ||R gw ) and SI j = h(PSID j ||h(K gw ||RK j ) without GW's secret key K gw . Furthermore, due to the nature of the PUF function, Adv cannot compute R j = PUF(C j ). Therefore, Adv cannot perform session key and impersonation attacks. Accordingly, we can say that PUFTAP-IoT is resistant to stolen verifier attacks.

Perfect Forward Secrecy
Assuming that GW's secret key K gw , is leaked to Adv, Adv can try to calculate Skey through K gw . However, since A i and SI j are masked with K gw as well as R gw and RK j which are secret keys generated for each entity, Adv cannot compute A i and SI j . Therefore, since Adv cannot calculate valid Skey, PUFTAP-IoT can guarantee perfect forward secrecy.

Session-Specific Random Number Leakage Attack
Assume that N u , N g , andN sd , which are random nonces generated in the session, were leaked to Adv. With these values, Adv will try to compute Skey. However, Adv cannot compute the session key Skey = h(N sd ||h(h(N u ||A i )||h(N g ||SI j ))). To calculate a valid Skey, A i and SI j must be calculated, but as mentioned in the Sections above, A i and SI j cannot be calculated by Adv. Therefore, PUFTAP-IoT is safe against session-specific random number leakage attacks.

Session Key Disclosure Attack
Adv wants to compute the Skey for obtaining sensitive information. However, as discussed in Sections 6.1.6-6.1.8, Adv cannot compute the valid Skey because of the computationally infeasible problem. Thus, PUFTAP-IoT prevents session key disclosure attacks.

Mutual Authentication
In PUFTAP-IoT, all entities authenticate each other by verifying messages containing Msg 1 , Msg 2 , Msg 3 , and Msg 4 . Moreover, these messages are changed with random numbers and current timestamps. After all entities authenticate each other, they compute the same Skey. Thus, PUFTAP-IoT guarantees mutual authentication.

BAN Logic
For proving that PUFTAP-IoT is able to provide secure authentication, we conduct BAN logic [32]. The notations used in BAN logic are shown in Table 2, and the five rules used are as follows [43][44][45]: Message meaning rule: Nonce verification rule: Freshness rule:

Skey
The session key in PUFTAP-IoT #ε The statement S is fresh χ| ≡ ε χ believes the statement ε χ ε χ sees the statement ε Encrypt ε with Key χ ⇒ ε χ controls ε χ Key ↔ ω χ and ω shard and use Key for communication To implement BAN logic, we describe logical rules, goals, assumptions, and ideal forms, thereby proving that PUFTAP-IoT provides secure mutual authentication.

Goals
In order to prove that secure mutual authentication is achieved, the following goals must be achieved:

Idealized Forms
The idealized forms are: The following assumptions are generated for the initial state of PUFTAP-IoT to achieve the BAN logic proof:

Proof
The main proof using the rules and assumptions of BAN logic is: Step 1: S 1 can be obtained from M 1 .
Step 2: S 2 can be obtained by applying the MMR with A 1 .
Step 3: S 3 can be gained from the FR with S 2 and A 2 .
Step 4: S 4 can be acquired by applying the NVR with S 2 and S 3 .
Step 5: S 5 can be obtained from M 2 .
Step 6: S 6 can be gained from MMR with S 5 and A 3 .
Step 7: S 7 can be obtained by applying FR with S 6 and A 4 .
Step 8: S 8 can be obtained from NVR with S 6 and S 7 .
Step 9: S 9 can be obtained from M 3 .
Step 10: S 10 can be gained from MMR with S 9 and A 5 .
Step 11: S 11 can be obtained by applying FR with S 10 and A 6 .
Step 12: S 12 can be obtained from NVR with S 10 and S 11 . S 12 : GW| ≡ SD j | ≡ (h(N sd ||K gs )) Step 13: S 13 can be obtained from M 4 .
Step 14: S 14 can be obtained from MMR with S 13 and A 7 .
Step 15: S 15 can be obtained from FR with S 14 and A 8 , since K gs = h(h(N u ||A i )||h(N g ||SI j )).
Step 16: S 16 can be obtained from NVR with S 14 and S 15 .
Step 17: S 17 and S 18 can be obtained from S 8 and S 12 since Skey = h(N sd ||K gs ). Step 18: S 19 and S 20 can be obtained by applying JR from S 17 , S 18 , A 11 , and A 12 .
Step 19: S 21 and S 22 can be obtained from S 4 and S 16 since Skey = h(N sd ||K gs ). Step 20: S 23 and S 24 can be obtained by applying JR from S 21 , S 22 , A 9 , and A 10 . Therefore, we prove that PUFTAP-IoT can satisfy all goals of BAN logic. Accordingly, it can be said that PUFTAP-IoT can guarantee secure mutual authentication.

ROR
We use the ROR model [33] to describe the semantic security of PUFTAP-IoT. We demonstrate that session key security can be guaranteed through the ROR model [46][47][48]. This section briefly describes the ROR model and presents a proof of the protocol's session key security in Theorem 1. PUFTAP-IoT in the ROR model has three participants P t , which are service user P t 1 U i , gateway mathcalP t 2 GW , and sensing device P t 3 S j . Additionally, for each participant, tth represents an instance of the running participant. We assume that an attacker Adv can modify, remove, insert or learn messages sent during communication. In the ROR model, various queries are defined to simulate real-world attacks, Execute, CorruptSC, Reveal, Send, and Test queries. A detailed description of the query follows: • Execute(P t 1 U i , P t 2 GW , P t 3 SD j ): Adv conducts Execute query to obtain messages sent over insecure channels between U i , GW, and SD j .
• CorruptSC(P t 1 U i ): CorruptSC indicates that Adv can obtain information stored in the smart card of U i .

•
Reveal(P t ): Reveal(P t ) is that Adv returns the session key Skey between P t 1 U i , P t 2 GW , and P t 3 SD j . Skey is safe if Adv reveals Skey using the Reveal(P t ) query.
• Send(P t , M): Send query allows Adv to transmit the M message to P t and receive a response. • Test(P t ): A fair coin f c is tossed before the game starts, and the result is known only to Adv. Adv uses this result to determine Test query. If Adv conducts this query and Skey is fresh, P t will return Skey for f c = 1 or a random nonce for f c = 0. Otherwise, P t returns a null (⊥).
After Adv conducts Test query on participants, Adv has to separate resulting values. Adv checks the consistency of the random bit f c through the output of the Test query. For Adv to win the game, the guessed bit f c must equal f c. Additionally, the collisionresistant one-way hash function h(·) is accessible to all participants. Model h(·) is a random oracle Hash.

Security Proof
Theorem 1. Adv can obtain information by breaking the session key security. Mark the advantage of Adv running in polynomial time as Adv t . Then, we obtain: Here, q h , q p , and q s are the number of Hash, PUF, and Send queries, respectively. |Hash| and |PUF| are the range space of the hash function h(·) and PUF function PUF(·), respectively. In addition, C and s denote Zipf's parameters, and l D is the number of bits in the biometric B i of U i .

Proof.
We run four sequence games GM i to prove session key security, where i ∈ [0, 4]. Succ Adv,i represents the event that Adv wins GM i by correctly guessing any bit f c. The advantage of Adv winning the game GM i is denoted by Pr[Succ Adv,GM i ]. Each game is described below.
• GM 0 : Adv can execute a real attack on PUFTAP-IoT through this game. Adv selects f c at the beginning of GM 0 . Then, according to this game, we obtain: • GM 1 : Adv conducts the Execute(P t 1 U i , P t 2 GW , P t 3 SD j ) query through this game and eavesdrops transmitted messages < Msg 1 , V 1 , T 1 , TH ID i , PSID j >, < Msg 2 , V 2 , V 3 , T 2 >, < Msg 3 , V 4 >, and < Msg 4 , V 5 , V 6 >. Adv then checks whether the derived Skey is real to execute Reveal and Test queries. In PUFTAP-IoT, the session key consists of Skey = h(N sd ||K gs ). To derive Skey, Adv must know the ID and random numbers of U i , GW, and SD j . As a result, Adv never increases the probability of winning GM 1 . Thus, GM 0 and GM 1 can be considered indistinguishable, and we obtain: • GM 2 : To obtain Skey, Adv conducts Hash and Send queries.Adv can modify exchanged messages to carry out active attacks. However, all exchanged messages are protected using the one-way hash function h(·) and consist of secret credentials and random numbers. Moreover, it is difficult for Adv to derive secret credentials and a random nonce because it is a computationally infeasible problem depending on the properties of h(·). So, using the birthday paradox, we obtain: • GM 3 : It is similar to GM 2 . Adv conducts Send and PUF queries. As described in Section 3.3, PUF(·) has security properties. So, we can obtain the following result: Since Adv has no knowledge of identity ID i and password PW i , Adv must guess these parameters from the extracted values. However, it is computationally infeasible for Adv to guess ID, password, and B i simultaneously. Thus, GM 3 and GM 4 are indistinguishable. By utilizing Zipf's law, we can obtain: Now that all the games were run, Adv has to guess the bit to win the game. Thus, we can obtain following results: From Equations (1) and (2), we obtain the result as follows: With Equations (5) and (6), we derive the below equation: Using the trigonometric inequality, we can obtain the results of Equations (4), (5), and (7).
Finally, multiply both sides of Equation (8) by 2 to obtain the desired result.

Scyther Tool Simulation
In this section, we simulate IoT-PUFTAP using the scyther tool [34]. The scyther tool is a push-button tool to verify and analyze various security protocols. It supports unbounded model checking and multi-protocol analysis and provides a graphical user interface (GUI) to trace security vulnerabilities [49]. We validated the proposed protocol using the scyther tool according to the specifications below: • Scyther tool checks security attack classes and possible protocol behaviors of the proposed protocol based on a pattern refinement algorithm. • Scyther tool traces the most efficient and optimal security attacks through the "Find best attacks" setting. • Scyther tool analyzes the security of the proposed protocol using claim events, including "Secret", "Alive", "Weakagree", "Niagree", and "Nisynch". • To support multiple executions of protocols in the scyther tool, the "Maximum number of run" and "Maximum number of patterns per claim" parameters are set to 5 and 10, respectively.
To simulate IoT-PUFTAP, we write code in "Security Protocol Description Language (SPDL)". After that, the scyther tool simulates the "Secret", "Alive", "Weakagree", "Niagree", and "Nisynch" claim events under the DY model. Note that the claim event "Secret" means that the parameter can ensure confidentiality during the authentication phase. The claim event "Alive" denotes that the participants are alive and running the protocol in same session. "Weakagree" can be satisfied when participants actually communicate with a legal participant. "Niagree" can be guaranteed when participants agree on the exchanged parameters. "Nisynch" is the non-injective synchronization claim event, which means that messages are exchanged from legal participants in appropriate sequence. We conducted simulation on a Ubuntu 20.04.2 LTS virtual machine with an Intel Core i3-8100 3.60 GHz CPU and 16.0 GM of RAM. Figure 4 shows the basic framework of the scyther tool. Firstly, we describe the proposed protocol into the scyther GUI according to the syntax of SPDL. Then, the scyther command-line tool performs the security validation using claim events. Finally, the command-line tool outputs the summary reports and trace class graphs. When the protocol satisfies each claim event, the result window displays the "OK" message and "No attacks" comment.   Figure 6 indicates the simulation result of PUFTAP-IoT. The result shows that each role is not exposed to security attacks and ensures the "Secret", "Alive", "Weakagree", "Niagree", and "Nisynch" claim events. Therefore, we can demonstrate that PUFTAP-IoT can resist security vulnerabilities and ensure mutual authentication between each participant.

Efficiency Analysis
In this section, we compare computation cost, communication cost, and security aspects with other relevant papers to prove the efficiency of PUFTAP-IoT.

Security and Functionality Features Comparison
In this section, we compare PUFTAP-IoT with the related existing protocols in terms of speculation, replay and man-in-the-middle, spoofing, guessing, known session-specific temporary information (KSSTI), device capture, device impersonation, and session key disclosure attacks and security features such as anonymity, forward secrecy, and secure mutual authentication. Table 3 indicates that the existing protocols do not meet all security requirements. On the other hand, PUFTAP-IoT meets all essential security requirements for communication in IoT environment.

Computation Cost Comparison
We cited [50,51] to compare and analyze computation cost with other authentication protocols. Accordingly, we hypothesized notations and times for cryptographic functions and functional functions as follows: T h , T rg , T pu f , and T f as the execution time needed for hash function, random nonce generation, PUF function, and fuzzy extraction, where T h , T rg , T pu f , and T f are 0.23 ms, 53.9 ms, 12ms, and 2.68 ms, respectively. Table 4 briefly shows the comparison results. Table 4. Computation cost of login and authentication phase.

Results of Comparison
The results of the comparative analysis of PUFTAP-IoT and other papers in terms of security, computation cost, and communication cost are as follows. Although PUFTAP-IoT has a higher computational cost compared with authentication protocols in other papers, the communication cost is similar or lower. Moreover, from a security point of view, PUFTAP-IoT is safe against a variety of attacks and can provide security for guessing, brute-force, and device capture attacks using three-factor, PUF, honey_list, etc. Therefore, PUFTAP-IoT can provide very secure services to service users in the IoT environment, even though the computation cost is higher than other authentication protocols.

Conclusions
With the development of WSN and IoT, areas using IoT are gradually expanding. Therefore, a secure authentication protocol is required to provide secure IoT services. In this paper, we analyze the security vulnerabilities of two-factor and three-factor authentication protocols in various IoT-based environments. To compensate for the security vulnerabilities of these protocols, we proposed PUFTAP-IoT, which applied PUF, honey_list, and threeelement technology. We used BAN logic to prove that PUFTAP-IoT can provide secure mutual authentication. We also demonstrated that PUFTAP-IoT can achieve Sean key security through the ROR model. In addition, the scyther simulation tool was used to show that the proposed protocol is safe against various attacks in a wireless network environment. In addition, as a result of the performance analysis of the protocol, it was found that it provides a more secure service in the IoT environment compared with other authentication protocols. In conclusion, PUFTAP-IoT is safer for real-world applications in IoT environments than other related technologies. In the future, based on the proposed protocol, we will analyze the network delay and through put of the protocol through programming and simulation and apply the developed protocol to the real environment to develop better protocols.