T2T-MAP: A PUF-Based Thing-to-Thing Mutual Authentication Protocol for IoT

As security has always been an afterthought of innovation, the security of IoT (Internet of Things), in general, and authentication, in particular, has become a serious research challenge. Although many authentication protocols have been proposed in the literature during the past decade, most of them do not fulfill the IoT security and performance requirements. Furthermore, only a very small number of these protocols can be used in Thing-to-Thing (T2T) architectures, where Things autonomously authenticate each other without involving any human intervention. In this paper, we propose a novel lightweight T2T mutual authentication protocol (T2T-MAP) using PUFs (Physical Unclonable Functions). The protocol employs PUFs technology to allow each Thing to uniquely identify and authenticate itself in an IoT infrastructure by using the physical randomness of its circuitry. We design the protocol and perform a security analysis to show that it is secure against known attacks. Also, we prove the security of the protocol using a security protocol prover. Finally, we implement a prototype of the protocol on resource-constrained devices and then conduct a performance analysis to demonstrate that the protocol allows fast authentication, reasonable communication overhead, and low energy consumption.


I. INTRODUCTION
IoT (Internet of Things) allows the interconnection of an exponentially increasing number of heterogeneous devices, called Things. This interconnection expands the classical network of the Internet from a Machine-to-Machine (M2M) communication system to a Thing-to-Machine (T2M) and Thing-to-Thing (T2T) communication system. This has allowed the emergence of various smart applications and new ubiquitous Internet services in various fields. However, this important evolution of the Internet to a heterogeneous infrastructure has unfortunately invited cybercriminals to exploit the new infrastructure and mount distributed and devastating cyberattacks at large-scale as well as at local-scale [1]- [7]. These cyberattacks have demonstrated to the community how catastrophic and diversified cybercrimes could be in a world where everything is perceived as a connected computer [8].
Interestingly, most of these cyberattacks, if not all, are due to security vulnerabilities in the adopted authentication protocols. In fact, as the service of authentication constitutes the The associate editor coordinating the review of this manuscript and approving it for publication was Fung Po Tso . spine of all security properties, 1 any weakness residing on the adopted authentication mechanism will turn the system into a brightening target for cybercriminals to conduct cyberattacks. Moreover, it is important to note that in this new type of heterogeneous networks, the impact of cyberattacks is not limited to information being stolen as in classical systems but may also include the loss of human lives [8]. Therefore, more research is required to develop new authentication protocols that are secure and reliable by-design and conform to IoT security and performance requirements.
The challenge of designing and developing secure and reliable authentication protocols for IoT has become mature and well-known to the research community. Many research works have been conducted for this purpose. In fact, ten years after the emergence of IoT (i.e., early 2010), a large number of authentication protocols, known as lightweight protocols (sometimes ultra-lightweight), were designed and proposed for various IoT wired or wireless infrastructures (e.g., Cloud, VANETs, MANETs, and WSNs [74]), and IoT applications (e.g., smart healthcare, home automation, and smart transportation) [67]. These protocols relied on the application of classical cryptographic mechanisms, where some of them adopted ECC (Elliptic Curve Cryptography), while others employed lightweight cryptographic operations, such as simple hash functions and bitwise logical operators. However, these protocols suffer from some known vulnerabilities that are related to the incorrect usage of classical cryptographic mechanisms, which has resulted in the re-occurrence of known cyberattacks but with an IoT flavor. In addition, as IoT aims to transform everything into a connected computer, Things are most likely going to be autonomously communicating with each other without any human intervention. This form of communication, commonly known as T2T, constitutes a fundamental communication scheme that future IoT communications tend to adopt. Unfortunately, we have observed that only a few authentication protocols were proposed in the literature for this particular communication scheme (i.e., T2T). The need for developing T2T authentication protocols that conform to IoT security and performance requirements has seriously increased.
There has been a noticeable convergence from the research community to develop lightweight and secure-by-design authentication protocols for IoT using PUFs (Physical Unclonable Functions) [11]- [25]. In fact, PUFs are physical one-way functions constructed from the unique nanoscopicstructure of physical objects (e.g., integrated circuits, crystals, magnets, lens, solar cells, or papers) and their reaction to random events. This intrinsic uniqueness in the structure and reaction is due to the idiosyncrasies in the manufacturing process of the objects. It allows not only the unique identification of an object but also its authentication. Furthermore, it is assumed to be impossible to clone the PUF of an object (and hence the object itself), which somehow can be perceived as a security-by-design that will prevent any possible impersonation and cloning attacks. Thus, PUFs are considered as a reliable and prominent physical security technology to develop lightweight authentication protocols for IoT. Moreover, various semiconductor companies have already adopted PUFs for securing their integrated circuits [58], [59]. Although PUFs are believed to have security-by-design, the feasibility of some attacks based on machine-learning [28]- [36] and sidechannel [36]- [43] has been demonstrated.
In this paper, we adopt PUF technology to design and implement a T2T lightweight mutual authentication protocol that has security-by-design for IoT. For short referencing, we attribute the name ''T2T-MAP'' (Thing-to-Thing Mutual Authentication Protocol) for the protocol. We first design the protocol and perform a security analysis to demonstrate the resilience of the protocol against known attacks. Also, we use a well-established security protocol verifier to automatically prove some security properties of the protocol. Then, we implement the protocol on low-cost devices, concretely, on Arduino development boards. We show that the proposed protocol performs efficiently in terms of execution time, communication overhead, and energy consumption.
Compared to the existing PUF-based authentication protocols [11]- [25], the proposed authentication protocol is secure against the attacks that were reported on those protocols as well as to known attacks [64]. Moreover, the proposed protocol adopts a new concept of extended challenge-response pairs (eCRPs) to obfuscate the classical structure of CRPs (cf. Section IV-A) and make the system resilient to CRPs disclosure and malicious insider attacks. In addition to that, the protocol uses the cryptographic concept of distributed value [9] to allow the transmission of PUF response in a secure way that prevents attackers from conducting modeling attacks. Furthermore, the protocol imposes to each authenticating party to use its embedded PUF circuit to establish mutual authentication, which enforces the service of nonrepudiation. Last but not least, the proposed protocol is purely lightweight (from a cryptographic perspective) by applying simple hash functions and logical bitwise operators.
To summarize, the main contributions of this paper are as follows: 1) We design T2T-MAP, a PUF-based mutual authentication protocol for IoT. We adopt the concept of eCRPs to make the protocol secure against CRPs disclosure, malicious insider, and modeling attacks. 2) We analyze the security of the protocol and discuss the resilience of the protocol to some known attacks. Moreover, we use Tamarin [65] to automatically prove the security of the protocol. 3) We implement T2T-MAP on resource-constrained devices and evaluate its performance with respect to the execution time, communication overhead, and energy consumption for different configurations. The remainder of the paper is organized as follows. In Section II, we provide a brief overview of PUFs and the concept of PUF-based authentication. In Section III, we review some recent PUF-based authentication protocols. In Section IV, we design a T2T PUF-based authentication protocol for IoT. Section V discusses the proposed protocol properties and analyzes its security against attacks. Also, a formal security analysis using Tamarin is conducted in the same section. In Section VI, we implement the protocol and conduct a performance analysis on the protocol. We conclude the paper in Section VII.

