Lightweight IoT Authentication Protocol Using PUFs in Smart Manufacturing Industry

Abstract

Over recent years, the Internet of Things (IoT) has been widely adopted in various domains, including modern manufacturing. However, IoT security remains a critical challenge due to resource constraints and deployment in unsecured environments. This paper introduces a lightweight IoT authentication protocol leveraging physical unclonable functions (PUFs) tailored for smart manufacturing. The protocol employs lightweight cryptographic techniques and a PUF-based challenge–response mechanism to ensure key security properties such as confidentiality, integrity, anonymity, and perfect forward secrecy. Through a combination of formal analysis, the proposed protocol demonstrates resilience against prevalent attacks while significantly reducing computational and communication overheads. Comparative performance analysis highlights its efficiency and suitability for resource-constrained IoT environments.

1. Introduction

The Internet of Things (IoT) is an advanced technology that enables seamless communication and data exchange between interconnected devices. IoT devices possess the capability to autonomously process and make decisions regarding connected objects. However, the proliferation of real-time applications and devices has introduced challenges related to the need for intelligent and secure communication. The concept of IoT is continuously evolving, transforming into a comprehensive solution that addresses the growing demands of modern society by utilizing communication systems without human intervention. This evolution is particularly significant, given the vast volumes of data generated in this domain. IoT finds applications in diverse areas such as public safety [1], healthcare [2], smart homes [3], and social networking [4], demonstrating its wide-ranging impact and potential. In particular, IoT plays a vital role in smart manufacturing, where secure and efficient communication between devices ensures operational reliability and data integrity.

A smart manufacturing system refers to the implementation of an integrated network within a manufacturing environment to facilitate seamless communication of information and commands between machining units and end-users. Such systems can function across different communication methods. Transmitting sensitive data requires robust security measures, including unique identification and end-to-end encryption, to protect data integrity and confidentiality [5]. Consequently, every IoT node within the network must be safeguarded against potential external threats. One of the critical considerations in designing a secure smart manufacturing system is ensuring the protection of its communication infrastructure. A promising security approach involves the use of physical unclonable functions (PUFs), which are digital logic designs embedded within integrated circuits (ICs) [6]. PUFs exploit inherent variations in the semiconductor manufacturing process to generate unique, non-replicable identifiers, making them well suited for IoT authentication. As a lightweight and efficient security mechanism, PUFs provide a one-way function that maps a set of inputs (challenges) to corresponding outputs (responses), forming unique challenge–response pairs (CRPs). These CRPs are non-repeatable and specific to each device containing a PUF module, thereby enhancing authentication security (see Figure 1).

In addition to PUFs, complementary security mechanisms, such as unique serial or ID numbers, and true random number generators (TRNGs) are often employed to further strengthen device authentication and data protection by ensuring device uniqueness and providing robust randomness for cryptographic operations.

Therefore, this paper addresses the challenge of securing communication in smart manufacturing by proposing a lightweight and robust authentication protocol based on physical unclonable functions (PUFs) to enhance device authentication and ensure data integrity.

1.1. Related Work

In this section, we provide an overview of advancements in IoT authentication, particularly focusing on machine-to-machine communication. Despite numerous proposals for IoT authentication, limited research has been conducted on lightweight IoT authentication mechanisms that leverage device properties while addressing key security services, such as confidentiality, integrity, data privacy, anonymity, unlinkability, untraceability, and perfect forward secrecy.

Kalra et al. [7] proposed an elliptic curve cryptography (ECC)-based mutual authentication scheme for secure communication between cloud servers and embedded devices. This protocol relies on the hypertext transfer protocol (HTTP). The ECC-based protocol ensures security through cryptographic authentication. Although effective, it does not address the full spectrum of security services required for resource-constrained IoT devices. Patil et al. [8] introduced an innovative authentication framework to enhance the security of IoT communications. This system integrates authentication using signature (AUS) and security with complexity reduction (SCR) techniques, aimed at preventing unknown threats. However, it falls short of providing a lightweight solution that integrates device-specific attributes while ensuring comprehensive security. In a similar context, Liu et al. [9] proposed authenticated key exchange protocols for wireless body area networks (WBANs), using symmetric cryptography for selective node authentication. Although these protocols minimize computational and communication overhead, they fail to address the full range of IoT security requirements. Li, Xiong et al. [10] presented a lightweight mutual authentication protocol with built-in anonymity for WBANs. Although the protocol offers resilience and anonymity against various attacks, it does not fully protect node anonymity, leaving the system vulnerable to the tracking of second-level nodes by attackers.

Shuai et al. [11] developed an anonymous authentication scheme for smart home environments, utilizing elliptic curve cryptography (ECC). This scheme eliminates the need for verification tables during authentication and uses a random number approach to protect against replay attacks. Chatterjee et al. [12] proposed a PUF-based authentication and key exchange protocol for IoT devices, eliminating the need for explicit challenge–response pair (CRP) storage at the verifier. Their work integrated identity-based encryption (IBE) and keyed hash functions, demonstrating its effectiveness in securing IoT infrastructure against man-in-the-middle attacks. Rullo et al. [13] investigated PUF-based authentication for identification tags, addressing security vulnerabilities arising from protocol weaknesses and PUF unreliability. Their work emphasized the importance of hardware design in mitigating attacks and simplifying the tag enrollment process. Although their protocol improves security, it does not fully consider the range of security services and challenges faced by large-scale IoT deployments.

Recent studies have also identified significant trends and challenges in IoT authentication. Alsheavi et al. [14] reviewed IoT authentication protocols, highlighting key challenges such as privacy protection, scalability, and human factors. Their comparative analysis offers valuable insights for future research but lacks practical solutions for addressing these challenges in resource-constrained IoT nodes. Similarly, Kamarudin et al. [15] explored IoT authentication paradigms, summarizing recent developments but offering limited solutions for scaling lightweight authentication mechanisms. Laghari et al. [16] analyzed security trends and challenges in IoT applications, discussing authentication mechanisms for specific deployments. However, they did not consider the unique constraints of industrial IoT systems.

