Security of a PUF Mutual Authentication and Session Key Establishment Protocol for IoT Devices

Abstract

Recently, Zerrouki et al. proposed a Physically Unclonable Function (PUF) mutual authentication and session key establishment protocol for IoT (Internet of Things) devices. Zerrouki et al.’s PUF protocol is interesting because it does not require the storage of any sensitive information on the local memory of the IoT device, which avoids many potential attacks, especially side-channel attacks. Therefore, we carefully investigate the security of Zerrouki et al.’s PUF protocol under the leakage assumption of the session key. Our findings are in the following. First, Zerrouki et al.’s PUF protocol fails to provide known-key security. That is, the adversary can impersonate not only the server to cheat the IoT device but also the IoT device to cheat the server when the adversary corrupts a session key between the server and the IoT device. Second, Zerrouki et al.’s PUF protocol suffers from the key-compromise impersonation attack. It means that the adversary can impersonate the IoT device to cheat the server if the adversary discloses the server’s secret key. Third, Zerrouki et al.’s PUF protocol does not support backward secrecy for the session key. That is, the adversary is always able to derive the session key from the previous session key. We also suggest the root cause of these security flaws in Zerrouki et al.’s PUF protocol. As a case study, our cryptanalysis results would promote a security model for more robust and efficient PUF authentication and session key establishment protocol. Moreover, our idea of the key compromise can be used to evaluate other novel PUF protocol designs.

1. Introduction

With the Internet and Web expansion into physical reality, the Internet of Things (IoT) is driving the next wave of innovation in both network models and computational technology. However, compared to traditional networks, IoT-driven networks are more prone to security exploitation due to the huge number of complex, heterogeneous, and interoperable IoT devices [1]. Therefore, more robust security technology is required to prevent the illegal leakage of sensitive data through the theft and hacking of IoT devices. In practice, the authentication and session key establishment protocol aims to secure sessions and support confidential data transmission for IoT devices.

However, the design of the authentication and session key establishment protocol is a daunting task in IoT networks. On the one hand, any security weakness in the protocol allows a compromised IoT device to gain access to the IoT trusted network and conduct unauthorized communication, inject false data, access confidential data, and launch dangerous attacks. On the other hand, it is challenging to deploy traditional authentication protocols because of the processing resource limitation of IoT devices. Hence, there is a desire for strong but lightweight authentication and session key establishment protocol for IoT devices.

A Physically Unclonable Function (PUF) [2] is an irreversible probabilistic function that produces a random bit string. PUF has been widely employed as a security primitive to provide device identification and authentication. There are many application scenarios of PUF. A software license requires a software license key or a product key that is used during the installation of software. This key authorizes a genuine purchase of the software product by the user and verifies the authenticity of the software installation copy. The adversary may attempt to steal the key and hence cracks the copies of the original versions. To defend against such piracy behavior, software companies may resort to using a PUF to generate the key. The PUF also can protect the intellectual property of Field Programmable Gate Array (FPGA) design modules. The identity of a hardware device can be recognized by comparing the PUF response to the registered one to find the misappropriation of hardware device and FPGA design modules.

The silicon PUF [3] eliminates the need to store secret keys in the device memory. This feature makes it a potential alternative to designing more low-cost authentication and session key establishment protocols. Hence, in this paper, we investigate the PUF authentication and session key establishment protocols for IoT devices.

1.1. Related Work

Delvaux et al. [4] reviewed 19 early PUF entity authentication protocols in chronological order: from the original PUF proposal (2001) to the more complicated noise bifurcation and system PUF proposals (2014). Gope and Sikdar [5] presented current progress and open challenges in designing PUF authentication and session key establishment protocols for IoT devices. According to the different PUF assumptions, we can briefly classify the PUF protocols for IoT devices into three categories, which are as follows:

