A Lightweight Mutual Authentication Mechanism for Applications Utilizing Low-Power IoT Devices

Abstract

Nowadays, Low-Power Internet of Things (LP-IoT) devices are widely utilized due to their affordability and low energy consumption. However, LP-IoT devices face significant security challenges, including data breaches, unauthorized access, and malicious attacks, due to their constrained hardware resources. These challenges are particularly critical in applications that involve the transmission of sensitive data. To enhance the security of LP-IoT devices, we propose a lightweight mutual authentication mechanism designed explicitly for LP-IoT devices. This mechanism utilizes simplified cryptographic operations to strike a balance between security requirements and resource constraints, thereby ensuring secure and reliable data transmission, as well as mutual authentication, between devices and servers. In addition, we demonstrate the potential of this mechanism in protecting data integrity and device security through a scenario in a financial technology application. Our proposed mechanism adapts to the characteristics of low-power devices while enhancing their security and practicality across different application environments, offering a secure and lightweight solution to the security challenges of LP-IoT devices.

1. Introduction

In recent years, Internet of Things (IoT) devices have gained widespread adoption across various industries due to their capability to connect numerous devices, enabling intelligent automation, remote monitoring, and efficient data management. IoT technologies are utilized in different fields, including healthcare, smart cities, agriculture, transportation, and industrial automation, significantly transforming traditional processes.

Within IoT technologies, low-power IoT (LP-IoT) technology plays a pivotal role in our daily life, due to its advantages of being low cost, requiring minimal energy consumption, and demonstrating suitability for long-term deployments in resource-constrained environments. LP-IoT devices can operate for extended periods using batteries or energy harvesting mechanisms, making them ideal for remote monitoring and scenarios where frequent maintenance is inconvenient. They collect and transmit data via sensors and wireless connections, enabling real-time decision-making and improving efficiency in various applications. For example, LP-IoT devices can be employed to detect and monitor wildfires, providing early warnings and critical real-time data to mitigate environmental damage and protect lives. In agriculture, LP-IoT helps monitor soil moisture, crop conditions, and weather parameters, thereby optimizing resource usage and improving yield efficiency. In urban contexts, LP-IoT sensors facilitate the management of parking spaces, reducing congestion and enhancing mobility. In insurance companies, LP-IoT assists in assessing driving risks through “Pay as You Drive” (PAYD) and “Pay How You Drive” (PHYD) plans [1,2,3]. To balance profitability with the insured’s risk, insurance companies install LP-IoT devices on policyholders’ cars, enabling the tracking of driving patterns and sending data back to the insurance company.

Despite these advantages, LP-IoT devices face significant security challenges, including data breaches, unauthorized access, and malicious attacks, primarily due to their constrained computational power, memory capacity, and energy resources [4,5,6,7,8,9,10,11,12]. Existing security solutions, such as encryption and authentication mechanisms, often rely on computational ability and energy, and this is a limitation due to the characteristics of LP-IoT devices.

In particular, the use of LP-IoT in FinTech scenarios highlights the urgency of lightweight security solutions. Financial data and transaction records are highly attractive targets for adversaries, and if an LP-IoT device is impersonated or compromised, attackers may inject fraudulent data or disrupt decision-making, leading to severe financial and operational risks. Conventional cryptographic protocols, such as RSA or ECC, impose excessive computational and energy burdens on these devices. Therefore, it is essential to design a mutual authentication mechanism that ensures security while remaining feasible for disposable or resource-constrained LP-IoT deployments.

Moreover, practical studies report that LP-IoT deployments are frequently exposed to credential reuse, replay, and man-in-the-middle attacks in real-world settings, including finance-adjacent applications. These observations underscore the need for a lightweight yet robust mutual authentication mechanism to protect data integrity and device legitimacy under resource constraints [13,14].

In this study, we propose a lightweight mutual authentication mechanism specifically tailored for LP-IoT devices. The main contributions of this work are as follows: (1) we design a mechanism that balances strong security with lightweight operations; (2) we formalize the adversarial model and evaluate the scheme against practical attack vectors; and (3) we provide comparative performance analysis to demonstrate suitability for real-world deployment.

The paper is organized as follows: Section 2 reviews related works, highlighting the limitations of existing security mechanisms for LP-IoT devices. Section 3 introduces the proposed lightweight mutual authentication mechanism, detailing its design and implementation. Section 4 presents security and functional analyses, demonstrating the mechanism’s capability to defend against common attack scenarios while maintaining efficiency. Finally, Section 5 concludes the study and outlines potential future research directions.

