Enhancing Account Information Anonymity in Blockchain-Based IoT Access Control Using Zero-Knowledge Proofs

Abstract

Blockchain and smart contracts are widely used in IoT access control to create decentralized, trustworthy environments for secure access and record management. However, their application introduces a dual challenge: The transparency of blockchain and the use of addresses as identifiers can expose account privacy. To tackle this issue, this paper proposes a blockchain-based IoT access control system that enhances account anonymity and preserves privacy, particularly regarding user behavior, habits, and access records through the use of zero-knowledge proofs. The system incorporates an access control mechanism that combines access control lists with capability-based access control, enabling ownership verification of access rights without disclosing identity information. To evaluate the system’s feasibility, we conduct experiments in a smart building scenario, including both qualitative comparisons with existing methods and quantitative analyses of performance in terms of time, space, and gas consumption. The results indicate that our scheme achieves the best time efficiency in the proof generation and authorization phases, completing them in just 7 and 10 s, respectively—representing half the time required by the second-best approach. These findings underscore the system’s superior cost efficiency and enhanced security compared to existing solutions.

1. Introduction

1.1. Background

With the rapid development of wireless communication and sensors, the Internet of Things (IoT) has gained growing recognition among the general public for its features of implementing connection, interaction, and data exchange across diverse devices [1]. According to recent data, the number of connected IoT devices has surged to approximately 50 billion, with projections indicating a substantial increase to 75 billion by 2025 [2,3]. The notable rise of the Internet of Things (IoT) highlights its ability to be used in various areas, including smart homes, healthcare, smart cities, smart buildings, etc. The integration of IoT devices in these scenarios will undoubtedly enhance user experiences [4]. Nevertheless, the IoT system’s extensive collection of private user information, including personal health, location, and social relations information, poses a significant risk in the presence of unauthorized access. For this purpose, access control (AC), which effectively monitors resource access and prevents the unauthorized flow of information, has been a fundamental component of IoT systems [5].

Most IoT access control mechanisms are built upon four commonly used access control mechanisms: Role-based Access Control (RBAC) [6], Attributed-based Access Control (ABAC) [7], Capability-based Access Control (CapBAC) [8], and the Access Control List (ACL) [9]. Compared to other models, CapBAC uniquely facilitates communication between two objects without a direct connection by employing an unforgeable token, which contains a reference to the corresponding objects, namely, ’capability’ [10]. Consequently, CapBAC is superior in its ability to prevent direct access between objects and facilitate the revocation operation [11]. Particularly, owing to the design of the token structure, the integration of privacy-preserving measures, such as asymmetric encryption and zero-knowledge proof, can be easily facilitated, thereby enhancing the access control system’s security and anonymity.

However, traditional IoT access control mechanisms face prolonged issues regarding centralized authority managing resources and validating the ownership of access rights, potentially resulting in a single point of failure [12]. Furthermore, it is challenging to identify an authority that can obtain the trust of all entities involved [13]. To address this issue, it is imminent to leverage the features of blockchain technology, such as fault tolerance and immutability, in the access control mechanism to establish a more decentralized and robust access mode.

The adoption of blockchain-based IoT access control (BIAC) is widely advocated due to its numerous advantages, including enhanced transparency, trustlessness, decentralization, resiliency, security, authorization, cost-effectiveness, immutability, and auditability, when compared to alternative methods [14,15]. However, in [16], Miers et al. demonstrated groundbreaking evidence that sensitive transactions in Bitcoin can be traced by third parties using network topology, thus violating user privacy. This finding contradicts the widely held public perception that blockchain accounts are entirely anonymous. This issue is not unique to Bitcoin. It extends to other blockchains that rely on blockchain addresses to identify the participants in transactions.

Certainly, the security of user privacy information in BIAC is susceptible to the previously mentioned issue. Simultaneously, the existing BIAC systems rarely pay enough attention to the risks involved in the storage of records within the blockchain and smart contracts. Several of them even build on-chain behavior lists with access data and user information in plaintext. For instance, although [12] comprehensively addressed the issues of misbehavior and the corresponding penalty by maintaining several on-chain lists such as a policy list, misbehavior list, and lookup list, these can be easily compromised by eavesdropping due to the on-chain raw data storage of privacy in a majority of fields, including ‘ScAddress’, ‘Resource’, etc. By contrast, Hu et al. [13] focused on account privacy in BIAC and the corresponding on-chain lists via zero-knowledge proof. However, their system merely considers the user’s anonymity, thereby disregarding the significance of the object’s privacy. The above-mentioned designs introduce a potential vulnerability, as an attacker could exploit this system to deduce user behavior and habits by preemptively matching blockchain addresses to subjects or objects in the context of transactions, leading to a potential breach of privacy in behavior, habits, and records.

As a promising solution to this challenge, zero-knowledge proof enables a scenario in which a prover convinces a verifier that a statement is true without disclosing any additional information [17]. Out of numerous zero-knowledge proof algorithms, Groth16 [18], a renowned implementation of zero-knowledge proof, stands out for its compact proof size and rapid verification times, which enhance not only the time and space efficiency but also the scalability of the system. In response to the high storage costs associated with permissionless blockchains, Groth16 shows its significant superiority in blockchain-based applications. In recent years, to address the protection of user privacy, the blockchain-based AC system with zero-knowledge proof has recently gained popularity as a study area [19]. Zero-knowledge proof is widely used in the existing works to decouple the ownership of access rights from blockchain accounts [4,13,16,20]. Nevertheless, none of them comprehensively addresses both the subject’s and the object’s privacy, making it challenging to guarantee that attackers will not compromise the system by exploiting the overlooked side.

1.2. Motivation

As discussed above, storing access data and user information on the blockchain in current blockchain-based IoT access control systems is inevitable. The transparency inherent in the blockchain introduces a potential risk of private information leakage. In detail, when a user seeks access to an IoT resource, a necessary registration procedure takes place between the user and the resource owner. Typically, the user is mandated to provide his/her blockchain address as the unique identifier (i.e., ID) during this process. However, using a blockchain address as an ID without implementing sufficient security and privacy-preserving designs raises several security concerns, potentially compromising the user’s on-chain behavior, habits, and record privacy. Several specific factors contribute to this condition:

• Object’s Privacy: From the viewpoint of an IoT device, challenges associated with private data analysis persist within these systems. In BIAC systems, not only subjects and resource owners but also IoT devices are required to connect to the on-chain environment. Due to the limitations in computational power, a commonly employed approach involves utilizing an intermediary object as the gateway for blockchain connection. In this structural setup, the object assumes control over IoT devices and represents them on the blockchain. However, a potential vulnerability arises in this configuration. In existing studies where the object is employed, privacy preservation for the object often gains less recognition compared to the subject’s privacy or is even overlooked. In this context, malicious attackers within the system could easily distinguish IoT devices if the object’s ID is directly used to represent the corresponding controlled IoT device. Once IoT devices are identified, attackers can exploit this information to steal both behavior and identity details from the IoT devices by analyzing public on-chain data.
• Proof Verification: In the pursuit of a high-efficiency and low storage cost, most systems presented in existing works perform zero-knowledge proof verification in the off-chain environment. Nevertheless, this introduces additional trust assumptions and eventually requires the blockchain’s intervention to resolve disputes [21]. Additionally, off-chain verification functions may be susceptible to proof falsification and tampering, which can compromise the accuracy and robustness of the access control mechanism within the system. Therefore, it is necessary to implement on-chain zero-knowledge proof verification in BIAC systems.
• Record Accessibility: In the majority of access control systems, access records are indispensable for auditability and traceability in case of accidents and mistakes. In BIAC, smart contracts often play the important role of maintaining these records due to their immutable feature, which safeguards access records against tampering and falsification. However, the use of smart contracts presents a double-edged sword. Conversely, concerns regarding the privacy of user access rights and actions are on the rise in smart contracts. For instance, in [12], the authors designed a lookup table using smart contracts to display registration information, which poses a high risk of unauthorized access to records. This is attributed to the accessibility of data stored in the smart contract by anyone who knows the contract’s address.

1.3. Our Contribution

As a response to the aforementioned potential threats, we endeavor to enhance security in BIAC systems, ensuring the anonymity of accounts and mitigating security concerns related to behavior, habits, and record privacy. The specific contributions of our work are outlined in the following:

1.

To address object privacy, we propose a unified strategy that emphasizes protecting all entities, particularly the object. By combining hash functions with zero-knowledge proofs, we securely process subject and object identities, enhancing account anonymity. Our method offers stronger resistance to object-side linkage attacks than most existing approaches.

2.