• Ideal PUF construction. The ideal PUF protocol provides a baseline for the design of PUF protocols and is useful for supporting authentication and session key establishment. The ideal PUF protocols [6,7] always generate a secret stable PUF response at runtime under controlled operating conditions.
• Noisy-based PUF construction with Fuzzy Extractor (FE)/reverse FE. One of the limitations of PUFs is their sensitivity to the environmental noise incurred by ambient and operating conditions. The response of a PUF to the same challenge may be changed due to the current conditions, for example, temperature and voltage levels. FEs [8,9] were proposed as a solution to this problem. Due to the complex and time-consuming nature of FEs, reverse FEs [10,11] were developed for the fast implementation of secure sketches and FEs. Many researchers proposed the PUF authentication and session key establishment protocols using FE or reverse FE. Some PUF protocols aim to provide additional security and privacy functions. Guan et al. [12] proposed a PUF identity authentication protocol that employs the unique identification information generated by both the PUF and passwords set by users. Aman et al. [13] presented a PUF protocol, which requires the exchange of only two messages between the server and the IoT device. Mostafa et al. [14] designed a lightweight mutual two-factor authentication mechanism. Idriss et al. [15] demonstrated a lightweight PUF-based protocol that uses secret pattern recognition to offer mutual authentication and authenticated secret message exchange for constrained devices. An et al. [16] proposed a lightweight anonymous authentication protocol that does not require the storage of a large number of Challenge–Response Pairs (CRPs). Wang et al. [17] proposed a PUF protocol that introduces the supplementary sub-protocol to enhance resistance to the desynchronization attack. Zerrouki et al. [18] proposed a mutual authentication and a session key establishment protocol for IoT devices based on Silicon PUFs using Arbiter chips. Other PUF protocols emphasize the design for special application scenarios. Gope and Sikdar [19] proposed a novel privacy-aware authenticated key agreement scheme for secure smart grid communication. Kaveh et al. [20] designed a two-way physically secure signcryption scheme for secure smart grid communication. Yanambaka et al. [21] presented a device authentication scheme that uses PUFs and is suitable for the Internet-of-Medical-Things (IoMT). Shao et al. [22] proposed an anonymous PUF authentication protocol for Wireless Medical Sensor Networks (WMSNs) by using PUFs, FE, cryptographic one-way hash functions, and bitwise XOR operations. Alkatheiri et al. [23] designed a PUF authentication protocol for an Unmanned Aerial Vehicle (UAV)-based multi-agent system robust. Yu et al. [24] designed a PUF authentication protocol for the Internet of Drones (IoD) to guarantee reliable and useful services in smart city environments. Zheng et al. [25] demonstrated a lightweight PUF-based mutual authentication and key exchange protocol for Peer-to-Peer (P2P) IoT applications.
• Training PUF model-based construction. Machine Learning (ML) modeling attacks [26] have emerged as the primary security issue for PUF protocols. In such attacks, the ML algorithm collects and analyzes the data from a PUF and uses them to create a model for the PUF. Therefore, we require ML-attack-resilience-based PUF authentication and session key establishment protocols. Majzoobi et al. [27] proposed a Slender PUF protocol that does not follow the classic paradigm of exposing the full PUF responses. They demonstrated that the Slender PUF protocol could be resilient against known ML modeling attacks if carefully designed. Huang et al. [28] proposed a lightweight mutual authentication protocol based on configurable tristate PUFs that can resist ML modeling attacks. However, these protocol-level approaches are not scalable, meaning that they are unsuitable for most IoT environments.

Concerning the security strength, training PUF model-based construction possibly achieves strong authentication and session key, compared with ideal PUF construction and noisy-based PUF construction with FE/reverse FE. In view of implementation concerns, noisy-based PUF construction with FE/reverse FE is more robust than ideal PUF construction and training PUF model-based construction.

1.2. Our Contributions

Zerrouki et al.’s PUF protocol [18] is interesting because it does not require the storage of any sensitive information on the local memory of the IoT device, which avoids many potential attacks, especially side-channel attacks. Moreover, using the Verifpal tool, the security of Zerrouki et al.’s PUF protocol is evaluated by the formal method. In addition, Zerrouki et al. performed a comparison of the PUF protocols and discussed the advantages and efficiency of Zerrouki et al.’s PUF protocol. The reader is referred to [18] for these full technique details.

Therefore, in this paper, we carefully study the security of Zerrouki et al.’s PUF protocol. Our results are as follows:

• Zerrouki et al.’s PUF protocol fails to provide known-key security. That is, when an adversary knows a previous session key of Zerrouki et al.’s PUF protocol, they can impersonate not only the IoT device to cheat the server but also the server to cheat the IoT device.
• Zerrouki et al.’s PUF protocol suffers from key-compromise impersonation attacks. This means that an adversary can impersonate an IoT device to cheat the server when the adversary captures the secrets of the server of the corresponding IoT device.
• Zerrouki et al.’s PUF protocol does not support backward secrecy for the session key. We demonstrate that once an adversary finds the current session key between the IoT device and the server, the adversary can continuously derive all their subsequent session keys from it.

