NIABIAuth: A Non-Interactive Attribute Binding Identity Authentication Protocol for Internet of Things Terminals

Abstract

The large-scale deployment of distributed devices in the Internet of Things (IoT) brings urgent demands for secure, scalable, and lightweight identity authentication. For example, virtual power plants integrate numerous heterogeneous energy terminals to support grid dispatch and market operations, while posing challenges such as real-time access, resource constraints, and identity privacy protection. To address these challenges, this paper proposes NIABIAuth, a non-interactive attribute binding identity authentication protocol for IoT terminals. NIABIAuth supports dynamic challenge computation and binds cryptographic identity proofs with terminal attributes, enabling fine-grained and privacy preserving access control. By storing identity credentials and verification records on the chain, this protocol ensures traceability and tamper resistance. Experiments demonstrate that NIABIAuth maintains low authentication latency and is consistent throughput, even under constrained conditions. Compared with baseline methods, NIABIAuth achieves substantial reductions in communication and computation cost. The proposed NIABIAuth was formally verified using the AVISPA tool, which proved that it could resist common attacks, including replay attacks, man-in-the-middle attacks, etc. A large number of simulation experiments have demonstrated that the proposed protocol can provide real-time identity authentication for Internet of Things terminals.

1. Introduction

With the continued advancement of digital infrastructure and pervasive connectivity, the Internet of Things (IoT) has evolved into a foundational component across various sectors, such as smart grids, industrial automation, intelligent transportation, and urban sensing systems. These systems typically involve large-scale coordination among heterogeneous terminal devices, which perform critical tasks such as real-time sensing, distributed control, and data-driven decision making. As the scale and complexity of IoT deployments increase, ensuring the authenticity and trustworthiness of participating devices has become a fundamental requirement for maintaining system integrity and operational reliability.

In many real-world IoT scenarios, terminal devices are geographically dispersed, frequently updated, and managed across distinct administrative domains. Devices are often deployed by different stakeholders, such as equipment manufacturers, service providers, and end users. These characteristics introduce substantial challenges in the design and enforcement of identity authentication mechanisms. The lack of centralized control, coupled with the heterogeneity of devices and communication protocols, significantly complicates the establishment of mutual trust among entities. Prior studies have explored centralized authentication [1], lightweight cryptographic methods [2], and blockchain-assisted authentication protocols [3,4]. While these approaches address some of the challenges, they still face notable limitations under large-scale and heterogeneous IoT deployments. Furthermore, adversaries may exploit insecure interfaces or impersonate legitimate nodes to compromise system behavior, disrupt services, or gain unauthorized access to sensitive data.

Traditional identity authentication frameworks, such as those based on centralized certificate authorities or interactive cryptographic protocols, while effective in certain IoT settings, encounter notable limitations when applied to large-scale and decentralized environments. These approaches often impose high communication and computation costs [5], which are unsuitable for low-performance devices operating under strict latency and bandwidth constraints. In addition, traditional methods may not adequately address privacy-related issues, since exposing static identifiers or metadata during the authentication process can facilitate device tracking and behavioral profiling [6].

The importance of secure and efficient identity authentication in IoT systems is further underscored by the critical nature of many of their application domains. For instance, in virtual power plants (VPPs) and other smart grid infrastructures, authentication failures may lead to incorrect control decisions, energy delivery disruptions, or the spread of malicious commands [7]. Similar risks exist in intelligent transportation systems [8], where compromised devices can interfere with traffic management or vehicle coordination. Therefore, authentication is not merely a security layer, but a core enabler of safe and dependable IoT operation.

Given these considerations, the development of identity authentication mechanisms that can accommodate the unique requirements of large-scale, heterogeneous, and real-time IoT environments remains a significant research challenge. Prior studies on blockchain-based authentication [9,10] provide decentralization and tamper-resistance, but often lack efficient privacy-preserving mechanisms. Attribute-based authentication enables fine-grained access control, yet incurs substantial computational costs. These gaps highlight the need for solutions that can simultaneously achieve low-latency operation, scalability to massive heterogeneous devices, and protection of device-level privacy.

1.1. Motivations

As IoT ecosystems continue to expand across domains such as smart grids, industrial systems, and intelligent transportation, the authentication of a rapidly growing number of heterogeneous terminal devices has become increasingly critical. These devices operate in dynamic, decentralized environments with varying resource constraints and security requirements. However, existing identity authentication solutions remain inadequate in meeting the demands of such systems.

First, traditional authentication methods, including certificate authority-based PKI and lightweight symmetric-key protocols, have been successfully applied in many IoT scenarios [11,12]. Nevertheless, when extended to large-scale, heterogeneous, and privacy-sensitive IoT environments, these approaches encounter significant challenges. Commonly used mechanisms such as password-based login, certificate-based PKI frameworks, and symmetric key pre-distribution schemes still depend on centralized certificate authorities (CAs), which constitute single points of failure and hinder scalability in distributed deployments. Moreover, certificates often expose static device identifiers and organizational metadata, thereby compromising privacy and enabling potential tracking or profiling. In addition, centralized authentication frameworks typically involve frequent server communication and certificate verification operations, which impose high computational and communication costs. This burden is particularly problematic for low-performance devices, rendering such methods impractical for time-sensitive or large-scale IoT deployments.

Second, existing blockchain and zero-knowledge-based approaches lack the ability to bind device identity with application-specific attributes in a secure and efficient manner. While blockchain provides a decentralized trust infrastructure and ensures non-alterability of stored records, it does not inherently protect or blind device identities, as confirmed by prior studies [13,14]. Non-interactive zero-knowledge proofs (NIZKs) can reduce the need for multi-round communication, but most existing ZKP-based authentication protocols still focus solely on identity verification without capturing contextual or attribute-based constraints.

Furthermore, recent studies have proposed a wide range of authentication protocols for IoT, including blockchain-assisted schemes [3,4], decentralized factory authentication [6], and machine learning-enhanced access control [7]. While these methods address important aspects such as decentralization, scalability, or adaptive security, they often lack the necessary combination of lightweight design, privacy protection, and formal verifiability required for deployment in real IoT environments. While many cryptographic schemes with theoretical security guarantees have been proposed, they often fall short in terms of deployability and operational efficiency. For example, blockchain-based dynamic key protocols [5] and decentralized identity frameworks [8] demonstrate promising theoretical properties but have not been evaluated under conditions involving large-scale concurrent access, heterogeneous device functionalities, or low-performance devices. As a result, their scalability and robustness in dynamic real-world environments remain unproven, a concern also highlighted in recent systematic reviews [9]. Furthermore, few existing protocols come with formal security proofs that comprehensively address issues such as impersonation and replay attacks. This gap between theoretical justification and empirical validation limits their applicability in IoT scenarios that require strict security guarantees.

1.2. Contributions

In response to the limitations of existing identity authentication mechanisms in large-scale, low-performance, and privacy-sensitive IoT environments, the main contributions of this work are summarized as follows:

• We propose NIABIAuth, a non-interactive attribute binding identity authentication protocol, to address the challenge of secure, scalable, and privacy-preserving authentication in decentralized IoT environments. NIABIAuth is designed to support lightweight verifiable authentication of heterogeneous IoT terminals under real-time high-concurrency conditions while taking into account privacy protection and fine-grained access control.
• We introduce a lightweight attribute aware authentication mechanism that enables verifiable binding without revealing device identity and its application-specific attribute values. Specifically, NIABIAuth incorporates Pedersen commitments into the Schnorr proof structure, allowing devices to cryptographically commit to attribute values in a hiding and binding manner. These commitments are then embedded into non-interactive authentication proofs, ensuring that only devices satisfying predefined policy constraints are granted access. This enables fine-grained access control in privacy-sensitive IoT scenarios, while its non-interactive proof design ensures efficiency even under high concurrency conditions.
• We provide both comprehensive formal validation and experimental evaluation of NIABIAuth to demonstrate its effectiveness, security, and practicality. Security is formally proven under the random oracle model, covering threats such as impersonation, replay and key compromise. Meanwhile, extensive experiments conducted on heterogeneous hardware platforms have demonstrated the low-latency performance, minimal encryption cost, and stable throughput of NIABIAuth under high concurrency conditions. These results jointly confirm that NIABIAuth achieves a strong balance between lightweight design, provable security, and deployment scalability, making it suitable for real-time and large-scale IoT deployments.