II. PUFs (PHYSICAL UNCLONABLE FUNCTIONS)
PUFs (Physical Unclonable Functions) 2 are physical oneway functions constructed from the unique nanoscopicstructure of physical objects (e.g., integrated circuits, crystals, magnets, lens, or solar cells) and their reaction to random events. It allows not only the unique identification of an object but also its authentication. In fact, when a given PUF is excited with a random event, called challenge, the function returns a unique, unpredictable, and reproducible response. The set of all possible challenges and their corresponding responses is often referred to as the CRPs (Challenge-Response Pairs).
Among the recently explored security applications of PUFs, the development of on-the-fly and lightweight authentication protocols. These protocols would provide security for resource-constrained devices without having the devices to store any credentials on their limited non-volatile memories. This for example makes them resilient against physical invasive attacks [61]- [63].
To exploit the advantages of PUFs for integrated circuit authentication in general, and device authentication in particular, a typical challenge-response-based protocol is adopted [27]. The protocol consists of two main phases, the registration phase (a.k.a., enrolment phase) and the verification phase (a.k.a., authentication phase). During the registration phase, a device is enrolled in a database (a trust center) by registering pairs of challenges and responses (CRPs), generated from the PUF that is embedded in the device's circuit. Therefore, each registered device d id will have its proper set of challenge and response pairs in the database id = {(c 0 , r 0 ), . . . , (c n , r n )}. The authentication of a registered device d p (a.k.a., prover) by another device d v (a.k.a., verifier) consists of having device d v randomly select one CRP, e.g., (c i , r i ) ∈ p , and interrogate the device d p by sending the challenge value c i and obtaining the corresponding response r i . Once the response r i is received, d v compares it with the registered response r i . If both responses are identical (or closely identical), i.e., r i r i , the device d p is authenticated, otherwise, it is rejected.

III. RELATED WORK
There has been a considerable number of research work aiming to develop PUF-based authentication protocols for IoT (Internet of Things) applications. These protocols apply different types of PUFs and aim to provide Things with a secure-by-design authentication mechanism that is resilient to classical attacks as well as to attacks that are particularly related to PUFs. In the following paragraphs, we briefly review some recent PUF-based authentication protocols. Also, the detail of the attacks that we mention for each related work is discussed in [64] and [71]. TABLE 1 summarizes the difference between the reviewed PUF-based authentication protocols. The protocols are compared using six characteristics (Column 2 to 7): (1) Used PUF, shows the type of PUF being used for the implementation of the authentication protocol referred in Column 1. (2) Authentication scheme, indicates the considered architecture to be either a Thing-to-Thing, in the sense resource-constrained to resource-constrained device, or a Thing-to-Machine, in the sense resource-constrained device to a resourceful device architecture. (3) Properties C1, C2, C3, and C4, mean whether the referred protocol uses PUFs on both parties, is lightweight from a cryptographic perspective, scalable, and allows the establishment of cryptographic keys, respectively. (4) Implementation platform specifies the type of hardware used to implement the PUF and the communicating parties. (5) Evaluation, in terms of security C5, performance C6, and circuit size C7. (6) Possible attacks indicate the different attacks that can be generated on the referred protocol as demonstrated in [64] and [71].
In [11], Boyapally et al., proposed a PUF-based authentication protocol for smart meters in the context of smart grid applications. The protocol allows a smart meter to be authenticated to a server using PUFs. It adopts the DAPUF (Double Arbiter-PUF) [10] augmented with a linear feedback shift register (LSFR) module. They discussed the security of the protocol and showed that it is resilient to man-in-the middle attacks as well as to PUF-modeling attacks. Nevertheless, the security of this protocol can be easily breached and the server can be impersonated. We showed in [76] how the security of the protocol can be broken. In [12], Bansal et al., proposed a PUF-based authentication protocol with key establishment for vehicles-smartgrid infrastructures. A formal security analysis was performed using Mao-Boyd Logic to prove the security of their protocol. However, the protocol was shown to be vulnerable to spoofing and message forging attacks. Qureshi and Munir [13] proposed a PUF-based identity-preserving authentication protocol for T2M authentication scheme. The protocol uses shuffling techniques to store obscured and uncorrelated information about the registered devices' PUFs instead of storing plaintext CRPs (Challenge-Response Pairs). The authors showed that the protocol is reliable and resilient to machine-learning attacks. Unfortunately, the protocol was shown to be vulnerable to replay and DoS attacks. Also, the protocol has a security single point of failure that allows the entire system to be compromised. Yanambaka et al. [14] proposed an FPGA PUF-based authentication protocol for medical IoT devices. It applies an obfuscation technique to perform authentication without CRPs disclosure. Notwithstanding, the security of the protocol was not assessed. The protocol contains vulnerabilities that can be exploited to generate attacks, such as machinelearning, CRPs disclosure, and replay attacks.
In [15], Nozaki and Yoshikawa, proposed a XOR-arbiter PUF-based one-way authentication protocol that is resistant to machine-learning attacks. It adopts the notion of distributed value [9] to obfuscate the PUF responses when being challenged and allow provers to store partial information about the CRPs of others. Also, it reduces the prediction rate for a successful machine-learning attack when a PUF is challenged. However, no security evaluation was conducted. The protocol is vulnerable to spoofing and CRPs disclosure attacks. In [16], Chatterjee et al., proposed a PUF-based authentication protocol for IoT. The protocol allows an IoT device to get authenticated to a verifier by using its proper PUF and applying elliptic curve operations, pairing operations, and a hash function. A prototype of the protocol was implemented for a video surveillance application and an informal security analysis was performed. Nevertheless, the protocol is vulnerable to DoS and impersonation attacks. In [17], Liang et al., developed a PUF-based authentication protocol for RFID systems in the context of IoT. The protocol allows an RFID-tag to be authenticated to a back-end server. The authors used BAN (Burrows-Abadi-Needham) logic to prove the correctness of the protocol and performed an informal security analysis of the protocol with respect to modeling attacks, man-in-the-middle attack, replay attack, CRPs exposure, and spoofing attacks. A performance analysis was also performed. However, the protocol was found to be vulnerable to de-synchronization, CRPs disclosure, and spoofing attacks. Kim et al. [18] proposed a PUF-based authentication protocol for device-server authentication. Nonetheless, the security of the protocol was not evaluated. Also, it was shown that the protocol is vulnerable to CRPs disclosure, key disclosure, and DoS attacks. In [19], Mahalat et al., proposed a PUF-based authentication protocol for secure Wi-Fi authentication of IoT devices. The protocol is adapted for a T2M authentication scheme. Notwithstanding, similar to other protocols, it has been demonstrated to be vulnerable to spoofing, CRP disclosure, and DoS attacks. In [20], Mughal et al., proposed a PUF-based authentication protocol, called PAS (PUF-based Authentication Scheme), for smart devices in IoT smart home applications. The protocol allows users, equipped with smartphones, to be authenticated to a gateway so that they can send command-messages to connected smart devices (e.g., a lightbulb or thermostat). Notwithstanding, the protocol is vulnerable to message forging, key disclosure, and DoS attacks.
Barbareschi et al. [21] proposed the PHEMAP (PUF-based Mutual Authentication Protocol), an SRAM PUF-based mutual authentication protocol for T2T authentication schemes. The protocol strongly relies on synchronization to operate correctly. For that reason, it has been shown to be vulnerable to desynchronization and DoS attacks. In [22], Yilmaz et al. proposed an arbiter PUF-based authentication protocol for T2M authentication scheme. Based on the use of a neural network model of the PUF, the protocol allows a verifier to authenticate a prover without having to store the CRPs on the verifier's memory. The protocol makes use of a device MAC address and a timestamp to obfuscate the PUF response by applying the RC5 cipher. However, the security of the protocol was not evaluated. Also, the protocol is vulnerable to insider spoofing attacks, CRP disclosure, and RC5 cracking. Feng et al., [23] proposed a PUF-based lightweight attestation and authentication protocol, called AAoT, for IoT and cyber-physical systems. The protocol uses PUFs along with fuzzy extractors to derive a secret key that is used to establish mutual authentication between devices. However, the security of the protocol was neither discussed nor assessed. The protocol was proven to be vulnerable to spoofing, CRP disclosure, and replay attacks. Idriss and Bayoumi [24] proposed a PUF-based authentication protocol with a key exchange for resource-constrained systems, such as RFID systems. The protocol relies on a challenge-challenge scheme to establish authentication. The authors analyzed the security of the protocol against guessing and challenge collection attacks. Nevertheless, the protocol was pointed out to be insecure against spoofing, manin-the-middle, and CRP disclosure. Clupek and Zeman [25] proposed a PUF-based mutual lightweight authentication protocol for T2T authentication schemes. It uses a third trusty party (TTP) as a trusted authority to establish a robust authentication between Things. It relies on the use of low-cost PUFs, simple hash functions, and the binary eXclusive-OR operator. The authors have claimed that the protocol is secure and provides security services. However, it was demonstrated that the protocol is vulnerable to certain secret disclosure, message forging, and modeling attacks.
Some more recent work have proposed PUF-based authentication solutions to solve the PUF-related challenge of not exposing the CRPs during authentication or storage (a.k.a., AA protocols). For example, Chatterjee et al., [72] proposed 3PAA, a private PUF-based protocol for anonymous authentication. The protocol relies on the concept of zeroknowledge and elliptic curve cryptography (ECC) to allow k-times anonymous authentication of users to an application provider (AP) through a trusted party (group manager, or GM) without revealing the CRPs. This makes the system more resilient to PUF modeling attacks. The protocol was implemented and the security of the protocol was formally verified. A performance evaluation was also conducted. However, the protocol does not enforce mutual authentication between a user and an application provider. The protocol only allows the application provider to verify the authenticity of the user, whereas the latter has no ability to verify that it is communicating with the legitimate application provider and not with an attacker. Hence, if the AP is compromised, it may allow a particular user to authenticate and use the service VOLUME 9, 2021 more than k times. In T2T-MAP, the mutual authentication and non-repudiation are guaranteed using PUFs. That is to say, each party can verify that it is communicating with the legitimate counterpart as we discuss in Section V. Additionally, the application provider is vulnerable to a spoofing attack. In fact, an attacker can impersonate the application provider and run the tracing phase to remove the access log entry of a victim user from the GM. To that end, the attacker intercepts an authentication session between the victim user and the application provider and use the messages to initiate the tracing procedure. In this procedure, the attacker does not have to authenticate itself to the GM as the legitimate application provider. The GM just checks the value of the parameter that the attacker obtains after intercepting the authentication session. As a consequence to this attack, the GM removes the access log entry of the application provider for the user, which would cause inconsistencies in the system.
Braeken [73] proposed another method to provide authentication between two IoT devices using PUFs and a common trusted cluster node, where the CRPs are not exposed. Nevertheless, in the context of our paper, this research work as well as the work in [72] are not lightweight from the cryptographic perspective as they adopt elliptic curve cryptography (ECC). Moreover, their protocols' performance evaluation is conducted using non-resource constrained hardware, such as the Intel i5 processors, which we believe cannot be used to conclude that a protocol would provide similar performance on resource-constrained devices such as the ones we consider in this paper (i.e., Arduino boards).