Table 1. Used Notation.

Notations	Descriptions
IDA	The identity of an IoT device A
Regreq	Registration request
Authreq	Authentication request
CA,i/CA,i+1	The ith/i+1st challenge of the IoT device A
RA,i/RA,i+1	Response to the challenge CA,i/CA,i+1
R’A,i	A noisy response of CA,i
KA,i/KA,i+1	Extracted key from RA,i/RA,i+1
PA,i/PA,i+1	Helper data of RA,i/RA,i+1
TS1, TS2, TS3, TSa1, TSa2, TSa3	Timestamps
PUF, PUF1, PUF2, PUF3, PUFn	The PUF instances
PUFA	The PUF of an IoT device A
Gen	Generation procedure of FE
Rep	Reproduction procedure of FE
h	Cryptographic one-way hash function
()K	Encryption function using the secret key K

summarizes the notations and cryptographic functions used throughout the paper.

2. Supported Security Mechanisms

2.1. PUF

A PUF is a security primitive that exploits physicality randomness in PUF-based devices. An example is silicon PUFs, which are a sub-class of PUFs. Because of manufacturing differences, an integrated circuit (IC) maintains unique physical characteristics. That is, the output of each IC will be unique for the given input. Hence, a silicon PUF is designed by extracting the unique output that is called the response from an input that is called the challenge. Here, a challenge and its corresponding response form a so-called CRP. As shown in Figure 1, it is impossible for PUFs to output the same response when the different challenges are inputted, and the different PUFs output the same response when the same challenge is inputted. Zerrouki et al. [18] divided the silicon PUF into three major classes: memory-based PUFs, delay-based PUFs, and analog–electronic PUFs.

The device embedded in the IC uses its silicon PUF for security applications, such as cryptographic key generation and authentication. Depending on the number of CRPs, silicon PUFs have two categories: weak PUFs and strong PUFs. A weak PUF is capable of generating a small number of CRPs and, therefore, is applied to derive cryptographic keys. Comparatively, a strong PUF provides a very large number of CRPs and is more suitable for authentication protocols.

2.2. Fuzzy Extractor

Intrinsically, the noises in the IC environments affect the reliability of the silicon PUF. When the same challenge is input into the PUF, the noises may cause errors in one or more response bits of the PUF and result in an incorrect response that differs from the original generated one. Therefore, in practice, cryptographic applications do not directly make use of the responses of the PUF.

As a coding technique, the FE can extract uniform random strings from noisy and non-uniform random data. Hence, the FE can eliminate the response noises of the PUF and achieve error correction for the responses of the PUF. As shown in Figure 2, the FE consists of a pair of algorithms, i.e., generation (Gen) and reproduction (Rep). Gen takes the initial response W as the input, and the outputs are uniform random string R, and the cryptographic key and a non-secret string P are the public helper data. To reproduce the uniform random string, the Rep algorithm takes two inputs: noisy response W’ and public helper data P. The reproduction process can succeed in recovering the uniform random string R when W and W’ are very close [29].

3. Zerrouki et al.’s Models of PUF Protocol

Many systems are related to IoT to some extent, such as Smartphone-assisted systems [30,31] for wearable devices, Blockchain-based systems [32,33,34,35] for multi-WSN (Wireless Sensor Networks), privacy-preserving verifiable data sharing, and smart city applications. We can compare them with Zerrouki et al.’s system and protocol. First, wearable devices, multi-WSN, and smart city applications systems dedicate to special network architectures. Comparatively, Zerrouki et al.’s system focuses on a general client–server network architecture. Second, Blockchain-based systems need to employ Blockchain techniques, and Zerrouki et al.’s system makes use of PUF. Third, PUF mutual authentication and session key establishment protocols may be embedded into those systems when the authentication service and the confidentiality service are necessary.

3.1. System Model