The remainder of this paper is organized as follows. Section 2 reviews existing identity authentication protocols, including centralized, decentralized, and attribute binding approaches, and identifies their limitations in IoT scenarios. Section 3 presents the detailed design and workflow of the proposed protocol NIABIAuth. Section 4 evaluates the performance of NIABIAuth through experiments across heterogeneous hardware environments and analyzes its computational and communication efficiency compared to baseline methods. Section 5 concludes the paper and outlines directions for future work.

2. Related Work

2.1. Centralized Authentication Protocols

Traditional authentication in IoT systems typically follows a centralized architecture, relying on trusted third parties such as CAs for key management and identity verification. While such systems can meet baseline security requirements, their structural design introduces several inherent limitations. One of the most critical concerns is the risk of a single point of failure. Because authentication depends on centralized servers or CAs, any compromise or downtime of these entities can result in a complete breakdown of the authentication service. In addition, privacy leakage is a prominent issue: digital certificates often embed static device identifiers and organizational attributes in plaintext, making them vulnerable to tracking, interception, or misuse. When a large number of heterogeneous terminals attempt concurrent access, scalability bottlenecks emerge. Centralized servers struggle to accommodate the linear increase in communication and computation demands, leading to difficulties in satisfying the low-latency and high-availability requirements of real-time IoT environments.

To address these challenges, researchers have proposed various improvements based on cryptographic optimization, focusing primarily on symmetric encryption [15,16,17], elliptic curve cryptography (ECC) [18,19,20,21,22], and group signature schemes [23,24,25]. In symmetric encryption-based methods, authentication typically depends on pre-shared keys to preserve anonymity. For instance, Muhammad et al. [15] proposed a secure anonymous authentication framework for UAV networks using chaotic maps, symmetric encryption, and hash functions. Mohamed et al. [16] designed a forward-secure symmetric key authentication protocol for edge-cloud IoT environments. Although such schemes offer low computational cost, they face significant challenges in key distribution, and the use of pre-shared keys over public channels introduces vulnerability to insider threats and interception. To mitigate key management difficulties, ECC has been widely adopted. ECC employs a public-key cryptosystem in which each device holds a key pair, with the public key openly shared and the private key kept secret. Abdi et al. [19] proposed a lightweight ECC-based anonymous authentication protocol incorporating biometric information and fuzzy extractors. Ding et al. [20] reduced computational complexity by minimizing the number of point multiplication operations required for identity verification. Appala et al. [21] introduced a multi-factor ECC-based approach that grants access only upon successful submission of multiple authentication tokens. Hu et al. [22] presented a secure and efficient authentication and key negotiation protocol that integrates ECC-based key exchange, dynamic identity anonymity, and resistance to forgery and ephemeral key leakage. Group signature-based schemes provide another direction, offering inherent anonymity by allowing users to sign messages as group members without revealing individual identities. This approach is particularly prevalent in vehicular ad hoc networks (VANETs). Jiang et al. [23] proposed AAAS, which combines pseudonym mechanisms and group signatures for secure vehicle communication. Recognizing the susceptibility of classical group signatures to quantum attacks and key exposure, Cao et al. [24] introduced a quantum-resistant scheme based on lattice cryptography and bonsai tree signatures. Chen et al. [25], however, highlighted the heavy computational burden of lattice-based group signatures and proposed improvements that reduce key size to achieve lightweight identity authentication. Despite these advancements, many group signature schemes still suffer from inefficiencies in communication and computation, and their real-world security remains underexplored.

In summary, centralized authentication models fundamentally conflict with the decentralized and dynamic nature of modern IoT deployments. While cryptographic enhancements can alleviate certain technical limitations, they do not resolve systemic architectural weaknesses such as trust centralization, poor scalability under high concurrency, and reliance on always-available central authorities. Furthermore, most traditional schemes lack native support for mutual authentication and large-scale concurrent verification, thereby constraining their applicability in complex, latency-sensitive, and heterogeneous IoT environments.

2.2. Decentralized and ZKP-Based Protocols

In order to overcome the inherent limitations of centralized identity authentication architectures, researchers have increasingly adopted blockchain technology as a decentralized foundation for trust management [26,27]. By leveraging the tamper-proof, transparent, and distributed ledger properties of blockchain, these approaches aim to eliminate reliance on single points of failure and enable all network participants to jointly maintain authentication records. Furthermore, recording authentication operations immutably on-chain enhances system auditability and supports full lifecycle traceability. Originally developed to support the transparency of Bitcoin transactions [28], blockchain has since become a foundational technology in domains such as digital currency, smart grids, and beyond.

In the context of the IoT, blockchain has been explored to support secure data management [29,30], resource trading [31], resource sharing [32,33], vehicle identity management [34], and shared ride systems [35]. Due to identity authentication being a fundamental prerequisite for these services, various blockchain based authentication methods have emerged. For example, Khashan et al. [36] proposed a lightweight authentication mechanism combining blockchain and edge computing to adapt to the restrictions of the Internet of Things. Mao et al. [37] used identity based signatures to establish cross domain trust anchored on blockchain infrastructure. Wang et al. [3] proposed EBIAS, a blockchain based identity authentication scheme that uses ECC and SHA-256 to protect sensitive device data. Blockchain based identity verification has also been applied to in vehicle networks: Azees et al. [38] designed an anonymous identity verification system that utilizes Merkle hash trees to manage real-time records, while subsequent solutions [39] eliminate reliance on centralized trusted entities, enhance message integrity, and protect the privacy of vehicle users.

In recent years, an increasing number of studies have explored the integration of ZKPs with blockchain infrastructures to enhance privacy and verifiability in IoT authentication protocols. This line of research seeks to overcome the limitations of centralized schemes while reducing identity exposure during verification. Early efforts such as that of Pathak et al. [13] proposed a hybrid blockchain and ZKP framework that supports mutual authentication between IoT terminals and base stations. However, its reliance on multi-round interaction and computationally capable edge devices makes it less suitable for constrained or real-time settings. Similarly, Rivera et al. [14] introduced a multi-factor authentication system under a zero-trust architecture, which generates one-time passwords (OTPs) via distributed blockchain nodes. While enhancing security, its performance suffers from latency and unreliability when nodes are intermittently offline. To address some of these limitations, recent protocols have explored lightweight and non-interactive ZKP mechanisms. Ramezan and Meamari [40] developed zk-IoT, enabling remote devices to prove firmware and data integrity without exposing internal states, achieving sub-second proof generation and verification. Commey et al. [41] combined Physical Unclonable Functions (PUFs) with ZKPs in Hyperledger Fabric to link hardware identity to blockchain credentials while preserving privacy. In a similar vein, Li et al. [42] proposed a blockchain-PUF mutual authentication scheme optimized for low-end devices, leveraging aggregate signatures to resist impersonation attacks. Further expanding this space, Narkedimilli et al. [43] introduced FL-DABE-BC, a protocol that integrates decentralized attribute-based encryption and blockchain to support secure identity authentication and federated learning. Additionally, Li et al. [44] proposed a blockchain-enabled authentication scheme under a zero-trust model, offering fine-grained access control and improved resistance to replay and spoofing attacks in power IoT environments.

In summary, decentralized authentication protocols based on blockchain and zero-knowledge proofs have shown great potential in enhancing trust, auditability, and privacy in IoT environments. However, existing schemes often suffer from high computational cost, reliance on interactive proof procedures, or limited support for fine-grained attribute verification. These constraints hinder their practical deployment in low-performance or high-concurrency IoT environments.

2.3. Attribute Binding Identity Authentication Protocols

Recent research has recognized that verifying device identity alone is often insufficient in IoT environments. It is equally critical to confirm that a device possesses specific attributes, such as role, access level, and operational context while preserving attribute confidentiality. This requirement has spurred the development of attribute binding authentication protocols that integrate fine-grained policy enforcement with identity verification.

A significant direction involves combining zero-knowledge proofs with attribute based primitives. Ramezan and Meamari [40] introduced a blockchain-enhanced ZKP protocol enabling devices to attest to firmware integrity and attribute validity without revealing internal state. Narkedimilli et al. [43] apply decentralized attribute-based encryption and blockchain to support authentication in federated learning scenarios. Both schemes deliver privacy-preserving attribute verification, but incur considerable proof sizes or require interactive multi-party selection processes. Lightweight attribute binding methods tuned for constrained IoT platforms are also emerging. Commey et al. [41] developed a Hyperledger-based ZKP scheme that couples PUF-derived attributes with blockchain credentials. Separately, Tian and Li [45] designed a CP-ABE solution for secure data sharing that uses elliptic curve-based attribute encryption and offloads key operations to an edge blockchain. While efficient in proofs and communication, both schemes focus primarily on access control rather than simultaneous identity authentication workflows.