IV. THE PROPOSED PROTOCOL (T2T-MAP)
In this section, we propose T2T-MAP, a secure lightweight T2T PUF-based authentication protocol for IoT (Internet of Things). It allows two Things to mutually authenticate each other through a central gateway. We start by introducing the concept of eCRPs (extended CRPs) that T2T-MAP uses for authentication. Then, we present the phases of T2T-MAP for its establishment. Next, we discuss the security and performance properties and analyze the security of T2T-MAP against known attacks. TABLE 2 reports a summary of the adopted notation in the T2T-MAP authentication protocol.

A. THE CONCEPT OF EXTENDED CRPs (eCRPs)
From the related work, we have learned that if the CRPs (Challenge-Response Pairs) of registered Things are stored on a verifier in plaintext, they are subject to physical invasion attacks where they can be disclosed. Also, if for each registered Thing a verifier stores a large set of CRPs, the whole system becomes less efficient and not scalable as Things have limited storage capacity. Therefore, to thwart these security and performance issues, we have adopted the following two approaches:

1) FIRST APPROACH
We have transformed the classical CRP structure from a 2-tuple (c, r) to a 5-tuple (x 1 , x 2 , x 3 , α 1 , α 2 ), which we have called the extended CRP, or eCRP for short. We denote the eCRP by the letter . For example, if a Thing T i stores an eCRP about Thing T j , we write i (T j ). The content of an eCRP i (T j ) consists of three challenge values, x i 1 , x i 2 , and x i 3 , and two obfuscated response values α ij 1 and α ij 2 . These obfuscated response values are computed using the challenges and the PUF functions of both involved Things as expressed in the following two equations, where i (·) and j (·) are the PUF functions of Thing T i and T j , respectively. and Under this form, the obfuscated response values α can only and exclusively be used by Thing T i and Thing T j , and cannot be used by either of them to impersonate the other (e.g., in case of a malicious insider). Also, if Thing T i is compromised, the values of α ij 1 and α ij 2 cannot be used by T k to impersonate Thing T i or T j .
We note that this method of obfuscating the response by combining two responses together into one single response is inspired by the concept of distributed value used in cryptography [9]. Also, the idea of using the PUF function of both authenticating parties to construct responses is inspired by the work of Yanambaka et al. [14].

2) SECOND APPROACH
Considering the limited storage-capacity of resourceconstrained devices, we only store one eCRP per Thing on a Thing's memory. That is, if a Thing T 0 is configured to authenticate n other Things T i =0 , it only stores n extended CRP. However, we note that the eCRP is constructed based on three classical CRPs as we have used three challenges, x i 1 , x i 2 and x i 3 , and computed the obfuscated response values of α ij 1 and α ij 2 by combining their responses. In anyways, this way of storing the eCRPs allows using a given challengeresponse pair more than once. In fact, it is not the case in classical PUF-based authentication protocols, where a strong PUF is required to generate a large number of CRPs, and each CRP has to be used only once.

B. T2T-MAP PHASES
Similar to all other PUF-based authentication protocols, T2T-MAP consists of two phases: the enrolment and the authentication phase. In this subsection, we present how the enrolment phase occurs in T2T-MAP, then show the verification and authentication. It is important to note that in addition to performing authentication, T2T-MAP allows the establishment of a symmetric cryptographic key between two Things once mutually authenticated.

1) ENROLMENT PHASE
This setup phase is conducted in a secure environment, where two Things (here the gateway is represented by a TABLE 1. This table summaries the differences between the reviewed PUF-based authentication protocols. Due to space limitation, we have entitled some columns with a numbered letter Ci , where C0: Authentication scheme (T2M or T2T), C1: Mutual authentication using PUFs (from both authenticating parties), C2: lightweight (no asymmetric cryptography and no pre-established keys), C3: Scalability, C4: Key establishment (for message authentication, confidentiality, and data integrity), C5: Security evaluation, C6: Performance evaluation, C7: PUF-circuit size evaluation. The details of possible attacks are discussed in Section III of [64]. In this table, the symbols , , and •, indicate Yes, No, and Possible, respectively. TABLE 2. Summary of the notation adopted in T2T-MAP authentication protocol.
Thing, e.g, T j ), T i and T j , are brought next to each other to exchange 3 challenges and reveal 2 obfuscated responses each. Both Things, T i and T j , start by generating random