To design the PUF protocol, Zerrouki et al.’s system model describes the network architecture and its network component’s requirements. As shown in Figure 3, Zerrouki et al.’s system model has two types of entities: the IoT devices and the server. The IoT devices could equip various sensors. After a session of the PUF protocol, both the IoT device and the server authenticate each other and establish a session key for the subsequent secure communication. Certainly, the server needs secretly to store the security parameters of the IoT devices during the enrollment phase. Zerrouki et al.’s system model further assumes that:

• IoT devices are resource-constrained; that is, IoT devices merely have limited capabilities of computation, memory, communication, and energy.
• Each IoT device is equipped with an IC consisting of a PUF, which can provide the unique CRPs for the IoT device’s security applications.
• The server has not the limitation of processing resources. This means that the server can carry out hardware/software network security solutions such as intrusion detection systems/intrusion prevention systems, firewalls, and anti-denial of service systems.

3.2. Security Model

In Zerrouki et al.’s security model, IoT devices are untrustworthy because they lack physical or hardware/software protection and are even deployed in public and hostile spaces. Meanwhile, the adversary can eavesdrop on the exchanged messages and alter them during the session of the PUF protocol. More importantly, an adversary may capture IoT devices and obtain critical secrets from their local memory. However, the adversary cannot exploit a PUF to simulate another one due to PUF’s unique physical characteristics. In addition, the communication between the IoT device microcontroller and its PUF component is through a secure channel.

Zerrouki et al.’s security model treats the server as the trusted party. In addition, the server and the IoT device should execute the enrollment phase in a secure environment.

4. Zerrouki et al.’s PUF Mutual Authentication and Session Key Establishment Protocol

Zerrouki et al.’s PUF protocol consists of three modules, i.e., the enrollment phase, the authentication phase, and the session key establishment phase. Their protocol employs both the PUF and the FE to secure the IoT devices and the trusted server. The IoT device registers to the server during the enrollment phase. After that, the IoT device and the server authenticate each other and secretly share a session key via the run of the authentication phase and the session key establishment phase.

4.1. Enrollment Phase

When a new IoT device A wants to be a member of the trusted network, both IoT device A and the server firstly enter into the enrollment phase. After successful registration, IoT device A becomes a legal member of the trusted network and never seeks the server’s permission to enroll. Figure 4 illustrates the enrollment phase. The detailed steps are as follows.

Step 1. IoT device A sends the message {ID_A, Reg_req}.

Step 2. Upon receiving {ID_A, Reg_req}, the server randomly generates C_A,i and sends the message {ID_A, C_A,i} back to the IoT device A.

Step 3. Upon receiving {ID_A, C_A,i}, IoT device A computes R_A,i by PUF_A(C_A,i). Then, IoT device A sends the message {ID_A, C_A,i, R_A,i} to the server.

Step 4. Upon receiving {ID_A, C_A,i, R_A,i}, the server extracts K_A,i and P_A,i by using Gen(R_A,i), where (K_A,i, P_A,i) = Gen(R_A,i). Then, the server hashes ID_A and K_A,i using h and further stores ID_A, h(ID_A), C_A,i, h(K_A,i), and P_A,i on its secure local database. In the end, the server informs IoT device A about the completion of the registration process.

4.2. Authentication Phase

During the authentication phase, the IoT device uses the CRP of the PUF as a fingerprint to prove its identity to the server. Hence, the IoT device does not store any secret information and therefore avoids physical attacks. They perform the following steps:

Step 1: IoT device A finds the current TS₁ and calculates h(ID_A) and h(ID_A, TS₁). Then, IoT device A sends the message {h(ID_A), Auth_req, TS₁, h(ID_A, TS₁)} to the server.

Step 2: Upon receiving {h(ID_A), Auth_req, TS₁, h(ID_A, TS₁)}, the server executes the following operations.

Step 2.1: The server searches the existence of the received h(ID_A) in its secure local database and retrieves ID_A, h(ID_A), C_A,i, h(K_A,i), and P_A,i. If the finding fails, the server rejects the authentication request.

Step 2.2: The server calculates h(ID_A, TS₁) and further verifies whether the calculated h(ID_A, TS₁) is equal to the received one. If the comparison fails, the server rejects the authentication request.

Step 2.3: The server finds the current TS₂ and calculates h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS₂). Then, the server sends message {C_A,i, P_A,i, TS₂, h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS₂)} to the IoT device A.

