PHYSICAL UNCLONABLE FUNCTION BASED MUTUAL AUTHENTICATION AND KEY EXCHANGE

Abstract

Methods and endpoint nodes and controllers are disclosed for mutual authentication and key exchange. In an embodiment, physical unclonable function circuits on the endpoint nodes are used in combination with key masks to allow mutual authentication and key exchange between the endpoint nodes.

Claims

1. A method, in a first endpoint node, of authentication and key exchange with a second endpoint node, the method comprising: generating a first cryptographic nonce; sending a request message to the second endpoint node, the request message comprising the first cryptographic nonce; determining a challenge for a physical unclonable function circuit of the first endpoint node and a key mask designated for the first endpoint node to use for authentication and key exchange with the second endpoint node; applying the challenge to the physical unclonable function circuit of the first endpoint node and thereby generating a physical unclonable function response; obtaining a first intermediary secret value from the physical unclonable function response; receiving a response message from the second endpoint node, the response message comprising: first ciphertext and a second cryptographic nonce, the first ciphertext having been generated by the second node from the first cryptographic nonce and first session key material using the first intermediary secret value; decrypting the first ciphertext in the response message using the first intermediary secret value to obtain a decrypted first cryptographic nonce and decrypted first session key material; comparing the decrypted first cryptographic nonce with the first cryptographic nonce generated on the first endpoint node and authenticating the second endpoint node if the decrypted first cryptographic nonce matches the first cryptographic nonce generated on the first endpoint node; obtaining a second intermediary secret value from the first intermediary secret value using the key mask designated for the first endpoint node to use for authentication and key exchange with the second endpoint node; generating second session key material; generating second ciphertext from the second session key material and the second cryptographic nonce using the second intermediary secret value; sending the second ciphertext to the second node; and generating a session key for encrypted communication with the second endpoint node from the first session key material and the second session key material.

2. The method according to claim 1, wherein the first intermediary secret value is obtained by applying a hash function to physical unclonable function response and an identifier of the second endpoint node and the second intermediary secret value is obtained from an XOR operation of the key mask and the first intermediary secret value.

3. The method according to claim 1, wherein generating second ciphertext from the second session key material and the second cryptographic nonce using the second intermediary secret value comprises encrypting the second session key material and the second cryptographic nonce using the second intermediary secret value.

4. The method according to claim 1, wherein generating second ciphertext from the second session key material and the second cryptographic nonce using the second intermediary secret value comprises using a trapdoor function.

5. The method according to claim 4, wherein the trapdoor function comprises carrying out a point multiplication over an elliptic curve on the second session key material to obtain an elliptic curve point multiplied second session key material and encrypting the elliptic curve point multiplied second session key material and the second cryptographic nonce using the second intermediary secret value.

6. The method according to claim 1, wherein decrypting the first ciphertext using the first intermediary secret value and/or encrypting the second session key material and the second cryptographic nonce using the second intermediary secret value comprises applying an authenticated encryption method.

7. The method according to claim 6, wherein the authenticated encryption method is a counter with cipher block chaining message authentication code method, a Galois/Counter mode method, an offset codebook mode method or an encrypt-then-authenticate-then-translate method.

8. A method of facilitating authentication and encrypted communication between a first endpoint node and a second endpoint node, the method comprising: selecting a first challenge for a physical unclonable function circuit of the first endpoint node and a second challenge for a physical unclonable function circuit of the second endpoint node, wherein the physical unclonable function circuit of the first endpoint node outputs a first challenge response in response to the first challenge and physical unclonable function circuit of the second endpoint node outputs a second challenge response in response to the second challenge; generating a first key mask using the first challenge response and the second challenge response such that the first key mask encodes a first intermediary secret value of the first endpoint node and a first intermediary secret value of the second endpoint node; generating a second key mask using the first challenge response and the second challenge response such that the second key mask encodes a second intermediary secret value of the first endpoint node and a second intermediary secret value of the second endpoint node; providing a key mask for the second endpoint node encrypted by the second challenge response to the second endpoint node; and providing a key mask for the first endpoint node encrypted by the first challenge response to the first endpoint node, wherein the key mask for the second endpoint node is one of the first key mask and the second key mask and the key mask for the first endpoint node is the other of the first key mask and the second key mask.

9. A method according to claim 8, wherein the first intermediary secret value of the first endpoint node is obtained from a hash function of a concatenation of the first challenge response and an identifier of the second endpoint node, the first intermediary secret value of the second endpoint node is obtained from a hash function of a concatenation of the second challenge response and an identifier of the first endpoint node, the second intermediary secret value of the first endpoint node is obtained from a hash function of the first intermediary secret value of the first endpoint node, and the second intermediary secret value of the second endpoint node is obtained from a has function of the first intermediary secret value of the second endpoint node.

10. A method according to claim 8, further comprising authenticating the first endpoint node by sending a first cryptographic nonce to the first endpoint node and comparing a response received from the first endpoint node with an expected function of the first cryptographic nonce and the first challenge response.

11. A method according to claim 8, further comprising generating first error correcting code helper data and second error correcting code helper data respectively using the first challenge response and the second challenge response.

12. An endpoint node comprising: a physical unclonable function circuit configured to generate physical challenge responses in response to respective challenges; a memory storing: an indication of an identifier of a second endpoint node an indication of a challenge designated for the second endpoint node to use for authentication and key exchange; an indication of a challenge designated for the endpoint node to use for authentication and key exchange with the second endpoint node; and a key mask designated for the endpoint node to use for authentication and key exchange with the second endpoint node; a communication interface configured for communication with the second endpoint node; and a processor configured to: generate a first cryptographic nonce; send a request message to the second endpoint node, the request message comprising the first cryptographic nonce; apply the challenge designated for the endpoint node to use for authentication and key exchange with the second endpoint node to the physical unclonable function circuit and thereby generate a physical unclonable function response; obtain a first intermediary secret value of the endpoint node from the physical unclonable function response; receive a response message from the second endpoint node, the response message comprising: first ciphertext and a second cryptographic nonce, the first ciphertext having been generated by the second node from the first cryptographic nonce and first session key material using the first intermediary secret value; decrypt the first ciphertext in the response message using the first intermediary secret value of the endpoint node to obtain a decrypted first cryptographic nonce and decrypted first session key material; compare the decrypted first cryptographic nonce with the first cryptographic nonce generated on the endpoint node and authenticate the second endpoint node if the first ciphertext is decrypted successfully and the decrypted first cryptographic nonce matches the first cryptographic nonce generated on the endpoint node; obtain a second intermediary secret value of the second endpoint node from the first intermediary secret value of the endpoint node using the key mask designated for the first endpoint node to use for authentication and key exchange with the second endpoint node; generate second session key material; generate second ciphertext from the second session key material and the second cryptographic nonce using the second intermediary secret value of the second endpoint node; send the second ciphertext to the second endpoint node; and generate a session key for encrypted communication with the second endpoint node from the first session key material and the second session key material.