Our approach employs physical unclonable functions (PUFs) for mutual authentication, ensuring efficient security for resource-constrained IoT devices through unique challenge–response pairs (CRPs). It provides key security features such as anonymity, unlinkability, untraceability, and forward secrecy, while addressing clock synchronization with timestamps. This solution integrates mutual authentication and device-specific uniqueness via PUFs, with security being validated using the Burrows–Abadi–Needham (BAN) logic framework and the SPAN/AVISPA tool. Comparative analysis shows its enhanced security and efficiency, particularly for IoT nodes in smart manufacturing.

1.2. Motivations and Contributions

Although several machine-to-machine authentication protocols for IoT have been proposed, they often lack the necessary lightweight characteristics and security to be viable for IoT nodes in the smart manufacturing industry, primarily due to the resource constraints of such nodes. Furthermore, while a few mutual authentication and key agreement protocols have been suggested, very few consider the use of physical unclonable functions (PUFs). PUFs are one-way functions that map a set of inputs (challenges) to corresponding outputs (responses), generating unique, non-repeatable challenge–response pairs (CRPs) specific to each device. Driven by the significance of authentication mechanisms that leverage the uniqueness of PUFs in IoT networks, this paper aims to design a secure protocol that ensures mutual authentication and provides essential security features, including anonymity, untraceability, unlinkability of transmitted messages, and challenge–response-based authentication using PUFs. The key contributions of this paper are listed below:

• We present a secure and efficient mutual authentication protocol based on PUFs, specifically developed for IoT environments. This protocol guarantees essential security attributes such as confidentiality, integrity, anonymity, unlinkability, and untraceability.
• To resolve clock synchronization challenges, our protocol replaces traditional nonces with timestamps, ensuring accuracy and reliability.
• The security of the proposed protocol is rigorously verified using the established Burrows–Abadi–Needham (BAN) logic framework and assessed using the SPAN/AVISPA tool. Additionally, an informal security analysis is provided to further validate the protocol.
• A comparison of our protocol with existing solutions highlights its superior performance in terms of both security robustness and efficiency.

This paper is organized as follows: Section 2 describes the system model that underpins the proposed approach. Section 3 provides a detailed explanation of the secure protocol. In Section 4, we evaluate the security features of the protocol. Section 5 offers an analysis of the protocol’s performance. This paper is concluded in Section 6.

2. Network and Adversary Model

This section outlines the IoT network framework and the adversarial model associated with the designed protocol.

2.1. IoT Network Model

This model is a one-hop (single-tier) architecture, as depicted in Figure 2. It consists of two nodes: the main node (S) and second-level nodes (SNs). The main node, referred to as the local server, is resource-rich and can be implemented as the local server. The SNs are resource-limited sensors.

2.2. Adversary Model

The following adversarial model is used to assess the proposed scheme:

• The server node (S) is considered trustworthy in terms of its legitimate operation and authentication capabilities, but it may be vulnerable to an adversary gaining unauthorized access to its database. This could allow the adversary to steal or manipulate stored information. However, the server’s master secret key (KS) remains secure.
• The adversary has the ability to eavesdrop on all links within the network and may replace or replay previously transmitted messages.
• An adversary can capture any sensor node (SN), granting them access to all confidential information stored in the node’s memory. A full security breach occurs for the captured node. However, this should not compromise the confidentiality of other uncaptured nodes in the network.
• Our security framework is based on the well-established Dolev–Yao threat model [17], which considers communication between two entities over an untrusted channel. The evaluation of our protocol’s security, including analysis and simulation, is performed within this model.

2.3. Challenge–Response Mechanism Based on PUF Model

In our protocol, the physical unclonable function (PUF) enables a challenge–response authentication mechanism. Each sensor node (SN) and the server (S) use PUFs to generate authentication parameters.

The server (S), which embeds a PUF, generates a set of randomly selected challenge values (C) and securely stores only these challenge values in a database (PUF-S). The corresponding response values (R) are dynamically generated by the PUF at the time of authentication, enhancing security by eliminating the need for stored response values. Similarly, the sensor node (SN), which also integrates a PUF, generates and stores its own challenge values (C) in a secure database (PUF-SN), relying on the PUF to produce the corresponding responses (R) when required. This design reduces storage overhead while strengthening security against cloning and tampering.

To introduce a new device into the network, an enrollment phase securely initializes its PUF-based challenge–response authentication parameters. The use of PUFs reinforces system security by ensuring unique authentication parameters, mitigating cloning risks, and protecting against replay attacks and other security threats (see Figure 3).

3. Proposed Protocol

This section outlines the lightweight IoT authentication protocol using PUFs, designed to enhance the security of IoT networks. The protocol effectively mitigates all known attacks while ensuring key security attributes. The notations and symbols used throughout the protocol are summarized in

Table 1. Symbols used in the protocol.

Notation	Description
S	Server (S).
SA	System administrator (SA).
SN	IoT sensor node (SN).
${\mathrm{TP}}_S$	Temporary confidential parameters selected by the S.
${\mathrm{TP}}_{SN}$	Temporary confidential parameters selected by the SN.
${\mathrm{T}}_S$	Timestamp generated by the S.
${\mathrm{T}}_{SN}$	Timestamp generated by the SN.
N	Nonce (random number) used for freshness in communication.
${\mathrm{tid}}_{SN}$	Temporary identity of the SN.
${\mathrm{id}}_{SN}$	Permanent identity of the SN.
${\mathrm{C}}_{SN-S}$	Challenge value stored in the SN table for communication with the S.
${\mathrm{R}}_{SN-S}$	Response value stored in the SN table for communication with the S.
${\mathrm{K}}_S$	Master secret key of the S or the PC.
${\mathrm{k}}_{SN}$, ${\mathrm{f}}_{SN}$	Temporary confidential parameters selected by the S for the SN.
SSK	Session secret key to be agreed upon for secure communication.
${\mathrm{a}}_{SN}$, ${\mathrm{b}}_{SN}$	Authentication-related parameters securely stored within the SN’s memory.
h(..)	Collision-resistant one-way cryptographic hash function.
$\alpha$, $\beta$, y, $\eta$, $\mu$	Authentication parameters used by the S for authentication with the SN.
${\mathrm{x}}_{SN}$, ${\mathrm{y}}_{SN}$	Auxiliary parameters used for authentication.
XY:Z	Entity X transmits message Z to entity Y over a publicly accessible communication channel.
⊕	Bitwise XOR operation.
t	Timestamp or time value used to ensure the freshness of the communication.
C	Cryptographic challenge or commitment value.
MI	Message Integrity value to ensure message authenticity and integrity.
XSN	Shared secret key between the SN and the S for secure communication.
MMR	Message meaning rule