Step 3: Upon receiving {C_A,i, P_A,i, TS₂, h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS₂)}, IoT device A executes the following operations.

Step 3.1: IoT device A uses its PUF to generate R’_A,i = PUF_A(C_A,i). Since R’_A,i is noisy, IoT device A reproduces K_A,i by using Rep(R’_A,i, P_A,i). IoT device A calculates h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS₂) and verifies whether the calculated h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS₂) is equal to the received one. If the comparison fails, IoT device A terminates the session. Otherwise, IoT device A authenticates the server.

Step 3.2: IoT device A computes C_A,i+1 = h(C_A,i‖K_A,i) and R_A,i+1 = PUF_A(C_A,i+1), and then finds the current TS₃, calculates h(h(ID_A), TS₃, h(K_A,i), R_A,i+1), and encrypts R_A,i+1 using the key h(K_A,i). IoT device A sends the message {TS₃, h(h(ID_A), TS₃, h(K_A,i), R_A,i+1), (R_A,i+1)_h(KA,i)} to the server.

Step 4: Upon receiving {TS₃, h(h(ID_A), TS₃, K_A,i, R_A,i+1), (R_A,i+1)_h(KA,i)}, the server decrypts (R_A,i+1)_h(KA,i) by the key h(K_A,i) and further computes its h(h(ID_A), TS₃, h(K_A,i), R_A,i+1). The server verifies whether the calculated h(h(ID_A), TS₃, h(K_A,i), R_A,i+1) is equal to the received one. If the comparison fails, the server terminates the session. Otherwise, the server authenticates the IoT device A.

Note that in [18], Zerrouki et al.’s PUF protocol demands that IoT device A computes h(h(ID_A), TS₃, K_A,i, R_A,i+1) in Step 3.2 and the server verifies it in Step 4. However, it is incorrect because the server does not know K_A,i during the authentication phase and cannot verify h(h(ID_A), TS₃, K_A,i, R_A,i+1). Hence, h(K_A,i) should replace K_A,i in Step 3.2 and Step 4.

4.3. Session Key Establishment Phase

IoT device A and the server use h(K_A,i) as the session key. The server generates (K_A,i+1, P_A,i+1) = Gen(R_A,i+1), calculates C_A,i+1 = h(C_A,i‖h(K_A,i)), and hashes K_A,i+1 to achieve h(K_A,i+1). Then, the server updates the stored C_A,i, h(K_A,i), and P_A,i of IoT device A to the new computed C_A,i+1, h(K_A,i+1), and P_A,i+1 for the next session.

We need to point out that Zerrouki et al.’s PUF protocol [18] does not require checking the freshness of TS₁, TS₂, and TS₃. This is not correct. We add them in Figure 5, which depicts the process of the authentication and session key establishment between IoT device A and the server.

5. Known-Key Security of Zerrouki et al.’s PUF Protocol

The server and the IoT device should secretly produce a new random session key after the run of a PUF mutual authentication and session key establishment protocol. These session keys are desirable in order to limit the amount of data available for cryptanalytic attacks, for example, ciphertexts generated using a session key in the encryption application. That is to say that the session keys aim to limit exposure in the event of session key leakage. The known-key security demands that a sound protocol should still achieve its security goal in the face of an adversary who has learned some previous session keys [36,37]. The known-key security is necessary for PUF mutual authentication and session key establishment protocol. In practice, an adversary can hijack the session of the protocol to reveal the obsolete session key. One hijacking approach is that the adversary may persuade the victim’s IoT device to install malicious protocol execution software, which leaks the secrets during the IoT device’s protocol run. An alternative approach to obtain session keys is to use social engineering. The adversary directly demands that the IoT device outputs the session key because they want to use the session key to decrypt some encrypted messages. The IoT device may provide the session key when the adversary is granted access to these encrypted messages.

We know that the session key in Zerrouki et al.’s PUF protocol is h(K_A,i). Hence, to evaluate the known-key security, we assume that the adversary knows h(K_A,i) in Zerrouki et al.’s PUF protocol.

5.1. Impersonating Server Attack

Figure 6 describes our impersonating server attack on Zerrouki et al.’s PUF protocol. When IoT device A wants to start a new session, the adversary, who takes the role of server, communicates with IoT device A as follows:

(1)