2. Related Work

Several authentication mechanisms have been proposed to enhance security for low-power IoT (LP-IoT) devices while balancing computational efficiency and energy consumption. In this section, we review key existing works and highlight their strengths and weaknesses.

Zhao et al. [15] conducted a comprehensive survey of IoT authentication mechanisms, highlighting the vulnerabilities associated with lightweight, low-power devices. They proposed using Chebyshev chaotic encryption as an alternative to elliptic curve cryptography (ECC), offering strong security with reduced computational cost. However, the mechanism still relies on iterative computations and modular arithmetic, which may be challenging for ultra-low-power IoT devices. Additionally, the security of the mechanism depends heavily on initial parameter secrecy, and the lack of standardized protocols reduces its broad applicability.

Thakare et al. [16] introduced an authentication mechanism based on elliptic curve cryptography (ECC), hash functions, and XOR operations to optimize computational and storage overhead. While their mechanism was formally verified to defend against replay attacks, man-in-the-middle attacks, and insider threats, its reliance on ECC still imposes significant computational demands. The mechanism also has relatively high communication overhead (1408 bits), which may be a concern for bandwidth-constrained IoT networks.

Peivandizadeh et al. [17] designed a secure authentication and key agreement protocol specifically for low-power and Lossy Networks (LLNs). Their approach improved security by addressing vulnerabilities in the RPL routing protocol. The use of ECC-based cryptographic mechanisms, however, still presents challenges for ultra-low-power IoT devices, and the mechanism is tailored for RPL-based networks, limiting its applicability to broader IoT scenarios.

Zhou et al. [18] proposed a cloud-assisted authentication mechanism utilizing ECC, hash functions, and XOR operations. While their hierarchical four-party authentication model effectively distributes computational tasks, reducing device-side load, it heavily depends on cloud infrastructure. This reliance may not be suitable for all LP-IoT applications, particularly in environments with limited or intermittent network connectivity.

Das et al. [19] focused on smart healthcare IoT authentication, introducing a session key update mechanism for enhanced security. Their lightweight authentication and key agreement protocol used XOR and hash functions, ensuring resilience against common attacks while maintaining low computational and storage overhead. However, the reliance on IoT gateways for authentication could be a limiting factor in decentralized IoT environments, and the scalability of this mechanism has not been thoroughly evaluated.

From these works, we observe some challenges in the LP-IoT environment as follows:

• Reliance on computationally intensive cryptographic operations (such as ECC), which may not be feasible for LP-IoT devices.
• High communication overhead, making it unsuitable for bandwidth-constrained networks.
• Limited scalability in dynamic IoT environments, where frequent device additions and removals can introduce security and performance concerns.
• Some mechanisms, despite being lightweight, still requiring iterative computations or modular arithmetic, making them impractical for ultra-low-power IoT devices.

Therefore, there is a need for an authentication mechanism that minimizes power con-sumption while maintaining security and scalability for LP-IoT applications. In recent years, many lightweight authentication mechanisms have been proposed to enhance IoT device security. Zhao et al. [15] proposed a Chebyshev chaotic map-based scheme, while Thakare et al. [16] combined ECC, hash, and XOR operations for lightweight mutual authentication. Peivandizadeh et al. [17] further explored ECC-based approaches, whereas Zhou et al. [18] leveraged cloud computing resources to offload ECC computations. Das et al. [19] utilized lightweight hash and XOR operations to reduce computational overhead.

In addition, the Anti-Poisoning Attack Decentralized Privacy-Enhanced Federated Learning (APDPFL) scheme [20] has been proposed to address poisoning threats in federated learning systems. Although this direction focuses on data-level protection rather than device-level authentication, it reflects the breadth of IoT security research and complements our study by showing advances in parallel domains.

3. Proposed Mechanism

In this section, we introduce our proposed mechanism, detailing its system components and workflow. This mechanism is specifically designed to address the unique security requirements of LP-IoT devices, ensuring secure communication and data integrity without excessive resource consumption.

3.1. System Introduction

The proposed mechanism is based on LP-IoT devices, assuming they are equipped with storage and 4G/5G network connection capabilities. A Data Collection Server is placed to collect all the data that LP-IoT transfers back. Users can use this data in the Data Collection Server for further applications.