Our system uniquely applies zero-knowledge proofs to establish ownership of access rights, seamlessly integrating them with Capability-based Access Control and embedding them in access tokens. Unlike prior work, it supports on-chain verification of zero-knowledge proofs, reducing the risk of falsification and tampering while enhancing access control accuracy and robustness. To facilitate evaluation and comparison, we have made the full source code publicly available, including the on-chain verification function, in Section 5.3.

3.

We also present a robust method for secure and auditable record access. Specifically, a privacy-preserving, tamper-resistant access log is implemented via smart contract, enabling authorized queries while blocking unauthorized ones. Compared to [12], our approach ensures higher confidentiality in access and auditing, addressing concerns related to smart contract transparency.

The remainder of this paper is structured as follows. Section 2 reviews the related work in the field. Section 3 analyzes existing attack models in current BIAC systems. Section 4 presents our proposed BIAC system, followed by Section 5, which details its implementation through experiments. Section 6 evaluates the system’s performance from multiple perspectives. Section 7 then discusses potential concerns and limitations. Finally, Section 8 concludes the paper. The conceptual overview of our paper is shown in Figure 1.

2. Related Work

This section provides an overview of existing works related to the research fields discussed above.

Xu et al. [22] introduced a decentralized capability-based IoT access control system utilizing smart contracts, representing one of the most pioneering approaches in capability-based BIAC (Blockchain-based Identity and Access Control) systems. This scheme addresses performance bottlenecks and the vulnerability of single points of failure found in access control mechanisms relying on centralized authorization servers. While Xu et al.’s work stands as an innovation in the field, certain challenges persist. In response, Nakamura et al. [23] identified issues related to capability management and delegation. They proposed a smart contract-based CapBAC (Capability-based Access Control) scheme characterized by more fine-grained capability management and flexible capability delegation. Furthermore, in Nakamura et al.’s work, smart contracts play the role of recording access behaviors. However, it is noteworthy that user privacy preservation is frequently overlooked in these systems.

With escalating concerns about data privacy in the Internet of Things, cryptographic methods are increasingly recognized as a viable solution for privacy preservation in capability-based BIAC systems. To address the significance of establishing a privacy-preserving access control system for the industrial Internet of Things (IIoT), Wang et al. [24] integrated a lightweight cryptographic algorithm, NTRU (Nth-degree Truncated Polynomial Ring Units), with an on-chain verification function. This combination effectively encrypts users’ registration information and blocks malicious requesters. Simultaneously, Saini et al. [25] approached privacy preservation from a different perspective. In their work, the authors considered the security of medical data generated by smart healthcare devices within a smart-contract-based access control framework. They proposed a smart-contract-based distributed and dynamic access control mechanism that empowers patients as the true owners of their sensitive electronic medical records (EMRs) and enables secure sharing. Leveraging elliptic curve cryptography, the EMRs can be encrypted and signed to facilitate trustful sharing.

Nevertheless, the previous studies in the field of privacy preservation in capability-based BIAC systems only focused on data privacy and were mostly restricted to limited scenarios. This trend is attributed to the underestimation of the significance of account privacy. Account privacy, serving as the foundation for behavioral, habitual, and record privacy, revolves around the anonymity of user accounts. Issues related to the security and privacy of accounts, such as the risk of user identity leakage, should not be disregarded in safeguarding users’ interests [26]. Evidence from [16] suggests that anonymous accounts and transactions are necessary to avoid tracking by third parties and underscores the substantial risk posed by the absence of approaches ensuring account anonymity in a blockchain. Consequently, account privacy in capability-based BIAC systems is gaining increasing attention. As the pioneers in this aspect, Hu et al. [13] explored the adversary model, identified account privacy issues, and leveraged zero-knowledge proof to decouple the ownership of access rights from blockchain accounts. This work overcomes the disadvantages introduced by blockchain features, thereby enhancing account privacy in BIAC.

Contrasting Hu’s proposal, Lin et al. [27] incorporated ZK-rollups into the access control authorization process, presenting a blockchain-based Attribute-based Access Control (ABAC) system that integrates zero-knowledge rollups and smart contracts. It is notable that, in [27], quantitative experiments were conducted to prove that the proposed system is suitable for high-traffic IoT environments and provides security analysis to verify the system’s ability to guarantee honesty when compared with the approaches presented in [13,16].

In this study, we further evaluate various existing BIAC systems, as mentioned previously, in comparison with our proposed system. The details of this comparison are presented in

Table 1. Comparison of the proposed system and some existing studies on the BIAC system.

	Hu et al. [13]	Nakamura et al. [23]	Wang et al. [24]	Lin et al. [27]	Proposed System
Access model	CapBAC	CapBAC	CapBAC	ABAC	CapBAC and ACL
Privacy preservation strategy	ZKP and Hash function	–	NTRU and NFT	ZK-rollups	ZKP and Hash function
Object’s privacy	✕	✕	✕	✕	✓
On-chain records	✕	✕	✓	✕	✓
Prevention of reidentification attack	✓	✕	✓	✕	✓
Prevention of replay attack	✓	✕	✓	✓	✓
Prevention of identity forgery	✓	✕	✕	✓	✓
Capability verification (cost)	Off-chain (low)	Off-chain (low)	On-chain (medium)	On-chain (high)	On-chain (low)
Implementation	IoT with different administrators	Token delegation in IoT	IIoT	High-traffic IoT	IoT in smart building

. Our analysis focuses on the distinct features, functionalities, and application scenarios of each system. It is evident that our proposed system demonstrates strong capabilities in data privacy and integrity. This advantage is primarily due to its unique consideration of the object’s privacy and the realization of the on-chain verification mechanism, which are not as comprehensively addressed in other prominent systems. Furthermore, it is notable that while Hu’s proposal [13] adopts a similar access model and privacy preservation strategies to ours, it lacks specific measures for protecting the object’s privacy and does not support on-chain verification. These omissions could potentially compromise the system’s effectiveness. Moreover, the quantitative analysis of the efficiency between ours and Hu’s system is presented in Section 6.

3. Attack Model

In this section, we examine three prevalent types of attacks, including reidentification attacks, replay attacks, and identity forgery, by analyzing cases from existing blockchain-based IoT access control studies.

3.1. Reidentification Attack

Whether initiated by internal malicious users or external attackers, a reidentification attack may be launched if the adversary possesses the following capabilities: (1) maintaining a peer node in the blockchain, (2) having permission to access records, and (3) possessing sufficient computational power and technical expertise to perform cryptanalysis and analyze behavioral patterns.

Although some existing systems employ anonymization techniques to generate unidentifiable IDs for users, this does not guarantee absolute anonymity. An attacker, denoted as $Ad{v}_1$, who operates a node in the blockchain and gains or illicitly acquires access to the records, can construct behavioral habit models by analyzing transaction patterns. These models significantly enhance $Ad{v}_1$’s ability to link anonymized or pseudonymized IDs back to real-world identities.

3.2. Replay Attack

With the following capabilities of (1) registering as a legitimate subject in the system, (2) capturing real-time communications between different entities, and (3) replicating captured messages, an insider can launch a replay attack to compromise system authentication and authorization.

Replay attacks are typically executed in two phases—the authentication phase and the resource-provisioning phase—with each targeting different objectives, as observed in existing studies.

During the authentication phase, if an adversary $ad{v}_2$ uses network sniffing tools to eavesdrop on and intercept a legitimate user’s authentication data, they can replay the previously intercepted authentication request at a later time. This enables the attacker to gain unauthorized access to a system that relies solely on static credentials. Similarly, in the resource-provisioning phase, an adversary $ad{v}_3$ can intercept an IoT resource request and replay it to operate IoT devices or retrieve their outputs without proper authorization.

3.3. Identity Forgery

From the perspective of objects and IoT devices, the system is also vulnerable to an identity forgery attack. If an adversary meets the following prerequisites of (1) the ability to impersonate legitimate IoT devices or objects and (2) access to records and lists related to access control, this attack can be potentially executed.

An adversary $ad{v}_4$ can forge the identity of a legitimate IoT device or object to access system resources, steal sensitive information, and provide fraudulent services under a fake identity.

For instance, in a smart home environment such as [28], $ad{v}_4$ could impersonate a legitimate smart lock device by using stolen identity credentials. Once authenticated, the adversary would gain unauthorized control over the door lock system, effectively granting themselves physical access to the residence without triggering suspicion. With access to the home’s access control configurations and device lists, $ad{v}_4$ could modify or disable alerts, making the intrusion undetectable to both the homeowner and the backend monitoring service. Furthermore, the attacker might log fabricated access records to make it appear that the lock was opened by an authorized user at a typical time, thereby masking their presence. By maintaining the forged identity over time, $ad{v}_4$ could repeatedly access the property, eavesdrop on other smart devices, or even provide counterfeit services to residents or third-party systems that rely on the lock’s status. This example highlights how identity forgery in a single IoT device, such as a smart lock, can compromise the physical and digital security of an entire IoT ecosystem.