13. An endpoint node comprising: a physical unclonable function circuit configured to generate physical challenge responses in response to respective challenges; a memory storing: an indication of an identifier of a second endpoint node an indication of a challenge designated for the second endpoint node to use for authentication and key exchange; an indication of a challenge designated for the endpoint node to use for authentication and key exchange with the second endpoint node; a key mask designated for the endpoint node to use for authentication and key exchange with the second endpoint node; a communication interface configured for communication with the second endpoint node; and a processor configured to: receive a request message from the second endpoint node, the request message comprising the first cryptographic nonce; apply the challenge designated for the endpoint node to use for authentication and key exchange with the second endpoint node to the physical unclonable function circuit and thereby generate a physical unclonable function response; obtain a first intermediary secret value of the endpoint node from the physical unclonable function response; obtain a first intermediary secret value of the second endpoint node using the key mask designated for the endpoint node to use for authentication and key exchange with the second endpoint node; generate first session key material; generate first ciphertext from the first cryptographic nonce and first session key material using the first intermediary secret value of the second endpoint node; generate a second cryptographic nonce; send the first ciphertext and the second cryptographic nonce to the second endpoint node; receive second ciphertext from the second endpoint node; decrypt the second ciphertext using the second intermediary secret value of the endpoint node to obtain a decrypted second cryptographic nonce and decrypted second session key material; compare the decrypted second cryptographic nonce with the second cryptographic nonce generated on the endpoint node and authenticate the second endpoint node if the second ciphertext is successfully decrypted and the decrypted second cryptographic nonce matches the second cryptographic nonce generated on the endpoint node; generate a session key for encrypted communication with the second endpoint node from the first session key material and the second session key material.

14. The endpoint node according to claim 12, wherein the first intermediary secret value of the endpoint node is obtained by applying a hash function to the physical unclonable function response and an identifier of the other endpoint node, and the second intermediary secret value is obtained by applying a hash function to the first intermediary secret value.

15. The endpoint node according to claim 12, wherein the processor is further configured to generate the second ciphertext from the second session key material and the second cryptographic nonce using the second intermediary secret value by encrypting the second session key material and the second cryptographic nonce using the second intermediary secret value.

16. The endpoint node according to claim 12, wherein the processor is further configured to generate second ciphertext from the second session key material and the second cryptographic nonce using the second intermediary secret value comprises using a trapdoor function.

17. The endpoint node according to claim 12, wherein the processor is further configured to decrypt the first ciphertext using the first intermediary secret value and/or encrypting the second session key material and the second cryptographic nonce using the second intermediary secret value by applying an authenticated encryption method.

18. The endpoint node according to claim 17, wherein the authenticated encryption method is a counter with cipher block chaining message authentication code method, a Galois/Counter mode method, an offset codebook mode method or an encrypt-then-authenticate-then-translate method.

19. The endpoint node according to claim 12, wherein the memory further stores error correction code helper data for the reconciliation of the challenge response generated by the physical unclonable function circuit, and the processor is further configured to use the error correction code helper data to apply the challenge designated for the endpoint node to use for authentication and key exchange with the second endpoint node to the physical unclonable function circuit and thereby generate a physical unclonable function response.

20. A controller for facilitating authentication and encrypted communication between a first endpoint node and a second endpoint node, the controller being configured to: select a first challenge for a physical unclonable function circuit of the first endpoint node and a second challenge for a physical unclonable function circuit of the second endpoint node, wherein the physical unclonable function circuit of the first endpoint node outputs a first challenge response in response to the first challenge and physical unclonable function circuit of the second endpoint node outputs a second challenge response in response to the first challenge; generate a key mask for the second endpoint node using the first challenge response and the second challenge response such that the key mask for the second endpoint node encodes first intermediary secret value of the first node and a first intermediary secret value of the second endpoint node; generate a key mask for the first endpoint node using the first challenge response and the second challenge response such that the key mask for the first endpoint node encodes a second intermediary value secret of the first endpoint node and a second intermediary secret value of the second endpoint node; provide the key mask for the second endpoint node encrypted by the second challenge response to the second endpoint node; and provide the key mask for the first endpoint node encrypted by the first challenge response to the first endpoint node.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In the following, embodiments of the present invention will be described as non-limiting examples with reference to the accompanying drawings in which:

[0031] FIG. 1 is a block diagram showing a system for physical unclonable function based authentication and key exchange according to an embodiment of the present invention;

[0032] FIG. 2 is a table showing data stored in an enrollment and update controller of a system for physical unclonable function based authentication and key exchange according to an embodiment of the present invention;

[0033] FIG. 3 is a flow diagram showing a method updating data stored on endpoint nodes in an embodiment of the present invention;

[0034] FIG. 4A and FIG. 4B are tables showing data stored on endpoint nodes in an embodiment of the present invention;

[0035] FIG. 5 is a flow chart showing a method mutual authentication and key exchange between endpoint nodes according to an embodiment of the present invention;

[0036] FIG. 6 is a table showing a comparison of protocols against a list of security features, including mutual authentication, secure session key, the requirement of server participation, NVM for storage of secret locally and PFS;

[0037] FIG. 7 is a table showing a comparison of computational complexity for protocols; and

[0038] FIG. 8 is a table showing a comparison of communication and storage costs for protocols.

DETAILED DESCRIPTION

[0039] The present disclosure relates to physical unclonable function (PUF) based protocols for mutual authentication and key exchange between endpoints in peer-to-peer systems.

[0040] A PUF may be used as a “device fingerprint” for individual device authentication [2], [3]. A typical PUF-based authentication process is as follows. An enrolment phase is required to be carried out securely in a controlled environment once before the PUF can be deployed in the field for device authentication. During the enrolment phase, an adequate number of challenge response pairs (CRPs) of the PUF has to be collected and stored in the verifier's database. In the authentication phase, the verifier randomly selects a CRP from its database and then transmits the challenge to the prover. The prover obtains a response by applying this challenge to its PUF and sends the response back to the verifier. By comparing the received PUF response with the enrolled one, the verifier can authenticate the prover's device. A typical PUF-based authentication scheme requires the verifier to safely store a CRP database of the prover's PUF. This is easier to achieve if the verifier is a powerful server. If direct authentication of P2P IoT devices is to be achieved without a proxy server this scheme is infeasible as the verifier, an IoT endpoint, has limited resources to ensure the secure storage of the CRPs. As a result, PUF-based authentication schemes without the CRP