Due to the hardware limitations of LP-IoT devices, it is not possible to execute complex encryption mechanisms and perform frequent authentication. Our proposed mechanism enables the LP-IoT device to operate a secure authentication mechanism with the Data Collection Server, ensuring data security both in storage and during transit. In this system design, we focus on the device and data security between LP-IoT devices and the Data Collection Server.

3.2. The Lightweight Mutual Authentication Mechanism

In this study, we demonstrate our proposed mechanism in a general scenario with a simple application model. Our research focuses on the authentication process between an LP-IoT device and a Data Collection Server. The LP-IoT data collection model is shown in Figure 1.

The hardware devices or servers involved in the proposed authentication mechanism are depicted in

Table 1. Hardware notations used in the proposed authentication mechanism.

Device/Server	Description
${LP}_i$	$\mathrm{The} {LP}_i$ is the ith device used in the default deployment environment.
DCS	$\mathrm{The} \mathrm{Data} \mathrm{Collection} \mathrm{Server}, \mathrm{which} \mathrm{is} \mathrm{responsible} \mathrm{for} \mathrm{collecting} \mathrm{and} \mathrm{storing} \mathrm{the} \mathrm{data} \mathrm{transferred} \mathrm{from} {LP}_i$.
AS	The Authentication Server is responsible for registering the LP-IoT device and sending the generated secret key.

.

The notations used are shown in

Table 2. Symbol notations used in the proposed authentication mechanism.

Symbol	Description
${LPID}_i$	$\mathrm{The} i^{th}$ LP-IoT device ID
${ISC}_i$	$\mathrm{The} \sec \mathrm{ret} \mathrm{number} \mathrm{of} \mathrm{the} i^{th}$ LP-IoT device
$p_i$$, q_i$	Two distinct large prime numbers
$t_j$	$\mathrm{A} \mathrm{timestamp}, \mathrm{where} j \in \{1,2\dots ,n\}$
$∆T$	A predefined, reasonable length of time for the party that receives a message with a timestamp to ensure the freshness of the received message.
${TD}_i$	The transferred data from the LP-IoT device i
$h( )$	Hash function
$\oplus$	XOR operation

as follows.

3.2.1. Registration Phase

AS Figure 2 shows, when the users initiate these kinds of IoT-based data collection applications, they will assign a unique LP-IoT device ID ${\mathit{L}\mathit{P}\mathit{I}\mathit{D}}_{\mathit{i}}$ and a corresponding secret number ${\mathit{I}\mathit{S}\mathit{C}}_{\mathit{i}}$ to each LP-IoT device. A user can then register its LP-IoT device with these values at the AS. The AS will generate ${\mathit{p}}_{\mathit{i}}$ and ${\mathit{q}}_{\mathit{i}}$ and calculate the following operations:

$$A=h({LPID}_i⨁{ISC}_i⨁p_i⨁q_i)$$

(1)

$$B=A⨁h({ISC}_i⨁{LPID}_i⨁q_i)$$

(2)

$$C=h\left(A⨁B⨁p_i\right)$$

(3)

$$D=h\left(B⨁C\right)⨁p_i⨁q_i$$

(4)

After AS finishes the calculation, AS will store $\mathit{A}, \mathit{B}, \mathit{C}, {\mathit{I}\mathit{S}\mathit{C}}_{\mathit{i}}, {\mathit{p}}_{\mathit{i}} \mathbf{a}\mathbf{n}\mathbf{d} {\mathit{q}}_{\mathit{i}}, \mathbf{a}\mathbf{n}\mathbf{d} \mathbf{s}\mathbf{e}\mathbf{n}\mathbf{d} \mathbf{t}\mathbf{h}\mathbf{e} \mathit{B}, \mathit{C}, \mathit{D},$ and ${\mathit{q}}_{\mathit{i}}$ to ${\mathit{L}\mathit{P}}_{\mathit{i}}$. Then the registration phase is accomplished.

This phase ensures that each device is initialized with a unique identity and secret parameters before operation. By preloading these lightweight values, the mechanism avoids expensive key negotiation during runtime, which is critical for resource-constrained LP-IoT devices.

3.2.2. Mutual Authentication Phase