Overall, while recent attribute-aware solutions support fine-grained access verification, they often trade off between interaction complexity, proof efficiency, and privacy preservation. Additionally, many have yet to undergo rigorous formal analysis, particularly under real-world constraints such as device heterogeneity and concurrency. To address these limitations, this paper introduces NIABIAuth, a decentralized identity authentication protocol that integrates non-interactive zero-knowledge proofs with blockchain-based verification. The proposed protocol preserves the lightweight signature efficiency of the Schnorr scheme while integrating Pedersen attribute commitments to enable fine-grained access control and dynamic terminal identity authentication. To provide a balanced evaluation, we compare NIABIAuth with several representative protocols, including those proposed by Li et al. [18], Abdi et al. [19], Tentu et al. [21], Hu et al. [22], and Wang et al. [3]. As shown in

Table 1. Descriptive comparison of representative IoT identity authentication schemes.

Protocol	Blockchain Trust Model	Attribute Binding	Privacy Preservation	Communication Pattern	Deployment Complexity
Li [18]	Centralized server	None	No	Multi-round	Low
Abdi [19]	Centralized server	None	Partial	Multi-round	Low
Tentu [21]	Permissioned blockchain	Static	Partial	Multi-round	Medium
Hu [22]	Trusted third party	None	No	Multi-round	Low
Wang [3]	Permissioned blockchain	Static	Full	Multi-round	Medium
Rivera [14]	Public blockchain	Dynamic	Full	Multi-round	High
NIABIAuth	Permissioned blockchain	Static	Full	Single-round	High

, the comparison considers blockchain trust model, attribute binding mechanism, privacy preservation, communication pattern, and deployment complexity. The results indicate that NIABIAuth achieves a unique balance of decentralization, privacy, and efficiency through its single-round, non-interactive proof design and policy-based static attribute binding, while previous works either rely on centralized trust anchors or require multiple interactive rounds. Although NIABIAuth introduces moderate blockchain-related overhead due to distributed ledger maintenance, its architecture ensures transparent auditability and scalable authentication across heterogeneous IoT devices. Hence, NIABIAuth should be viewed not as a universal replacement, but as a complementary solution well-suited for decentralized IoT environments that demand both fine-grained access control and privacy preservation.

3. NIABIAuth: Non-Interactive Attribute Binding Identity Authentication Protocol

This section presents NIABIAuth, a lightweight and privacy-preserving identity authentication protocol designed for IoT terminal devices. The protocol enhances the classical Schnorr Protocol by integrating non-interactive zero-knowledge proofs with attribute binding mechanisms based on cryptographic commitments.

Table 2. The mathematical symbols used in the paper and their meanings.

Symbol	Meaning of Symbols
$\mathbb{G}$	A cyclic group of prime order q, used for cryptographic operations
G	Generator of group $\mathbb{G}$
$ID$	Identity identifier
$PID$	Ephemeral pseudonymous identifier
$PK$	Public key of the device derived from the private key
$sk$	Private key of the IoT terminal device
$\mathcal{A}$	Attribute value to be privately bound to the identity
H	A secondary generator independent of G, used for commitments
r	Ephemeral randomness for Schnorr signing
$r_c$	Randomness used in attribute commitment
R	Commitment used in the Schnorr style proof
c	Challenge computed as a hash over public parameters and session info
C	Pedersen commitment to the device attribute
s	Schnorr response in non-interactive form
P	Authentication proof submitted by the prover
$\mu$	Session metadata
$\parallel$	Connector symbol
T	Timestamp
$\sigma$	Session Identifier

summarizes the main symbols used throughout the protocol description.

3.1. NIABIAuth

3.1.1. Overall Protocol Design

To clearly illustrate the proposed Protocol, Figure 1 presents the general overview of the NIABIAuth. The protocol is designed to support secure, low-latency, and privacy-preserving authentication among IoT terminal devices by leveraging a non-interactive zero-knowledge proof and blockchain as a decentralized trust anchor. In this architecture, smart IoT devices generate local authentication proofs, and peer nodes within the blockchain network act as verifiers by executing dedicated smart contracts. The blockchain only records limited public information necessary for verification, including an ephemeral pseudonymous identifier ($PID$), together with the public key and attribute commitment. Unlike a fixed identifier, $PID$ is generated using a secure hash function and a fresh temporary commitment R for each session. This design prevents linkability of different activities associated with the same device, while still allowing authorized auditors to recompute $PID$ values when traceability is required. Sensitive data such as private keys or raw attribute values are never stored on-chain, thereby ensuring both verifiability and privacy protection. All identity generation and binding operations are initiated by the devices themselves. Each terminal independently generates its own cryptographic key pair and an attribute commitment using a Pedersen scheme. For clarity, this paper illustrates a single-attribute commitment. In practice, NIABIAuth can be extended to multiple attributes, where each attribute ${\mathcal{A}}_i$ is bound into an independent Pedersen commitment $C_i={\mathcal{A}}_i·G_i+r_i·H$, or aggregated into a vector commitment to support richer attribute-binding policies. During authentication, the device provides a zero-knowledge proof demonstrating knowledge of all committed attributes without revealing them. This extension maintains the non-interactive property of the protocol while enabling more expressive authentication. The resulting public key and attribute commitment are submitted to the blockchain via peer nodes during the registration phase. The use of non-interactive proofs eliminates the need for multi-round communication, thereby reducing latency and computational cost for low-performance devices. The architecture comprises the following core components:

• Terminal devices: These devices act as authentication requesters in peer-to-peer communication scenarios. Each device locally generates its cryptographic identity, including a public-private key pair and a zero-knowledge commitment to its attribute. During the authentication phase, a device constructs a non-interactive zero-knowledge proof that binds its public key and attribute commitment, and submits this proof to the blockchain network for verification. This process enables devices to demonstrate identity legitimacy and attribute compliance without disclosing sensitive identity information or attribute values.
• Peer nodes: They are full participants in the blockchain network and serve two main roles: (a) as identity registrars, they receive registration submissions from terminal devices and invoke smart contracts to validate and store public keys and attribute commitments in the distributed ledger; (b) as identity verifiers, they receive proof submissions from communicating devices, retrieve the corresponding identity records from the ledger, and execute verification logic as defined in the NIABIAuth smart contract. After completing verification, the peer node returns the authentication result to the involved devices and logs the transaction details on-chain to ensure non-repudiation and traceability. The selection of peer nodes may consider computational capabilities and storage availability, as they are responsible for executing verifications and maintaining the blockchain state.
• Blockchain ledger: The blockchain functions as a tamper-resistant, append-only ledger that maintains all device identity records and authentication transaction logs. It stores the public key of each device and attribute commitment, as well as inputs and outputs of authentication sessions. By decentralizing trust and removing reliance on traditional certificate authorities, the blockchain enhances system transparency and integrity. It also enables independent verification and auditing of authentication events across administrative domains without exposing underlying sensitive information.

This design reflects a shift from centralized identity infrastructures toward lightweight, decentralized, and privacy-preserving authentication protocols suitable for large-scale and dynamic IoT environments.

3.1.2. Smart Contract Design

Smart contracts serve as the central execution modules within the NIABIAuth. They coordinate essential operations including identity registration, zero-knowledge-based identity verification, and secure logging of authentication outcomes. To meet the specific requirements of large-scale IoT deployments, namely resource constraints, high concurrency, and privacy preservation, this work introduces a set of lightweight and modular smart contracts. Unlike general-purpose contract designs, the proposed implementation minimizes computational and communication cost, and is tailored for cryptographic authentication workflows that rely on non-interactive zero-knowledge proofs and attribute commitments. The smart contract framework consists of two primary modules:

• Identity Registration Contract. This contract is responsible for anchoring the public identity information of IoT devices to the blockchain. Each device independently generates its public-private key pair and computes a Pedersen commitment to its private attribute during the registration phase. The device then submits its identifier, public key, and attribute commitment to the blockchain network through a designated peer node. The peer node invokes the registration contract, which validates and stores the identity record immutably on-chain. This enables tamper-resistant identity management without relying on centralized certificate authorities or cloud-based key issuers, and establishes the foundational trust required for subsequent authentication interactions.
• Identity Authentication Contract. This contract verifies the proofs generated by IoT devices based on the NIABIAuth. A device submits a non-interactive proof consisting of a Schnorr tuple $(R,s)$, an attribute commitment C, and session metadata. The peer node invokes the contract, which retrieves the corresponding public key and commitment from the blockchain. It then reconstructs the challenge and verifies the proof using elliptic curve operations. Upon successful verification, the contract logs the result and emits a confirmation event. This contract supports low-latency, privacy-preserving authentication without revealing sensitive identity or attribute information.