[0041] storage in both endpoint devices of the verifier and the prover are desperately needed in such P2P IoT applications.

[0042] FIG. 1 is a block diagram showing a system for physical unclonable function based authentication and key exchange according to an embodiment of the present invention. The system 100 comprises an enrollment and update controller 120 and two endpoint nodes: endpoint node A 140A and endpoint node B 140B. The two endpoint nodes can also be two dies in a heterogeneous integrated circuit package to enable highly secure die-to-die communications between chiplets. This system can also be used to enhance the security of chiplets, which may involve communication between chiplets manufactured by different foundries and outsourced IP cores from multiple venders. Such trust assurance is important for chiplets in the aerospace, defense, industrial and automotive markets. It is envisaged that systems which implement the protocols described herein may be implemented with more than two endpoint nodes. Since the update and authentication processes take place with pairs of endpoint nodes, for larger systems, the processes described herein are carried out between pairs of endpoint nodes.

[0043] The enrollment and update controller 120 comprises a processor 122, a secure memory 124 and a communications interface 126. Endpoint node A 140A comprises a processor 142A, a PUF circuit 144A, a non-volatile memory 146A and a communications interface 148A. Endpoint node B comprises a processor 142B, a PUF circuit 144B, a non-volatile memory 146B and a communications interface 148B. The PUF circuit can be any weak or strong PUF, such as any of the delay-based PUFs (e.g., arbiter and ring-oscillator PUFs), memory PUF, sensor PUF, optical PUF, monostable PUF, via-PUF, etc. that has sufficient CRPs to support the number of endpoint nodes to be paired for direct secure mutual authentication. In addition, the PUF circuits 144A and 144B of the two endpoint nodes need not be the same. Both wire and wireless interfaces can be used for 148A and 148B as long as the endpoint nodes 140A and 140B use the same communication protocol supported by their enrolled network server. For example, WiFi and network socket for connection may be used. Long-distance communication interfaces like cellular network, Ethernet, short-distance wireless protocols like Bluetooth, RFID, NFC and wired communication like RS232, and USB are also possible. The high-speed chiplets require high bandwidth serial or parallel communication interface between dies or chips. The state-of-the-art serial interfaces are 112G USR/XSR (ultra-short reach, extra-short reach) and parallel interfaces are High Bandwidth Interconnect HBI (an offshoot of HBM) and OpenHBI, BoW (bunch of wires) and Intel Advanced Interface Bus (AIB).

[0044] Endpoint node A 140A and endpoint node B 140B are relatively small lightweight devices such as sensor nodes of an IoT system. Therefore, they have limited storage capacity and security. As discussed in more detail below, the processors 142A and 142B of the endpoint nodes are operable to execute a lightweight hash function (for example, sponge-like construction) and a lightweight block cipher optimized for performance in hardware implementation like SIMON [20]. It is assumed that the non-volatile memories 146A and 146B of the end point nodes are not secured and have limited storage capacity.

[0045] The enrollment and update controller 120 may be implemented as a server and is assumed to have greater storage and processing capacity than the endpoint nodes. In addition, the enrollment and update controller 120 can securely store a database of challenge response pairs for the endpoint nodes in the secure memory.

[0046] The objective of the system 100 is to establish direct mutual authentication and direct secure communications thereafter between the endpoint nodes 140A and 140B by utilizing the on-the-fly key generation property of PUF.

[0047] In the following description it is assumed that the CRPs of the endpoint nodes 140A and 140B have already been securely collected in the design house or a trusted entity and securely transmitted to enrollment and update controller 120. The threat model assumes the presence of an attacker who can connect to the network and is able to eavesdrop the communication channel during the authentication process. It is also assumed that the attacker can initiate an unbound number of authentication requests. The attacker cannot break into the secure memory 124, but can have access to the endpoint nodes 140A and 140B to retrieve any stored data in the device. The objective of the attacker is to impersonate any end-devices and steal the secret session key without being detected.

[0048] FIG. 2 is a table showing data stored in an enrollment and update controller of a system for physical unclonable function based authentication and key exchange according to an embodiment of the present invention. As shown in FIG. 2, the secure memory 124 of the enrollment and update controller 120 stores the challenge set and response set of the PUF circuit for each device. Endpoint node A 140A has a device ID ID.sub.A. The PUF circuit 144A of endpoint node A 140A has a challenge set C.sub.A and a response set R.sub.A. Endpoint node B 140B has a device ID ID.sub.B. The PUF circuit 144B of endpoint node B 140B has a challenge set C.sub.B and a response set R.sub.B. The enrolment phase is firstly conducted in the design house or a trusted entity, where the CRPs of each PUF-embedded chip are collected after fabrication. After which, the direct CRP access paths are permanently removed. Once the customer identity is authenticated, the CRPs will be transferred to the customer's local server for the intended applications. Note that the CRP collection is assumed to be conducted in a secure environment and the transfer of CRPs is also securely completed with the help of various supply chain authentication protocols.

[0049] The proposed protocol consists of two phases, i.e., an enrolment and update phase, and a mutual authentication and key exchange phase. The endpoint nodes only have to communicate with the server in the enrollment and update phase. After which, the endpoint nodes can connect and authenticate each other directly.

[0050] Embodiments of the present disclosure utilize the Exclusive-OR (XOR) cipher to generate a key mask for a dedicated device pair. The mask can be publicly stored in the device without compromising the security. Its purpose is to enable the endpoint node to securely retrieve the intermediary secret of its pairing endpoint node during the authentication process.

[0051] Notations used in the present disclosure are shown in table 1 below.