2) AUTHENTICATION PHASE
This phase is illustrated by the MSC 5 of FIGURE 2, where we have set i = 1 and j = 2 for simplicity. The gateway is generally assumed to have more resources than Things. Although the gateway is also a Thing in the context of IoT, we rather prefer to explicitly call it a gateway instead of a Thing to make a difference in the resource-capabilities. The steps of the authentication are as follows: Step 1. T2T-MAP assumes that a Thing T i|j starts the protocol by sending a direct request for authentication to another Thing T j|i . This step is not illustrated in FIGURE 2. Then, Things T i and T j use the eCRP that is related to the gateway 5 MSC (Message Sequence Chart) is a graphical language for the description of the interaction between different components of a system. This language is standardized by the ITU (International Telecommunication Union) [75]. Step 2. The gateway G receives the challenges from both Things and applies its local PUF to compute the values of β for each Thing, as follows: and The gateway generates a nonce N 0 and then takes the first value β i0|j0 1 and hashes it along with the xor of its nonce N 0 and the corresponding Thing's nonce N i|j , i.e., computes H(β i0|j0 1 , N i|j ⊕ N 0 ). This hash is again hashed along with the nonces to compute the obfuscated response value . This value is the response of the gateway to the challenges.
Step 3. The gateway uses the extended CRP that is related to each Thing to retrieve the challenges x 0 1 , x 0 2 , and x 0 3 and applies the local PUF function to produce the responses 0 (x 0 1 ), 0 (x 0 2 ), and 0 (x 0 3 ), which are the challenges to be sent to Things. The gateway then constructs and sends two messages m 1 and m 1 that contain the identities of Things along with its identity, the nonces, the three challenges, the computed obfuscated response, and a hash value, denoted by H( * ), that is computed over the entire message for message integrity protection.
Step 4. Things receive the gateway's messages and start by verifying its integrity, i.e., H( * ). 6 Then, the extended FIGURE 1. The enrolment phase of T2T-MAP. During this phase Things T i (∀i ∈ N * ) and the gateway G exchange challenges and responses to construct each an extended CRP (a 5-tuple), denoted by i (T 0 ) ( 0 (T i ), respectively). The 5-tuple i (T 0 ) ( 0 (T i ), respectively) stores 3 challenges, x i 1 , x i 2 and x i 3 (x 0 1 , x 0 2 and x 0 3 , respectively), and 2 authentication values, α i 0 1 and α i 0 2 (α 0i 1 and α 0i 2 , respectively). These two values are computed using the locally generated challenges and the PUF functions of each authenticating party, i.e., i (·) of Thing T i and 0 (·) of the gateway G.
CRP is used to retrieve the value of α If both values are equal, the gateway is authenticated by both Things.
Step 5. Both Things then use the received challenges to apply their local PUF function and compute the corresponding responses, i|j ( 0 (x 0 1 )), i|j ( 0 (x 0 2 )), and i|j ( 0 (x 0 3 )). Using the computed values, both Things compute the values of β 0i|0j 1 and β 0i|0j 2 , as follows: β and β 0i|0j 2 Once computed, the value of β 0i|0j 1 is hashed along with the xor of the nonces and then hashed again with the nonces, i.e., H(H(β 0i|0j 1 , N i|j ⊕N 0 ), N i|j , N 0 ). A message m 2 (and m 2 ) is constructed using the identities of the authenticating parties, the nonces, the hashed response, and the hash of the entire message H( * ) for integrity protection. The message is then sent to the gateway.
Step 6. The gateway receives the messages m 2 and m 2 from Thing T i and T j , respectively. It uses the stored value Step 7. The gateway generates a secret random nonce L 0 and computes two additional values α 0i 3 and α 0j 3 using the following equation: Also, the gateway computes the values L 0 ⊕ H(α 0i|0j 3 ) and H(α 0i|0j 2 ) ⊕ α 0j|0i 2 , and then sends two messages m 3 and m 3 to Thing T i and T j , respectively. These messages contain the identity of the authenticating parties, the nonces, the value Step 8. Things receive the gateway's messages and start by verifying its integrity, i.e., H( * ). The extended CRP is used to retrieve the value of α . At this stage, both Things have a shared secret nonce L 0 as well as a part of the extended CRP of the other Thing. These two information will be used to establish a T2T authentication between T i and T j .
Step 9. In this step, both Things start authenticating each other. To that end, Thing T i|j that first initiated the protocol generates a key K then xores the key with the hash of the xor of the obfuscated response α 0j|0i 2 of Thing T j|i and the secret nonce L 0 , to compute the value K ⊕ H(α 0j|0i 2 ⊕ L 0 ). This value allows to securely send and share the key with the other Thing. Then, it uses the nonces and the secret nonce . This value allows authenticating the source of the message to be sent as well as to link this second part of the authentication to the first part that was performed with the gateway (through the use of the secret nonce L 0 ). These values are sent to the other party along with a message integrity code, i.e., H( * ).
Step 10. Upon the reception of the message from T i|j , Thing T j|i checks the integrity of the message, i.e., H( * ), and then uses the previously computed value β of Thing T i|j along with the key K to prove the correct key computation to Thing T i|j . Also, it computes the value H(H(α 0i|0j 2 , N ij ), N i , N j , L 0 ) for message source authenticity and sends these values along with the message integrity code.
Step 11. Thing T i|j receives the message of Thing T j|i (i.e., m 5 ) and starts by checking its integrity code, i.e., H( * ). Then it uses the previously computed value β It is important to note that the protocol has actually been designed to operate on two types of configurations: (1) Thing-to-Thing authentication through a gateway, and (2) Thing-to-Thing authentication without a gateway. The first configuration is the one proposed in this paper, whereas the second has been discussed in details in [71].
The reason for having two possible configurations is to make the authentication protocol suitable for a number of applications that require heterogeneous architectures and typologies. Here are some key differences between the two configurations: (1) In T2T without gateway configuration (Configuration 2), Things have to locally store authentication information about each other, whereas in T2T with gateway (Configuration 1), they only store authentication information about the gateway (the gateway stores authentication information about the Things). Therefore, Configuration 2 is suitable for scenarios where Things have the ability to locally store authentication information. It is also suitable in a scenario where the presence of a gateway is impossible (e.g., WSNs in hostile environment, jet fighters at higher altitudes, etc,). (2) Configuration 2 is more suitable for architectures that involve a higher mobility, whereas Configuration 1 is more appropriate for architecture with less mobility. (3) Configuration 1 allows a greater scalability than Configuration 2 due to the fact that Things do not store authentication information locally about all other Things. However, the current version of Configuration 1 uses one single gateway that may constitute a bottleneck when the number of Things increases. (4) Configuration 2 can be considered less risky than Configuration 1. In fact, the gateway is a third party that may constitute a security risk in the case where it is compromised (e.g., insider attack). (5) Configuration 2 is convenient for network paradigms where Things directly communicate and authenticate each other without a third party (e.g., a vehicle authenticating a road sign), whereas Configuration 1 is suitable for Things that communicate through a third party (e.g., in a smart homes application, a user uses its smartphone to authenticate with a smart thermostat through a Wi-Fi access point and regulate the room temperature).

V. T2T-MAP PROPERTIES AND SECURITY ANALYSIS
In this section, we discuss some security as well as performance properties of T2T-MAP. Next, we perform a security analysis on the protocol by discussing the resilience of T2T-MAP against some known attacks and then by formally proving its security using Tamarin security protocol prover.

A. PROTOCOL PROPERTIES
T2T-MAP provides a set of security and performance properties that conform to IoT security and performance requirements. In the following paragraphs, we present these properties:

1) LIGHTWEIGHT
From the cryptographic perspective, T2T-MAP is considered as a lightweight, if not an ultra-lightweight, authentication protocol for the following reasons: The protocol is based on the use of PUFs (Physical Unclonable Functions) to prove device identities. Moreover, it uses simple hash functions as well as the bitwise logical exclusive OR operator (XOR) to establish authentication and secret key FIGURE 2. Message sequence chart of T2T-MAP. This first part of the protocol allows only a mutual authentication of two Things to a gateway. The notation M x→y denotes a message M sent from x to y (where x, y ∈ {0, 1, 2}, 0 refers to the gateway G, 1 refers to Thing T 1 , and 2 refers to Thing T 2 ). The PUF of G, T 1 , and T 2 , are 0 (·), 1 (·), and 2 (·), respectively. Also, N 0 , N 1 , and N 2 , are three nonces generated by G, T 1 , and T 2 , receptively, ⊕ is the bitwise eXclusive OR operator, N ij is the XOR of the two nonces N i and N j (N ij = N i ⊕ N j ), and H(·) is the hash function. The variables x i 1 , x i 2 , and x i 3 , where i ∈ {0, 1, 2}, are challenges generated by a Thing T i , whereas α Furthermore, the lightweight property of the protocol covers the fact that the protocol allows a relatively low storage overhead (see scalability below), low communication overhead and energy consumption, as we will demonstrate in Section VI-B.

2) MUTUAL AUTHENTICATION
T2T-MAP provides mutual authentication. In fact, to establish authentication between three entities, each entity is required to use its own PUF function to generate authentication responses that will prove its identity.