To implement the above functionality, the smart contract defines the following three key functions: (a) SetDevice: This function records the identity information of a device on the blockchain. It stores the device’s public key and corresponding attribute commitment, providing a verifiable and tamper-resistant reference for future authentication sessions. (b) ReadDevice: This function retrieves registered identity data from the blockchain. During authentication, peer nodes use this function to access the stored public key and commitment of a device in order to validate incoming authentication proofs. (c) Judge: This function performs the core verification logic of the NIABIAuth. It checks whether the submitted authentication proof satisfies the required cryptographic conditions, and returns a result indicating the success or failure of the verification.

3.2. NIABIAuth Workflow

Conventional identity authentication protocols based on zero-knowledge proofs, such as the interactive variant of the Schnorr protocol, typically require multiple rounds of message exchange between the prover and the verifier. Although these protocols offer strong cryptographic guarantees, their reliance on interactivity introduces significant communication latency and increases protocol complexity. These limitations become particularly pronounced in densely deployed IoT environments where numerous devices are required to perform frequent identity authentication under constrained computational and network resources.

To overcome these challenges, the NIABIAuth adopts a non-interactive design that enables identity authentication to be completed in a single communication step. This is achieved by applying the Fiat-Shamir heuristic to transform the interactive Schnorr protocol into a non-interactive zero-knowledge proof. In addition, the protocol introduces attribute binding via cryptographic commitments, allowing devices to demonstrate compliance with policy-relevant properties without revealing the underlying values. This structure reduces communication cost, improves authentication latency, and enhances privacy protection for constrained devices operating in dynamic and distributed environments. The NIABIAuth consists of two primary phases: (a) registration phase, in which devices submit their public keys and attribute commitments to the blockchain via peer nodes; (b) authentication phase, where devices generate self-contained proofs that are verified by peer nodes using smart contracts. The non-interactive nature of the protocol enables efficient processing of concurrent authentication requests, supports scalability to large networks, and maintains cryptographic soundness. These properties make NIABIAuth particularly suitable for secure, privacy-preserving identity verification in real-world IoT systems.

3.2.1. NIABIAuth Registration Phase

The registration phase establishes the cryptographic identity of each terminal device and anchors it to the blockchain in a tamper-resistant manner. Figure 2 shows the overall process of the identity verification phase, where the prover independently generates its encrypted material, and verifier verify and store registration info on the chain to support subsequent verification. The details are shown in Algorithm 1, and the process consists of the following steps:

Step 1: Each terminal device locally generates its own key pair $(sk,PK)$, where $PK=sk·G$, and selects a private attribute value $\mathcal{A}$ representing properties such as access level and functionality type.

Step 2: The device selects a random blinding factor r and computes a Pedersen commitment $C=\mathcal{A}·G+r_c·H$, which hides the attribute value while preserving its verifiability.

Step 3: The device submits its unique identifier $ID$, public key $PK$, and attribute commitment C to a designated peer node in the blockchain network.

Step 4: Upon receiving the registration data, the peer node verifies its format and uniqueness, and then calls the identity registration smart contract to write the identity information $(ID,PK,C)$ to the blockchain.

Step 5: The blockchain stores the validated record in the distributed ledger, thereby enabling future authentication and preventing unauthorized identity alterations.

Algorithm 1: NIABIAuth  Registration
Input: Elliptic curve parameters: $(G,q)$, elliptic curve second generator: H, device: D, device identity: $ID$, attribute value: $\mathcal{A}$, peer node: P. Output: Write registration information into the blockchain.
1 D: $sk\leftarrow Z_q$ ;	// Generate the private key
2 D: $PK\leftarrow sk·G$ ;	// Compute the public key
3 D: $r_c\leftarrow Z_q$ ;	// Generate randomness for commitment
4 D: $C\leftarrow \mathcal{A}·G+r_c·H$ ;	// Compute Pedersen attribute commitment
5 D: $M_{reg}\leftarrow ID,PK,C$ ;	// Construct the registration message
6 D: Send $M_{reg}$ to P;
7 P: SetDevice.Check(ID) ;	// Verify format and uniqueness
8 P: SetDevice.Store(ID, PK, C) ;	// Store registration info on blockchain

    Specifically, the format validation ensures that the submitted registration data comply with the expected structure and cryptographic domain parameters. The peer node checks whether the public key $PK$ lies on the designated elliptic curve, whether the attribute commitment C is of valid group order, and whether the identifier $ID$ satisfies the syntactic and length constraints defined by the protocol. The uniqueness validation guarantees that each device identity corresponds to a single registration record on the blockchain. To achieve this, the peer node computes a hash index and queries the ledger to determine whether the same hash or identifier has been previously registered. If a collision or duplicate entry is detected, the registration is immediately rejected. This process prevents replay or cloning of device identities before the data are permanently recorded on-chain. In NIABIAuth, the use of peer nodes as registration intermediaries does not imply centralization but rather reflects the operational model of a permissioned blockchain consortium. Resource-constrained IoT devices typically lack the ability to directly broadcast and sign blockchain transactions. Therefore, peer nodes operated by consortium members (such as gateways, domain controllers, or edge servers) serve as the verifiers during the registration phase. They authenticate the device’s registration proof and then act as endorsing proxies to forward the validated registration transaction to the blockchain. To prevent a malicious peer from modifying, suppressing, or falsely acknowledging a registration attempt, NIABIAuth adopts an explicit dual-signature registration protocol. Each registration transaction is signed by both the device and the peer, ensuring mutual accountability and preventing unauthorized enrollment. During registration, the device generates its own key pair $(sk,PK)$, which becomes the identity it intends to register on-chain. The device uses this private key $sk$ to sign its registration information $(ID,PK,C)$, producing $sig{n}_P$. After validating the device’s ZKP proof, format constraints, and uniqueness of the identity record, the peer node verifies $sig{n}_P$ using $PK$, and then generates its own consortium-issued signature $sig{n}_V$. This binds the peer to its verification decision and prevents it from later denying having endorsed the registration. The peer then submits the full transaction $(ID,PK,C,sig{n}_P,sig{n}_V)$ to the blockchain. Once confirmed, the ledger returns an immutable receipt, which the peer forwards to the device. Although the receipt is relayed by the peer, it cannot be forged or altered by the peer because it is signed by the consortium’s ordering and endorsement service; any modification would invalidate its signatures and be immediately detected by the device. The device performs a verification by checking that the transaction hash in the receipt matches the hash of its submitted registration information and by validating the consortium-issued signatures attached to the receipt. If these checks succeed, the device is assured that its registration has been permanently recorded on-chain, even in the presence of a potentially adversarial peer. This design maintains decentralization at the consortium level while providing practical scalability and security for lightweight IoT devices.

3.2.2. NIABIAuth Authentication Phase

In this work, “non-interactive” refers to the authentication phase between the prover and verifier, which completes in a single message transmission containing the zero-knowledge proof. The verifier does not issue any challenge to the prover, and no iterative exchanges are required. Although the verifier retrieves the prover’s public key and attribute commitment from the blockchain, this process involves only access to a publicly auditable ledger and does not constitute an interaction with the prover. Such public-state dependency is consistent with standard non-interactive zero-knowledge frameworks, where verification may rely on a common reference string or shared public data source. The NIABIAuth enables each IoT terminal to prove its identity and corresponding attribute commitment in a non-interactive and privacy-preserving manner. A crucial component of this process is the use of specific session metadata, which ensures freshness, contextual binding, and replay protection. Figure 3 shows the overall process of the authentication phase, and the specific details are as follows:

Step 1: The device generates a fresh ephemeral scalar $r\in {\mathbb{Z}}_q$ and computes the temporary commitment:

$$R=r·G.$$

(1)

Step 2: The device constructs session metadata, which contains the following two components: (a) Timestamp T: The current UNIX time obtained from the synchronized time source. This value ensures temporal freshness and mitigates replay attacks; (b) Session Identifier $\sigma$: A 128-bit randomly generated string or UUID created at the beginning of the session. It uniquely distinguishes this authentication attempt from others, even if initiated at a similar time. The metadata $\mu$ is structured as