As Figure 3 shows, when a LP-IoT device ${\mathit{L}\mathit{P}}_{\mathit{i}}$ first deploys to an environment, ${\mathit{L}\mathit{P}}_{\mathit{i}}$ must conduct a mutual authentication process between ${\mathit{L}\mathit{P}}_{\mathit{i}}$ and AS. The LP-IoT device makes the following computational operations marked with a timestamp ${\mathit{t}}_{\mathbf{1}}$.

$$A^{*}=B⨁h({ISC}_i⨁{LPID}_i⨁q_i)$$

(5)

$$E_1=A^{*}⨁B=h({ISC}_i⨁{LPID}_i⨁q_i)$$

(6)

$$F=D⨁E_1$$

(7)

$$E_2=E_1⨁F⨁p_i⨁t_1=D⨁p_i⨁t_1$$

(8)

After the calculation, the ${\mathit{L}\mathit{P}}_{\mathit{i}}$ sends the message ${\{\mathit{E}}_{\mathbf{2}}$, ${\mathit{t}}_{\mathbf{1}}\}$ to AS. The AS first records the timestamp ${\mathit{t}}_2$ when it receives the message from ${\mathit{L}\mathit{P}}_{\mathit{i}}$ and then verifies whether the ${\mathit{L}\mathit{P}}_{\mathit{i}}$ is trustworthy via the following process.

$$verify if ∆T>(t_2-t_1)$$

(9)

$$verify if h\left(B⨁C\right)⨁q_i⨁t_1==E_2$$

(10)

$$Generate E_3=h(A⨁t_3)$$

(11)

After AS transmits the message ${\{\mathit{E}}_{\mathbf{3}}$, ${\mathit{t}}_{\mathbf{3}}\}$ back to ${\mathit{L}\mathit{P}}_{\mathit{i}}$, the ${\mathit{L}\mathit{P}}_{\mathit{i}}$ first records the timestamp ${\mathit{t}}_{\mathbf{4}}$ when it receives the message from AS and then verifies whether the AS is trustworthy via the following process.

$$verify if ∆T>\left(t_{4 }{-t}_3\right)$$

(12)

$$verify if h\left(A^{*}⨁t_3\right)==E_3$$

(13)

Unlike conventional protocols that rely on expensive asymmetric operations, our mechanism only requires hash and XOR operations with timestamps. This provides freshness against replay attacks while keeping computational overhead minimal, which directly fits the low-power profile of LP-IoT deployments.

3.2.3. Data Transmission Phase

As Figure 4 shows, when the mutual authentication phase is accomplished, ${\mathit{L}\mathit{P}}_{\mathit{i}}$ can transfer the targeted data $\mathit{D}\mathit{A}$ to DCS by embedding it into the message $\mathit{T}{\mathit{D}}_{\mathit{i}}$ along with a current timestamp ${\mathit{t}}_{\mathbf{5}}$.

$${TD}_i=\{h\left({LPID}_i⨁{ISC}_i\right)⨁DA, t_5\}$$

(14)

After DCS receives the message ${\mathit{T}\mathit{D}}_{\mathit{i}}$, it first records the timestamp ${\mathit{t}}_{\mathbf{6}}$ when it receives the message from ${\mathit{L}\mathit{P}}_{\mathit{i}}$ and then derives the targeted data via the following process.

$$verify if ∆T>(t_6-t_5)$$

(15)

$$Derive DA=h\left({LPID}_i⨁{ISC}_i\right)⨁{TD}_i$$

(16)

3.2.4. Device Purge Phase

Once ${\mathit{L}\mathit{P}}_{\mathit{i}}$ is no longer needed or has been lost, the user may ask AS to execute the device purge phase. The AS will delete all information related to the device identity ${\mathit{L}\mathit{P}\mathit{I}\mathit{D}}_{\mathit{i}}$.

The purge process guarantees that once a device is decommissioned or compromised, its credentials cannot be reused. This simple step reduces the risk of long-term impersonation without introducing additional runtime costs.

4. Analyses and Discussion

In this section, we will conduct a security analysis and functional analysis to ensure that our proposed mechanism is secure and can withstand common attack scenarios, while also considering its functional purpose.

4.1. Adversarial Model

For the security analysis, we assume the following adversarial model tailored to the LP-IoT environment. This model defines the capabilities and limitations of potential attackers, providing a clear basis for the subsequent analyses.

4.1.1. Adversary Capabilities