In Step 1 of the authentication phase, IoT device A sends the message {h(ID_A), Auth_req, TS₁, h(ID_A, TS₁)} to the adversary.

(2)

Upon receiving the message, the adversary finds their current TS_a2, calculates h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS_a2), and sends the message {C_A,i, P_A,i, TS_a2, h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS_a2)} to IoT device A in Step 2.3 of the authentication phase. We know that the adversary is able to calculate this h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS_a2), because in the previous session, the IoT device A’s values h(ID_A), C_A,i, and P_A,i were transmitted over the insecure channel, and the adversary can eavesdrop on them.

(3)

According to Step 3.1 of the authentication phase, IoT device A successfully checks the validity of TS_a2. Then, IoT device A should compute R’_A,i = PUF_A(C_A,i) and then recover K_A,i by using Rep(R’_A,i, P_A,i). Moreover, IoT device A can confirm that the calculated h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS_a2) is equal to the receiving h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS_a2), because these two values are computed using the fully same inputs of h and h is the deterministic hash function. As a result, IoT device A should authenticate the adversary as the server.

(4)

In Step 3.2 of the authentication phase, IoT device A generates and sends the message {TS₃, h(h(ID_A), TS₃, h(K_A,i), R_A,i+1), (R_A,i+1)_h(KA,i)} to the adversary.

(5)

Upon receiving the message, the adversary obtains R_A,i+1 during Step 4 of the authentication phase because he/she knew h(K_A,i) and can encrypt (R_A,i+1)_h(KA,i) using h(K_A,i).

(6)

In the session key establishment phase, the adversary also is able to generate C_A,i+1, P_A,i+1, and h(K_A,i+1) because he/she knew C_A,i, K_A,i, and R_A,i+1 and h and Gen are public functions. Now, the adversary has C_A,i+1, P_A,i+1, and h(K_A,i+1) to impersonate the server in the next session.

Figure 6. Impersonating server attack.

Figure 6. Impersonating server attack.

According to the above, we conclude that IoT device A mistakenly believes the adversary is the server at the end of the session. At the same time, IoT device A and the adversary share the session key, i.e., h(K_A,i).

Further discussion. On the other hand, IoT device A and the server should still authenticate each other using Zerrouki et al.’s PUF protocol, even if the adversary exploits our impersonating server attack. The reason is that the server updated the parameters C_A,i+1, h(K_A,i+1), and P_A,i+1 during the previous session key establishment phase and should believe that these parameters are valid for IoT device A. Therefore, both IoT device A and the server are uneasy about recognizing the adversary when the impersonating server attack happens in Zerrouki et al.’s PUF system.

One related problem is that the adversary must distinguish the targeted IoT device A from other IoT devices when there are multiple IoT devices attempting to establish sessions with the real server over insecure channels. In this case, the adversary can eavesdrop on each IoT device’s {h(ID_A), Auth_req, TS₁, h(ID_A, TS₁)} during Step 1 of the authentication phase in Zerrouki et al.’s PUF protocol. The adversary verifies whether the receiving h(ID_A) is equal to their local h(ID_A). If they are equal, then the adversary continuously implements the above impersonating server attack; otherwise, the adversary allows it to communicate with the real server. Another related problem is that Zerrouki et al.’s PUF system always has trusted IoT devices and untrusted IoT devices at the same time. It is necessary to tell a trusted IoT device from its rogue counterpart. The adversary can identify the targeted IoT device A if they further verify h(h(ID_A), TS₃, h(K_A,i), R_A,i+1) during (5) of the above impersonating server attack. We know other untrusted IoT devices cannot generate h(h(ID_A), TS₃, h(K_A,i), R_A,i+1) because they do not have correct h(K_A,i). However, the adversary cannot figure other trusted IoT devices out if they do not corrupt their corresponding secrets.

5.2. Impersonating IoT Device Attack

Note that Zerrouki et al.’s security model assumes that IoT devices are untrustworthy. Hence, IoT device A may disclose its ID_A to the adversary. Moreover, we need to point out that (R_A,i+1)_h(KA,i) was generated by IoT device A in the previous session and further sent over an insecure channel in Step 3.2 of the authentication phase. Therefore, the adversary can eavesdrop on (R_A,i+1)_h(KA,i) during the previous session of IoT device A and decrypt (R_A,i+1)_h(KA,i) using h(K_A,i). The adversary can generate (K_A,i+1, P_A,i+1) = Gen(R_A,i+1) and calculate h(K_A,i+1). Then, the adversary sets R_A,i = R_A,i+1 and h(K_A,i) = h(K_A,i+1). At the same time, the server should replace C_A,i, P_A,i, and h(K_A,i) by C_A,i+1, P_A,i+1, and h(K_A,i+1) in the session key establishment phase of the previous session.