$$\mu =T\parallel \sigma .$$

(2)

Step 3: The device computes a challenge value c using a hash function $H_1$ over a set of publicly known elements, as follows:

$$c=H_1(PK\parallel R\parallel C\parallel \mu ).$$

(3)

This binding ensures that the proof is unique to the session and tightly bound to the public key of device and attribute commitment.

Step 4: The device computes the response:

$$s=(r+c·sk) mod q,$$

(4)

to form the non-interactive zero-knowledge proof tuple $P=(R,s,C,\mu )$ and appends its identity identifier $ID$ to the message $M=(R,s,C,\mu ,ID)$. The full authentication message M is then submitted to the peer node.

Step 5: Next, enter the verification phase. The verification process can be seen in Algorithm 2. Upon receiving the authentication request, the peer node extracts the identity identifier $ID$ from the message and retrieves the corresponding public key $PK$ and registered attribute commitment $C_{reg}$ from the blockchain using the ReadDevice function.

Algorithm 2: NIABIAuth  Verification

    Step 6: The peer node uses the received parameters $(R,C,\mu )$, along with the retrieved $PK$, to recompute the challenge value:

$$c^{\prime }=H_1(PK\parallel R\parallel C\parallel \mu ),$$

(5)

This ensures that the verifier is working with the same challenge value.

Step 7: The peer node verifies that $s·G$ and $R+c^{\prime }·PK$ are equal. If the equality holds, it indicates that the device possesses the private key corresponding to $PK$, and has correctly responded to the challenge.

Step 8: To ensure attribute integrity, the peer node verifies that the submitted commitment C matches the one registered on the chain, that is, whether C and $C_{reg}$ are equal. This check ensures that the authentication proof is consistent with the registered attribute and that no substitution or tampering has occurred.

Step 9: If After completing the proof tuple verification and confirming that the submitted attribute commitment C matches the registered commitment $C_{reg}$, the peer node performs two additional checks to ensure session integrity: (a) Timestamp freshness check: The peer node verifies whether the received timestamp T falls within an acceptable time window $\Delta t$ relative to the local clock. If the timestamp is stale or significantly ahead, the request is rejected to mitigate replay or timing attacks. (b) Session identifier uniqueness check: The peer node consults a temporary cache of recently seen session identifiers $\sigma$. If the same $\sigma$ has already been processed, the request is deemed a duplicate and is rejected.

Only when all four conditions are satisfied, namely (a) Correct Schnorr proof, (b) Valid attribute binding, (c) Fresh timestamp, (d) Unused session identifier, the authentication is considered successful. The peer node then calls the SetDevice function to record the verification result on the blockchain using a freshly generated pseudonymous identifier $PID=H(ID\Vert R)$, where R is a random temporary commitment updated in each session, instead of a fixed device ID, thereby preventing long-term linkability across multiple authentications.

Step 10: Upon receiving a positive response from the peer node, the device concludes the authentication session. At this point, it has cryptographically demonstrated both the ownership of its registered key pair and the validity of its associated attributes. The device may now securely engage in subsequent activities, depending on the application context. The integrity and auditability of the session are ensured through the recorded verification result and session metadata.

3.3. Security Analysis

To strengthen the security analysis of NIABIAuth, we explicitly define the adversarial model, security goals, and provide both formal verification and theoretical analysis. This ensures that the guarantees of the proposed scheme are rigorously established and not left implicit.

3.3.1. Correctness of NIABIAuth

Before analyzing the security properties of NIABIAuth, we first show that the protocol satisfies the completeness property: any honest device following the protocol will always be accepted by the verifier.

During the authentication phase, the device samples a randomness $r\in {\mathbb{Z}}_q$ and computes the commitment $R=r·G$. It then derives the challenge using the Fiat–Shamir heuristic as $c=H_1(PK\Vert R\Vert C\Vert \mu )$ and computes the response $s=(r+c·sk) mod q$. Upon receiving $(R,s,C,\mu )$, the verifier recomputes the challenge as $c^{\prime }=H_1(PK\Vert R\Vert C\Vert \mu )$ and checks whether the verification equation $s·G=R+c^{\prime }·PK$ holds. For an honest device, substituting $s=r+c·sk$ gives $s·G=(r+c·sk)·G=r·G+c·sk·G=R+c·PK$. Since both parties compute the challenge deterministically from the same public inputs, we have $c=c^{\prime }$, and thus the verification condition $s·G=R+c^{\prime }·PK$ always holds.

Therefore, NIABIAuth satisfies correctness: every device possessing the legitimate private key $sk$ can always produce a proof that will be accepted by an honest verifier.

3.3.2. Trust Model, Threat Model, and Security Goals

Trust Model: NIABIAuth operates under a consortium-managed permissioned blockchain that serves as a distributed trust anchor. Each participating organization within the consortium possesses endorsement rights for registering and validating IoT devices. Device key pairs are generated locally during the manufacturing phase or at the initial onboarding stage, while attribute commitments are signed or endorsed by domain administrators before being recorded on-chain. The initial root of trust is therefore established through consortium governance policies rather than through a centralized certificate authority. This trust model decentralizes key management without sacrificing accountability, ensuring that each registration or update event remains verifiable and auditable. The blockchain is not treated as a black-box component but as a verifiable infrastructure that enforces decentralization, immutability, and transparency of identity management operations. It provides tamper-resistant storage for device identifiers, public keys, and attribute commitments, each of which is cryptographically protected and pseudonymized.

Threat Model: We consider a standard Dolev–Yao adversary who has full control over the communication channel. The adversary can intercept, replay, delay, modify, and inject messages at will. However, the  adversary is bounded by standard cryptographic hardness assumptions, such as the infeasibility of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP) and the hiding/binding properties of the Pedersen commitment scheme. Blockchain nodes are assumed to follow consensus protocols honestly and provide tamper-resistant storage, though adversaries may attempt to analyze stored data. End devices are resource-constrained and may be targets of impersonation or replay attacks.

Based on the above trust and threat model, the subsequent security analysis demonstrates that NIABIAuth fulfills essential authentication, integrity, and privacy properties under the defined adversarial assumptions.

Based on the above model, NIABIAuth is designed to achieve the following security goals:

• Correctness: Any legitimate device following the protocol must always be authenticated successfully by the verifier.
• Impersonation Resistance: No adversary without knowledge of a device’s private key should be able to generate a valid authentication proof.
• Replay Resistance: Old authentication transcripts replayed by an adversary should be rejected by the verifier.
• Key Secrecy: Private keys and session-related randomness must remain computationally infeasible to derive from public messages.
• Forward Secrecy: Compromise of a long-term private key must not enable the adversary to derive session-specific randomness or reconstruct past authentication proofs.
• Attribute Integrity: Device attributes bound to an identity must remain unforgeable and verifiable.

3.3.3. Formal Simulation and Verification

To validate that NIABIAuth meets the security goals defined in the threat model, we conducted a formal verification using the AVISPA (Automated Validation of Internet Security Protocols and Applications) framework. AVISPA provides a standardized environment for specifying protocols in the High-Level Protocol Specification Language (HLPSL) and analyzing them under the Dolev–Yao adversary model.

The NIABIAuth protocol was modeled in HLPSL with roles corresponding to the key entities described in the threat model. The Device role captures the generation of Schnorr-based zero-knowledge proofs and Pedersen commitments, while the Verifier role represents a blockchain peer node responsible for verifying proofs through smart contract logic. An  Intruder role embodies the adversary with Dolev–Yao capabilities, and the Environment role coordinates protocol sessions. The HLPSL specification encoded security requirements for authentication, secrecy, and freshness, ensuring that only legitimate devices can be authenticated, private keys and attribute values remain confidential, and replayed proofs are rejected.

The model was analyzed using two AVISPA backends: OFMC, which performs symbolic state-space exploration to detect potential interleaving and man-in-the-middle attacks, and CL-AtSe, which verifies authentication and secrecy goals through constraint solving. To assess resilience under high concurrency, we simulated multiple parallel protocol sessions in which the adversary attempted to inject forged proofs, replay outdated transcripts, or impersonate devices without knowledge of private keys.