4. Proposed System Architecture

This section explores the theoretical feasibility of constructing a blockchain-based access control system through zero-knowledge proof, ensuring robust anonymity for account information, as well as mitigating security concerns related to behavior, habits, and record privacy for both objects and subjects. We begin by outlining the system framework, followed by the introduction of distinctive components not present in existing works. Finally, we explain the main functions of the system.

4.1. System Framework

To provide a clear and comprehensive illustration of the system framework, we first define symbols in

Table A1. Symbol table.

Parameter	Symbol
Current Time	$nt$
Expiry Time	$et$
Mapping Number	$\alpha$
Random Value	r
Proof	$\delta$
Public Signal	$out$
ori_token (owner side)	$o{t}_1$
ori_token (subject side)	$o{t}_2$
zkp_token	$zt$

(Appendix A.1) and the system overview in Figure 2. As depicted in Figure 2, our proposed system involves four key entities: subjects, resource owners, objects, and IoT devices. The main responsibilities of these entities are explained as follows:

• Subject: The subject in our system functions as the requester of IoT resources, representing the user being served in these systems. In our approach, the subject initiates the process by registering their information with the resource owner, becoming eligible to obtain their original token. Building upon the original token, the subject generates a token with zero-knowledge proof to represent the ownership of access rights. Following verification by both the resource owner and the blockchain, the subject is granted access authority, enabling them to access the IoT device through the object.
• Object: The object serves as the gateway that links IoT devices to the blockchain and controls the IoT device based on instructions from the resource owner. Due to computational limitations, IoT devices are connected to the blockchain through objects rather than establishing a direct connection. As a result, the primary role of the object is to relay commands from the resource owner to the IoT devices and transmit the responses from the IoT device back to the owner. Additionally, the object is tasked with promptly recording access details to the smart contract whenever the corresponding IoT device is accessed.
• IoT device: The IoT device functions as the resource provider in the system, offering a range of functionalities for the subject to utilize. Typically, IoT devices rely on microprocessors, limiting their computational capabilities, especially for tremendous computations. Consequently, the primary focus of the IoT device is on providing services, such as measuring temperature and activating devices, rather than performing complex computations.
• Resource owner: The resource owner holds the ownership of various entities, including IoT devices and their corresponding objects, which are collectively referred to as the ’resource’. In the system, the resource owner plays the role of an administrator when someone seeks access to resources under his/her ownership. The resource owner holds the authority to assess the submitted token and issue a response, indicating acceptance or rejection. Briefly, the resource owner is responsible for creating the blockchain and smart contract, validating the zero-knowledge proof, managing the server, issuing access commands, and granting access authority. Moreover, it is notable that our system allows for the existence of multiple resource owners.

In the system framework, we initiate with a step marked ’Initialization’, representing the registration process between the subject and the resource owner. As depicted in Figure 3, the subject communicates their ID to the resource owner who then provides the subject with an ori_token and a mapping number based on the subject’s identity. Then, the subject employs the ori_token and the zero-knowledge proof, incorporating the mapping number as a secret, to generate the zkp_token. The commitment of the zero-knowledge proof is expressed by the following function:

$$Kecca{k}_{256}\left(\alpha \right|\left|r\right)=h$$

(1)

Here, $Kecca{k}_{256}\left(\right)$ represents the output generated by Keccak256, a cryptographic hash algorithm. By using the sponge construction to map arbitrarily long inputs into fixed-length outputs, Keccak256 shows remarkable resistance against practical collision finding attacks and is the exclusive specified hash algorithm in Solidity [29]. In this function, $\alpha$ and r represent the mapping number and the random value, as introduced in Table A1 (Appendix A.1), and h is the output of $Kecca{k}_{256}\left(\right)$. $\alpha$, r, and h serve as the private input signal, public input signal, and the public output signal, respectively, in the circuit system. Utilizing this function, the resource owner initiates the construction of an arithmetic circuit as the primary step for zero-knowledge proof generation. Simultaneously, the resource owner records the mapping relation among the subject, the mapping number, and the access rights to an access control list stored locally.

After the system is set up, the following steps (shown as numbered steps in Figure 2) are performed to allow a user to access IoT resources:

• Step 1: When the subject intends to utilize the IoT device, the zkp_token is first submitted to the corresponding contract for publication.
• Step 2: The subject issues a notification to the resource owner, informing the submission and requesting the retrieval of results via an off-chain channel.
• Step 3: Upon receiving the submitted zkp_token, as notified by the subject, the resource owner proceeds to trace the token’s owner. The process involves checking the consistency of the subject’s ID included in the notification with the ID in the zkp_token, as well as verifying the zkp_token through a hybrid multi-factor verification mechanism.
• Step 4: The verification outcome, whether acceptance or rejection, is then returned along with the details of conducting token verification within the same off-chain channel mentioned earlier to the subject.
• Step 5: In the context of acceptance, access authority is granted to the corresponding subject, allowing the subject to use the IoT device.
• Step 6: The resource owner, upon receiving an access request from the above-mentioned subject, directs the object’s control through SSH to establish connectivity with the IoT device
• Step 7: The IoT device is operated utilizing wireless technologies like Bluetooth and Wi-Fi following the subject’s request.
• Step 8: In the meantime, the object records the access details into the contract, capturing information such as the subject’s ID, the object’s ID, access behavior, and the timestamp.

4.2. Identity Abstraction

In this work, we decouple identity identifiers from the ownership of access rights by distinguishing between descriptive identities and authentication identities, with each serving distinct phases of the access process.

Regarding descriptive identity, we refer to it as the ID and utilize it to provide a unique identifier for each entity (i.e., the subject, object, and device) in the system. Unlike existing approaches in this field, our methodology deviates by incorporating Keccak256, a hash function, into the ID generation process. This departure from directly employing the blockchain address, as the ID allows for the decoupling of the ID from on-chain transactions. To elaborate, we define the ID as follows:

$$ID=Kecca{k}_{256}\left(address\right)$$

(2)

The authentication identity consists of a double-layered token structure and is employed by a subject to obtain access permissions from the resource owner. The token initially generated and distributed by the resource owner is referred to as ori_token. Subsequently, the subject generates a complete token, including a zero-knowledge proof, known as zkp_token. Notably, ori_token serves as the foundational representation of the subject’s information upon which zkp_token is constructed. For the detailed contents of these two token types, please refer to

Table 2. Token elements.

Token Type	Field	Description	Remark
ori_token	ID	Identity.	Keccak256 (Address)
	Access rights	A set of authorized operations.	e.g., read operation
	Expiry time	The moment when the token becomes invalid.	Unix time
zkp_token (additional)	Proof	Indicating the knowledge of the mapping number.
	Public signals	Public input and output signals from circuits.	256 bytes
	Random value	A 3-byte number.

.

4.3. Access Control Mechanism

To seamlessly integrate the generated zero-knowledge proof and smart contracts into the access control mechanism, we design a hybrid access control mechanism that mixes CapBAC and ACL.

In our architecture, CapBAC enables the verification of access rights ownership through zero-knowledge proofs, eliminating the need for direct linkage to user identities. As outlined above, CapBAC introduces a double-layered token structure that encapsulates extensive validation information, thereby enhancing the accuracy of verification and facilitating subsequent tracking.

ACL includes a mapping relation between the secret for zero-knowledge proof and the corresponding access rights. Specifically, we introduce a field in the ACL named ’mapping number’ for this purpose. This mapping number, a 5-byte combination of numbers and alphabets, serves as a secret parameter for subjects to indicate ownership of access rights. During the initialization period, resource owners create and share the mapping number with the subject. To prove ownership during token generation, subjects use the mapping number and a 3-byte random value to generate a zero-knowledge proof. This proof is then presented to the resource owner for verification in the token verification stage.

By combining the features of ACL and CapBAC, our hybrid access control mechanism provides a confidential method for validating access rights without revealing the actual identities of the subjects. This integration ensures that the access control process remains both privacy-preserving and fine-grained. The ACL component maintains a clear and manageable structure for resource owners to define and update access permissions, while CapBAC enables decentralized delegation and proof-based verification. As a result, subjects can demonstrate authorization through zero-knowledge proofs that are verifiable by smart contracts, thus enabling automated, trustless enforcement. To illustrate this more clearly, we provide an example in Figure 4, which demonstrates the significance of integrating ACL and CapBAC. This example assumes that the subject has already been registered, as shown in Figure 3.