. The protocol is divided into three distinct phases: (1) initialization, (2) registration, and (3) authentication. The system administrator (SA) manages the initialization and registration phases. During the authentication phase, the sensor node (SN) and the server (S) interact for secure, anonymous mutual authentication and session key establishment. It is assumed that the SN communicates directly with the S in this first-level node setup.

3.1. Initialization Phase

The SA performs the following steps to initialize the server (S):

• The SA selects a master secret key $K_S$ for the server (S).
• The SA securely stores $K_S$ in the memory of the server (S).
• The SA embeds a PUF in the server (S) and applies a set of randomly chosen challenges (C), storing the corresponding responses (R) in the PUF-S database for future authentication.
• Similarly, the SA applies a set of challenges (C) to the PUF embedded in the SN and stores the responses (R) in the PUF-SN database.
• The SA securely stores the PUF-S database in the memory of SN.
• The SA securely stores the PUF-SN database in the memory of server (S).

3.2. Registration Phase

The SA registers an SN as follows:

• The SA assigns a unique secret identity ${\mathrm{id}}_{SN}$ for SN.
• The SA selects a temporary secret key $K_{SN}$ for SN.
• The SA computes:
  • $a_{SN}={\mathrm{id}}_{SN}\oplus h(K_S,K_{SN})$
  • $b_{SN}=K_S\oplus a_{SN}\oplus K_{SN}$
• The SA stores the tuple $\langle {\mathrm{id}}_{SN},a_{SN},b_{SN}\rangle$ in the SN’s memory.
• The SA stores ${\mathrm{id}}_{SN}$ in the server (S)’s memory.

Remark 1.

The key $K_{SN}$ is not stored at either the SN or S; it is used only for generating parameters $a_{SN}$ and $b_{SN}$.

Remark 2.

The symbol ${id}_{SN}$ denotes the real, persistent identity of the SN, along with its corresponding secret key.

3.3. Authentication Phase

The authentication phase involves the anonymous authentication of the SN with an S.

3.3.1. A: At the IoT Sensor Node (SN)

• The SN computes a temporary identity:

  $${\mathrm{tid}}_{SN}=h({\mathrm{id}}_{SN}\oplus N^{+1})$$

  (1)

  where N is a nonce (randomly generated number), and $N^{+1}$ represents the incremented version of the nonce to ensure uniqueness in each authentication session.
• The SN selects temporary parameters $T{P}_{SN}$.
• The SN generates a timestamp $t_{SN}$.
• The SN picks a random challenge $C_{SN-S}$ from the PUF-S database.
• The SN retrieves the corresponding response $R_{SN-S}$.
• The SN computes
  • $x_{SN}=a_{SN}\oplus {\mathrm{id}}_{SN}\oplus R_{SN-S}$
  • $y_{SN}=x_{SN}\oplus T{P}_{SN}$
• The SN computes a message integrity value:

  $$MI=h({\mathrm{tid}}_{SN},y_{SN},a_{SN},b_{SN},t_{SN},C_{SN-S},N^{+1})$$

  (2)
• The SN sends $\{{\mathrm{tid}}_{SN},y_{SN},a_{SN},b_{SN},C_{SN-S},t_{SN},MI\}$ to the S.

3.3.2. B: At the Server (S)

• The S verifies the timestamp $t_{SN}$.
• The S checks

  $${\mathrm{tid}}_{SN}=h({\mathrm{id}}_{SN}\oplus N^{+1})$$

  (3)
• The S computes the message integrity value and verifies it.
• The S applies the challenge $C_{SN-S}$ to the PUF and retrieves $R_{SN-S}$.
• The S computes
  • $x_{SN}=a_{SN}\oplus {\mathrm{id}}_{SN}\oplus R_{SN-S}$
  • $T{P}_{SN}=x_{SN}\oplus y_{SN}$

3.3.3. Server Prepares Response

• The S selects $f_{SN}$ and generates a timestamp $t_S$.
• The S picks a challenge $C_{S-SN}$ from the PUF-SN database and retrieves $R_{S-SN}$.
• The S computes
  • $\alpha =x_{SN}\oplus R_{S-SN}$
  • $y=\alpha \oplus f_{SN}$
• The S computes the session secret key:

  $$SSK=h(R_{SN-S}\oplus R_{S-SN}\oplus f_{SN}\oplus T{P}_{SN})$$

  (4)
• The S sends $\{{\mathrm{id}}_S,y,C_{S-SN},t_S,MI\}$ to the SN.

3.3.4. C: At the IoT Sensor Node (SN)

• The SN verifies ${\mathrm{id}}_S$, timestamp $t_S$, and computes $MI$.
• The SN applies the challenge $C_{S-SN}$ to the PUF and retrieves $R_{S-SN}$.
• The SN computes
  • $\alpha =x_{SN}\oplus R_{S-SN}$
  • $f_{SN}=\alpha \oplus y$
• The SN computes the session secret key:

  $$SSK=h(R_{SN-S}\oplus R_{S-SN}\oplus f_{SN}\oplus T{P}_{SN})$$

  (5)

4. Security Evaluation