3) SCALABILITY
The protocol can be qualified as scalable for the following reason. In terms of storage overhead, each individual Thing T i has to store 2n + 3 values, where n > 0 is the number of Things T j =i registered on Thing T i 's memory. For instance, each Thing T i stores only 5 values when n = 1. Each Thing will only store the eCRP of the gateway (the challenges x 1 , x 2 , and x 3 , are the same for all Things). Hence, if the variables are expressed in 32 bytes, each Thing will permanently have to store only 160 bytes, which is a reasonable overhead. This overhead grows linearly following the function f (n) = 2n + 3, where n > 0 is the number of registered eCRPs on a Thing.

4) KEY ESTABLISHMENT
T2T-MAP allows the establishment of a secret key at the end of the authentication. This key can be used for encryption (e.g., using ChaCha) and data integrity. The key is randomly generated during the authentication and immediately destroyed at the end of the session.

5) FRESHNESS AND LIVENESS
T2T-MAP protocol uses nonces for each authentication session, which makes, to some extent, each authentication session fresh and unique. This would prevent any replay attack using messages from a previous authentication session. Also, the protocol uses the nonce L 0 to allow Things T i and T j verify that the current communication is part of the previous communication with the gateway. This would prevent any session hijacking attempts.

6) AVAILABILITY
For the authentication protocol to be available at all times, each authenticating party has to have its authentication information, i.e., eCRPs, up-to-date. In the current version of T2T-MAP, the stored eCRPs are static and not updated, which would make the protocol always available (no desynchronization). However, following the security principles, these eCRPs need to be updated at some point. Thus, we assume the existence of a secure and frequent eCRP-updating procedure to allow Things to store and use new eCRPs. For example, this eCRP-updating procedure may consist of storing one additional eCRP per device during the enrolment phase and particularly use these additional eCRPs for the update procedure. This would prevent the possibility of forward securityrelated attacks as well as brute force attacks as discussed in the next paragraph.

7) FORWARD SECURITY
This property is strongly related to the lifetime of the used authentication information (e.g., the lifetime of an eCRP). If the lifetime is too long, an attacker would have enough time to brute force and disclose authentication information to perform the impersonation. For example, through a session hijacking attack (cf., next subsection), an attacker would be able to learn 50% of the eCRP of a given Thing T i (i.e., α 0i 2 ). Then, through brute-forcing and one single XOR-operation, the attacker will be able to learn the remaining part of the eCRP (i.e., α 0i 1 and α 0i 3 ). Using this information, the attacker can completely impersonate Thing T i during a future authentication session. Therefore, to mitigate this attack and provide forward security, we assume the existence of a secure eCRPupdating procedure that will allow Things to frequently and securely update the stored eCRPs.

8) NON-REPUDIATION
As PUFs are widely assumed to be unclonable functions and the authentication in T2T-MAP relies on the use of PUFs, we can claim that the security service of non-repudiation is guaranteed and enforced in T2T-MAP. Thus, no authenticating party can deny having participated in an authentication session.

B. SECURITY ANALYSIS
In what follows, the security strength of T2T-MAP against known attacks is discussed:  N ij ), N i , N j ). This obfuscation technique prevents eavesdroppers from collecting challenges and their corresponding responses during authentication to build a prediction model. Also, the base value of the challenges is not sent during authentication. In fact, what is being sent is the response from the local PUF for a challenge that is never revealed. For example, when Thing T 1 tries to authenticate the gateway, it sends the value 1 (x 1 1 ) and keeps x 1 1 confidential.

2) REPLAY ATTACK
A replay attack is prevented through the use of nonces. For example, throughout the authentication, three nonces are used: N 0 (generated by the gateway), N 1 (generated by Thing T 1 ), and N 2 (generated by Thing T 2 ). The obfuscated responses (i.e., β An attacker may think of intercepting some messages and using the same nonce N i|j to replay the messages and spoof Thing T i|j . This would be difficult, or impossible, for the attacker as the latter cannot force the other party, T j|i , to reuse the same nonce N j|i , used in a previous authentication session.

3) COMPROMISING GATEWAY/THING
If an attacker manages to gain access to the gateway or a Thing, it will not be able to infer and learn the eCRP of any other Thing. In fact, the eCRP, i|j (T j|i ), which is stored on Thing T i|j about Thing T j|i is information that is used by Thing T i|j to only verify the authenticity of Thing T j|i . It cannot be used in anyways by Thing T i|j to prove that it is Thing T j|i . Furthermore, an eCRP, i|j (T i|j ), is tightly-coupled to the two Things T i|j and T j|i , and cannot be used by another Thing T k (k = i = j).

4) SESSION HIJACKING
In this attack scenario, a malicious insider Thing, let us say T k , performs a legitimate authentication with Thing T i through the gateway and obtains the value α 0i 2 . As previously discussed, this value is used by Thing T i to prove its identity to another Thing T j . Then, after some time, the malicious Thing T k eavesdrops another authentication between the gateway and Things T i and T j . At the stage where the authentication with the gateway is achieved and both Things T i and T j have received from the gateway the information α 0i|0j 2 about the counterpart T j|i , the malicious Thing T k spoofs Thing T i and blocks its messages so that they do not reach Thing T j . At this point, the malicious Thing T k , can prove to T j that it is T i as it has the value α 0i 2 that it has learned from a previous legitimate authentication session. Therefore, to prevent such an attack, we have used the nonce L 0 of the gateway as an indicator of the current session. The value of L 0 is secretly shared among the legitimate parties. It will be used by the communicating Things, in this case T i and T j , to verify whether the received messages are somehow related to the authentication session that occurred with the gateway (liveness). Therefore, without the knowledge of L 0 , the malicious Thing T k will not be able to hijack the session.

5) INSIDER SPOOFING
A malicious Thing, say T k , could operate a legitimate authentication with another Thing, say T i , and obtain the response information α 0i 2 to spoof T i later on. In this situation, the malicious Thing will not be able to spoof T i as it has only one obfuscated response out of two obfuscated responses to prove that it is T i . In addition, the initial part of the authentication with the gateway requires the attacker the knowledge of the information α 0i 1 , which T k cannot obtain. Also, the value α 0i 1 is never sent in plaintext but always double hashed along with nonces.