TABLE-US-00001 Notation Description PUFA(C) Apply the challenge C to the PUF circuit (PUFB(C)) of endpoint node A (B) H(X) Hash of X a ⊕ b Exclusive OR a, b Concatenation [00001]$x\stackrel{R}{\leftarrow }X$ x is randomly chosen from the set X ϕ A key mask h = ECC.gen(X) Error correction code (ECC) generation phase. It generates the helper data h for the recovery of X X = ECC.rep({circumflex over (X)}, h) ECC reproduction phase. It corrects the noisy {circumflex over (X)} with the helper data h M = CCM.enc(f, k, m) CCM encryption of plaintext m with k as the key and f as the underlying block cipher, which could either be a pseudo- random function (PRF) or a pseudo- random permutation (PRP). The output M includes the ciphertext and a tag V = CCM.dec(f, k, M) CCM decryption of M with k as the key and f as the underlying block cipher. If key k is correct, V = m, where m is the plaintext. Otherwise, an error is returned in V. {0, 1}.sup.l The set of bit strings of length I

[0052] FIG. 3 is a flow diagram showing a method updating data stored on endpoint nodes in an embodiment of the present invention. The method 300 shown in FIG. 3 is carried out by the enrollment and update controller 120 and the pair of end point devices: endpoint node A 140A and endpoint node A 140B.

[0053] As mentioned above, the secure memory 124 of the enrollment and update controller 120 stores the data described above with reference to FIG. 2.

[0054] In step 302, for each intended pair of endpoint nodes (which in this example is endpoint node A and endpoint node B), the enrollment and update controller 120 selects a challenge C.sub.a for A and a challenge C.sub.b for B from their respective challenge sets, C.sub.A and C.sub.B.

[0055] In step 304, the corresponding responses, R.sub.a and R.sub.b, are also retrieved from the secure memory 124. To enable R.sub.a and R.sub.b to be recovered from the noisy responses reproduced by the respective device PUF circuits 144A and 144B in the field, the enrollment and update controller 120 also applies error correcting code (ECC) [21] to R.sub.a and R.sub.b to generate the corresponding helper data, h.sub.a and h.sub.b. To ensure the freshness of the session, the server generates two random nonces m and n for endpoint node A and endpoint node B respectively.

[0056] In step 306, an update request is sent individually to each respective node (i.e. endpoint node A and endpoint node B). The update request has the following form:

<ID.sub.self,challenge.sub.self,ID.sub.target,challenge.sub.target,helper_data,nonce>

[0057] where subscripts ‘self’ and ‘target’ refer to the designated device and its pairing device, respectively. An honest endpoint node A (or B) can generate a valid A.sub.a (or A.sub.b) to prove its identity to the enrollment and update controller 120.

[0058] In step 308A endpoint node A receives its designated update request and generates an authentication response in step 310A. The response is generated as follows: the endpoint node A applies the challenge C.sub.a to its PUF circuit 144A and generates the noisy response {circumflex over (R)}.sub.a:

{circumflex over (R)}.sub.a=PUFA(C.sub.a)

[0059] Then, using the helper data h.sub.a, the endpoint node A corrects the response:

R.sub.a=ECC.rep({circumflex over (R)}.sub.a,h.sub.a)

[0060] Then, an authentication response A.sub.a is generated as the hash of the corrected response XORed with the received nonce value m:

A.sub.a=H(R.sub.a⊕m)

[0061] A.sub.a is sent to the enrollment and update controller 120 with a randomly selected I-bit string x:

[00002]$x\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^l$

[0062] Similarly, in step 308B endpoint node B receives its designated update request and generates an authentication response in step 310B. The response is generated as follows: the endpoint node B applies the challenge C.sub.b to its PUF circuit 144B and generates the noisy response {circumflex over (R)}.sub.b:

{circumflex over (R)}.sub.b=PUFA(C.sub.b)

[0063] Then, using the helper data h.sub.b, the endpoint node B corrects the response:

R.sub.b=ECC.rep({circumflex over (R)}.sub.b,h.sub.b)

[0064] Then, an authentication response A.sub.b is generated as the hash of the corrected response XORed with the received nonce value n:

A.sub.b=H(R.sub.b⊕n)

[0065] A.sub.b is sent to the enrollment and update controller 120 with a randomly selected I-bit string y:

[00003]$y\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^l$

[0066] In step 314, the enrollment and update controller 120 authenticates the endpoint nodes by checking if A.sub.a=H(R.sub.a ⊕m) and A.sub.b=H(R.sub.b⊕n) using the nonce values sent to the respective endpoint nodes and the responses to the selected challenges.

[0067] If the endpoints are successfully authenticated, in step 314, the enrollment and update controller 120 calculates a pair of intermediary secrets, P.sub.1 and P.sub.2, from the response R of each designated endpoint node and the identity of its pairing endpoint node. Thus, for the pair of endpoint node A and endpoint node B, there are two pairs of intermediary secrets: (P.sub.1a, P.sub.2a) and (P.sub.1b, P.sub.2b).

[0068] The intermediary secrets are generated using the device identifiers of the partner endpoint nodes as follows:

P.sub.1a=H(R.sub.a,ID.sub.B)

P.sub.2a=H(P.sub.1a)

P.sub.1b=H(R.sub.b,ID.sub.A)

P.sub.2b=H(P.sub.1b)

[0069] A lightweight cryptographic hash function H is used to boost the entropy of PUF responses and prevent the plain responses from being intercepted. By including the partner's identities (ID.sub.B and ID.sub.A) in the calculation of P.sub.1a and P.sub.1b, the two parameters are made to be partner device-specific. Specifically, for endpoint node A, P.sub.1a is first calculated by hashing the concatenated R.sub.a and ID.sub.B. P.sub.2a is then obtained by hashing P.sub.1a, P.sub.1b and P.sub.2b are similarly obtained from hashing the concatenated R.sub.b and ID.sub.A consecutively.

[0070] In step 316, a key mask ϕ is generated for each endpoint node of the pair by an XOR operation of an intermediary secret of the node A and a corresponding intermediary secret of the node B. Each intermediary secret corresponding to one endpoint node acts as an endpoint node specific XOR cipher decryption key for the retrieval of the other intermediary secret corresponding to the other endpoint node. ϕ needs not to be kept private. It can be stored in the respective non-volatile memories 146A and 146B. Due to the cryptographic secure XOR cipher, the knowledge of ϕ does not help to reveal P.sub.1 and P.sub.2. Hence, both P.sub.1 and P.sub.2 can serve as the keys to decrypt a pair of puzzles (Q.sub.a and Q.sub.b) designated for an endpoint node with the help of its PUF circuit. These private data are concealed in ϕ.sub.1 and ϕ.sub.2 by the XOR cipher construction, P.sub.1a⊕P.sub.1b and P.sub.2a⊕P.sub.2b, respectively.

ϕ.sub.1=P.sub.1a⊕P.sub.1b