• Eavesdropping: The adversary can passively intercept communications between ${LP}_i$ and the servers (AS, DCS).
• Replay: The adversary may resend previously captured messages in an attempt to bypass authentication.
• Message Injection/Modification: The adversary may inject or alter transmitted messages to impersonate a device or server.
• Active Initiation: The adversary may actively send fabricated authentication requests to the AS or DCS.
• Limited Compromise: The adversary may obtain local information from a single compromised ${LP}_i$, such as its ${LPID}_i$ or partial stored values.

4.1.2. Adversary Limitations

• The adversary cannot reverse the on-way hash function.
• The adversary cannot derive the global secret parameters or system master secrets held securely by the AS.
• The initialization process is assumed to be performed in a trusted environment, ensuring each ${LP}_i$ is securely provisioned with its ${LPID}_i$ and ${ISC}_i$.

4.1.3. Adversary Goals

• Forge a legitimate ${LP}_i$ or AS to gain unauthorized access.
• Replay outdated messages to trick the system into accepting invalid credentials.
• Intercept or alter transmitted data without detection.
• Escalate a local compromise of one device into a broader system breach.

4.2. Resistance Against Common Attacks

• Eavesdropping Attack/Passive Attack
  The eavesdropping attack focuses on collecting data in a network environment, which may result in sensitive data leakage. Our proposed mechanism involves encrypting messages and data using XOR and a hash function during transmission. When a malicious attacker sniffs network packets, all the information is encrypted and cannot be decrypted effectively. This confirms that our proposed mechanism is effective in defending against eavesdropping attacks.
• Dictionary and Exhaustive Attack
  Dictionary and exhaustive attacks focus on systematically guessing or enumerating passcodes. These attacks are particularly effective when secret numbers lack sufficient complexity. To mitigate such risks, our proposed mechanism combines the LP-IoT device’s ID with the secret number using an XOR operation, followed by encryption and hashing processes before transmission. This layered approach effectively prevents attackers from successfully performing dictionary and exhaustive attacks.
• Credential Stuffing Attack
  The credential stuffing attack is a malicious attack where a malicious attacker utilizes a leaked valid password list to try to log in as an authorized user. Our proposed mechanism does not directly use a secret number; instead, it encrypts the secret number using the XOR of the LP-IoT device’s ID and transmits it after the hashing process. This confirms that our proposed mechanism is effective in defending against credential stuffing attacks.
• Forgery Attack/Impersonation Attack
  A forgery attack focuses on forging the mandatory infrastructure, trying to mislead both sides into believing they are communicating with a valid device. Our proposed mechanism is designed for LP-IoT and performs mutual authentication to verify both sides are trustworthy before data transmission. This confirms that our proposed mechanism is effective in defending against forgery attacks.
• Replay Attack
  The replay attack is a malicious attacker sniffing the valid credentials and resending the credentials to cheat the authentication mechanism as a valid user. Our proposed mechanism is attaching a timestamp in each transmission, and the AS also asks all the servers to check whether the $∆T$ is in a reasonable time period. This confirms that our proposed mechanism is effective in defending against replay attacks. The overhead for verifying freshness is only a single hash computation (0.12 ms in

  Table 3. Computation time for different cryptographic operations [15].

  Operation	Notation	Computation Time (ms)
  One-way hash function	$T_h$	0.00032
  ECC point multiplication	$T_{ecm}$	0.0171
  ECC point addition	$T_{ecca}$	0.0044
  Symmetric encryption/decryption	$T_{e/d}$	0.0056
  Modular exponentiation operation	$T_{me}$	0.0192
  Modular multiplication operation	$T_{mul}$	0.00088
  Chebyshev chaotic map operation	$T_{cm}$	0.0171
  Operation based on the Chinese Remainder Theorem	$T_{crt}$	0.00704
  Signature generation for the elliptic curve digital signature	$T_{sig}$	0.02182
  Verification for the elliptic curve digital signature	$T_{ver}$	0.03892
  Message authentication code	$T_{mac}$	0.00032

  ), which is negligible for LP-IoT devices.
• Man-in-the-Middle Attack
  In a man-in-the-middle attack, an attacker intercepts and potentially alters communication between the device and the server. To defend against this, our mechanism uses mutual authentication combined with timestamp-based hash masking. Even if communication is intercepted, the attacker cannot decrypt or modify the data without being detected, as each message’s integrity is verified using cryptographic hash functions and the inclusion of fresh timestamps. Since each authentication round generates new hash values bound to the current timestamp, the attacker cannot reuse old messages or maintain prolonged exposure.