Furthermore, the hybrid model enhances flexibility in dynamic IoT environments. For example, when a subject’s access needs to be updated or revoked, the resource owner can simply update the corresponding entry in the ACL without affecting the structure or issuance of capability tokens. This modularity reduces overhead and simplifies management in systems with frequent policy changes. Overall, the hybrid mechanism effectively balances scalability, security, and privacy, making it particularly well suited for distributed IoT ecosystems where both confidentiality and adaptability are critical.

4.4. Main Functions

The functions invoked in our system can be classified into three categories: on-chain functions, off-chain functions, and the function related to zero-knowledge proof.

4.4.1. On-Chain Functions

On-chain functions are completely invoked through the smart contracts deployed on the blockchain. As previously stated, our blockchain environment includes three types of smart contracts: the publication contract for proof publication, the verification contract for proof verification, and the recording contract for behavior records.

The publication contract is designed to facilitate the publishing and retrieval of zkp_tokens. Subjects can use the ’publish_token’ function to securely publish their zkp_tokens to the blockchain, mitigating the risk of tampering. Subsequently, resource owners can retrieve the zkp_token through the ’get_token’ function. By performing these operations on the blockchain, the blockchain’s tamper-resistant nature helps ensure the integrity of the token’s data.

The verification contract is designed to verify the proof within the zkp_token. It utilizes parameters from the verification key, essentially playing the role of the verification key. Once the zkp_token is obtained from the publication contract, the resource owner invokes verification functions within the verification contract. These functions assess whether the token owner possesses the knowledge of the corresponding mapping number by inputting the proof and public signals. Consequently, the verification functions return a Boolean value indicating acceptance or rejection.

The recording contract is designed to log access behavior on the blockchain. Recording detailed access conditions is crucial for future inspections and examinations. For this purpose, we include fields such as the subject’s ID, the object’s ID, the access behavior, and the timestamp within the recording contract. After accessing the IoT device, the object writes access data to the blockchain via the recording contract.

4.4.2. Off-Chain Functions

On the other hand, off-chain functions are also indispensable for token verification and IoT operation. For token verification, we implement a hybrid multi-factor verification mechanism that includes expiry time verification, token tampering verification, public output verification, and on-chain zero-knowledge proof verification. The workflow of this mechanism is illustrated in Figure 5. This comprehensive mechanism enables the resource owner to assess the subject’s trustworthiness and token validity. As mentioned earlier, the zero-knowledge proof verification is conducted on-chain, as introduced in the previous paragraph.

The expiry time verification function checks the expiration period of the submitted token. As indicated in Table 2, the expiry time is a field in both ori_token and zkp_token, indicating the moment when the token becomes invalid. Consequently, the resource owner can reject access if the token has expired.

The token tampering verification function relies on the implementation of a double-layered token structure. As previously mentioned, the ori_token is issued by the resource owner, and the zkp_token is constructed by the subject on top of the ori_token. That is to say, the ori_token is a subset of the zkp_token in terms of data structure. This property enables the resource owner to assess the subject’s trustworthiness from the perspective of set theory. Otherwise, any tampering with the token could lead to critical consequences, including errors in access data synchronization.

The public output verification function is designed to indirectly verify the knowledge of the mapping number. Following the principles of zero-knowledge proof, which implement functions through arithmetic circuits, we can reproduce the public output when knowing the input signals and the function independently. The resource owner retains the mapping number for each subject, and the subject publishes the random value within the zkp_token, serving as input signals. Consequently, the resource owner possesses all necessary information to reproduce the public output and thus realizes this process without the arithmetic circuits. Subsequently, a comparison is conducted between the public signals from the zkp_token and the expected public output from the resource owner. In essence, this function serves as a primary filter for invalid tokens, preventing unnecessary gas consumption by avoiding the excessive invocation of on-chain zero-knowledge proof verification.

4.4.3. Zero-Knowledge Proof Function

As a fundamental component of our system, the zero-knowledge proof function supports both on-chain and off-chain operations, serving as a critical mechanism throughout the authentication and authorization processes.

To provide a detailed description of the function, we maintain the use of the symbols defined in Table A1 (Appendix A.1) and introduce additional parameters. These include the hash outcome computed by Equation (1) h, the private input signal a, the public input signal b, the input size of the circuit $siz{e}_{in}$, the output size of the circuit $siz{e}_{out}$, the generated circuit $circuit$, and the verification contract—denoted as $Contrac{t}_{ver}$—as illustrated in Figure 2. Additionally, we define three parameters associated with the generated proof: ${\pi }_a$, which corresponds to the input values to the circuit being verified; ${\pi }_b$, which pertains to the intermediate constraints or conditions within the circuit; and ${\pi }_c$, which represents the output values of the circuit. Lastly, the verification result, denoted as $resul{t}_{pf}$, indicates the success or failure of the proof verification process. The complete process for implementing zero-knowledge proof is illustrated in Figure 6.

The zero-knowledge function begins with a trusted setup performed locally by the resource owner. This setup primarily involves the construction of a $circuit$ using parameters a, b, $siz{e}_{in}$, and $siz{e}_{out}$, which collectively define the computation logic. The constructed circuit is then compiled into a verification smart contract, which is denoted as $Contrac{t}_{ver}$.

In the second and third steps, the resource owner deploys the $contrac{t}_{ver}$ to the blockchain and shares the $circuit$ with the corresponding subject to prepare for proof generation.

To assert legitimate access rights to an IoT device, a subject must take advantage of the circuit definition ($circuit$), along with a mapping number and a random value, which are formatted as $\alpha$ and r, respectively. These components, together with the computed hash $h=kecca{k}_{256}(\alpha , r)$, serve as the essential inputs for the proof generation process described in Algorithm 1.

As shown in Algorithm 1, the proof generation begins by verifying whether the computed hash $h^{\prime }$ from $(\alpha , r)$ matches the expected value h (line 2). Upon successful validation, the algorithm extracts the arithmetic structures and cryptographic elements from the $circuit$, such as the functions $A\left(\right)$, $B\left(\right)$, and $C\left(\right)$, as well as group elements $G_1$ and $G_2$ (line 3). Next, the witness values are computed using the circuit and the input parameters, from which a polynomial $w\left(x\right)$ is constructed (lines 4–5). This polynomial encodes the intermediate variables of the circuit execution.

The algorithm then generates the three core components of the zero-knowledge proof, ${\pi }_a$, ${\pi }_b$, and ${\pi }_c$, by applying the circuit functions to the witness polynomial and performing elliptic curve operations over $G_1$ and $G_2$ (lines 6–8). A correction term $\delta$ is introduced to adjust the verification equation and preserve consistency between the proof elements and the expected output. Finally, the proof components are formatted, and the result $\delta , out$ is constructed and returned alongside the proof (lines 9–11). This proof tuple is then submitted to the blockchain for verification by the smart contract.

Algorithm 1 Generate proof.

Input:  $circuit$, $\alpha$, r, h Output:  ${\pi }_a$, ${\pi }_b$, ${\pi }_c$, $out$, $\delta$   1: $h^{\prime }=kecca{k}_{256}(\alpha , r)$   2: if  $h^{\prime }=h$then   3:    $\{A\left(\right), B\left(\right), C\left(\right), \tau , G_1, G_2\}\leftarrow circuit$   4:    $witness\leftarrow compute\_witness(circuit, \alpha , r, h^{\prime })$   5:    $w\left(x\right)\leftarrow \sum w_i·x^i$, where $w_i$ comes from $witness$   6:    ${\pi }_a=A\left(\tau \right)+w\left(\tau \right)·G_1$   7:    ${\pi }_b=B\left(\tau \right)+w\left(\tau \right)·G_2$   8:    ${\pi }_c=C\left(\tau \right)+{\delta }^{-1}·({\pi }_a·{\pi }_b-w\left(\tau \right)·G_1)$   9:    $\{\delta , out\}\leftarrow format({\pi }_a, {\pi }_b, {\pi }_c, h^{\prime })$ 10: end if 11: return  ${\pi }_a$, ${\pi }_b$, ${\pi }_c$, $out$, $\delta$

Then, the generated parameters, including ${\pi }_a$, ${\pi }_b$, ${\pi }_c$, and $out$, are standardized and formatted into a proof integrated to generate the zkp_token, which is submitted to the verification contract deployed on the blockchain.

Shifting to the verifier’s point of view, the verification contract receives the subject’s proof from their token and assesses its validity based on the security parameters established during the trusted setup phase. During this process, a verification result referred to as $resul{t}_{pf}$ is generated. The detailed implementation of this process is provided in Algorithm 2.

Finally, the blockchain returns $resul{t}_{pf}$ to the resource owner, serving as essential cryptographic evidence that informs and influences the subsequent multi-factor verification process.

Algorithm 2 Verify proof.