ϕ=P.sub.2a⊕P.sub.2b

[0071] In step 318, the key masks are encrypted and sent to the respective endpoint nodes.

X.sub.a=CCM.enc(AES,H(R.sub.a),(x,ϕ.sub.2))

X.sub.b=CCM.enc(AES,H(R.sub.b),(y,ϕ.sub.1))

[0072] Where X.sub.a is the encrypted message sent to endpoint node A and X.sub.b is the encrypted message sent to endpoint node B.

[0073] In step 320A, endpoint node A receives and decrypts the message X.sub.a:

Y.sub.a=CCM.dec(AES,H(R.sub.a),X.sub.a)

[0074] This is rejected if Y.sub.a=error, otherwise, x and ϕ.sub.2 are retrieved from Y.sub.a and if x is fresh, in step 322A, (ID.sub.B, C.sub.b, C.sub.a, h.sub.a, ϕ.sub.2) is stored in the non-volatile memory 146A of endpoint node A.

[0075] Similarly, in step 320B, endpoint node B receives and decrypts the message X.sub.b:

Y.sub.b=CCM.dec(AES,H(R.sub.b),X.sub.b)

[0076] This is rejected if Y.sub.b=error, otherwise, y and ϕ.sub.1 are retrieved from Y.sub.b and if y is fresh, in step 322B, (ID.sub.B, C.sub.a, C.sub.b, h.sub.b, ϕ.sub.1) is stored in the non-volatile memory 146B of endpoint node B.

[0077] Note that an XOR cipher can act as a one-time pad (OTP) to achieve perfect secrecy, if the length of the random key is at least as long as the plaintext. Besides, the random key must be kept completely secret and never be reused in whole or in part. All these requirements can be fulfilled by the proposed method. Use ϕ.sub.1=P.sub.1a⊕P.sub.1b for illustration. P.sub.1a and P.sub.1b are the outputs of the same hash function, which makes the length of both parameters the same. The “completely secret” requirement is also met by our proposed scheme as P.sub.1a and P.sub.1b are defined by the PUF responses. They can only be generated by the device when needed and are never stored or transmitted in plaintext. As for the one-time use policy of the OTP, even if the same challenge is picked for a device A to pair with different devices, e.g., B and C, the generated P.sub.1a is different for different pairing devices as the hash function used for the generation P.sub.1a is dependent on both R.sub.a and its pairing device's unique identity, i.e., ID.sub.B or ID.sub.C. Even though an authorized device can retrieve the corresponding P.sub.1 or P.sub.2 to the allocated challenge for any of its interlocutor, it still cannot impersonate as its interlocutor to communicate with other devices, neither does the attacker.

[0078] A device should only accept a fresh authentication mask from an authorized controller that possesses the correct CRPs of the device's PUF. To ensure this, the controller packs the mask ϕ.sub.2 with the fresh x sent by the endpoint node. The message package is encrypted using counter with cipher block chaining message authentication code (CCM) mode with H(R.sub.a) as the key and Advanced Encryption Standard (AES) as the underlying pseudo-random permutation (PRP). CCM combines cipher block chaining message authentication code (CBC-MAC) and counter (CTR) mode encryption to provide authenticated encryption, which assures both the confidentiality and authenticity of data. Besides, CCM has smaller code size as the decryption block of the underlying block cipher is not required. To decrypt the received message, endpoint node A applies C.sub.a to its PUF circuit to recover the key H(R.sub.a), and performs a decryption upon receiving the message. If the message can be successfully decrypted, it means that the message sender possesses the correct R.sub.a. Therefore, endpoint node A can believe that the enrolled or updated message (ID.sub.A, C.sub.a, ID.sub.B, C.sub.b, h.sub.a, ϕ.sub.2) is indeed from a trusted local server. If the decrypted x is the same as the fresh x that it sent, device A can confirm the freshness of the updated message, thus the replay of a compromised X, is prevented. Once the authenticity and freshness are confirmed, A stores the information in its local non-volatile memory. Similar process is carried out by device B. The same process can be performed whenever the authentication mask on the end point node's side needs to be updated. In addition to CCM mode, other secure Authenticated Encryption methods such as GCM mode, OCB mode, EAX mode, etc., can be used. In addition to AES, other secure PRF (Pseudo Random Function) or PRP (Pseudo Random Permutation) can be used.

[0079] FIG. 4A and FIG. 4B are tables showing data stored on endpoint nodes in an embodiment of the present invention. As shown in FIG. 4A, the data (ID.sub.B, C.sub.b, C.sub.a, h.sub.a, ϕ.sub.2) is stored on endpoint node A for authentication and key exchange with endpoint node B. As shown in FIG. 4B, the data (ID.sub.A, C.sub.a, C.sub.b, h.sub.b, ϕ.sub.1) is stored on endpoint node B for authentication and key exchange with endpoint node A.

[0080] FIG. 5 is a flow chart showing a method mutual authentication and key exchange between endpoint nodes according to an embodiment of the present invention. The method 400 shown in FIG. 5 is carried out between two endpoint nodes 140A and 140B for which the method 300 described above with reference to FIG. 3 has been carried out.

[0081] In step 402, endpoint node A 140A generates a cryptographic nonce T.sub.a which will be sent to endpoint node B 140B and later used in the authentication of endpoint node B.

[0082] In step 404, endpoint node A generates and sends a request message to endpoint node B 140B. The request message MSG.sub.1 comprises the identities of the endpoint nodes (ID.sub.A and ID.sub.B), the challenges used for the current session (C.sub.a and C.sub.b), and the cryptographic nonce (T.sub.a).

[0083] In step 406, endpoint node B receives the request message.

[0084] In step 408, endpoint node B checks the correctness of the message receiver and the existence of requestor and pairing challenges in its local non-volatile memory 146B. If yes, it fetches the enrolled challenge C.sub.b, helper data h.sub.b and key mask ϕ.sub.1 corresponding to (ID.sub.A, C.sub.a) from the non-volatile memory 146B.

[0085] In step 410, endpoint node B 140B applies the challenge C.sub.b to its embedded PUF circuit 144B to generate a reliable PUF response R.sub.b with the helper data h.sub.b.

{circumflex over (R)}.sub.b=(PUFB(C.sub.b))

R.sub.b=ECC.rep({circumflex over (R)}.sub.b,h.sub.b)

[0086] In step 412, endpoint node B 140B uses the key mask ϕ.sub.1, to recover the paired of A by XORing ϕ.sub.1 with P.sub.1b. The latter is the hash of R.sub.b and ID.sub.A.