4.3. Cryptographic Security

• Data Freshness and Hash-based Protection
  The authentication server (AS) does not distribute long-term session keys; instead, it relies on lightweight hash functions combined with timestamps to ensure data freshness. Even if a past message is intercepted, the bound timestamp and hash values prevent it from being reused in future sessions, thereby achieving forward protection against replay and forgery attempts.
• Low Computational Overhead
  The mechanism avoids computationally expensive operations, such as public-key cryptography, and instead relies on lightweight hashing and XOR operations. This makes it feasible for LP-IoT devices with limited processing power.
  As shown in Table 3, each masking step requires only one XOR and one hash operation, with combined latency below 0.15 ms, which is significantly lighter compared to RSA- or ECC-based protocols that require tens to hundreds of milliseconds per operation.
• Resistance to Side-Channel Attacks
  The mechanism is designed to mitigate the risks of side-channel attacks by minimizing the exposure of cryptographic computations to an external observer. Since the mechanism utilizes XOR and a hash function rather than complex modular arithmetic, it reduces the likelihood of timing attacks and power analysis attacks. Furthermore, the authentication process incorporates randomized elements, ensuring that each execution path varies slightly, making pattern analysis more difficult for adversaries.

4.4. Device and Communication Security

• Mutual Authentication
  Unlike traditional IoT authentication mechanisms that only verify client-side legitimacy, our mechanism ensures that both the LP-IoT device and the authentication server authenticate each other before any data transmission occurs. The proposed lightweight authentication mechanism for low-power IoT devices demonstrably upholds the property of mutual authentication by ensuring that both the device ${LP}_i$ and the Authentication Server (AS) verify each other’s legitimacy before any data exchange occurs. In the mutual authentication phase, the ${LP}_i$ first generates authentication values ($E_2$, $t_1$) derived from its unique ID, secret number, and time-sensitive parameters, which the DCS verifies for validity and timeliness. This prevents replay attacks and confirms the device’s authenticity. Subsequently, the DCS responds with its own authentication token ($N$, $t_3$), computed using shared secret components and a fresh timestamp, which the ${LP}_i$ validates through cryptographic checks. This bidirectional verification process, coupled with the use of lightweight hash and XOR operations, ensures that neither party proceeds without confirming the trustworthiness of the other.
  In contrast, schemes using ECC incur approximately 15–20 ms per scalar multiplication, which is more than two orders of magnitude heavier than our approach.
• Minimal Local Secrets
  The LP-IoT device stores only minimal security information (such as its device ID and a hashed value tied to its secret number). All authentication values are generated dynamically for each session using lightweight hash and XOR operations with fresh timestamps, eliminating the need for long-term session keys and further reducing the risk of key compromise.

4.5. Functional Analysis

• Suitability for LP-IoT Devices
  The proposed mechanism executes all complex calculations on the server side during the registration phase. The LP-IoT devices only store mandatory information generated by AS, which significantly reduces their computational loading. In the authentication phase, the devices execute only XOR operations, which is a simple logical function that requires minimal computational resources and power. This design aligns with the limited processing power and energy constraints of LP-IoT devices, ensuring efficient performance without overloading hardware.
• Lightweight Storage Requirements
  Our proposed mechanism requires minimal storage on LP-IoT devices. Only essential credentials, such as device IDs and hashed secret keys, are stored locally, reducing memory usage. This is particularly advantageous compared to mechanisms like ECC-based protocols, which require complex key management and large storage capacities.
• Flexibility Across IoT Applications
  Unlike protocols designed for specific industries (e.g., healthcare or smart grids), our mechanism is highly adaptable to various LP-IoT applications, including automobile insurance, supply chain management, and environmental monitoring. Its generic design ensures ease of integration into diverse IoT environments without significant architectural modifications.
• Reduced Communication Overhead
  Our proposed mechanism minimizes the number of communication steps during the authentication phase, thereby significantly reducing bandwidth consumption. This is particularly beneficial in LP-IoT environments where devices often operate under low-bandwidth or intermittent network conditions.