6) BRUTE FORCING PUF-RESPONSES
As the nonces, N i and N j , are sent in plaintext during the authentication, an attacker may try to brute force the hash function H(·) to find the obfuscated response value that was generated by an authenticating party. This would depend on the size of the response. If the response is in n bits, the attacker has to try at most 2 n values before finding the response.
To make this attack difficult and infeasible, instead of using the obfuscated response as the first parameter for the hash where v ∈ {1, 2}, we send the hash along with nonces of the hash of the obfuscated response along with the xor of nonces, i.e., H(H(β If the attacker brute forces the transferred hash, it will find the value of H(β ij|ji v , N ij ), which needs to be brute-forced again to find the value of β ij|ji v . In this case, the attacker will face a time complexity of O(2 n+2 ) to be able to disclose the eCRP of a particular Thing T i . Also, if the attacker (compromised Thing T j ) applies the session hijacking approach to learn the value of α 0i 2 of Thing T i =j , the attacker will have to brute force a time complexity of O(2 n+1 ). Therefore, we recommend the use of a bit-length of at least 64-bit (i.e., 8 bytes) for the response values so that the brute force attack on the hash function will be infeasible. This would eventually prevent the replay attack.

7) SECRET KEYS DISCLOSURE ATTACK
During the authentication, the protocol allows the communicating parties to establish a secret key to be used for encryption and/or data integrity. This key is immediately destroyed at the end of the communication. Therefore, the key is generated only when needed and erased once the session VOLUME 9, 2021 is terminated, which means that no secret keys are present permanently on the devices. This allows the devices to be resistant to any physical key disclosure attacks.
In addition to the above informal security analysis, we have used Tamarin [65], a well-established software tool for security protocol verification and theorem proving, to formally prove the security of T2T-MAP. To that end, we have implemented T2T-MAP in Tamarin's protocol specification language. This basically consists of writing rules of facts and lemmas. In fact, Tamarin models protocol's set of executions as a labeled transition system (LTS). The states of the LTS are multisets of facts formalizing the local states of the authenticating party running the protocol, the attacker's knowledge, and the exchanged messages. The transitions of the LTS are formalized using rules. Lemmas however, are used to express security properties, e.g., secrecy, to be verified by the tool in order to claim the security property for the protocol. The specification code of the protocol (a.k.a., the security protocol theory in Tamarin) consists of +/−216 lines of code. It can be accessed online at [66].
Next, based on the design of the protocol as well as on the above security analysis, we can observe that the security of T2T-MAP strongly relies on the secrecy of the following variables: The shared nonce L 0 (generated by the gateway). (4) The shared key K . Therefore, we can claim that if these variables are kept secrete and not disclosed to the attacker in anyways, then the protocol cannot be compromised. To verify this claim using Tamarin prover, we have written lemmas to express the secrecy of the aforementioned variables and prove whether the lemmas are always true. After executing the verification of the lemmas on Tamarin (which took around +/−3 seconds on a DELL Precision T7500 having an Intel Xeon E5507 at 2.27GHz CPU and 6GB of RAM, and running Linux Ubuntu LTS 20.04 Operating System), the tool proved the lemmas to be always true. This means that there exist no possible execution for the protocol that leads to the disclosure of any of those variables.

VI. PROTOCOL IMPLEMENTATION AND EVALUATION
In this section, we present the implementation detail of T2T-MAP and then evaluate its performance w.r.t. different protocol configurations.

A. PROTOCOL IMPLEMENTATION
To implement T2T-MAP, we have used Arduino development boards as low-cost and resource-constrained devices. We have specifically used two types of Arduino boards, namely, the Arduino Mega 2560 (R3) and the Arduino DUE. These two boards embed different microcontrollers of different processing and storage capacity as illustrated in TABLE 3. Also, we have used different configurations for the protocol with respect to the size of the challenges, the responses, the nonces, and the hash outputs. In this subsection, we present how we have implemented the PUF function, the eCRPs (extended CRPs), the communication, and the protocol code.

1) PUF IMPLEMENTATION
As there exist many types of PUFs, in this paper, we do not use a particular PUF. Also, we do not design or implement a new one either. We rather consider the use of an abstract PUF and keep the protocol as generic as possible. For the sake of this implementation, we have adopted the BLAKE 8 hash function that is available in the Arduino Cryptographic Library 9 to emulate the abstract PUF as well as the hash function H(·) used in the protocol. We emphasize that the abstraction is only to implement a generic prototype of T2T-MAP so that performance analysis can be performed. Researchers can use any type of PUF to build their own version of the authentication protocol.
Nevertheless, to use a hash function instead of a PUF to implement the protocol and perform a performance evaluation (in particular, in terms of execution time and energy consumption). We need to verify that the execution time of a PUF as well as its energy consumption are negligible w.r.t. a hash function execution time and energy consumption. This has been verified w.r.t. the results reported in [55]- [57]. In anyways, a hash function will be used to provide the desired output size and allow the use of a PUF function that requires a small area size and produces outputs of smaller sizes.

2) eCRPs IMPLEMENTATION
We have used random nonces as challenges and the hash of the nonces as their corresponding responses. Also, we have used different sizes, namely, 8 bytes, 16 bytes, and 32 bytes, for the challenges and responses, so that we can study the performance of the protocol when the sizes are changed (e.g., when upgrading the security level). The Arduino Cryptographic Library provides a random number generator to generate nonces of arbitrary sizes. Thus, for an n-bit configuration, we have used the random number generator to  generate nonces in n bits and feed the BLAKE hash function to produce their corresponding responses, which are also in n bits.

3) COMMUNICATION IMPLEMENTATION
To allow different boards to communicate with each other, we have used the embedded serial communication medium, which is also known as the URAT (Universal asynchronous receiver-transmitter) system. In fact, on each programming board, there exist some GPIO (General Purpose Input/Output) pins that are dedicated for communication, namely, TXD for transmission and RXD for reception. 10 Thus, to connect two development boards through the serial medium, the TXD pin of one board has to be connected to the RXD pin of the other board and vice-versa. Additionally, their ground pins (GND) have to be connected to each other. Such wiring is illustrated in FIGURE 4. Furthermore, for the communication speed, we have set the serial communication rate to 200000 baud, which is around 200kbps.

4) PROTOCOL CODE
For the protocol to run over an Arduino board, the protocol has to be first written using C/C++ programming language and then compiled for a specific Arduino board (e.g., Arduino Mega 2560 R3) using the Arduino IDE v1.8.13. The protocol, as well as the firmware, are then uploaded and written into the 10 Note that other GPIO pins (e.g., from 2 to 13) can also be configured to be used for communication through a software library, e.g., SoftwareSerial.  TABLE 4 reports the size, in KB, of the sketch (code) of the protocol for each Arduino development board, node (Thing T 1 , Thing T 2 , and Gateway), and for different size of the variables, i.e., challenges, responses, nonces, and message integrity codes. 11 We have noticed that the code of the gateway is larger than the code of Things (T 1 and T 2 ). This is because the gateway has to communicate with two different Things during a given authentication session. The size of the programs should not necessarily increase by increasing the size of the variables. In fact, the impact of increasing the size of the variables is related to the amount of SRAM (central memory) that will be used to execute the program, which will increase by increasing the size of the allocated variables.

B. PROTOCOL EVALUATION
In this subsection, we evaluate the performance T2T-MAP in terms of execution time, communication overhead, and power consumption, in the ideal case, i.e., no attackers.