In this section, we examine various known attacks and analyze how our protocol effectively mitigates each of them.

4.1. Informal Security Evaluation

In the subsequent section, we examine several key adversarial attacks and security properties, demonstrating how our protocol effectively prevents these attacks and ensures the achievement of the desired security properties.

4.1.1. Replay Attack

Replay attack prevention on the SN’s message in our protocol is ensured through the use of timestamps. The timestamp $\left(T{S}_N\right)$ is generated by the SN and is embedded in a manner that prevents it from being tampered with, erased, or replaced by an adversary (A).

4.1.2. Eavesdropping Threats

At the authentication phase of our protocol, the attacker will be able to record all the parameters transferred between the SN and S. However, using the one-wayness of h, it is impossible for the attacker to unfold the authentication parameters and learn any secret information.

4.1.3. Anonymous and Unlinkable Sessions

The user’s anonymity, untraceability, and unlinkability are critical security properties in authentication. Anonymity ensures that the real identity of the IoT sensor node (SN) remains secure, preventing its identification among other IoT nodes. Consequently, an attacker is unable to discern the actual identity of the node, as it is kept confidential and replaced with transitory identities that change with each session. Additionally, the proposed protocol ensures that sessions initiated by the same IoT node cannot be linked by an attacker to the same SN. Moreover, the adversary cannot correlate multiple sessions to a single SN. As a result, our protocol successfully achieves anonymity, untraceability, and unlinkability for all conducted sessions.

4.1.4. Security of Forward and Backward Integrity

Security of forward and backward integrity is an essential security property that ensures the confidentiality of past and future session keys, even if a temporary session key is compromised. This property is achieved through the use of the session secret key (SSK), which changes dynamically with each session, thereby preventing the exposure of any previous or future session keys.

4.1.5. Attack on Session Key Prediction

It is mitigated through the use of the SSK and nonce (N), both of which change dynamically with each session.

4.1.6. Attack on the Man-in-the-Middle Protocol

The protocol defends against this attack through the use of ${\mathrm{tid}}_{SN}$, ${\mathrm{C}}_{SN-S}$ and MI.

4.1.7. Identity Spoofing Attack

This is prevented by utilizing ${\mathrm{tid}}_{SN}$ and MI, both of which are secured through a one-way hash function. Specifically, ${\mathrm{tid}}_{SN}$ is calculated from several parameters, represented as ${\mathrm{tid}}_{SN}$ = h(${\mathrm{id}}_{SN}$⨁ ${\mathrm{N}}^{+1}$), and it is updated with every transmission since N changes with each message. Consequently, an attacker cannot generate a valid temporary identity without knowing the corresponding ${\mathrm{id}}_{SN}$ and N.

4.1.8. Authentication Using Physical Unclonable Functions (PUFs)

The PUF is utilized in our protocol to apply the challenge–response mechanism. Both the SN and S maintain databases of PUF parameters, as discussed in Section 2.3. These databases enhance overall security by implementing the challenge–response technique to ensure the freshness and uniqueness of authentication parameters and session establishment. This approach effectively protects IoT networks from known attacks.

4.2. Formal Verification Using BAN Logic

The BAN (Burrows–Abadi–Needham) logic [18] is a widely recognized framework for the analysis and verification of authentication protocols. It plays a critical role in proving the correctness of cryptographic protocols by formalizing the beliefs of participants based on their communication. In this paper, we employ BAN logic to demonstrate that our authentication scheme guarantees mutual authentication between a sensor node (SN) and a server (S). We begin by introducing the key symbols and rules of BAN logic, which provide a systematic way to represent the belief states of the protocol participants. Subsequently, we present the formal proof of our authentication protocol, using BAN logic to establish its security properties and verify that it meets the desired authentication objectives.

4.2.1. Fundamentals of BAN Logic

Consider P (client) and S (server) as the interacting entities, where X and Y signify a parameter, formula, or expression. The symbols are defined in

Table 2. BAN logic symbols.

Notation	Description
P|≡ X	(P believes X) P is authorized to act as though X is true.
P ⊲ X	(P sees X) a message sent to X.
P |∼ X	At a certain point in time P sent X. Furthermore, at the time of sending, P believed X.
P |→ X	(P has authority over X) P is a trusted source for X.
#(X)	(X is fresh) meaning that X has not been sent before in any run of the protocol.
(X, Y)	X or Y is a part of (X, Y).
${‹\mathrm{X}›}_Y$	X combined with Y.
P↔S	K is a confidential parameter shared between P and S.
P$P\leftrightarrows S$	(P and S share secret X) X is a confidential known only to P, S and possibly some trusted associates.

.

Additionally, we apply the established BAN logic rules to confirm that the authentication protocol we propose ensures secure mutual authentication and key establishment, as described in the following sections:

• MMR (MMR): If P observes X protected with Y, and P assumes that Y is a secret key shared with S, then P infers that S has previously sent X.

  $${\displaystyle \frac{\mathrm{P}\mid \equiv \mathrm{P}\stackrel{\mathrm{Y}}{⟷}\mathrm{S},{\mathrm{P}⊲\langle \mathrm{X}>}_Y}{\mathrm{P}\mid \equiv \mathrm{S}|\sim \mathrm{X}}}$$

  (6)