The results of the formal analysis consistently returned the verdict SAFE across both backends, indicating that no attack traces violating the specified security goals were identified. In particular, the verification confirmed that legitimate devices were always accepted, while impersonation attempts without the private key were consistently rejected. Replay attempts using previous transcripts also failed due to the inclusion of session-specific randomness. Furthermore, the secrecy analysis demonstrated that the adversary was unable to infer either long-term keys or ephemeral randomness from public communication. Even under hypothetical post-compromise scenarios, the forward secrecy property was preserved since past session data remained computationally protected. Attribute commitments were also verified to be both binding and tamper-detectable, ensuring attribute integrity against modification.

These verification results provide strong evidence that NIABIAuth is robust under a wide range of symbolic attacks in the Dolev–Yao model. The consistency between the theoretical definitions in the threat model and the formal simulation outcomes demonstrates that the protocol achieves its intended security properties. By combining Schnorr zero-knowledge proofs, Pedersen commitments, and session-specific randomness, NIABIAuth is shown to provide correctness, impersonation resistance, replay protection, key secrecy, forward secrecy, and attribute integrity within a hostile network environment.

3.3.4. Theoretical Analysis of Security Properties

The NIABIAuth implements a provably secure authentication mechanism by combining non-interactive Schnorr proofs with Pedersen attribute commitments. While the AVISPA-based formal analysis in Section 3.3.2 demonstrates that NIABIAuth resists a wide range of symbolic attacks under the Dolev–Yao model, it is also necessary to provide a complementary theoretical justification. In what follows, we provide cryptographic arguments to demonstrate how the protocol achieves its main security properties under standard assumptions such as the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP) and the binding/hiding guarantees of the Pedersen commitment scheme.

• Resistance to Impersonation Attacks
  Proof: The authentication proof in NIABIAuth is based on the Schnorr identification protocol transformed into a non-interactive zero-knowledge form via the Fiat-Shamir heuristic. Under the discrete logarithm assumption in cyclic group $\mathbb{G}$, an adversary without knowledge of the private key $sk$ cannot compute a valid response s satisfying the verification equation $s·G=R+c·PK$. Moreover, since the challenge c is derived via a collision-resistant hash function over public parameters and session-specific metadata, the protocol resists impersonation attack.
• Resistance to Attribute Inference Attacks
  Proof: The NIABIAuth effectively resists attribute inference attacks through the use of Pedersen commitments, which are known to be statistically hiding under standard cryptographic assumptions. Given a commitment $C=\mathcal{A}·G+r·H$, where $\mathcal{A}$ is the private attribute value and r is randomly selected blinding factor, the distribution of C is computationally indistinguishable for different values of $\mathcal{A}$ due to the presence of high entropy randomness r. Consequently, even if an adversary intercepts multiple authentication messages containing distinct or repeated commitments, the inherent randomness ensures that no information about the underlying attribute can be extracted. Moreover, since the commitment is bound to the device identity and submitted as part of a zero-knowledge proof, an adversary cannot isolate or manipulate C independently to perform correlation-based or frequency-based inference. This property ensures that NIABIAuth achieves strong contextual privacy, preserving the confidentiality of device attributes even under full transcript exposure.
• Resistance to Man-in-the-Middle (MITM) Attacks
  Proof: In each session, the challenge value c is deterministically computed as a hash over public inputs, including the temporary commitment R, the public key $PK$, the attribute commitment C, and the session metadata $\mu$. This binding ensures that any modification of message components by a MITM adversary will result in an inconsistent challenge and thus an invalid proof. Furthermore, because the authentication message includes only the proof tuple $(R,s,C,\mu )$, and no round-trip interaction occurs between prover and verifier, the attacker has no opportunity to alter or inject values dynamically during a challenge-response exchange. Any attempt to relay or modify previously captured authentication messages is rendered ineffective due to the inclusion of session metadata, which are verified during the proof validation. Therefore, NIABIAuth provides robust protection against MITM attacks and ensures the authenticity and integrity of each authentication session under adversarial relay conditions.
• Resistance to Replay Attacks
  Proof: Session metadata comprising a timestamp T and a unique session identifier $\sigma$ is incorporated into the hash that defines c. This prevents reuse of old proofs, as each session yields a unique challenge. The verifier additionally checks that T is within a freshness window $\Delta t$ and that $\sigma$ has not been seen before, effectively resisting replay attacks.
• Forward Security
  Proof: The NIABIAuth achieves forward security by ensuring that each authentication session is cryptographically independent from previous ones. In every session, the device generates fresh ephemeral randomness r for the temporary commitment $R=r·G$ and includes session metadata $\mu$ in the challenge computation c. As a result, even if the long-term private key $sk$ is compromised after certain sessions have been completed, the transcripts of prior authentications cannot be retroactively linked to or used to recover the session-specific randomness r, due to the one-way nature of the hash function and the computational hardness of the discrete logarithm problem. Furthermore, because the attribute commitment C also involves blinding randomness $r_c$, the values observed in earlier sessions remain unlinkable and resistant to retrospective analysis. Thus, the confidentiality of past interactions remains preserved even in the event of private key exposure, satisfying the requirement of forward security.
• Backward Security
  Proof: Backward security is ensured in NIABIAuth by incorporating fresh, per-session randomness and context-specific challenge computation that tightly binds each proof to a unique session. Even if an adversary intercepts a valid proof tuple $(R,s,C,\mu )$ from a past session, they cannot use this information to forge valid authentication messages for future sessions. This is because the challenge c is derived from session-specific metadata including a fresh timestamp and session identifier which change with each execution. Reusing a prior proof in a new session context will result in challenge mismatch during verification, causing the proof to fail. Moreover, since the Schnorr response s depends on the freshly ephemeral r, the adversary cannot adaptively derive a new valid response for a modified c without knowing the secret key $sk$. Therefore, past transcripts offer no computational advantage in generating valid proofs for future sessions, and the protocol maintains resistance to forward-forging or predictive attacks, thereby achieving strong backward security.

3.4. Attribute Update and Revocation Mechanism

To enhance the completeness of NIABIAuth, we further discuss how attribute and credential revocation can be supported within the existing framework. In NIABIAuth, each device’s identity is linked to a Pedersen commitment $C=g^a{h}^r$ representing its attribute set. When a device’s role changes or its credential is compromised, the consortium administrator or domain authority can issue an updated attribute commitment $C^{\prime }$ and register it on-chain through a revocation transaction. The blockchain thus maintains an immutable record of both valid and revoked commitments. During subsequent authentication, the verifier only accepts proofs generated from the latest valid commitment associated with the device’s pseudonymous identifier. This ensures that revoked or outdated credentials cannot be reused, while the specific attribute values remain hidden due to the hiding property of the commitment scheme.

This revocation discussion demonstrates that NIABIAuth can support controlled attribute lifecycle management without relying on a centralized certificate authority. The revocation process leverages the transparency and auditability of the blockchain, while the cryptographic design preserves unlinkability and privacy. Such a mechanism allows secure deactivation and reissuance of device credentials with minimal protocol modification, improving the overall completeness and practicality of the proposed system.

4. Experiments and Results

The proposed NIABIAuth serves as a lightweight and privacy-preserving identity authentication mechanism for IoT terminal devices. It supports secure and efficient under large-scale, low-performance, and high-concurrency conditions. By leveraging non-interactive zero-knowledge proofs and attribute binding commitments, the protocol eliminates the need for interactive exchanges or centralized trust anchors, making it particularly suitable for real-time decentralized IoT environments. This section presents the implementation details, experimental setup, and performance evaluation of NIABIAuth under three hardware configurations and simulated network conditions. The experiments aim to evaluate key performance indicators such as registration latency, authentication latency, and encryption computation cost, and verify the scalability and robustness of the protocol in real-world IoT deployment scenarios.

4.1. Experimental Setup

4.1.1. Experimental Configuration

As IoT systems continue to evolve across diverse domains including smart cities, industrial control, autonomous infrastructures, and energy applications such as VPPs, ensuring secure and efficient device authentication under heterogeneous conditions has become a critical challenge. In particular, decentralized and privacy-preserving protocols must be deployable on devices with varying computational capabilities, while maintaining high authentication throughput and low latency. To evaluate the practicality and scalability of the proposed NIABIAuth, we selected a VPP scenario for simulation and designed a set of experiments reflecting typical IoT deployment conditions. These experiments are conducted across three representative hardware configurations: (a) High-performance node: Intel i9-11900H processor, 8-core CPU, 8 GB RAM. This configuration represents edge computing platforms or core blockchain validators responsible for proof verification and ledger management. (b) Mid-performance node: Intel i7-7700K processor, 4-core CPU, 4 GB RAM. This reflects industrial gateways or local control centers equipped with moderate processing resources. (c) Low-performance node: Intel i5-7200U processor, 2-core CPU, 2 GB RAM. This simulates lightweight edge or endpoint devices that require lightweight authentication logic.