1) EXECUTION TIME AND ENERGY CONSUMPTION
To evaluate the execution time of T2T-MAP, we use a digital oscilloscope and plot the voltage/current variation over time on a given development board. Having the plot of voltage/current over time, we can identify the portion of the signal that represents the execution of the protocol and measure its time duration. This would give us the execution time of the protocol on the measured board. However, we note that measuring the execution time using the oscilloscope can be performed as part of the energy consumption evaluation process. Therefore, in the next paragraphs, we present the energy consumption evaluation process and perform the execution time measurements at the same time.
To compute the electrical energy consumed by each Thing (or board) during t seconds, we apply the Joule's law as follows, where E is the energy in Joule, V is the supplied voltage in Volt, I is the intensity of the current flowing to the board in Ampere, and t is the time in Second: Hence, to calculate the energy that is consumed during the execution of T2T-MAP, we need to know the voltage that is being supplied to the board, the intensity of the electric current flowing within the board during the execution of T2T-MAP, and the execution time of the protocol. The supplied voltage is the operating voltage of the boards. According to the boards' specifications, it is 5V for the Arduino Mega and 3.3V for the Arduino DUE. The execution times of T2T-MAP, for different configurations, can be determined from the voltage/current plot over time as we will see later.
The intensity of the electrical current, however, needs to be measured during the execution of T2T-MAP. To that end, we use the Tektronix MSO3014 digital storage oscilloscope to measure the intensity of the current.
To measure the intensity of the electrical current flowing within the board during a period of time using an oscilloscope, we can apply one of the following two approaches: (1) We connect a resistor in series to the power cable of the board. Then, we connect the oscilloscope's voltage probe cable to both resistor's extremities to measure the voltage drop between the resistor. Having the measured voltage drop V and the known resistor's capacity R, we apply the Ohm's law (V = R × I ) to calculate the intensity of the electrical current I . (2) We connect the oscilloscope's current probe cable directly to the power cable of the board and measure the intensity of the electrical current that is flowing through it. Although the second approach is straightforward, we have adopted the first approach due to the unavailability of the oscilloscope's current probe cable in our laboratory. Thus, we have used the oscilloscope to measure the voltage drop over a 10 resistor and set up the oscilloscope to automatically apply the Ohm's law. This visualizes the current flow instead of the voltage drop (viz., FIGURE 5).
Practically, to measure the intensity of the current during the execution of T2T-MAP with high precision, we need to identify the part of the signal, i.e., the signal of I (t), during which the authentication protocol is executing. To that end, we have reprogrammed each Thing (board) in such a way so that the board performs the following operations: (1) Booting.
(2) Stay idle for τ ms. (3) Turn an LED light ON for τ ms and then turn it OFF. (4) Execute the protocol. (5) Turn the LED light ON for τ ms then turn it OFF. For the Arduino Mega board the duration of τ is 1000ms, whereas for the Arduino DUE it is 200ms. This is due to the considerable difference in the execution speed of T2T-MAP on both boards. In this way, we can identify the portion of the signal during which the protocol is executing. FIGURE 6 and FIGURE 7 illustrate the execution of the protocol's code on the Arduino Mega and Arduino DUE boards for variable sizes 8 bytes, 16 bytes, and 32 bytes, respectively. We note that these figures have been generated using a sampling rate of 100 samples per second. We can observe in FIGURE 6 that the Arduino Mega board draws an M-shaped current intensity during its boot phase (approximately within the first 1 second). Then the current intensity drops down for another 1 second during the board idle state. The current intensity jumps up when the LED light is turned ON for a duration of 1 second. Then, it drops down during the protocol execution. Once the protocol terminates, the current intensity jumps up again due to the lighting of the LED for another 1 second before it turns OFF. At this point, we can easily identify that the part of the signal that represents the execution of the authentication protocol is the part of the signal where the current intensity has dropped down between two consecutive lightings of the LED. The same can be observed in FIGURE 7, except that the Arduino DUE board draws a V-shaped current intensity during its boot phase instead of M. Schematically, the part of the signal that represents the execution of the authentication protocol is situated within the two dashed vertical lines on both figures.
We have performed at least 50 consecutive executions to compute the average time for the protocol to execute on each board. We have measured the time length of the parts of the signal that represents the execution of T2T-MAP with the help of the oscilloscope's cursors. FIGURE 8 illustrates the average execution time of T2T-MAP for different variables sizes (8,16, and 32 bytes), and for both the development boards, i.e., Arduino Mega 2650 and Arduino DUE. Also, it is important to note that the execution time of the entire authentication protocol is expressed by the execution time of Thing T 1 as the latter is the last Thing that finishes the execution of T2T-MAP.
In the case of the Arduino Mega 2650 (R3), the entire protocol (authentication and key derivation confirmation) requires an average execution time of 214.20ms, 270.20ms, and 348.40ms, when the variables size is 8, 16, and 32 bytes, respectively. It is important to bear in mind that T2T-MAP involves the mutual authentication of three communicating parties, i.e., Thing T 1 , Thing T 2 , and gateway G, as well as the establishment of a symmetric key.
Also, the authentication of Thing T 1 and T 2 with respect to the gateway is processed sequentially (T 1 then T 2 ). Although the authentication execution would run faster if the authentication requests are processed in parallel, we decided to keep the processing sequential for simplicity. More importantly, the hardware platform on which the protocol is running is an 8-bit microcontroller that runs at a speed of 16MHz with 8KB of SRAM. Thus, for a resource-constrained platform like this one, the obtained execution time is reasonably acceptable. In the case of the Arduino DUE, however, the protocol runs faster. It requires an average execution time of 14.76ms, 27.58ms, and 65.00ms, when the variables size is 8, 16, and 32 bytes, respectively. In this second experiment, the protocol runs faster as the hardware platform is a 32-bit microcontroller that operates at a speed of 84MHz with 96KB of SRAM. Although this hardware configuration is still not that powerful, the average execution time of the protocol is excellent. In both cases (i.e., Arduino Mega 2650 and Arduino DUE), the execution time has increased when we have increased the size of the variables from 8 bytes to 16 bytes, and then to 32 bytes. This is totally normal as each board on a given configuration has to process more bytes than in a previous configuration.
If we consider Arduino Mega 2650 board, we can observe that the 16-byte configuration is around 26% slower than the 8-byte configuration, but 100% more secure. Hence, it is worth to sacrifice around 56ms more time for the execution of the protocol to guarantee double security. Moreover, the 32-byte configuration is around 29% slower than the 16-byte configuration, but 100% more secure. For double security, the choice of a 32-byte configuration would be straightforward. Also, although the 32-byte configuration is around 62% slower than the 8-byte configuration, it offers a security strength that is four times stronger than the security of the 8-byte configuration (200% more secure), which confirms our previous choice. Nevertheless, on Arduino DUE board, we can see that by doubling the size of the variables, the execution time doubles. Hence, the choice of a configuration will depend on the application constraints. Although, the 8-byte and the 16-byte configurations are 200% and 100%, respectively, slower than the 32-byte configuration, the latter offers a stronger security with an acceptable execution time (∼ 65ms).
Next, we have measured the intensity of the electrical current during the execution of T2T-MAP as follows: We have recorded the current intensity values during the protocol execution phase using a sampling rate of 500k samples per second. Then, we have computed the average value of the current intensities.
We have found that that the average electrical current intensity used by Thing T 1 , Gateway G, and Thing T 2 , is 87mA, 75mA, and 79mA, respectively, when the Arduino Mega board is being used. However, it is 57mA, 61mA, and 58mA, when the Arduino DUE board is being used. At this stage, knowing the average current intensity used by each Thing (board) during the execution of the protocol, and knowing the amount of time needed to execute the protocol, we have computed the amount of energy that is consumed by each Thing during the execution of the protocol  by applying the Joule's law (viz., Equation 10). TABLE 5 reports the energy consumed by each Thing during the execution of the protocol, on both boards, and for different variable sizes. These results express a low power consumption that is reasonably suitable for resource-constrained devices. On the Arduino DUE board, we can clearly observe a low power consumption, which does not go upper than 13mJ, when the maximum variable size configuration is adopted (i.e., 32 bytes).

2) COMMUNICATION OVERHEAD EVALUATION
In this subsection, we analyze the communication overhead of T2T-MAP during its execution for different variable sizes. TABLE 6 reports the size, in bytes, of the messages that are exchanged during T2T-MAP execution for both platforms and for different variable sizes. The size of the messages doubles along with the size of the variables. For example, message m 0 that is sent from Thing T 1 to the gateway has a total size of 40 bytes when the variables are expressed in 8 bytes. This size doubles to 80 bytes when the variables are expressed in 16 bytes, and to 160 bytes when the variables are in 32 bytes. FIGURE 9 illustrates the number of bytes each authenticating party sends during the authentication. The number of bytes sent by Thing T 1 and Thing T 2 is equal. The gateway, however, needs to send almost the double of what both Things send during the execution of the protocol as the gateway needs to communicate with both Things. Overall, the protocol requires 432 bytes (3456 bits), 864 bytes (6912 bits), and 1728 bytes (13824 bits), when the size of the variables is 8 bytes, 16 bytes, and 32 bytes, respectively. These amounts of bytes are reasonably acceptable for a resource-constrained environment where the network bandwidth is limited. In fact, as we aim to implement the protocol in an IoT application that uses a short-range wireless technology (e.g., Wi-Fi, Bluetooth, or ZigBee), the communication overhead would not be affected by the adopted technology. For example, if we consider the application of the 16-byte configuration on wireless networks such as Wi-Fi, Bluetooth,  or ZigBee, then each individual message of the protocol will fit within the payload of these technologies. Moreover, it is important to note that we have arbitrarily chosen that all fields (i.e., nonces, challenges, and hash function outputs) in a given message have the same size, either 8 bytes, 16 bytes, or 32 bytes. It is possible to express these fields in different sizes, which would certainly reduce the size of certain messages and improve the communication overhead.