• Nonce Verification Principle: If P is confident that X is new and that X was previously communicated by S, P will infer that S also acknowledges the validity of X.

  $${\displaystyle \frac{\mathrm{P}\mid \equiv \#\left(\mathrm{X}\right),\mathrm{P}\mid \equiv \mathrm{S}|\sim \mathrm{X}}{\mathrm{P}\mid \equiv \mathrm{S}\mid \equiv \mathrm{X}}}$$

  (7)
• Authority Rule: If P believes that S has authority over X and P also believes that S recognizes X, then P accepts X as true.

  $${\displaystyle \frac{\mathrm{P}\mid \equiv \mathrm{S}|\Rightarrow (\mathrm{X}),\mathrm{P}\mid \equiv \mathrm{S}\mid \equiv \mathrm{X}}{\mathrm{P}\mid \equiv \mathrm{X}}}$$

  (8)
• Freshness Combination Rule: If a component of a formula is considered fresh, then the whole formula is regarded as fresh. Therefore, if P believes X is fresh, P also believes that both X and Y are fresh.

  $${\displaystyle \frac{\mathrm{P}\mid \equiv \#\left(\mathrm{X}\right)}{\mathrm{P}\mid \equiv \#(\mathrm{X},\mathrm{Y})}}$$

  (9)
• Belief Principle: If P believes both X and Y, then P must also believe X.

  $${\displaystyle \frac{\mathrm{P}\mid \equiv (\mathrm{X},\mathrm{Y})}{\mathrm{P}\mid \equiv \mathrm{X}}}$$

  (10)
• Observation Principle: If P observes both X and Y, then P will also observe X.

  $${\displaystyle \frac{\mathrm{P}⊲(\mathrm{X},\mathrm{Y})}{\mathrm{P}⊲\mathrm{X}}}$$

  (11)

4.2.2. Analysis Goals for Our Authentication Protocol

In the following, we outline the primary objectives of analyzing our authentication scheme:

• Goal 1: S is confident that the SN acknowledges the XSN as a secure shared parameter between the SN and S.

S |≡SN| ≡  (SN $\stackrel{XSN}{⟷}$ S)

2.

Goal 2: The S is confident that $X_{SN}$ is a secure shared parameter between the SN and S.

S | ≡ (SN $\stackrel{XSN}{⟷}$S)

3.

Goal 3: The SN is assured that the S considers the SSK as a securely shared parameter between the SN and S.

SN |≡ S| ≡ (SN $\stackrel{SSK}{⟷}$ S)

4.

Goal 4: The SN is confident that the SSK serves as a securely shared parameter between the SN and S.

SN |≡ (SN $\stackrel{SSK}{⟷}$ S)

4.2.3. Messages Exchanged During Authentication

The following are the anticipated communications that occur during the authentication phase between the server (S) and the IoT sensor node (SN):

• M1: SN → S: ${〈\mathrm{tid}\mathrm{SN},\mathrm{y}\mathrm{SN},\mathrm{a}\mathrm{SN},\mathrm{b}\mathrm{SN},\mathrm{C}\mathrm{SN}-\mathrm{S},\mathrm{t}\mathrm{SN},\mathrm{MI}〉}_{SN\stackrel{XSN}{⟷}S}$
• M2: S → SN: ${〈\mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{MI}〉}_{SN\stackrel{SSK}{⟷}S}$

4.2.4. Introductory Assumptions

The key assumptions underlying our authentication scheme are outlined below:

• A1: The S believes ${\mathrm{id}}_{SN}$ is a confidential shared parameter between the SN and S: SN ∣≡ (SN $\stackrel{\mathrm{R}\mathrm{SN}-\mathrm{S}}{⟷}\mathrm{S}$)
• A2: The S believes ${\mathrm{t}}_{SN}$ is fresh: S∣≡#(${\mathrm{t}}_{SN}$)
• A3: The SN believes the XSN is a confidential shared parameter between the SN and S: SN ∣≡ (SN $\stackrel{\mathrm{XSN}}{⟷}\mathrm{S}$)
• A4: The S believes ${\mathrm{id}}_{SN}$ is a confidential shared parameter between the SN and S: S ∣≡ (SN $\stackrel{\mathrm{IdSN}}{⟷}\mathrm{S}$)
• A5: The SN believes ${\mathrm{R}}_{SN-S}$ is fresh: SN |≡ #(${\mathrm{R}}_{SN-S}$).
• A6: The SN believes the SSK is a secure shared parameter between the SN and S: SN ∣≡S∣≡ (SN $\stackrel{\mathrm{SSK}}{⟷}\mathrm{S}$)
• A7: The SN believes the S has jurisdiction over ${\mathrm{R}}_{SN-S}$, XSN and MI: SN∣≡S∣⇒{${\mathrm{R}}_{SN-S}$, XSN, MI}
• A8: The S believes the SN has jurisdiction over XSN, SSK, and MI: S∣≡ SN ∣⇒{XSN, SSK, MI}

4.2.5. Analysis of Our Authentication Scheme

We proceed with the analysis of the proposed authentication protocol to verify that it successfully achieves mutual authentication between the SN and S. Based on M1, we obtain

$${\mathrm{S}⊲\langle \mathrm{tid}\mathrm{SN},\mathrm{y}\mathrm{SN},\mathrm{a}\mathrm{SN},\mathrm{b}\mathrm{SN},\mathrm{C}\mathrm{SN}-\mathrm{S},\mathrm{t}\mathrm{SN},\mathrm{MI}>}_{SN\stackrel{XSN}{⟷}S}$$

(12)

S1: Using M1, A1 and by utilizing the MMR, we infer

$${\displaystyle \frac{\mathrm{S}\mid \equiv \left(\mathrm{SN}\stackrel{{\mathrm{Id}}_{\mathrm{SN}}}{⟷}\mathrm{S}\right),{\mathrm{S}⊲\langle \mathrm{tid}\mathrm{SN},\mathrm{y}\mathrm{SN},\mathrm{a}\mathrm{SN},\mathrm{b}\mathrm{SN},\mathrm{C}\mathrm{SN}-\mathrm{S},\mathrm{t}\mathrm{SN},\mathrm{MI}>}_{SN\stackrel{XSN}{⟷}S}}{\mathrm{S}\mid \equiv \mathrm{SN}|\sim {\langle \mathrm{tid}\mathrm{SN},\mathrm{y}\mathrm{SN},\mathrm{a}\mathrm{SN},\mathrm{b}\mathrm{SN},\mathrm{C}\mathrm{SN}-\mathrm{S},\mathrm{t}\mathrm{SN},\mathrm{MI}>}_{SN\stackrel{XSN}{⟷}S}}}$$

(13)

S2: Using A2 and by utilizing freshness rule, we deduce

$${\displaystyle \frac{\mathrm{S}\mid \equiv \#\left(\mathrm{tSN}\right)}{\mathrm{S}\mid \equiv \#{\langle \mathrm{tid}\mathrm{SN},\mathrm{y}\mathrm{SN},\mathrm{a}\mathrm{SN},\mathrm{b}\mathrm{SN},\mathrm{C}\mathrm{SN}-\mathrm{S},\mathrm{t}\mathrm{SN},\mathrm{MI}>}_{SN\stackrel{XSN}{⟷}S}}}$$

(14)

S3: Using S1 and S2, and by utilizing the nonce verification rule, we deduce

$${\displaystyle \frac{S\mid \equiv \#{\langle {\mathrm{tid}}_{\mathrm{SN}},{\mathrm{y}}_{\mathrm{SN}},{\mathrm{a}}_{\mathrm{SN}},{\mathrm{b}}_{\mathrm{SN}},{\mathrm{C}}_{\mathrm{SN}-\mathrm{S}},{\mathrm{t}}_{\mathrm{SN}},\mathrm{MI}\rangle }_{\mathrm{SN}}\stackrel{XSN}{⟷}S,S\mid \equiv \mathrm{SN}\mid \sim {\langle {\mathrm{tid}}_{\mathrm{SN}},{\mathrm{y}}_{\mathrm{SN}},{\mathrm{a}}_{\mathrm{SN}},{\mathrm{b}}_{\mathrm{SN}},{\mathrm{C}}_{\mathrm{SN}-\mathrm{S}},{\mathrm{t}}_{\mathrm{SN}},\mathrm{MI}\rangle }_{\mathrm{SN}}\stackrel{XSN}{⟷}S}{S\mid \equiv \mathrm{SN}\mid \equiv {\langle {\mathrm{tid}}_{\mathrm{SN}},{\mathrm{y}}_{\mathrm{SN}},{\mathrm{a}}_{\mathrm{SN}},{\mathrm{b}}_{\mathrm{SN}},{\mathrm{C}}_{\mathrm{SN}-\mathrm{S}},{\mathrm{t}}_{\mathrm{SN}},\mathrm{MI}\rangle }_{\mathrm{SN}}\stackrel{XSN}{⟷}S}}$$

(15)

S4: Using S3, S2, and by utilizing the belief rule, we deduce

$${\displaystyle \frac{\mathrm{S}\mid \equiv \#{\langle {\mathrm{tid}}_{\mathrm{SN}},{\mathrm{y}}_{\mathrm{SN}},{\mathrm{a}}_{\mathrm{SN}},{\mathrm{b}}_{\mathrm{SN}},{\mathrm{C}}_{\mathrm{SN}-\mathrm{S}},{\mathrm{t}}_{\mathrm{SN}},\mathrm{MI}\rangle }_{\mathrm{SN}}\stackrel{XSN}{⟷}\mathrm{S},\mathrm{S}\mid \equiv \mathrm{SN}\mid \equiv {\langle {\mathrm{tid}}_{\mathrm{SN}},{\mathrm{y}}_{\mathrm{SN}},{\mathrm{a}}_{\mathrm{SN}},{\mathrm{b}}_{\mathrm{SN}},{\mathrm{C}}_{\mathrm{SN}-\mathrm{S}},{\mathrm{t}}_{\mathrm{SN}},\mathrm{MI}\rangle }_{\mathrm{SN}}\stackrel{XSN}{⟷}\mathrm{S}}{\mathrm{S}\mid \equiv \mathrm{SN}\mid \equiv \left(\mathrm{SN}\stackrel{XSN}{⟷}\mathrm{S}\right)}}$$

(16)

(Goal 1)

S5: Using A3 and S4, and by utilizing the jurisdiction rule, we deduce

$${\displaystyle \frac{\mathrm{S}|\equiv SN|\equiv (SN\stackrel{XSN}{⟷}S),\mathrm{SN}\mid \equiv (\mathrm{SN}\stackrel{\mathrm{XSN}}{⟷}\mathrm{S})}{\mathrm{S}|\equiv (SN\stackrel{XSN}{⟷}S)}}$$

(17)

(Goal 2)

According to the M2, we obtain

$$SN⊲〈\mathrm{id},S,y,C,\mathrm{S}-\mathrm{SN},t,\mathrm{S},\mathrm{MI}〉\mathit{SN}\stackrel{SSK}{⟷}\mathit{S}$$

(18)

S6: Using M2 and A4, and by utilizing the MMR, we deduce

$${\displaystyle \frac{\mathrm{S}\mid \equiv (\mathrm{SN}\stackrel{\mathrm{Id}\mathrm{SN}}{⟷}\mathrm{S}),SN⊲〈\mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{MI}〉SN\stackrel{SSK}{⟷}S}{\mathrm{SN}\mid \equiv \mathrm{S}|\sim 〈\mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{MI}〉SN\stackrel{SSK}{⟷}S}}$$

(19)

S7: Using A1, A2 and A5, and by utilizing the freshness rule, we deduce

$$\mathrm{SN}\mid \equiv {\#\langle \mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{MI}>}_{SN\stackrel{SSK}{⟷}S}$$

(20)

S8: Using S6 and S7, and by utilizing the nonce verification rule, we deduce

$${\displaystyle \frac{\mathrm{SN}\mid \equiv \#{\langle \mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{MI}>}_{SN\stackrel{SSK}{⟷}\mathrm{S}},\mathrm{SN}\mid \equiv \mathrm{S}|\sim {\langle \mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{M}>}_{SN\stackrel{SSK}{⟷}\mathrm{S}}}{\mathrm{SN}\mid \equiv \mathrm{S}\mid \equiv {\langle \mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{MI}>}_{SN\stackrel{SSK}{⟷}\mathrm{S}}}}$$

(21)

S9: Using S8 and by utilizing the belief rule, we deduce

$${\displaystyle \frac{\mathrm{SN}\mid \equiv \mathrm{S}\mid \equiv {\langle \mathrm{id}\mathrm{S},\mathrm{y},\mathrm{C}\mathrm{S}-\mathrm{SN},\mathrm{t}\mathrm{S},\mathrm{MI}>}_{SN\stackrel{SSK}{⟷}\mathrm{S}}}{SN|\equiv S|\equiv (SN\stackrel{SSK}{⟷}S)}}$$

(22)

(Goal 3)

S10: Using A6 and S9, and by utilizing the jurisdiction rule, we deduce

$${\displaystyle \frac{SN|\equiv \mathrm{S}\mid \Rightarrow \{XSN,SSK,MI\},SN|\equiv S|\equiv (SN\stackrel{SSK}{⟷}S)}{\mathrm{SN}\mid \equiv (\mathrm{SN}\stackrel{SSK}{⟷}\mathrm{S})}}$$

(23)

(Goal 4)

Therefore, our authentication protocol ensures both mutual authentication and key exchange between the SN and S.

4.3. Formal Proof Using the AVISPA Tool

The evaluation of the proposed protocol is conducted using the AVISPA toolkit [19], a widely recognized tool for security protocol verification in the research community. Figure 4 illustrates the HLPSL code for the SN role.

The AVISPA toolkit utilizes two prominent model checkers for simulation: the constraint logic-based attack searcher (CL-AtSe) and the on-the-fly model checker. Figure 5 illustrates the findings from the CL-AtSe check, confirming that the proposed protocol is secure (SAFE) and immune to potential attacks. Likewise, Figure 6 displays the output from the OFMC checker, proving that the protocol is SAFE and aligns with the predefined security goals. We did not use the TA4SP model checker because it does not support XOR operations, while the SATMC model checker was flagged as “NOT SUPPORTED”.

5. Evaluation of Performance

In the following subsection, we assess the efficiency of our protocol by examining both its communication overhead and computational costs.

5.1. Communication Overheads

They are listed in

Table 3. Communication overhead cost of our protocol.

Between Nodes	Cost
SN → S	992 bits
S → SN	528 bits

. During the transmission from the SN to the S, the SN transmits the tuple (${\mathrm{tid}}_{SN}$, ${\mathrm{y}}_{SN}$, ${\mathrm{a}}_{SN}$, ${\mathrm{b}}_{SN}$, ${\mathrm{C}}_{SN-S}$, MI, ${\mathrm{t}}_{SN}$). Assume that |$t_{SN}$| = 32 bits. The size of this tuple is calculated as 6 × 160 + 32 = 992 bits. In the reverse transmission (S → SN), the S sends the tuple (${\mathrm{id}}_S$, y, MI, ${\mathrm{t}}_S$, ${\mathrm{C}}_{S-SN}$), of size 528 bits, assuming that ${\mathrm{t}}_S$ = 32 and ${\mathrm{id}}_S$ = m = 16 bits So 3 (160) + 16 + 32 = 528.

5.2. Computation Cost

Our protocol involves two main operations: the hash function and the XOR operation. Let $\left(t_h\right)$ represent the computation time for one hash invocation, and let $\left(t_{XOR}\right)$ represent the time for one XOR computation. Referring to the authentication phase, the S performs four hash invocations and five XOR computations, leading to a total computation time of $(4t_h+5t_{XOR})$. Similarly, the SN performs four hash invocations and five XOR operations, resulting in a total computation time of $(4t_h+5t_{XOR})$. Given that the computation time for the XOR operation is negligible, we approximate $(t_{XOR}\approx 0)$. Therefore, the computation cost for the hub node (S) is simplified to $\left(4t_h\right)$. For the sensor node (SN), it is simplified to $\left(5t_h\right)$. These findings are summarized in

Table 4. Computation and storage cost of our protocol.

Node	Storage Cost (in Bits)	Computation Cost
SN	960	4$t_h$ + 5$t_{xor}$ ≈ 4$t_h$
S	16m + 160	4thash+ 5$t_{xor}$ ≈ 4$t_h$

.

5.3. Computation Time and Energy Consumption

On a 32-bit Cortex-M3 microcontroller (STMicroelectronics, Geneva, Switzerland) operating at 72 MHz, the time required for a SHA-1 hash computation is 0.06 ms [20].

From

Table 5. Computation time and energy usage of the protocol.

Node	Computation Time (ms)	Energy Consumption (mJ)
SN	0.24	0.0285
S	0.24	0.0285

, both the sensor node (SN) and the hub node (S) require 0.24 ms for computation. When operating in an active mode at 300 K, the microcontroller draws 36 mA from a 3.3 V power supply [20], resulting in a power consumption of 118.8 mW. The corresponding energy consumption is calculated as $E=0.240\times {\displaystyle \frac{118.8}{1000}}=0.0285\mathrm{mJ}$. Table 5 lists the computation time and energy consumption of our protocol.

5.4. Storage Requirements

In the proposed protocol, the server (hub) node needs to retain its $k_S$ and the identities of all registered first-level sensor nodes, denoted as $\left(i{d}_{SN}\right)$. The second-level sensor node is expected to store a tuple comprising $(i{d}_{SN},a_{SN},b_{SN})$, along with the $k_S$. For first-level nodes, it only needs to store $\left(i{d}_{SN}\right)$, which is short and typically equal to 16 bits. We use SHA-1. Its output is 160 bits. Based on these settings, the sizes of various parameters are as follows: $(\left|i{d}_{SN}\right|=16)$ bits and $(\left|a_{SN}\right|=\left|b_{SN}\right|=\left|k_S\right|=\left|k_{SN}\right|=160)$ bits. Consequently, the storage required by the server (S) is $\left(\left(160+16m\right)\right)$ bits. The $\left(m\right)$ is the registered first-level sensor nodes’ number. For each second-level SN, the total storage needed is 640 bits. These storage requirements are detailed in

Table 6. Computation cost of cryptographic calculations.

Symbol	Description	Cost
${\mathrm{t}}_h$	One SHA-1 hash invocation	${\mathrm{t}}_h$
${\mathrm{t}}_{ecsm}$	ECC scalar multiplication	72.5$t_h$
${\mathrm{t}}_{sym}$	Symmetric enc.	Th
${\mathrm{t}}_{ma}$	Modular addition	0.3$t_h$
${\mathrm{t}}_{ecpa}$	ECC point addition	13$t_h$
${\mathrm{t}}_{mm}$	Modular multiplication	2.5$t_h$
${\mathrm{t}}_{map}$	ECC map-to-point	450$t_h$
${\mathrm{t}}_{exp}$	Modular exponentiation	600$t_h$

.

5.5. Comparisons with Other Schemes

To provide a clear comparison with prior schemes, we present the experimental results from [21,22]. These results are listed in

Table 7. Comparisons of the energy consumption and computation costs of the server.

Protocol	Computation Cost	Computation Time	Energy
Liu et al. [25]	6$t_h$ + 2$t_{sym}$ + 4$t_{ecsm}$ + 1$t_{pair}$ + 1$t_{exp}$ = 2534$t_h$	152.040 ms	18.060 mJ
He-Zeadally [26]	$t_{ecsm}$ + 1$t_{ecpa}$ + 1$t_{map}$ + 4$t_h$ = 757$t_h$	45.420 ms	5.40 mJ
Zhao [24]	5$t_h$ + 1$t_{sym}$ + 6$t_{ecsm}$ = 441$t_h$	26.460 ms	3.140 mJ
Liu et al. [27]	2$t_h$ + 2$t_{ecpa}$ + 1$t_{map}$ + 2$t_{ecsm}$ + 3$t_{mm}$ + 1$t_{ma}$ = 180.80$t_h$	10.8480 ms	1.290 mJ
He-Zeadally [23]	1$t_h$ + 2$t_{sym}$ + 2$t_{ecsm}$ = 148$t_h$	8.88 ms	1.06 mJ
Li et al. [10]	5$t_h$ + 11$t_{xor}$ = 5$t_h$	0.3 ms	0.035 mJ
Proposed scheme	4$t_h$ + 5 $t_{xor}$ = 4$t_h$	0.24 ms	0.28 mJ

, which displays the computation times of various cryptographic operations, normalized to the hashing time $\left(t_h\right)$. Using the data from Table 7, we can directly compare the efficiency of the proposed model with that of earlier schemes. In the authentication protocol from [23], the AAL server performs one hash operation, three symmetric encryption tasks, and one elliptic curve scalar multiplication, leading to a total cost of $(1t_h+1t_{ecsm}+4t_{sym}=77.5t_h)$. Similarly, the hub in that protocol requires one hash invocation, two symmetric encryption/decryption processes, and two elliptic curve point multiplications, resulting in a total computation time of $(1t_h+2t_{ecsm}+2t_{sym}=148t_h)$. For the user, the total computation time is $(2t_h+3t_{ecsm}+2t_{sym}=221.5t_h)$. In the protocol from [24], the user executes $(1t_{sym}+3t_{ecsm}+4t_h=222.5t_h)$, while the hub calculates $(1t_{sym}+6t_{ecsm}+5t_h=441t_h)$. In the protocol from [25], the user runs $(1t_{exp}+3t_h+4t_{ecsm}+1t_{sym}=894t_h)$, and the hub node performs $(1t_{exp}+1t_{pair}+4t_{ecsm}+2t_{sym}+6t_h=2534t_h)$. The approach proposed by [26] is not considered lightweight, as it requires complex elliptic curve map-to-point operations and pairings. The user’s computation involves four scalar multiplications on elliptic curves, a single map-to-point operation, one point addition, and four hash function evaluations, leading to a computation cost of $(4t_{ecsm}+1t_{ecpa}+1t_{map}+4t_h\approx 757t_h)$. The scheme from Liu et al. [27] also requires a substantial computation from the user, involving two hash function executions, two point additions on elliptic curves, two scalar multiplications on elliptic curves, three modular multiplications, and one modular addition. This results in a computation cost of $(2t_{ecpa}+1t_{map}+2t_{ecsm}+2t_h+1t_{ma}+3t_{mm}=180.8t_h)$. Although the protocol in [10] is relatively lightweight, requiring the server to execute $(11t_{xor}+5t_h=5t_h)$, our protocol demonstrates the highest efficiency in terms of energy consumption and computation time. Table 7 presents the energy consumption and computation time required by the hub node in the proposed protocol and other recent schemes during the authentication and key agreement phases. It is evident from this comparison that our protocol is significantly more efficient than the others.

6. Conclusions

In this study, we introduced an efficient IoT authentication protocol leveraging physical unclonable functions (PUFs), tailored for IoT devices with limited resources, particularly in smart manufacturing settings. The protocol facilitates mutual authentication, allowing authorized devices to provide authentication through the IoT network gateway and securely share a temporary symmetric session key for subsequent interactions. A thorough security analysis, involving both informal evaluations and formal verification via the AVISPA toolkit, confirms the protocol’s resilience against various known attack vectors. Furthermore, the performance analysis demonstrates that our protocol significantly reduces computational overhead by utilizing lightweight cryptographic operations, such as hash functions and XOR operations. Compared to existing protocols, our approach reduces the computation cost to fourth place, resulting in a computation time of 0.24 ms and an energy consumption of 0.028 mJ on a 32-bit Cortex-M3 microcontroller. These efficiency gains highlight the suitability of our protocol for resource-constrained IoT environments. Next, we plan to conduct extensive live security evaluations, including penetration testing with various tools. Furthermore, to strengthen the practical validation of our protocol, we intend to implement a prototype in a smart manufacturing testbed. This will enable us to assess its real-world performance in terms of latency, computational overhead, and energy efficiency. Additionally, we aim to conduct simulation experiments to compare our protocol against existing approaches in a dynamic IoT environment.