P.sub.1b=H(R.sub.b,ID.sub.A)

=ϕ.sub.1⊕P.sub.1b

[0087] In step 414, endpoint node B generates first session key material n.sub.a which is a random bit string of length l:

[00004]$n_a\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^l$

[0088] In step 418, endpoint node B generates a second cryptographic nonce T.sub.b.

[00005]$T_b\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^l$

[0089] In step 420, endpoint node B generates and sends a first response message to endpoint node A. The first response message comprises a puzzle Q.sub.a which is generated as ciphertext by encrypting the concatenated message of n.sub.a and the received T.sub.a using CCM encryption.

Q.sub.a=CCM.enc(AES,,(n.sub.a,T.sub.a))

[0090] The first response message MSG.sub.2 comprises the puzzle Q.sub.a and the second cryptographic nonce T.sub.b.

MSG.sub.2=<Q.sub.a,T.sub.b>

[0091] In step 422, endpoint node A 140A receives the first response message MSG.sub.2.

[0092] In step 424, endpoint node A 140A reads its non-volatile memory 146A to determine the PUF challenge designated for endpoint node B and retrieves the challenge C.sub.a, the helper data h.sub.a and key mask ϕ.sub.2 from the non-volatile memory 146A.

[0093] In step 426, endpoint node A 140A applies the challenge to its PUF circuit 144A and uses the helper data h.sub.a to generate the clean PUF response R.sub.a

{circumflex over (R)}.sub.a=(PUFA(C.sub.a))

R.sub.a=ECC.rep({circumflex over (R)}.sub.a,h.sub.a)

[0094] In step 428, endpoint node A 140A recovers the intermediary secret values P.sub.1a and P.sub.2a

P.sub.1a=H(R.sub.a,ID.sub.B)

P.sub.2a=H(P.sub.1a)

[0095] In step 430, endpoint node A 140A uses the received first response message to authenticate endpoint node B. Endpoint node A uses the intermediary secret value P.sub.1a as a decryption key to decrypt the received Q.sub.a. If decryption is successful and the decrypted is equal to T.sub.a, A accepts B as the authenticated interlocutor.

V.sub.a=CCM.dec(AES,P.sub.1a,Q.sub.a)

[0096] If V.sub.a=error, reject. Else the concatenated message (,) is unpacked from V.sub.a. If =T.sub.a then A authenticates B.

[0097] In step 432, endpoint node A generates second session key material. The second session key material n.sub.b is a random bit string of length l:

[00006]$n_b\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^l$

[0098] In step 434, endpoint node A generates a puzzle Q.sub.b for endpoint node B to solve using as a key. The puzzle is generated as ciphertext.

=ϕ.sub.2⊕P.sub.2a

Q.sub.b=CCM.enc(AES,,(n.sub.b,T.sub.b))

[0099] Endpoint node A then generates a second response message from this puzzle which is sent to endpoint node B.

[0100] In step 436, endpoint node B receives the second response message MSG.sub.3=<Q.sub.b>.

[0101] In step 438, endpoint node B uses the intermediary secret value P.sub.2b as a decryption key to decrypt the received Q.sub.b. If Q.sub.b can be successfully decrypted by P.sub.2b retrieved from hashing P.sub.1b, B can further check the freshness of the recovered . If both are valid, B accepts A as its authenticated interlocutor.

P.sub.2b=H(P.sub.1b)

V.sub.b=CCM.dec(AES,P.sub.2b,Q.sub.b)

[0102] If V.sub.b=error, reject. Else the concatenated message (,) is unpacked from V.sub.b. If =T.sub.b then B authenticates A.

[0103] In step 440A, endpoint node A 140A generates a session key and in step 440B, endpoint node B 140B generates the session key. Upon the successful mutual authentication, both parties can calculate sk=H(n.sub.a,n.sub.b)=H(,n.sub.b)=H(n.sub.a,) as the session key and use it directly for encrypted communication. Note that the session secrets, n.sub.a and n.sub.b, are independent and ephemeral. Therefore, the calculated session key sk is also fresh and independent. Besides, ϕ.sub.1 and ϕ.sub.2 do not have to be stored by both devices. With the current setting, the protocol can also execute successfully if B initiates the protocol first. The only difference is that B will authenticate A first before A authenticates B.

[0104] It is noted that the proposed protocol shown in FIG. 5 is efficient but cannot achieve perfect forward secrecy (PFS) if the long-term secrets of the entities are compromised. A small tweak on the protocol can be made to achieve PFS. The idea is to use a trapdoor function. The choice of a trapdoor function can be determined by the application. Thus, in an embodiment, an augmented mutual authentication and key exchange protocol based on the Elliptic Curve Diffie-Hellman (ECDH) problem is introduced. In addition to utilize Elliptic Curve Diffie-Hellman (ECDH) problem for achieving perfect forward secrecy in the augmented protocol, other trapdoor functions like the Diffie-Hellman problem can be used.

[0105] To achieve PFS, the enrollment phase of the proposed protocol requires several additional registration steps. The enrollment and update controller chooses a safe elliptic curve E over a finite field , where p is a prime, and then selects P∈E() of order n as a generator. The enrollment and update controller publishes {E, n, P} as public parameters, which are available to all entities including the adversary. All the other procedures remain the same.

[0106] For the augmented protocol, the plaintexts of the puzzles are slightly different. Device B encrypts (n.sub.aP,T.sub.a) instead of (n.sub.a,T.sub.a); Similarly, device A encrypts (n.sub.bP,T.sub.b) to create the puzzle Q.sub.b, where n.sub.aP and n.sub.bP are point multiplications over the elliptic curve. In this way, the leakage of long-term secrets, i.e., R.sub.a, R.sub.b (or P.sub.1a, P.sub.1b), will only provide the adversary with n.sub.aP and n.sub.bP. Thanks to the ECDH problem, the adversary is not able to calculate sk=n.sub.an.sub.bP with this information.