Input:  ${\pi }_a$, ${\pi }_b$, ${\pi }_c$, $out$, $Contrac{t}_{ver}$ Output:  $resul{t}_{pf}\in \{true, false\}$   1: $\{A\left(\right), B\left(\right), C\left(\right), G_1, G_2\}\leftarrow Contrac{t}_{ver}$   2: $A_{pub}\leftarrow A\left(out\right)$   3: $B_{pub}\leftarrow B\left(out\right)$   4: $C_{pub}\leftarrow C\left(out\right)$   5: $LH{S}_1\leftarrow e({\pi }_a, {\pi }_b)$   6: $RH{S}_1\leftarrow e(A_{pub}·G_1, B_{pub}·G_2)$   7: if   $LH{S}_1=RH{S}_1$then   8:    $LH{S}_2=e({\pi }_c, G_2)$   9:    $RH{S}_2=e(C_{pub}·G_1, G_2)$ 10:    if $LH{S}_2=RH{S}_2$ then 11:      $True\leftarrow resul{t}_{pf}$ 12:    else 13:      $false\leftarrow resul{t}_{pf}$ 14:    end if 15: else 16:    $false\leftarrow resul{t}_{pf}$ 17: end if 18: return   $resul{t}_{pf}$

5. Implementation

This section explores the implementation of the framework discussed in the previous section. We begin by examining the application scenario where our BIAC system can be effectively utilized. Following that, we introduce the hardware and software environment employed in the experiment. Finally, we prove the feasibility of the implementation through a conducted experiment.

5.1. Application Scenario

Our system has a feature that enhances anonymity for both subjects and objects. This makes it well suited for scenarios vulnerable to malicious attacks aimed at compromising data privacy. As a result, we plan to implement our system in the context of a smart building, focusing on climate control and lighting.

For a comprehensive understanding of the concept and details of the smart building scenario, please refer to [30].

5.2. System Configuration

The system implementation overview is illustrated in Figure 7. Our system comprises two subjects, two objects, two IoT devices, and a resource owner, who also serves as the miner and system maintainer. As mentioned earlier, there exists an off-chain channel established alongside the blockchain to facilitate communication between the subject and the resource owner. In implementing this channel, the resource owner, acting as the system maintainer, sets up a server to handle the receipt of subject notifications and access requests. The server also returns responses and provides execution information from the IoT device.

The system configuration encompasses both hardware and software components.

In focusing on the hardware configuration, the system has been equipped as shown in

Table 3. Hardware configuration.

Entity	Device	CPU	GPU	OS	Memory
Subject A	MacBook Air	Intel i5-1030NG7	Iris Plus G7	MacOS 12.4	8 GB
Subject B	MacBook Pro	Intel i7-9750H	Iris Plus 655	MacOS 11.5.2	8 GB
Miner/Resource owner/ Maintainer	Desktop PC	Intel i7-13700F	Nvidia GeForce RTX 4070	Windows 11	32 GB
Object A	Raspberry Pi 4	Cortex-A72	Integrated GPU	Raspbian 10	1 GB
Object B	Raspberry Pi 3	Cortex-A53	Integrated GPU	Raspbian 8	1 GB
IoT device A	Switchbot IoT bot
IoT device B	Switchbot IoT humidifier

.

The primary programming languages employed in our implementation are Python and Solidity. Python was utilized for implementing off-chain functions, such as IoT control, while Solidity was employed for on-chain functions, including zero-knowledge proof verification.

To establish our private Ethereum environment, we utilized the Geth client v1.16.1 [31], recognized as the official Go implementation of the Ethereum protocol in the command line. The devices connected to this private Ethereum environment function as peer nodes, operating through the Geth client.

To automate the invocation of smart contracts and retrieve running results from Solidity to Python, we employed Web3.py v7.12.0 [32], which is a Python library. This tool facilitated access to our private Ethereum environment in Python, providing the capability to control contract invocations through Python programs.

Regarding the software related to zero-knowledge proof generation and verification, we adopted Circom v2.2.2 [33] to generate the circuit to convert the commitment and Snarkjs v0.7.5 [34] to build the proof based on the generated circuit. Additionally, Snarkjs can generate a smart contract for verifying the proof at the resource owner’s side.

5.3. Experiment

We conducted experiments to validate the feasibility of implementing the system framework proposed in the previous section. Our source code for the implementation is now available on [35].

Referring to the system implementation overview depicted in Figure 7, we considered two subjects: Subject A (MacBook Air) and Subject B (MacBook Pro). Subject A aims to access IoT device A (Switchbot IoT bot) to control lighting conditions through Object A, while Subject B seeks to access IoT device B (Switchbot IoT humidifier) for humidity control and climate information retrieval through Object B, all within their authorized access rights.

To initiate the process, an initialization step was conducted between the subjects and the resource owner. For the initialization process, Subject A initialized his/her ID as 0xcaee213728819eb38a45674405bd894c1a0849a06e6a31e98119908773aafcb4 and obtained the mapping number 52244 from the resource owner. Subject B initialized his/her ID as 0xadb3d11372340aa9b42d754fba66822f7c6b53d0e26efda7a7488ed563efffb5 and obtained the mapping number 12345. The aforementioned details were recorded in the access control list by the resource owner. Simultaneously, Object A and Object B generated their IDs as 0x8b46ce2c4843de899f9ed5233623e95aa74825adf592ef17cf5fc07efb634d78 and 0xb7fec4a0295a38a48f16f58845fafab2411c332c8b39cc20573249f984928dbf, respectively. The resource owner, along with the two subjects and two objects, connected to the private Ethereum environment as peer nodes using the Geth client, as illustrated in Figure A1 (Appendix A.2). The resource owner deployed the publication contract, the verification contract, and the recording contract to the private Ethereum environment at this stage.

In this case, we show the whole process of Subject B controlling IoT device B to retrieve climate information.

In the first step, Subject B obtained the ori_token from the resource owner and proceeded to generate the zkp_token using the mapping number, 12345, and a random value, 234, with the assistance of Snarkjs. Figure A2 (Appendix A.2) illustrates Subject B’s zkp_token. The generated zkp_token was then submitted to the private Ethereum environment by invoking the publication contract.

Following that, Subject B accessed a page hosted on the server maintained by the resource owner. On the page, Subject B was prompted to provide their ID and the random value information from the submitted zkp_token to pair the token. This information submission is illustrated in Figure A3 (Appendix A.2).

According to the ID and the random value, the resource owner attempted to retrieve Subject B’s zkp_token from the publication contract. Once Subject B’s token was successfully retrieved, the resource owner utilized the hybrid multi-factor verification mechanism, which was implemented in Python, to verify Subject B’s trustworthiness. This mechanism involved invoking the verification contract to validate the authenticity of Subject B’s zkp_token. The concrete implementation of the hybrid multi-factor verification mechanism is detailed in Algorithm 3.

Following the verification, the resource owner obtained a result indicating the token’s acceptance or rejection from the program. Subsequently, the resource owner presented the result to Subject B on the page. Both the acceptance and rejection interfaces are illustrated in Figure A4 (Appendix A.2). In this instance, Subject B successfully passed the verification, resulting in an acceptance outcome.

The next steps are related to the usage of IoT device B. Referring to the set of access rights in Figure 3, we designed the ’Access right’ field as a set containing ’read’, ’write’, and ’exe’ in this implementation. Specifically, the ’read’ operation synchronizes real-time data on temperature and humidity from IoT device B; the ’write’ operation sets the target humidity levels (33%, 67%, and 100%) for IoT device B; the ’exe’ operation adjusts the current position of IoT device A’s trigger, thereby controlling the lighting function. In this case, Subject B submitted a ’read’ request on the page to retrieve temperature and humidity data from IoT device B. The resource owner approved the request and communicated with Object B to relay the command through SSH. Additionally, Object B connected to IoT device B over Wi-Fi, instructing the device to provide real-time data on temperature and humidity.

Algorithm 3 Hybrid multi-factor verification.

Input:  current time $nt$, subject B’s mapping number ${\alpha }_B$, subject B’s ori_token stored at the owner side $o{t}_{1B}$, subject B’s zkp_token $z{t}_B$ (expiry time of subject B’s zkp_token $e{t}_B$, subject B’s proof ${\delta }_B$, public signals in subject B’s zkp_token $ou{t}_B$, subject B’s random value for this time $r_b$) Output:  verification result True/False   1: Result_flag = 1   2: if  $e{t}_B<nt$  then   3:    Result_flag = 0   4: end if   5: if  $o{t}_{1B}⊈z{t}_B$  then   6:    Result_flag = 0   7: end if   8: if  $kecca{k}_{256}({\alpha }_B\left|\right|r_B)\ne ou{t}_B$  then   9:    Result_flag = 0 10: end if 11: if  $verify\_proof\left({\delta }_B\right|\left|ou{t}_B\right)\ne True$  then 12:    Result_flag = 0 13: end if 14: if Result_flag = 1 then 15:    return True 16: else 17:    return False 18: end if