Figure 7 depicts our impersonating IoT device attack on Zerrouki et al.’s PUF protocol. When the adversary wants to personate the IoT device A, the adversary starts a session with the server as follows:

(1)

In Step 1 of the authentication phase, the adversary finds their current TS_a1 and calculates h(ID_A) and h(ID_A, TS_a1). The adversary then transmits the message {h(ID_A), Auth_req, TS_a1, h(ID_A, TS_a1)} to the server.

(2)

Upon receiving the message, the server performs the following operations according to Step 2 of the authentication phase. (1) The server confirms the validity of TS_a1. (2) The server uses h(ID_A) to search the record ID_A, h(ID_A), C_A,i, h(K_A,i), and P_A,i in its secure local database and then calculates h(ID_A, TS_a1) and successfully checks the calculated h(ID_A, TS_a1) is equal to the received h(ID_A, TS_a1). (3) The server further finds its current TS₂, computes h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS₂), and transmits the message {C_A,i, P_A,i, TS₂, h(h(ID_A), C_A,i, P_A,i, h(K_A,i), TS₂)} to the adversary.

(3)

In Step 3.1 of the authentication phase, the adversary omits all operations of IoT device A.

(4)

In Step 3.2 of the authentication phase, the adversary encrypts their R_A,i using the key h(K_A,i), find their current TS_a3, and calculates h(h(ID_A), TS_a3, h(K_A,i), R_A,i). Additionally, then, the adversary sends the message {TS_a3, h(h(ID_A), TS_a3, h(K_A,i), R_A,i), (R_A,i)_h(KA,i)} to the server.

(5)

Upon receiving the message, the server confirms the validity of TS_a3. Then, the server uses its key h(K_A,i) to decrypt (R_A,i)_h(KA,i) and further computes h(h(ID_A), TS_a3, h(K_A,i), R_A,i). The server should successfully check that the calculated h(h(ID_A), TS₃, K_A,i, R_A,i) is equal to the received h(h(ID_A), TS_a3, h(K_A,i), R_A,i). As a result, the server authenticates the adversary as IoT device A.

(6)

In the session key establishment phase, the server should continue to compute C_A,i+1 = h(C_A,i‖h(K_A,i)), generate (K_A,i, P_A,i) = Gen(R_A,i), and hash K_A,i using h. Additionally, the server updates old C_A,i, P_A,i, and h(K_A,i) to new C_A,i+1, P_A,i, and h(K_A,i) for the next session. Note that in Zerrouki et al.’s PUF protocol, the server requires the calculation of C_A,i+1 = h(C_A,i‖K_A,i). However, the server does not store K_A,i in its secure local database. Hence, the server should use h(C_A,i‖h(K_A,i)) instead of h(C_A,i‖K_A,i) to compute C_A,i+1.

Figure 7. Impersonating IoT device attack.

Figure 7. Impersonating IoT device attack.

After impersonating the IoT device attack, we know that the server mistakenly believes the adversary is IoT device A at the end of the session. At the same time, both the server and the adversary share the session key, i.e., h(K_A,i).

Further discussion. In the subsequent session, IoT device A and the server will fail to authenticate each other because IoT device A will use the server’s C_A,i and P_A,i to recover R’_A,i and K_A,i in Step 3.1 of the authentication phase. However, P_A,i is an error helper data for R_A,i because the server applies R_A,i but not R_A,i+1 to generate the helper data P_A,i+1 in the adversary’s session. This means that our impersonating IoT device attack leads to Denial of Service (DoS). Comparatively, the adversary still can personate IoT device A to cheat the server in the subsequent sessions because he/she directly uses the correct session key h(K_A,i) to perform the impersonating IoT device attack, and the server does not check the correctness of the received R_A,i and R_A,i+1.

6. Key-Compromise Impersonation