The blockchain backend is built on Hyperledger Fabric 2.5, with all core components containerized via Docker to ensure modular deployment and execution isolation. As shown in Figure 4, the experimental Fabric network comprises two organizations, each containing two peer nodes. These peer nodes are responsible for maintaining the distributed ledger and executing smart contracts related to identity registration and authentication. Ordering service cluster manages global transaction sequencing and block dissemination across the network. A dedicated channel is established to support data isolation and access control across organizations. Within this channel, only participating organizations can access and validate transaction data, ensuring both confidentiality and consistency. Within this experimental setup, IoT clients such as edge and end devices interact with the blockchain via the Fabric SDK. During the identity authentication process, a client first constructs a transaction proposal and submits it through the specified channel to the peer nodes of the corresponding organization. These peer nodes acting as endorsers invoke the deployed smart contract, verify the submitted identity proof, and return signed endorsement responses. Once sufficient endorsements are collected according to the endorsement policy, the client assembles a complete transaction and submits it to the ordering service cluster. The ordering service packages the transaction into a block and broadcasts it to all peer nodes within the channel. This process ensures that authenticated identity records are immutably committed to the distributed ledger, supporting auditability and decentralized trust.

This experimental setup enables evaluation of the NIABIAuth in terms of performance and deployment compatibility, while highlighting its seamless integration with standard blockchain infrastructure and support for secure identity authentication in heterogeneous IoT environments.

4.1.2. Experimental Methods

To evaluate the effectiveness and practicality of the NIABIAuth in decentralized IoT environments, we conduct a series of experiments that examine its performance under varying device configurations. The evaluation is structured into two main components. First, we perform protocol-level stress testing to assess the capacity of blockchain system to handle high-concurrency authentication transactions. Using the Go testing framework, we invoke the smart contract functions responsible for identity registration and proof verification under different workloads. Key performance metrics such as authentication transaction throughput are recorded. These tests are used to determine the scalability and responsiveness of the NIABIAuth when deployed on a Hyperledger Fabric network. Second, we analyze the computational and communication cost of NIABIAuth in comparison with representative baseline protocols. This analysis includes both a theoretical comparison and an empirical evaluation across three hardware environments. For each configuration, we measure the average time required for device registration and authentication, focusing on both the terminal and peer node sides. These results verify the lightweight nature of the protocol and its adaptability to heterogeneous computing platforms. This experimental framework provides a comprehensive understanding of the practical deployability of NIABIAuth, highlighting its advantages in balancing security, efficiency, and scalability.

4.2. Performance Analysis

4.2.1. Performance Stress Test and Functions Efficiency Comparison Analysis

In blockchain-based identity authentication systems, maintaining high throughput and low latency under resource constraints is critical to supporting real-time applications. As a decentralized protocol, NIABIAuth relies on smart contract execution over distributed ledgers. This inevitably incurs computational and storage cost at the verifier (peer node) level. In constrained environments or unstable networks, excessive load may lead to transaction latency, throughput degradation, and compromised system responsiveness, especially in scenarios requiring frequent device authentication.

To evaluate the scalability and robustness of NIABIAuth under different computing power, we tested the performance of three core smart contract functions (SetDevice, ReadDevice, and Judge) in three representative node configurations. Each function corresponds to a key stage in the protocol: identity registration, credential retrieval, and proof verification.

In the experiments, we defined fixed target transaction throughput levels and recorded the actual throughput of system during execution. As illustrated in Figure 5, the horizontal axis indicates the configured target throughput (transactions per second), while the vertical axis reflects the observed throughput of system. Each authentication request is treated as a transaction. In the low-performance setup, all three functions maintain stable performance up to approximately 400–1000 TPS. The SetDevice function, which involves writing to the blockchain ledger, saturates earlier due to endorsement and state update cost. In contrast, the ReadDevice and Judge functions involve fewer state modification operations and maintain higher throughput under moderate load conditions. Performance improves significantly under mid-performance and high-performance configurations. In particular, the Judge function responsible for Schnorr proof verification can reach 2300 TPS before a performance bottleneck occurs. These results confirm that NIABIAuth scales efficiently across diverse hardware environments, from lightweight edge devices to high-throughput blockchain nodes.

To further evaluate transaction-level responsiveness, we performed target throughput tests on each core function. Specifically, we configured a series of target throughput values and simultaneously recorded the actual transaction send rate (actual transmission rate) and the confirmed transaction processing rate (actual throughput) as observed within the blockchain system. These tests were performed under a low-performance node configuration, simulating typical edge computing environments.

As shown in Figure 6, each subgraph corresponds to the performance of a core function under different target throughput settings. The horizontal axis represents the configured target throughput, while the two plotted lines correspond to the real-time performance of system. The blue line indicates the actual transmission rate observed at the client side, and the yellow line shows the actual throughput recorded at the peer node after consensus and contract execution. The results indicate that for ReadDevice and Judge, the actual throughput closely follows the target up to 1000 TPS, with negligible deviation between transmission rates and actual throughput. These two functions are involved primarily in proof validation and identity lookup, and their performance demonstrates NIABIAuth’s capability to maintain low-latency authentication even under constrained hardware. By contrast, SetDevice, which performs state updates to the blockchain ledger, begins to diverge from the target rate at higher loads, showing signs of write saturation. However, since this function is not on the critical real-time authentication path, its performance degradation has limited impact on end-to-end authentication latency. The experimental results confirm that NIABIAuth can sustain millisecond-level response under moderate to high authentication load, even in low-performance IoT deployments.

4.2.2. Computational and Communication Cost Comparison

To facilitate a fair comparison of computational and communication cost, we evaluate the average time consumption of fundamental cryptographic operations over 1000 execution cycles. Specifically, the SHA-256 hash function is used to represent hashing operations, with an average time cost denoted as $T_H$, measured at 0.03 ms per invocation. Elliptic curve scalar multiplication, a dominant cost in operations, is denoted as $T_{PM}$, averaging 0.45 ms per operation. In addition, lightweight operations such as bitwise $XOR$ are denoted as $T_{XOR}$, with an average time of 0.01 ms per execution. These baseline metrics provide the foundation for estimating the overall cost of NIABIAuth and comparable authentication schemes.

The time cost analysis in this study primarily focuses on the authentication phase, as it is executed more frequently than the registration phase in real-world deployments. Common low cost operations such as integer addition, basic multiplication, and equality checks, are excluded from the comparison due to their negligible impact on total cryptographic cost. The computational cost is decomposed into two components: the cost incurred by the terminal device for generating the zero-knowledge proof, and the cost borne by the peer node during proof verification.

Under consistent experimental conditions, the proposed NIABIAuth is compared against several representative schemes, including traditional lightweight designs by Li et al. [18], Abdi et al. [19], Tentu et al. [21], Hu et al. [22], and blockchain-based schemes by Wang et al. [3] and Rivera et al. [14]. As shown in

Table 3. Comparison of theoretical computational costs in different protocol authentication phases.

Protocol	Computational Composition	Time Cost (ms)
Li [18]	$18T_H+3T_{PM}+9T_{XOR}$	1.98
Abdi [19]	$22T_H+6T_{PM}+36T_{XOR}$	3.72
Tentu [21]	$4T_H+8T_{PM}$	3.72
Hu [22]	$6T_H+6T_{PM}+2T_{XOR}$	2.90
Wang [3]	$8T_H+6T_{PM}+3T_{XOR}$	2.97
Rivera [14]	$3T_H+4T_{PM}$	1.89
NIABIAuth	$2T_H+4T_{PM}$	1.86

, NIABIAuth achieves the lowest total computational cost among all evaluated methods. In particular, the time consumption of NIABIAuth is comparable to that of Li et al. [18], which also adopts a lightweight design but does not provide attribute binding. Compared with blockchain-based approaches such as Wang’s EBIAS [3] and Rivera’s protocol [14], NIABIAuth demonstrates substantially lower authentication latency, since its non-interactive proof mechanism eliminates multiple on-chain interactions. However, this comes at the cost of slightly higher on-chain storage overhead due to the inclusion of attribute commitments. Overall, NIABIAuth provides a stronger balance between privacy-preserving attribute binding and computational efficiency, making it particularly suitable for real-time applications in resource-constrained IoT environments, while blockchain-heavy protocols may be more appropriate when minimizing trust assumptions or ensuring long-term auditability is the primary goal.