• Scalability in a dynamic IoT environment
  The proposed mechanism is designed for operation in dynamic IoT settings, where the number of devices may frequently fluctuate. The registration phase has been designed to accommodate these changes, allowing the system to maintain its efficiency and security even in highly variable environments. This scalability ensures long-term usability across diverse IoT deployments.
• Enhanced Energy Efficiency
  The mechanism limits calculations on the LP-IoT device to XOR and hash functions. According to Table 3 [13], these operations require minimal computation time compared to other cryptographic methods. This ensures the mechanism is both fast and resource-efficient, meeting the performance requirements of LP-IoT devices while maintaining robust security.
  The performance evaluation demonstrates that our mechanism consumes only 1.56 ms per authentication cycle (as derived from Table 3). This value is substantially lower than other schemes that require more than 30 ms on average.
• Strong Security with Minimal Resource Consumption
  Despite its lightweight design, the mechanism provides robust security guarantees against common attack vectors, including reply attacks, impersonation attacks, and man-in-the-middle attacks. This balance between security and efficiency distinguishes our mechanism from traditional IoT security protocols.

4.6. Computation Time Analysis

Zhao et al. [15] has provided a list of time consumption for various cryptographic operations, as shown in Table 3. Theoretically, assuming a constant power supply, a shorter computation time corresponds to lower overall energy consumption.

Table 4. Comparison of the computation time among existing authentication schemes and our scheme.

Authentication Solution	Applied Operations	Approximate Computation Time (ms)
Zhao et al. [15]	Chebyshev chaotic mapping	0.0171
Thakare et al. [16]	ECC point multiplication + Hash + XOR	0.01742
Peivandizadeh et al. [17]	ECC point multiplication	0.0171
Zhou et al. [18]	Cloud-assisted ECC + Hash + XOR	0.00032 (with cloud computing ability)
Das et al. [19]	Hash + XOR (Session Key)	0.00032
Ours	XOR + Hash	0.00032

compares the computation time required for a single execution of cryptographic operations across several authentication schemes. Zhao et al. [15] and Peivandizadeh et al. [17] reported similar execution times (approximately 0.0171 ms) for Chebyshev chaotic mapping and ECC point multiplication, respectively. Thakare et al. [16] included ECC point multiplication, hash, and XOR operations, resulting in a computation time of 0.01742 ms. In contrast, Zhou et al. [18] achieved a significantly reduced computation time of 0.00032 ms by leveraging cloud computing resources to offload the heavy ECC operations. Similarly, Das et al. [19] utilized lightweight operations such as hash and XOR to attain the same level of performance. Our proposed method, based solely on XOR and hash functions, also achieves a computation time of 0.00032 ms—without relying on any cloud-based acceleration, thereby offering comparable efficiency with greater deployment flexibility in resource-constrained environments.

These findings emphasize the need for cryptographic mechanisms that minimize power consumption while maintaining robust security and scalability in LP-IoT environments. Our proposed solution fulfills this need by combining XOR and hash functions. It achieves computational efficiency comparable to the most lightweight authentication schemes, without relying on ECC-based operations or cloud-assisted infrastructure.

5. Conclusions

In this study, a secure mutual authentication mechanism tailored for low-power IoT (LP-IoT) devices is proposed. The proposed mechanism ensures secure communication between LP-IoT devices and data collection servers, enhancing data integrity and confidentiality in IoT-based applications.

Through comprehensive security analysis, this study demonstrated that the proposed mechanism effectively defends against common attack scenarios, including eavesdropping, dictionary and exhaustive attacks, credential stuffing, forgery, replay, and man-in-the-middle attacks. By leveraging lightweight cryptographic operations such as XOR and hashing, the mechanism achieves robust security without compromising the efficiency or power consumption of LP-IoT devices. In the functional analysis, we highlighted the adaptability of the mechanism across various application scenarios, such as usage-based insurance, asset tracking, and data collection for predictive analytics. Its flexible architecture supports seamless integration into existing IoT infrastructures and enables scalability, making it suitable for a wide range of IoT-dependent industries beyond financial technology, including healthcare, logistics, and smart cities.

For future work, one could explore the possibility of integrating lightweight, mutually authenticated LP-IoT devices into a Zero-Trust Architecture (ZTA) to derive a robust framework for general IoT-based applications.

In conclusion, this work helps bridge the gap between security and functionality in LP-IoT devices, offering a scalable, adaptable, and secure solution for safeguarding critical data and operations in IoT application scenarios.