In the final steps, the data were presented to Subject B on the page, as depicted in Figure 8. Simultaneously, Object B recorded (“0xadb3d11372340aa9b42 d754fba66822f7c6b53d0e26efda7a7488ed563efffb5”, “0xb7fec4a0295a38a48f16f58845fafab2411c332c8b39cc20573249f984928dbf”, “Read humidifier”, and 1698125023) in the recording contract, as shown in Figure 9.

Similarly, the subject granted the ‘exe’ access right was eligible to access IoT device A for controlling the lights in the building, following the above-mentioned pattern. However, Object A established a connection with IoT device A through Bluetooth instead of Wi-Fi.

6. Evaluation

6.1. Security Analysis

• Countermeasure against reidentification attack: To mitigate reidentification attacks, we introduced a dual privacy-preserving ID mechanism in our BIAC system, ensuring a complete decoupling of user identifiers from real-world identities. As outlined above, the ID structure in our system is defined as $Kecca{k}_{256}\left(Address\right)$. In this design, the outer hash function initially differentiates the anonymized user ID from traceable account information, while the inner component, which utilizes the blockchain address to uniquely identify participants, significantly increases the difficulty of linking account information to real-world identities. Notably, blockchain accounts are neither unique nor establish a one-to-one mapping with users. Furthermore, even in scenarios where either the subject or object faces potential privacy leakage, the ability to change accounts and reregister offers a straightforward solution to mitigate such risks.
• Countermeasure against replay attack: Our BIAC system effectively mitigates replay attacks in both the authentication and resource-provisioning phases. During authentication, a 3-byte random value r is incorporated as the public signal of $zkp\_token$. This challenge–response authentication mechanism mandates a unique nonce for each authentication round, with the nonce serving as a crucial component in zero-knowledge proof generation, thereby fundamentally preventing replay attacks. Furthermore, to counter replay attacks in the resource-provisioning phase, our system leverages the blockchain to verify the consistency between authentication and resource access. If a replay attack is detected, the access request is immediately denied. In essence, the replay resistance in the resource-provisioning phase is inherently dependent on the authentication phase and is collectively ensured by the challenge–response authentication mechanism implemented in our system.
• Countermeasure against identity forgery: As previously discussed, identity forgery typically occurs on the object side, where privacy and authentication are often neglected in existing studies. However, our system explicitly addresses these concerns by integrating a privacy strategy that combines hash functions with zero-knowledge proofs to securely process both subject and object identities. Specifically, under these protection mechanisms, each legitimate IoT device and object remains anonymous and cannot be impersonated, except in cases involving the theft of a blockchain account.

6.2. Formal Security Proof

6.2.1. Adversary Assumption

We consider a probabilistic polynomial-time (PPT) adversary $\mathcal{A}$ under the Dolev–Yao model. The adversary $\mathcal{A}$ may (1) Obtain valid tokens for any chosen identity using the system’s token generation process; (2) Observe all public ZKP parameters and circuit descriptions; (3) Attempt to produce a forged proof ${\pi }^{\prime }$ for a public signal $x^{\prime }$, without knowing any valid witness $(\alpha , r)$ that satisfies both the hash commitment and the circuit logic (i.e., the access policy, expiry check, etc.).

6.2.2. Valid Verification

In our system, each access authorization is encoded in a two-part token consisting of the original token $o{t}_2$ and a zero-knowledge token $zt$. These tokens encapsulate cryptographic commitments and zero-knowledge proofs. The original token contains the user’s mapping number $\alpha$, expiry time $et$, and access rights, while the zero-knowledge token includes a random nonce r, public signals $out$, and a zero-knowledge proof $\delta$. These elements are cryptographically bound by the commitment as in Equation (1). This commitment binds the prover to the private values $\alpha$ and r. To successfully validate access, the user must produce a zero-knowledge proof $\delta$ that convinces the verifier that they know values $\alpha$ and r such that

$$Kecca{k}_{256}(\alpha \Vert r)=h,P\left(\alpha \right)=1,nt<et$$

(3)

The verifier runs

$$Verify(out, \delta )=1$$

(4)

and checks that the current time $nt$ is within the token’s validity range. We define the full validity predicate as

$$Valid(o{t}_2, zt):=Verify(out, \delta )=1\wedge nt<et$$

(5)

6.2.3. Soundness Analysis

We consider the adversary $\mathcal{A}$ who attempts to forge a valid token $o{t}_2^{\prime }$ and proof ${\delta }^{\prime }$ without knowing a valid witness $(\alpha , r)$. For success, $\mathcal{A}$ must find $({\alpha }^{\prime }, r^{\prime })$ such that

$$Kecca{k}_{256}({\alpha }^{\prime } \Vert r^{\prime })=h,P\left({\alpha }^{\prime }\right)=1,nt<et$$

(6)

This requires either breaking the second pre-image resistance of $Kecca{k}_{256}$ or generating a proof ${\delta }^{\prime }$ that passes verification without a valid witness, violating ZKP soundness. We model this as

$$Pr[\mathcal{A}\Rightarrow Verify(ou{t}^{\prime }, {\delta }^{\prime })=1]\le \epsilon \left(\lambda \right)$$

(7)

where $\epsilon \left(\lambda \right)$ is a negligible function in the security parameter $\lambda$. This shows that our system provides unforgeability under standard assumptions.

6.2.4. Zero-Knowledge Analysis

To protect user privacy, the system ensures zero-knowledge. That is, there exists a simulator $\mathcal{S}$ which can output simulated proofs ${\delta }^{sim}$ such that

$$\mathcal{D}(\delta , {\delta }^{sim})\approx 0$$

(8)

for any efficient distinguisher $\mathcal{D}$, meaning the proof leaks no information about $\alpha$ or r.

6.3. Computation Overhead

The computational cost of our scheme was analyzed with Hu’s scheme [13] and Lin’s scheme [27] from the aspect of complexity. The main computing operations in these schemes include a bilinear pairing operation (bp), a map-to-point hash operation (mtp), a hash function (h), point addition (pa), point multiplication (pm), and scale multiplication (mul). Let $T_x$ denote the calculation cost of operation x. The average timing values found in the calculation of computational overhead are listed in (9)–(14):

$$T_{bp}\approx 1.6\mathrm{ms}$$

(9)

$$T_h\approx 1.6\mathrm{ms}$$

(10)

$$T_{pa}\approx 0.6\mathrm{ms}$$

(11)

$$T_{pm}\approx 0.8\mathrm{ms}$$

(12)

$$T_{mtp}\approx 0.8\mathrm{ms}$$

(13)

$$T_{mul}\approx 0.5\mathrm{ms}$$

(14)

Regarding the computational cost of token generation, as shown in

Table 4. Complexity analysis of token generation.

	Complexity	Cost
Hu et al. [13]	$2T_{pm}+2T_{pa}+T_{mul}+5T_h$	11.3 ms
Lin et al. [27]	$T_{bp}+T_{pm}+T_{pa}+T_{mul}+7T_h$	14.7 ms
Our scheme	$2T_{pm}+2T_{pa}+T_{mul}+T_h$	4.9 ms

, our scheme demonstrates significant efficiency gains over both Hu’s and Lin’s schemes. Specifically, our scheme achieved a computational cost of approximately 4.9 ms, which is only half that of Hu’s scheme and one-third that of Lin’s scheme. This efficiency is primarily attributed to our concise token design, which leverages the soundness and completeness of Groth16, thereby minimizing the need for extensive hash computations to decouple access rights from real-world user identities.

Similarly, in terms of the computational cost of authentication, as shown in

Table 5. Complexity analysis of authentication.

	Complexity	Cost
Hu et al. [13]	$6T_{bp}+2T_{pm}+2T_{pa}+2T_{mul}+2T_{mtp}+4T_h$	21.4 ms
Lin et al. [27]	$2T_{bp}+T_{pm}+T_{pa}+4T_h$	11 ms
Our scheme	$3T_{bp}+T_{pm}+T_{pa}+T_{mul}+T_{mtp}+T_h$	9.1 ms

, our scheme outperforms both alternatives. The token verification process in our system required 9.1 ms, surpassing Lin’s scheme (11 ms) and significantly outperforming Hu’s scheme (21.4 ms). This improvement is essentially due to the fact that Hu’s scheme incorporates two independent zero-knowledge proofs—one for identity verification and another for access right claims—which substantially impacts the verification efficiency, leading to a notable performance gap compared to the other schemes.