3) DISCUSSION
In the following paragraphs, we discuss the security and performance features of T2T-MAP and compare them with protocols of the related work. T2T-MAP provides security as well as performance properties. For security, the protocol allows the mutual authentication of devices using their embedded PUF circuits. This important feature makes T2T-MAP more secure than the reviewed related work protocols, where the PUF is used only by one authenticating party. For example, by imposing the use of PUFs on each authenticating party, T2T-MAP enforces the service of non-repudiation. Also, the protocol allows the establishment of a secret key that will be used to provide message confidentiality and integrity. In addition, the protocol provides forward security and prevents replay attacks through the use of an eCRP-update procedure and fresh nonces, respectively. Furthermore, we have shown that most of the reviewed protocols (9 out of 15) are vulnerable to CRPs disclosure (e.g., during their storage or transmission) and PUF impersonation by malicious insiders. T2T-MAP thwarts these attacks by adopting the concept of extended CRPs along with the cryptographic concept of distributed value (cf., Section VI-A). Moreover, in Section VI-B, we have discussed its resilience against machine learning attacks, replay attacks, node compromising attacks, session hijacking, malicious insider spoofing, brute force attacks, and secret key disclosure. Additionally, we have used Tamarin security protocol verifier to automatically prove the security of T2T-MAP by proving the property of secrecy.
In terms of performance characteristics, T2T-MAP is a lightweight protocol that uses PUFs, simple hash functions, and the bitwise exclusive logical OR operator (XOR). Also, in the case where an encryption is used to secure the communications, lightweight ciphers, such as ChaCha, can be used to maintain the property of lightweightness. Also, we emphasis that the latter property expresses the low storage overhead, low communication overhead, and low energy consumption of the protocol. These important features allow the protocol to be adopted by resource-constrained devices. In addition, the protocol is considered to be scalable as it theoretically allows a large number of Things to be mutually and securely authenticated without any constraints.
We have implemented the protocol on resourceconstrained devices and evaluated the performance of the protocol w.r.t. execution time, energy consumption, and communication overhead, for three different configurations and under two different hardware platforms. T2T-MAP allows a mutual authentication of three parties (e.g., Thing T 1 , Thing T 2 , and gateway) to be performed in 214.20ms, 270.20ms, and 348.40ms, when variables (i.e., nonces, PUF's challenges, PUF's responses, and hash outputs) are expressed in 8 bytes, 16 bytes, and 32 bytes, respectively, on Arduino Mega boards. This authentication is even faster on Arduino DUE boards, where it takes around 14.76ms, 27.58ms, and 65.00ms, for its completion for the respective variable sizes. The execution times are within the range that is reasonably acceptable for resource-constrained applications. Also, compared to the execution times reported by the related work on resourceful hardware, we can claim that our protocol is highly competitive and provides fast authentication.
With respect to energy consumption, T2T-MAP shows reasonable results. Depending on the device (i.e., being Thing T 1 , Thing T 2 , or gateway), the energy consumption varies between 53.32mJ and 93.18mJ, 71.61mJ and 117.54mJ, and 91.32mJ and 151.55mJ, for the respective variable sizes on Arduino Mega boards. However, energy consumption is considerably lower on Arduino DUE boards as it varies between 1.35mJ and 2.77mJ, 1.89mJ and 5.19mJ, and 9.07mJ and 12.22mJ, for the respective variables sizes. These values are reasonably low for resource-constrained devices, such as the ones used in IoT infrastructures.
During the protocol communication, the bandwidth consumption reveals an acceptable overhead. In fact, the protocol requires the transmission of 208 bytes, 416 bytes, 832 bytes, for the respective variable sizes. This communication overhead is reasonably suitable for networks with limited bandwidths. It is possible to distribute the size of the variables in a non-uniform way where the different fields are expressed in unequal sizes. This would certainly improve the communication overhead as certain messages will have a smaller size.
To appraise the efficiency of our authentication protocol, we wanted to compare our performance results with the results of the related work. Nevertheless, we found that it was a very challenging task that may end up drawing unfair conclusions. In fact, we were not able to perform any consistent comparison due to the following reasons: (1) Many implementations from the related work use powerful devices that are not resource-constrained devices, which makes it unfair to compare with an implementation that is fully resource-constrained. (2) Most of the related work does not provide enough information about the configurations and the results. This leads to an incomplete comparison.
(3) Most of, if not all, related work, do not provide the complete structure of the messages that are exchanged during the execution of the protocol. Making random assumptions on the structure of the messages results in an unfair comparison.
Finally, we report in the first row of TABLE 1 the features and properties of T2T-MAP so that it can be compared to the ones of the related work PUF-based authentication protocols.

VII. CONCLUSION
IoT (Internet of Things) is a networking paradigm that allows billions of heterogeneous devices, called Things, to be connected to the Internet. This important evolution has and still expanding the classical network of the Internet from a Machine-to-Machine (M2M) communication system to a Things-to-Machine (T2M) and Things-to-Things (T2T) communication system. However, on the downside, it has invited cybercriminals to exploit the new heterogeneous infrastructure and mount catastrophic and diversified cyberattacks. Interestingly, most of these cyberattacks, if not all, are due to security vulnerabilities in the adopted authentication protocols. This has turned the attention of many researchers and industrial companies to invest a large amount of efforts to come up with new authentication protocols that are suitable for IoT.
Although many IoT authentication protocols have been proposed in the literature during the past decade, most of them, if not all, do not have a security-by-design and do not fulfill the IoT security and performance requirements. Furthermore, most of these protocols were not designed to be used in T2T architectures, where Things are supposed to autonomously and securely authenticate each other without any human intervention. This has turned our attention to investigate in this research direction to analyze the current advancement and propose possible improvements. Therefore, in this paper, we have proposed T2T-MAP, a lightweight mutual authentication protocol for T2T architectures in the context of IoT. The protocol applies PUFs (Physical Unclonable Functions), as a physical security-bydesign technology, to allow Things to efficiently authenticate each other with the lowest cost. Compared to the existing PUF-based authentication protocols from the literature [11]- [25], we claim that T2T-MAP is more resilient to various attacks, such as CRPs (Challenge-Response Pairs) disclosure, malicious insider, replay, session hijacking, brute force, secret disclosure, machinelearning, and node compromising attacks. Also, it provides mutual authentication, non-repudiation, forward-security, and liveness. Furthermore, besides being resilient to various attacks, T2T-MAP is scalable, lightweight, fast, and energy-efficient.
To summarize, the main contributions of this paper are as follows: 1) We have designed a lightweight secure-by-design authentication protocol for IoT. The protocol uses PUFs technology to allow resource-constrained devices to mutually authenticate each other without involving any human intervention. We have adopted the concept of extended CRPs (eCRPs) to make the protocol secure against CRPs disclosure, malicious insider, and modeling attacks. These attacks were shown to be possible on many authentication protocols from the related work. 2) We have discussed the resilience of T2T-MAP w.r.t. machine-learning, replay, node compromising, session hijacking, insider spoofing, brute force, and secret disclosure attacks. In addition, we have employed, Tamarin, a security protocol verification tool to verify the security of the protocol. 3) We have implemented the protocol on resourceconstrained devices and on different platforms using three different configurations. These configurations differ by the size of the variables (i.e., nonce, PUF's challenges, PUF's responses, and hash function outputs) that may be manipulated by the protocol. We have evaluated and discussed the performance of T2T-MAP with respect to the execution time, communication overhead, and energy consumption. We have shown that T2T-MAP runs at a fairly acceptable speed, has a reasonable communication overhead, and consumes a negligible amount of energy. Despite all the advantageous features that T2T-MAP provides, the protocol still has some limitations as nothing is perfect. First of all, the protocol is designed in such a way so that each device, i.e., Thing, stores only one eCRP about any other device. We have assumed (in Section VI-A) the existence of an eCRP update procedure so that devices can renew the stored eCRPs and maintain the property of forward-security as well as the resilience against brute force attacks. This eCRP update procedure may consist of storing one additional eCRP per device during the enrolment phase and particularly use these additional eCRPs for the update procedure. We plan to investigate and integrate this procedure on a future version of the protocol. Furthermore, along with all related work protocols, T2T-MAP is vulnerable to race condition-based attacks discussed in [67]- [70]. We plan to improve the security of T2T-MAP with respect to these attacks. We also plan to use an existing PUF, e.g., an SRAM-PUF, to deploy the protocol on a real-life IoT application that adopts short-range wireless technologies, such as Wi-Fi, Bluetooth, ZigBee, or RFID, and mitigate some of the recently reported attacks on these technologies.

DISCLAIMER
This work is part of a Ph.D. thesis [71] that was published at Queen's University in January 2021. In the thesis, a PUF-based authentication protocol was designed and developed for two configurations: (i) Thing-2-Thing authentication through a gateway and (ii) Thing-2-Thing authentication without a gateway. The first configuration is presented in this paper. Thus, the reader would find high similarity between the content of this work and the part of the thesis that discusses the protocol in terms of structure and content.