To ensure consistency in the evaluation of communication cost across different authentication protocols, a unified parameter setting is adopted. The length of the identity identifier is denoted by $L_{ID}$, which is configured as 160 bits. The output length of the hash function, represented by $L_H$, is defined as 256 bits, following the SHA-256 standard. The bit length of an uncompressed elliptic curve point is denoted by $L_R$, set to 512 bits. This length applies to all elliptic curve elements involved in the protocol, including the Schnorr commitment R and the Pedersen commitment C. The response scalar in Schnorr-based protocols is represented by $L_s$, with a length of 256 bits. Metadata used for freshness verification includes a timestamp and a session identifier, whose lengths are denoted by $L_T$ and $L_{SID}$, respectively, each occupying 160 bits. Additionally, for protocols employing bitwise obfuscation, the length of the $XOR$ value is expressed as $L_{XOR}$, configured as 64 bits. These parameters serve as the basis for calculating the total communication cost associated with each authentication message.

Table 4. Comparison of theoretical communication costs in different protocol authentication phases.

Protocol	Message Composition	Communication Cost (bits)
Li [18]	$6L_H+3L_{XOR}+4L_R$	3776
Abdi [19]	$4L_H+13L_{XOR}+L_R$	2368
Tentu [21]	$L_{ID}+2L_H+3L_R$	2208
Hu [22]	$L_{ID}+2L_H+2L_T+2L_R$	2176
Wang [3]	$L_{ID}+3L_H+3L_T+2L_R$	2432
Rivera [14]	$2L_{ID}+L_H+2L_T+2L_R+2L_s$	2432
NIABIAuth	$L_{ID}+L_s+L_T+2L_R+L_{SID}$	1760

presents the total communication cost of each protocol, measured as the cumulative bit length of all messages transmitted during a single authentication session. Among the evaluated methods, NIABIAuth again achieves the lowest communication cost, with a total message size of 1760 bits. In comparison, the protocol proposed by Li et al. [18] has the highest cost, transmitting 3776 bits per session, which is more than twice that of NIABIAuth. Other representative schemes, such as those by Hu et al. [22] and Tentu et al. [21], exhibit moderate communication costs between 2176 and 2208 bits, but are still more than 20% higher than that of NIABIAuth. It is worth noting that both Wang et al. [3] and Rivera et al. [14] adopt blockchain-based designs to enhance trust and transparency. However, their communication costs remain at 2432 bits, which is significantly higher than the 1760 bits of NIABIAuth. This demonstrates that the proposed NIABIAuth method not only preserves the inherent advantages of blockchain but also achieves superior efficiency, making it more practical for large-scale IoT and edge deployments.

NIABIAuth reduces overall communication cost through a compact proof structure that unifies identity, session metadata, and attribute commitments in a single round of interaction. This makes it particularly well-suited for IoT environments where minimizing transmission volume is crucial for latency control and energy efficiency.

To comprehensively assess the time efficiency of the proposed NIABIAuth, we adopt registration time and authentication time as core performance indicators and compare the protocol against several representative authentication schemes under varying hardware configurations. Figure 7 presents the time cost of each method across high-performance, mid-performance, and low-performance nodes, reflecting typical deployment conditions in heterogeneous IoT environments. Although NIABIAuth exhibits slightly higher registration latency than the scheme proposed by Abdi et al. [19] and Rivera et al. [14], it consistently achieves lower authentication latency than all baseline methods. Across all configurations, the protocol maintains an average authentication time of approximately 10 milliseconds or less, indicating strong adaptability to devices with different computational capabilities. These results confirm that NIABIAuth offers a favorable balance between efficiency and scalability, making it suitable for real-time identity authentication in low-performance systems.

4.2.3. Energy and Memory Overhead Analysis

To further evaluate the lightweight performance of NIABIAuth, we conducted a detailed energy and memory overhead analysis on the Intel Core i5 platform. Although this device is more powerful than typical IoT hardware, its cycle-level profiling enables a fine-grained estimation of the resource costs on embedded platforms through a cycle-accurate methodology.

Each cryptographic primitive used in NIABIAuth was profiled using Intel VTune Profiler and hardware performance counters to measure instruction counts and CPU cycles. The measurements were then normalized to equivalent energy values under a representative embedded configuration by applying an average energy-per-cycle coefficient of 2.7 pJ, corresponding to a 48 MHz ARM Cortex-M7 microcontroller operating at 3.3 V and 4.8 mA. The same estimation process was applied to six representative authentication schemes: Li [18], Abdi [19], Tentu [21], Hu [22], Wang [3], and Rivera [14]. All protocols were implemented under identical cryptographic libraries and compiler optimizations for fairness.

The resulting energy consumption, runtime memory usage, and static binary size are summarized in

Table 5. Cycle-accurate estimation of energy and memory overhead.

Protocol	Energy per Proof (mJ)	Runtime Memory (KB)	Binary Size (KB)
Li [18]	5.83	64.1	58.3
Abdi [19]	6.12	66.5	60.2
Tentu [21]	4.75	58.4	54.8
Hu [22]	7.41	70.3	63.5
Wang [3]	3.88	55.2	50.7
Rivera [14]	4.22	59.8	57.9
NIABIAuth	2.45	44.2	42.5

. The “Energy per Proof” column reflects the total energy required for one authentication event, including proof generation and verification, extrapolated to an embedded execution model. The “Runtime Memory” represents the peak dynamic allocation measured through Valgrind’s massif tool, while “Binary Size” refers to the compiled firmware image excluding external dependencies.

As shown in Table 5, NIABIAuth exhibits the lowest overall energy and memory overhead among the evaluated schemes. The total energy required for one authentication operation (including proof generation and verification) is approximately 2.45 mJ, representing a 58% reduction compared with Li’s protocol and a 37% reduction compared with the blockchain-based Wang’s scheme. The runtime memory usage of 44.2 KB and a static binary size of 42.5 KB indicate that NIABIAuth can be executed comfortably on embedded systems with 128–512 KB SRAM, such as ARM Cortex-M7 or ESP32-class devices.

The cycle-level analysis further revealed that elliptic curve scalar multiplications dominate the computational cost, accounting for approximately 75% of the total energy consumption. Pedersen commitment generation contributes around 16%, and hash computations account for the remaining 9%. Future optimizations may focus on precomputation or hardware acceleration to further reduce energy usage. Despite being implemented and profiled on an Intel platform, the cycle-accurate projection demonstrates that NIABIAuth maintains a significantly lower computational footprint, validating its claim as a lightweight and scalable authentication framework suitable for low-power IoT devices.

5. Conclusions and Future Work

This paper proposes NIABIAuth, which aims to achieve secure and efficient authentication of heterogeneous terminals in the IoT environment. NIABIAuth improves the Schnorr protocol by embedding verifiable attribute commitments into the authentication proof, enabling identity authentication that incorporates contextual constraints such as device type, domain role, or access level. This design supports fine-grained, privacy-preserving authentication without relying on fixed identifiers or centralized certificate authorities. Identity credentials and authentication records are stored on a permissioned blockchain to ensure tamper resistance, traceability, and decentralized trust management. Comprehensive experiments on heterogeneous hardware platforms confirm that NIABIAuth achieves millisecond-level latency and stable throughput across low-performance, mid-performance, and high-performance nodes. Compared with existing methods, it significantly reduces communication and computation cost while maintaining strong resistance to impersonation, replay, and key leakage attacks, which has been verified through formal analysis of AVISPA. These results demonstrate the practical deployability of NIABIAuth in real-time and large-scale IoT scenarios involving multi-domains and high concurrent access requirements.

In future work, we plan to further optimize the proof generation and verification processes to accommodate ultra-low-power IoT terminals, particularly through the use of hardware-assisted cryptographic primitives and lightweight signature aggregation techniques. Additionally, we are exploring the integration of NIABIAuth with federated identity management frameworks to enable cross-domain authentication and trust negotiation among heterogeneous IoT subsystems.

Finally, we acknowledge that full decentralization is not always the most practical solution. For many IoT applications, a light form of centralization such as delegating part of the identity management or access control functions to a trusted service provider may simplify deployment while still maintaining acceptable levels of privacy protection. In this sense, NIABIAuth should be viewed as a complementary approach, whose fully decentralized and non-interactive design can be combined with lighter centralized controls to enhance applicability in diverse real-world IoT scenarios.