Meanwhile, to accurately assess the computational overhead and identify potential bottlenecks in our system, we evaluated the memory and CPU usage of off-chain functions. Specifically, the experiments included an analysis of CPU usage variations over time during the trusted setup process (Figure 10a), the contract deployment process (Figure 10b), memory usage variations over time during the trusted setup process (Figure 10c), and the token generation process (Figure 10d).

The trusted setup process was highly CPU-intensive, with CPU usage remaining close to 100% for most of the time, indicating that it involves computationally heavy tasks which are likely related to cryptographic operations. Additionally, its memory usage steadily increased over time, eventually stabilizing at around 500 MB, suggesting that the process accumulates data gradually. In contrast, the contract deployment process had minimal CPU usage, staying below 10% with only minor fluctuations, implying that it primarily involves I/O operations rather than computation-heavy tasks.

The token generation process was memory-intensive, with memory usage rising rapidly to nearly 1600 MB before dropping sharply, indicating large-scale data processing and temporary memory allocation. Meanwhile, the trusted setup process exhibited more stable memory consumption compared to the zero-knowledge proof computation during the token generation process, which showed significant memory fluctuations. These insights suggest that optimizing CPU performance is crucial for the trusted setup phase, while memory management improvements could help reduce peak memory usage in the token generation process.

The contract deployment phase, having low resource demands, may not require significant optimization.

From the perspective of our BIAC system, these performance characteristics highlight the necessity of phase-specific resource optimization to ensure efficient and scalable operation across diverse IoT environments. The trusted setup phase, as implemented in our case, produced a highly CPU-intensive profile, primarily due to the cryptographic computations involved in circuit generation and parameter initialization. To improve the responsiveness and scalability of this phase, it can benefit from parallel execution frameworks or the integration of hardware acceleration modules, such as GPUs or dedicated cryptographic co-processors.

In contrast, the token generation phase in the BIAC system exhibited memory-intensive behavior, with memory usage peaking rapidly during zero-knowledge proof construction. This indicates that the proof generation logic incurs substantial temporary memory allocation. To address this, our system can adopt memory-efficient techniques such as on-the-fly computation, modular proof construction, or optimized memory buffer management to mitigate peak loads, especially in large-scale or memory-constrained deployments.

Finally, the contract deployment phase showed minimal resource consumption, confirming its lightweight nature and operational suitability for frequent use, even on edge devices or gateways with limited capabilities. As we continue to scale toward broader IoT ecosystems involving thousands of devices, these insights provide practical guidelines for optimizing system performance while maintaining the core guarantees of privacy, decentralization, and fine-grained access control.

6.4. Time Performance

We assessed the time performance of the system, classifying it into three categories: setup time for zero-knowledge proof, system execution time, and contract deployment time. The evaluation was conducted using the devices mentioned in Section 5.2.

Concerning the setup time of zero-knowledge proof, it comprises three components: circuit compilation time, trusted setup time, and verification key generation time. Specifically, the circuit compilation time denotes the duration for compiling the circuit with over 150,000 constraints to convert the commitment in the system, which is written by circom. This process took 39.63 s. A trusted setup was employed to initialize the parameters that are crucial for the zero-knowledge property of zero-knowledge proof and essential for system security [36]. This initialization process took 41.24 s in our system. Notably, the verification key generation time, referring to the time it takes to generate the key for the prover to verify the proof, was measured at up to 901.71s (i.e., ∼15 min). Although we used smart contracts as a replacement for the off-chain verification process, the verification key is integrated into the contracts, making the verification key generation process indispensable. The resource owner is responsible for executing the operations related to the setup.

In assessing the system execution time, we explored the efficiency of operations associated with tokens, IoT, and contract usage. The operations on the zkp_token, including token generation, token submission, and token verification, have been elucidated in previous chapters, with respective durations of 6.98 s, 0.74 s, and 0.15 s. The IoT operation time was calculated from the resource owner’s request initiation to the reception of the response from the IoT device, with the object serving as the gateway. This entire process was completed in 2.44 s. Subsequently, the creation of records consumed 5.73 s, as the object logged access behavior on the blockchain.

In the context of contract deployment, the publication contract, verification contract, and recording contract required 1.89 s, 3.72 s, and 1.81 s, respectively.

Table 6. Time performance of operations.

Process	Operation	Time [s]	Operater	Overall Time [s]
Setup	Circuit compilation	39.63	Resource owner	982.58
	Trusted setup	41.24
	Verification key generation	901.71
Execution	zkp_token generation	6.98	Subject	16.04
	zkp_token submission	0.74	Subject
	zkp_token verification	0.15	Resource owner
	IoT operation	2.44	Resource owner/ Object/IoT device
	Record creation	5.73	Object
Deployment	Publication contract	1.89	Resource owner	7.42
	Verification contract	3.72
	Recording contract	1.81

facilitates an intuitive analysis of each process’s overall time. Through a comparison of the time performance across setup, execution, and deployment, it is evident that the setup time stands out as the bottleneck in our system, consuming 982.58 s and significantly exceeding the durations of the other two processes.

Although there is currently no feasible approach to substantially mitigate latency caused by the bottleneck, this limitation has negligible impact on the practical implementation of our system. Fortunately, both the setup and contract deployment are included in the initialization process, requiring execution only once for each system. Furthermore, the initialization process operates independently of IoT usage, ensuring no impact on system execution, as it is conducted in advance. These design features enable our system to achieve efficient implementation despite the presence of the bottleneck.

In addition to evaluating the time performance of our system, we also assessed it in comparison with Hu’s scheme [13], Lin’s scheme [27], and Maesa’s scheme [20] to provide a comprehensive comparative analysis.

As shown in Figure 11, we conducted a comprehensive comparison of the proof generation time, access right authorization time, and on-chain computation time, which constitute essential functions of the authentication phase in BIAC systems.

From Figure 11a,b, it is evident that our proposed system consistently achieved the best performance across all evaluated systems. Among the remaining approaches, Lin’s system demonstrated higher efficiency, followed by those of Hu and Maesa.

Figure 11c further illustrates that both our proposed system and Lin’s system exhibited superior performance, as their on-chain computation times remain independent of the number of subjects. In contrast, Maesa et al. overlooked this aspect, which represents a major limitation, posing significant scalability challenges. Although our system did not achieve the absolute best performance in this particular scenario, the gap between it and Lin’s system under optimal configuration is negligible, while our system significantly outperformed Lin’s system under the worst configuration.

6.5. Space Performance

Although Hu et al. [13] proposed a privacy-preserving BIAC architecture using zero-knowledge proof and demonstrated the superior time performance of the system, the proving key size, reaching up to approximately 150 MB, raised our concerns due to the expensive storage costs in the blockchain [37].

As a countermeasure in our system, we configured the power of the parameter associated with the constraints in the trusted setup file to be 18, allowing the file to accommodate $2^{18}$ constraints. This configuration is suitable for handling 150,000 constraints during the initiation of a new ceremony (known as “powers of tau”), ensuring a balanced approach without excessive surplus or insufficiency. The powers of tau ceremony was adopted to generate the initial parameters for the Zero-Knowledge Succinct Non-Interactive Argument of Knowledge [38].

Following this configuration, we successfully generated a series of files for setup and verification key generation. The proving key was sized at 79.2 MB. Additionally, the files for circuit, input, output, witness, and proof were 841 KB, 200 B, 2 KB, 4.7 MB, and 806 B, respectively.

In the context of IoT usage, we created files for token usage and contracts. Specifically, Subject B (as mentioned in Section 5.3) had ‘ori_token’ and ‘zkp_token’ files with sizes of 139 Bytes and 19 KB, respectively. Furthermore, the publication contract, verification contract, and recording contract were sized at 10.4 KB, 46.8 KB, and 6.77 KB.

As depicted in Figure 12, we show the space performance of the functions related to zero-knowledge proof in both our system and Hu’s system, supporting a visual comparison. The size of the proving key in our system is evidently almost half of that in Hu’s, demonstrating our superior space performance. In addition, the sizes of our verification key and proof are nearly equivalent to those in Hu’s system. This suggests that our system does not pose an expense bottleneck for the blockchain in this aspect.

6.6. Gas Fee Performance

Generally speaking, the consumed gas fee can be calculated by the following equation [12]:

$$gasfee=gasused\times gasprice$$

(15)

In our work, we only evaluated the gas used by our system, because the gas price differs across various blockchains.

There are two scenarios that consume gas within our system: contract deployment and contract invocation. In terms of contract deployment, three contracts, including the publication contract, the verification contract, and the recording contract, are deployed to the blockchain. Through our dedication to realizing the contract functions as concisely as possible, the deployment cost satisfies our expectations. We measured how much gas was used to deploy each contract. The gas fees were 965,225, 6,446,120, and 1,471,791, respectively.