[0107] The protocols described above may be implemented as follows. Two Avnet Ultra96-V2 boards are used as the endpoints. Ultra96-V2 is an ARM-based, Xilinx Zynq UltraScale+TM MPSoC ZU3EG A484 development board. It supports PYNQ for Xilinx FPGA device, which means that Python language and libraries are provided for the application development to benefit from both the FPGA programmable logic and ARM microprocessor. A personal computer is used as the controller. The involvement of the controller is only in the enrollment and update phase. Any PUF with good uniqueness and randomness to minimize the probability of response collision or correlation that may be exploited by the attackers can be embedded into the IoT devices. Thus, there is no restriction on the type of PUF which can be used in the protocol. The PUF can be flexibly selected to meet the device resource or any specific application requirements. A highly reliable PUF will relax the error correction requirement. Though with near-perfect reliability has been proposed in the literature, without loss of generality, we assume that the PUFs embedded in the devices have high but not perfect reliability. Therefore, ECC is required as the PUF responses are used for key generation in the proposed scheme. In our experiment, the reliable and modeling resistant Arbiter PUF is chosen for the implementation on the FPGA. The PUF overlay is then loaded through the ARM core for system configuration. The remaining cryptographic modules such as ECC and hash may be directly imported from Python libraries. For demonstration purposes, the proposed protocol may be designed on top of the network socket. The elapsed time from device A initiating the protocol till the completion of mutual authentication and session key generation is less than 1.5 seconds. As only public information, i.e., device identity, challenge, ECC helper data and key mask, are stored in the device, the storage and security requirements in each device are also low.

[0108] In the following, the advantages and improvements offered by the protocols described above are discussed. Several relevant solutions have been proposed in the literature [4], [5]-[7] to solve the bottlenecks of the classical PUF-based device authentication schemes. The protocol of [4] combines the PUF with a certificate-less identity based encryption. It requires a verifier node to act as the proxy to authenticate the two IoT endpoints. It also requires the presence of a Security Association Provider (SAP) during the authentication phase to manage the authentication helper data. Besides, the protocol requires the verifier to store a secret hash key in a non-volatile memory (NVM). This requirement has completely defeated the fundamental tenet of using PUF to avoid keeping the secret in local memory.

[0109] On the other hand, the Babel-chain PUF-based mutual authentication protocol (BC-PHEMAP) [5] applies the PUF response iteratively to the PUF to create PUF chains for authentication. Since multiple PUF operations (8 in the text example) are required and each PUF operation has to be 100% reliable in order to preserve the enrolled chain result, this scheme is not practical due to the inevitable unreliability of PUF responses in the field. What is more, the BC-PHEMAP scheme reveals raw PUF responses during the protocol executions. The scheme requires strong PUF to ensure the chain or its subset is never reused to pair different devices but this also provides an opportunity for the adversary to collect a large number of used raw responses for modelling attack.

[0110] The scheme in [6] also requires a trusted third party server during the mutual authentication of two IoT endpoints. The server is responsible for providing the authentication message and generating the session keys. The protocol trades message exchange times (delays) for zero-storage in the device side and reduced storage requirement in the server side. Two rounds of mutual authentication between the server and the device and one round of mutual authentication between devices are required for a complete protocol run. On a par with [5], it does not take into account the practical PUF reliability issues.

[0111] Similar to [4], the work [7] relies on the combination of PUF with a public-key cryptography on elliptic curve to achieve mutual authentication between IoT nodes without the need for a local CRP storage. Each IoT node will obtain its public and private key pair after an enrolment phase with the server in a secure environment. The public keys are stored in the device's memory while the private keys are recovered with the help of the PUF during the authentication phase. 14 rounds of elliptic curve scalar multiplications are required to complete the protocol runs, which increases the computational cost of the protocol significantly.

[0112] Based on the above discussions, existing PUF-based authentication schemes, either with or without requiring a CRP storage in the verifier, cannot be used to instantiate a low-cost, key-less, directly authenticated and directly connected P2P IoT network. The protocols of the present disclosure achieve the direct PUF-based mutual authentication and key exchange, and outperforms existing works in both security, computational complexity and communication cost.

[0113] FIG. 6 is a table showing a comparison of protocols against a list of security features, including mutual authentication, secure session key, the requirement of server participation, NVM for storage of secret locally and PFS. In FIG. 6 to FIG. 8, “proposed protocol A” indicates the protocol of described above with reference to FIG. 5, and “proposed protocol B” indicates the protocol with the modification to use ecliptic curves to achieve PFS as described above.

[0114] Mutual authentication and secure session key are two fundamental security features to ensure that only the legitimate devices are involved in the communication and the communication is secured with a secret session key. All protocols in comparison can perform mutual authentication. Two protocols, TDSC2018 [4] and Elsevier2019 [5], do not produce secure session key through the authentication process. The protocol TDSC2018 [4] exchanges public key instead and uses public key encryption to secure transmission, which incurs significantly higher computational costs than other protocols that use symmetric key cryptography. Except the protocol JSEN2021 [7] and our proposed protocols, all other protocols [4], [5], [6] require server participation for mutual authentication. Involving server participation during the authentication process is inefficient and not well-suited to P2P IoT scenarios. It requires more protocol rounds and incurs extra latency. Storing secrets locally on the device's NVM make the protocol TDSC2018 [4] vulnerable to memory attacks. Lack of PFS makes the previous communication messages vulnerable to long-term secret leakage in protocols like JIoT2017 [6], Elsevier2019 [5]. Protocol JSEN2021 [7] and the proposed protocol B stand out as the only two candidates that meet all the desirable security features for securing mutual authentication and key exchange in P2P IoT setting.

[0115] FIG. 7 is a table showing a comparison of computational complexity for protocols. The computational complexity listed for each protocol includes computations performed during the mutual authentication and key exchange phase at both the device node and the participating third-party node (if any). Let N.sub.H, N.sub.MAC, N.sub.PUF, N.sub.ECC, N.sub.Enc, N.sub.PA, N.sub.PM and N.sub.BP denote the numbers of rounds of hash function, message authentication code (MAC), PUF, error correction code for PUF, encryption and decryption, point addition over elliptic curve, point multiplication over elliptic curve and bilinear pairing, respectively. Since the proposed protocol does not dictate the type of cryptographic modules such as PUF and hash as long as they meet the required functionality with acceptable implementation cost, FIG. 7 only lists the names of the cryptographic modules for a fair comparison. Similarly, for an implementation platform-independent comparison of computational complexity, the number of rounds for each required operation is listed and compared. Trivial operations like concatenation or bitwise exclusive OR are omitted without impacting the relative accuracy of the comparison.