Key-compromise impersonation [36,37] is a desirable security attribute for mutual authentication and session key establishment protocols. Considering that the server’s secret keys are disclosed, clearly, an adversary that knows these secret keys can impersonate the server since these secret keys precisely identify the server. However, it may be desirable in some circumstances that this loss does not enable the adversary to impersonate other IoT devices on the server.

In Zerrouki et al.’s PUF protocol, the server maintains the record ID_A, h(ID_A), C_A,i, h(K_A,i), and P_A,i for IoT device A on its secure local database. When we assume that the adversary obtains ID_A, h(ID_A), C_A,i, h(K_A,i), and P_A,i for IoT device A, it is easy to see that the adversary can impersonate IoT device A on the server. The impersonating IoT device attack described in Section 5.2 is a practical way to realize key-compromise impersonation. As a result, we claim that Zerrouki et al.’s PUF protocol fails to achieve the security of key-compromise impersonation.

7. Backward Secrecy of Zerrouki et al.’s PUF Protocol

Backward secrecy [38] guarantees that a passive adversary who knows a contiguous subset of session keys cannot discover future session keys. To corrupt the backward secrecy of mutual authentication and session key establishment protocol, the adversary always exploits the fact that the sessions have a certain relevance.

In Zerrouki et al.’s PUF protocol, we assume that an adversary knows h(K_A,i), which will be used in the next session between IoT device A and the server. Whenever IoT device A and the server run the next session, the adversary can eavesdrop on the message {TS₃, h(h(ID_A), TS₃, K_A,i, R_A,i+1), (R_A,i+1)_h(KA,i)} in Step 3.2 of the authentication phase. Then, the adversary decrypts (R_A,i+1)_h(KA,i) by using their h(K_A,i). The adversary further generates (K_A,i+1, P_A,i+1) = Gen(R_A,i+1) and hashes K_A,i+1 to find the next session key h(K_A,i+1). This tracking process of the session keys can always continue as long as IoT device A and the server run the sessions. Hence, we demonstrate that Zerrouki et al.’s PUF protocol fails to provide backward secrecy for the session key.

8. Verification Experiment of Our Attacks

Scyther [39] is a tool for the automatic verification of security protocols. Scyther can verify protocols with unlimited sessions and random numbers. Scyther had been used to analyze Internet Key Exchange (IKE) protocol suites and ISO/IEC 9798 authentication protocol series. We use Scyther to confirm our attacks on Zerrouki et al.’s PUF protocol. Known-key security, key-compromise impersonation, and backward secrecy of Zerrouki et al.’s PUF protocol all depend on the assumption of the obsolete session key leakage. We, therefore, write it into the protocol description of Zerrouki et al.’s PUF protocol in Scyther. For Zerrouki et al.’s PUF protocol, Figure 8 shows that the Noninjective synchronization (Nisynch) and Noninjective agreement (Niagree) properties are not satisfied, and the session key, i.e., h(K_A,i), is proved to be insecure. According to the verification of Zerrouki et al.’s PUF protocol, we conclude that the authentication and key establishment process between the IoT device and the server is insecure and suffers from attacks within bound.

9. Conclusions and Future Works

In Zerrouki et al.’s PUF protocol, we find that both the IoT device and the server do not maintain any long-term secret key. In detail, the server stores the record ID_A, h(ID_A), C_A,i, h(K_A,i), and P_A,i for each IoT device A in its secure local database, and the IoT device merely keeps its ID_A. Hence, the session key generation for the next session fully relies on the session key in the current session. This means that Zerrouki et al.’s PUF protocol is insecure when the adversary only compromises one session key. Our finding of the security flaws of Zerrouki et al.’s PUF protocol can be defeated if the IoT device and the server share a long-term secret key and properly apply it to generate each session key. However, it violates Zerrouki et al.’s design requirement for the PUF protocol; that is, the IoT device does not store any secrets to prevent physical attacks. This solution, therefore, is deemed imperfect.

It is still a challenge to design PUF authentication and session key establishment protocols for IoT devices. As a future work, it would be interesting to evaluate the security goals of PUF authentication and session key establishment and present its formal security definitions under the PUF communication model. Our cryptanalysis results of Zerrouki et al.’s PUF protocol provide a reference for the security definitions. Another future work is to propose the PUF authentication and session key establishment protocol, which not only satisfies the formal security definitions but also achieves high-performance efficiency.