On one hand, the publication contract is mainly used by subjects to publish their zkp_tokens on the blockchain. In our case, this cost 244,263 in gas fees by Subject B during the experiment introduced in Section 5.3.

On the other hand, the recording contract is invoked by objects to log access behavior on the blockchain. Object B expended 3,575,874 in gas fees to record Subject B’s ’read’ operation on the chain in this case.

Lastly, it is noteworthy that the invocation of the verification contract was free of charge. This is attributed to the parameters being defined in the contract during the coding stage, eliminating the need for additional data to be written to the blockchain.

Table 7. Gas Performance.

Function	Gas Used (gas)
Deploying Publication.sol	965,225
Deploying Verifier.sol	6,446,120
Deploying Recording.sol	1,471,791
Invoking publish_token()	3,575,874
Invoking verify_proof()	0
Invoking submit_record()	244,263

visualizes the gas fees used for each function.

To validate the excellent scalability of our system, we further evaluated the gas consumption of each on-chain operation as the number of subjects increased from 1 to 100 in increments of 10, as depicted in Figure 13.

From this graph, it is evident that the gas consumption of all main operations exhibits an approximately linear correlation with the number of users. This demonstrates the system’s strong scalability in terms of gas consumption, ensuring that even with thousands or millions of users, the cost remains predictable and does not grow exponentially.

7. Discussion

7.1. Selection of Zero-Knowledge Proof

In our system, we employ Groth16 as the zero-knowledge proof algorithm to assert access rights in a lightweight, efficient, and cost-effective manner. However, the suitability of Groth16 for this scenario has been a subject of considerable discussion.

To figure out this problem, it is essential to first establish the criteria for selecting an appropriate zero-knowledge proof scheme. Given the limited storage capacity and high storage costs associated with the blockchain, the proof size should be the primary consideration, as it fundamentally determines the practical feasibility of system implementation in real-world scenarios. Additionally, the proof generation and verification times, which directly impact the latency of the authentication phase, play a crucial role in system performance. Lastly, certain qualitative factors, such as the necessity of a trusted setup, may also influence availability in specific use cases.

Referring to the prioritized criteria, we compared Groth16 with PLONK [39] and Bulletproofs [40], two prominent zero-knowledge proof schemes that are applicable to various use cases. A detailed comparison is presented in

Table 8. Comparison of Groth16, PLONK, and Bulletproofs.

Property Scheme	Groth16 [18]	PLONK [39]	Bulletproofs [40]
Proof Size (256-bit)	~800 bytes	1–1.5 KB	1–2 KB
Proof Generation Time	Fast (preprocessing required)	Slightly slower than Groth16	Slower than both Groth16 and PLONK
Proof Verification Time	Extremely fast (constant time)	Fast (slightly slower than Groth16)	Slow (linear in witness size)
Trusted Setup	Required (circuit-specific)	Required (universal)	No trusted setup
Use Cases	Blockchain-based authentication	Blockchain rollups	Confidential transactions (e.g., Monero)

.

As illustrated in Table 8, Groth16 demonstrates significant advantages in proof generation and verification, both of which are critical assessment criteria in this context. Among the evaluated schemes, Groth16 emerges as the fastest and most cost-efficient option, making it widely adopted in blockchain-based authentication systems that require high responsiveness and minimal communication overhead.

However, these benefits come at the expense of certain limitations, particularly regarding the necessity of a trusted setup and reduced transparency. In contrast, Bulletproofs is distinguished by its support for trustless setups, making it particularly well suited for applications such as confidential transactions in the Monero network. Meanwhile, PLONK strikes a balance between quantitative performance and qualitative attributes, which has contributed to its adoption in blockchain rollups.

As a result, in the context of a blockchain-based IoT access control system, Groth16 emerges as the optimal choice, as its characteristics closely align with the requirements of the blockchain-based authentication phase.

7.2. Decentralization

Although our approach aims to achieve high decentralization by delegating authority from centralized entities to the blockchain, it remains infeasible to completely eliminate the role of a trusted authority in facilitating registration and transaction tracking under the current blockchain structure. Consequently, the resource owner functions as the trusted authority, ensuring the stable operation of the system. However, this raises concerns regarding the system’s dependence on the resource owner for core functionalities such as token verification and access management.

In our case, apart from subject registration, most core functionalities, including zero-knowledge proof verification and access record management, are executed within the on-chain environment. While the resource owner retains the ability to determine the outcome of token verification, the results of the zero-knowledge proof are immutably recorded on the blockchain and remain accessible to all participants. This mechanism effectively prevents the resource owner from tampering with the verification results, thereby ensuring strong non-repudiation. Similarly, the traditionally centralized management of access lists is constrained by the decentralized on-chain access record structure, ensuring that centralized functionalities remain transparently supervised by the decentralized framework of our system.

Moreover, as a fundamental requirement for using the BIAC system, subjects must trust the resource owner’s integrity and provide necessary privacy-related information; otherwise, the registration process cannot be completed. Consequently, our system adheres to the same trust model as well-established BIAC systems, such as those presented in [13,24,27].

7.3. Scalability

Without scalability, an IoT system would quickly become overwhelmed, becoming unable to handle the increasing load, manage network traffic efficiently, or maintain robust security measures. This makes scalability a necessity for ensuring that IoT solutions remain efficient, reliable, and secure as they evolve and expand over time. As a result, we present and analysis our scheme’s scalability to dispel the potential concerns.

Fortunately, our system design enhances scalability by offloading most core functions to the on-chain environment, with the exception of user registration and resource provisioning. Consequently, the overall scalability of our system aligns with that of Ethereum. Considering a real-world deployment on the Ethereum mainnet, where the network throughput reaches approximately 30 transactions per second (TPS)—which significantly exceeds the requirements of our IoT access scenario—our system’s scalability is well supported in this regard.

For off-chain operations, such as user registration and resource provisioning, scalability primarily depends on the computational and communication capacity of the resource owner’s server. As long as high-performance infrastructure is employed in real-world deployment, these functions will not become a bottleneck limiting system usability.

Based on these factors, our system effectively mitigates scalability concerns and ensures robust performance under varying operational demands.

Regarding the scalability of IoT devices in our system, we envision a medium-scale deployment, with an upper limit of several thousand devices, and our system is designed based on this assumption. In the future, we aim to enhance our system to handle scalability challenges in large-scale IoT deployments involving millions of devices.

8. Conclusions

In this paper, we focused on realizing a privacy-preserving blockchain-based IoT access control system designed to ensure the anonymity of accounts and mitigate security concerns related to behavior, habits, and record privacy by integrating smart contracts and zero-knowledge proof into our system, which comprehensively address both the subject’s and the object’s privacy. Various unique components such as access control lists and the double-layered token were introduced to our system as assistance. We proved the theoretical and implementing feasibility of realizing the system. Through a series of quantitative experiments to assess the system from the aspects of time, space, and gas fee, our system has been proven to have superior cost efficiency in comparison to the existing works.

At present, our system is designed specifically for deployment on the Ethereum mainnet or blockchains with comparable structural characteristics. Cross-chain interoperability, including access and request handling across heterogeneous chains, is beyond the current scope and thus not yet supported.

Our system still has some drawbacks and limitations, as are outlined below:

1.

Currently, our primary focus is on demonstrating the feasibility of utilizing the token to access IoT devices within our system. However, for a capability-based access control system, enabling token delegation is crucial. The absence of token delegation may subject our system to heavy criticism regarding scalability and flexibility.

2.

One of the primary objectives of this work is to leverage the blockchain and smart contracts to enhance decentralization. However, the inclusion of a resource owner as an entity could introduce a significant challenge by centralizing power and authority, thereby conflicting with this goal. While we have demonstrated that the centralized functionalities remain transparently supervised within the decentralized framework, a more effective approach would be to further reduce the involvement of the resource owner.

3.

For an access control system, validating its practicality across various application scenarios is essential. However, our current use case and performance evaluation are limited to the smart building scenario.

Motivated by the limitations and drawbacks mentioned above, our future work is planned as follows:

1.

We aim to integrate a flexible token delegation and revocation system into our framework while still ensuring the anonymity of accounts and preventing behavior, habits, and record privacy from leakage in the future.

2.

To address the issue related to decentralization, we aim to distribute the resource owner’s authority across the blockchain network, and if feasible, to eliminate this entity entirely in future developments.

3.

We consider that a comprehensive evaluation of scalability is crucial to demonstrate the system’s applicability to large-scale deployment. Therefore, we plan to extend our testing to diverse scenarios of varying scales, such as smart cities or industrial IoT (IIoT), and conduct a corresponding comprehensive performance evaluation in the future.