[0116] As shown in FIG. 7, protocols, TDSC2018 [4], Elsevier2019 [5] and JIoT2017 [6], all require a third party to complete the mutual authentication between devices. Among the existing protocols, TDSC2018 [4] and JSEN2021 [7] have the highest computational complexity as they both require compute-intensive public-key cryptography over elliptic curve. The protocol TDSC2018 [4] requires 16 point additions, 8 point multiplications and 4 bilinear pairing operations to be performed in total while the protocol JSEN2021 [7] requires 6 rounds of point addition and 16 rounds of point multiplication. A point addition and a point multiplication over elliptic curve secp256r1 consume around 2.56 ms and 112.34 ms, respectively, on TI's CC2538 SoC (in comparison, SHA256 only consumes around 0.061 ms in the same platform) [7]. Bilinear pairing has been widely regarded as an expensive operation for terminal devices. The present invention does not need point multiplication and elliptic curve cryptography unless PFS is required. If PFS is needed, the proposed augmented protocol B of the present invention needs only two point multiplications on each device to achieve PFS. The protocol Elsevier2019 [5] is lightweight but its practicality is severely constrained by the PUF reliability problem. Besides, discussed above, it is also vulnerable to modeling attacks. The number of cost-effective hash operation rounds of JIoT2017 [6] is similar to the proposed protocols, but JIoT2017 [6] requires more MAC, encryption/decryption, PUF and the associated ECC operations. Therefore, its overall complexity is estimated to be higher than the proposed protocol besides its need for a trust server. In addition to the high performance, privacy and security achievable without the need for a trusted third party, our proposed protocol outperforms other existing schemes in terms of its low component cost for direct P2P authentication and the avoidance of storing a secret key locally.

[0117] FIG. 8 is a table showing a comparison of communication and storage costs for protocols. Another important factor for protocol comparison is the communication bandwidth and storage costs, which can be calculated for each device pair. Note that global public parameters like the elliptic curve to be used are not accounted. Following the same generalization setting in [7], the device identities and timestamps are assumed to be 32 bits, the outputs of hash, private keys, random nonces, and challenges and responses of PUFs are all recommended to be 256 bits. The tag produced by MAC operations is assumed to be 128 bits. As for elliptic curve points, we assume each point (P.sub.x, P.sub.y) is 512 bits, where P.sub.x and P.sub.y denote the 256-bit x and y coordinates, respectively. Besides, we assume the encryption method used in [6] is also the CTR-mode encryption and the ciphertext and plaintext are assumed to have the same length. As shown in FIG. 8, those protocols that involve a third party in the mutual authentication process, i.e., JIoT2017 [6], TDSC2018 [4] and Elsevier2019 [5], require a higher number of message exchanges. Though the first two protocols [4], [6] have minimum storage cost per device pair, their respective total communication cost is much higher than other protocols in comparison. Each of the two proposed protocols can be completed with only three message passes, and consumes very low bandwidth (around 3,000 bits) and storage (around 1,000 bits).

[0118] In summary, based on the results of the comparison in FIG. 6 to FIG. 8, the proposed PUF-based mutual authentication and key exchange protocols provide a very high-level of security and require comparatively low computational complexity, communication bandwidth and storage cost.

[0119] Thus, embodiments of the present invention enable direct connections between IoT devices. Data is only stored in the local devices without storing in a central server, which provides high security and privacy, and low latency and development cost. The proposed protocol can be used to benefit smart home applications, e.g., remote control of security cameras or smart locks, or drone remote control and surveillance, or communication between a window actuator and its external weather station, and so on. In such applications, the proposed protocol allows the host to turn on the smart lock or water heater using their phones remotely; to see a live video feed on their smartphone directly, or control the drone with low latency, or adjust the window quickly according to the outside weather conditions. With no need of a relay server, this greatly reduces an expensive and long-term cost of server traffic. Besides, the proposed protocol enables end-to-end data encryption, which can protect information like the video streaming from being leaked. Unlike existing hardware-based or software-based solutions, no secrets are required to be stored in those IoT devices, which greatly reduces the risk of tampering attacks.

[0120] Whilst the foregoing description has described exemplary embodiments, it will be understood by those skilled in the art that many variations of the embodiments can be made within the scope and spirit of the present invention. As the present invention is platform and communication interface agnostic, its application is not limited to securing off-chip communication. One good example of on-chip P2P network is a System-in-Package (SiP) chip, where smaller chiplets replace a large functional equivalent monolithic System-on-Chip (SoC), While disaggregating SoC into multiple chiplets offer numerous cost and performance advantages, it also increases the attack surface. Chiplets are exposed to rising risks of hardware-based trojans and man-in-the-middle (MITM) attacks. This invention provides a solution to authenticate the legitimacy of third-party chiplets and protect sensitive data transfers among chiplets to prevent them from being eavesdropped or sabotaged.

REFERENCES

[0121] [1] J. R. Wallrabenstein, “Practical and secure IoT device authentication using physical unclonable functions,” in Proc. 2016 IEEE 4th Int. Conf. Future Internet Things Cloud (FiCloud). Vienna, Austria: IEEE, August 2016, pp. 99-106. [0122] [2] T. Idriss and M. Bayoumi, “Lightweight highly secure PUF protocol for mutual authentication and secret message exchange,” in Proc. 2017 IEEE Int. Conf. RFID Technol. Appl. (RFID-TA). Warsaw, Poland: IEEE, 2017, pp. 214-219. [0123] [3] P. Gope and B. Sikdar, “Lightweight and privacy-preserving two-factor authentication scheme for IoT devices,” IEEE Internet Things J., vol. 6, no. 1, pp. 580-589, February 2018. [0124] [4] U. Chatterjee, V. Govindan, R. Sadhukhan, D. Mukhopadhyay, R. S. Chakraborty et al., “Building PUF based authentication and key exchange protocol for IoT without explicit CRPs in verifier database,” IEEE Trans. Dependable Secure Comput., vol. 16, no. 3, pp. 424-437, May-June 2018. [0125] [5] M. Barbareschi, A. De Benedictis, E. La Montagna, A. Mazzeo, and N. Mazzocca, “A PUF-based mutual authentication scheme for cloud-edges IoT systems,” Future Generation Comput. Syst., vol. 101, pp. 246-261, December 2019. [0126] [6] M. N. Aman, K. C. Chua, and B. Sikdar, “Mutual authentication in IoT systems using physical unclonable functions,” IEEE Internet Things J., vol. 4, no. 5, pp. 1327-1340, October 2017. [0127] [7] S. Li, T. Zhang, B. Yu, and K. He, “A provably secure and practical PUF-based end-to-end mutual authentication and key exchange protocol for IoT,” IEEE Sensors J., vol. 21, no. 4, February 2021.