An Access Control System Based on Blockchain with Zero-Knowledge Rollups in High-Traffic IoT Environments
Abstract
:1. Introduction
- (1)
- We propose the ZK-rollups of the access control authorization process, where the authorization matching and access token grant processes from different access control requests can be grouped into the same batch of transactions to generate the zero-knowledge proof uniformly.
- (2)
- We propose a specialized zero-knowledge proof, to ensure that participants involved in the authorization can be honest and that the sensitive data in the authorization matching process will not be leaked. Furthermore, we develop a practical system that supports zero-knowledge access control authorization and demonstrates the complete arithmetic circuit generation algorithms and the protocol implementations.
- (3)
- We design sufficient experiments to prove that the proposed system is suitable for high-traffic IoT environments and provide security analysis to verify the system’s ability to guarantee honesty.
2. Related Work
2.1. Attribute-Based Access Control
2.2. Blockchain Technology
2.3. zkSNARK and Zero-Knowledge Rollups
- : Input a security parameter and an arithmetic circuit C, then use the key generator function to probabilistically sample a proving key and verification key . Both keys can be exposed as public parameters and can be used multiple times.
- : Given a proof key , an input message x, and a witness w, outputs a non-interactive proof , which proves the correctness of the circuit C. In the zkSNARK framework, the arithmetic circuits C are first transformed into the rank 1 constraint system (R1CS) , which in turn generates the x and w required by .
- : Given verification key , the proof , and input x, outputs 1 if the verification is correct, otherwise 0 if it is false.
2.4. Blockchain-Based AC Systems with ZKP
3. System Overview
3.1. Participant Entities
- Requester
- Requester Device
- Owner
- Owner Server
- IoT Devices
- Gateway
- Blockchain
- Smart Contract
3.2. Sample Access Control
4. Access Control Authorization with ZK-Rollups and Protocols
4.1. Access Control Authorization with ZK-Rollups
- (1)
- The owner receives an access control authorization request from a specific requester, as well as the requester attributes for authorization.
- (2)
- The owner matches the access attributes with the set policy.
- (3)
- The requester obtains the required token to access the IoT device.
4.1.1. Authorization Matching Circuits
- (1)
- Requester uses to initiate access control authorization, owner server generates access attributes for matching;
- (2)
- Owner uses policy to match, if , then the authorization access control is legal, otherwise it fails.
- Equivalence Matching. Determines that is exactly equal to , e.g., is consistent with the policy.
- Range Matching. Determine within the given range of , for example, the timestamp of this access control is , the timestamp of last access control is , and the maximum time interval allowed for consecutive access is , which needs to satisfy .
- Multi-value matching. Assume , , multi-value matching needs to judge . For example, the “Access Action” determines whether a requester has read access to all files in a file list.
- : Construct an arithmetic circuit where x and y are equal;
- : Construct an arithmetic circuit with x in the specified range of y. In practice it is a quantitative relationship determined by the matching requirements of access attributes and policies;
- (: Construct an arithmetic circuit which reveals that and output the hash calculation result h.
- : The arithmetic circuit initialization function.
- : The owner uses and to query in the owner server to obtain the and of the corresponding IoT device, and after combining them with , the access attribute A is generated.
Algorithm 1 Build Matching Circuit |
Input: |
Output: C |
|
4.1.2. Access Token Grant Circuits
- : Construct an arithmetic circuit to verify that is a leaf node of a Merkle tree with root , where are the sibling nodes needed to generate the Merkle proof. As shown in Figure 3, in order to construct the Merkle proof of Leaf 1, we need Hash 0-1, Hash 1 as sibling nodes. Then first determines whether hash(Hash 0-0 + Hash 0-1) and Hash 0 are equal, and then we determine whether hash(Hash 0 + Hash 1) and Root Hash are the same. The relevant intermediate arithmetic circuits are generated by and .
- : Output the sibling nodes necessary for the Merkle proof, where the hash value of leaf is .
- , : means all leaf nodes in the Merkle tree, this function replaces a node in from to and output the new Merkle root hash , as well as the new Merkle leaf nodes ;
Algorithm 2 Build Device Merkle Circuit |
Input: |
Output: |
|
Algorithm 3 Build Access Merkle Circuit |
Input: |
Output: |
|
- As the tree height increases, the time overhead of Algorithms 2 and 3 execution will be concentrated on , which will slow down the authorization overall, as we will show in Section 5.2 in conjunction with experimental data.
- also needs to bring Merkle leaves into memory for generating proof, considering an IoT environment with a large number of devices and access authorization requests, a tree with a height of 30 can verify about 1 billion leaf nodes, and a leaf hash of 256 bits will bring a memory overhead of × 256 bit = 32 GB.
- The article [40] shows that the height of the Merkle tree only affects how many leaves can be verified with the Merkle proof, and has no effect on the security of proof, which is mainly determined by the hash function.
- The owner needs to query Merkle leaves from the public ledger; taller trees mean heavier transmission delay.
4.1.3. Zero-Knowledge Rollup Circuits
Algorithm 4 Build ZK-Rollup Circuit |
Input: |
Output: |
|
4.2. Protocols of System
4.2.1. Setup Phase
- Goal: register users in the proposed system, which may be owners or requesters
- Smart contract parameters:
- (1)
- Requester or owner , generate locally the public-private key pair for encryption and the public-private key pair for signature , r is the randomness.
- (2)
- Upload to the smart contract, is the user type.
- (3)
- Generate globally unique user identifier by smart contract and store user information in public ledger.
- Goal: the owner registers the owned IoT device with the blockchain network
- Smart contract parameters:
- (1)
- Owner generates locally the identifier of the owned device and the public-private key pair for encryption .
- (2)
- Submit to the smart contract.
- (3)
- The smart contract stores the information of the IoT device to the public ledger, where and represent the default and which shows that no requesters can use a token to access to the IoT device, and adds a leaf node to the “Device Merkle Tree” marked as .
- (4)
- Register a callback event with the owner server so that the owner is aware that a requester has initiated access control authorization for the IoT device.
- Goal: upload verification key of ZK proof to smart contract
- Smart contract parameters:
- (1)
- Owner generates C with Algorithm 4, input parameters , , are queried from the public ledger, the rest of the parameters can be generated through a batch of past authorization requests.
- (2)
- (3)
- is uploaded to the smart contract, which generates a globally unique identifier and stores to the public ledger.
4.2.2. Access Control Authorization Phase
- Goal: let the requester request user attributes () from owner for access control authorization
- Smart contract parameters:
- (1)
- Requester uploads to the smart contract to obtain the needed user attributes for a specific IoT device.
- (2)
- The smart contract will store the requester attributes information in the public ledger .
- (3)
- Register a callback event with the requester device so that the requester detects the owner’s modification of , then triggers the callback event registered by the owner in Register Device.
- Goal: let the owner inform the requester of the required user attributes format for authorization
- Smart contract parameters:
- (1)
- The owner senses the request of getting user attributes format through the callback event and stores the policy P required in the server.
- (2)
- Prepare the data structure , where , indicating the name and type (string/int/unsigned int array) of a single user attribute.
- (3)
- Obtain the of the corresponding requester from the public ledger and use the encryption function to obtain .
- (4)
- Call the smart contract to add to the corresponding , and then trigger the callback event registered by Get User Attributes.
- Goal: requester formally initiates access control authorization
- Smart contract parameters:
- (1)
- Requester detects that the owner has set the user attributes format required for authorization via the callback event.
- (2)
- Decrypt using the private key, and then generate the required for authorization locally.
- (3)
- Obtain the of the corresponding owner from the public ledger, and use the encryption function to obtain and compute .
- (4)
- Call the smart contract.
- (5)
- Smart contract generates the identifier for this access control authorization in the public ledger and stores to the public ledger.
- (6)
- Add a leaf node to the “Access Merkle Tree”, the identifier of tree generated by smart contract is .
- (7)
- Trigger the callback event for the owner registered in “Register Device”, informing the owner that a requester has initiated authorization.
- Goal: owner integrates authorization requests into a batch of transactions, constructs the zero-knowledge proof, and submits them to smart contracts for verification, the authorization matching result of transactions should be all successful or failed.
- Smart contract parameters:
- (1)
- Following the receipt of a predetermined number of access control authorizations, the owner begins building the circuit C using Algorithm 4, where the public ledger is queried for the input parameters , , and the remaining parameters are built using the authorization requests received.
- (2)
- In C, all in the batch, initial and before access control authorization are set to x that can be made public, then read and previously saved locally to construct the proof using Equation (2);
- (3)
- Owner uploads to the smart contract, where is the authorization result type of (success/failure), and . represents the duration of the requester to access the device. , , and are encrypted using the requester’s encryption public key. Furthermore, is generated using Equation (4).
- (4)
- The smart contract verifies that all in exist in x and obtains , from x to compare with the values in the current public ledger, if they are equal, the corresponding is obtained by and executes verification using Equation (3), otherwise the smart contract will return.
- (5)
- After executing verification, if the verification value is 1, the smart contract assigns a value of 1 to the nonce and records in corresponding to , then assign and to the corresponding “Device” if is true. If the verification value is 0, the smart contract will reject the batch of authorization verification.
4.2.3. Token Authentication Phase
- Goal: requester uses the token to access the IoT device
- (1)
- (2)
- Requester initiates a new access control command, encrypts and using , which is then sent to the IoT device.
- (3)
- The IoT device decrypts to obtain and , also obtains in the current public ledger via the gateway, and uses Equation (4) to check the correctness of . If is legitimate, the IoT device generates a random number to send to the requester.
- (4)
- Requester encrypts with and sends it to the IoT device. The IoT device decrypts and compares it with the previous value to achieve strong authentication of the requester.
- (5)
- To make sure that is fresh, the requester must repeat steps (2)–(4) when a new access control command is initiated.
5. Evaluation
5.1. Implementation Details
5.2. Experiment Results
6. Security Analysis
6.1. Potential Attack Modes and Defenses
- Attack 1: a malicious requester wants to obtain the privileges of a device by forging the requester attributes in an existing authorization request. On the one hand, is generated based on zkSNARK, which does not expose any information about access attributes and policies, and on the other hand, user attributes are encrypted using the requester’s private key, which cannot be restored by the attacker via . Furthermore, the format of the user attribute is not exposed, because is also encrypted during the transmission.
- Attack 2: a malicious requester initiates a replay attack, reusing in the public ledger to initiate access control authorization. If the is 1, the owner server will not perform authorization matching after receiving the request. If the is found to be 0, although the malicious requester obtains the authorization result through Protocol 7, it cannot obtain , , and the IP of the device through decryption. The malicious requester can neither initiate access control to the IoT device nor obtain any knowledge about .
- Attack 3: a malicious owner receives an access authorization request from a requester and has the corresponding policy in its server, but the owner chooses to forge non-existent requester attributes to perform the authorization matching. in the arithmetic circuit to ensure that the owner can only use the submitted requester attributes for matching, and proof of “Access Merkle Tree” ensures that exists and any forged requester attributes do not pass the Merkle proof test.
- Attack 4: a malicious owner wishes to bypass the rules of authorization matching and arbitrarily grant access permission of an IoT device to a requester. This system ensures that this behavior does not occur in three ways: first, the malicious owner cannot build a non-existent proof of “Access Merkle Tree”, which ensures that an owner can only grant the token through an authorization request initiated by a requester; second, , if equal to 1, ensures that requests that have completed authorization matching are not reused; third, if equal to 0, with line 9 of Algorithm 4 ensures the correspondence between the requester and the authorization request, the malicious owner cannot use the request initiated by a specific requester to grant token to another requester.
- Attack 5: the attacker aims to take control of an IoT device by replaying previous requests during the “Token Authentication” phase. To prevent the attacker from obtaining the most recent , the and are encrypted using the symmetric secret key . Moreover, the freshness of assures that an attacker cannot obtain access control by using ’s previous value.
6.2. Formal Security Verification Using AVISPA
7. Conclusions
7.1. Research Summary
7.2. Future Work
- Each participant entity in the proposed system must maintain a public-private key pair since the conventional asymmetric encryption key management technique is used. However, in an IoT environment with high traffic and many participating entities, such a key management method is undoubtedly very complicated. To lessen the difficulties of key management on the one hand and provide fine-grained access control to encrypted data on the other, we intend to add attribute-based encryption [51] in future work.
- In practice, we found that using Algorithm 1 to generate authorization matching circuits is strongly related to the specific business. Despite the fact that we have established three matching patterns, users still need to construct several authorization matching circuits beforehand to meet various business needs. To maximize the effectiveness of authorization matching circuit generation, we want to further improve Algorithm 1 and provide relevant template configuration techniques in future work.
- Currently, the proposed system takes into account that in a high-traffic IoT environment, the owner’s side may receive a large number of access authorization requests instantaneously, so it adopts the idea of ZK-rollups to design the Protocol “Access Control Verify”. However, the requester also needs to send a large number of access authorization requests at the same time to obtain the privileges of an IoT device. Therefore, in future work, we plan to use similar batch optimization on the requester side to improve the performance of the related protocols.
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
References
- Chen, S.; Xu, H.; Liu, D.; Hu, B.; Wang, H. A vision of IoT: Applications, challenges, and opportunities with china perspective. IEEE Internet Things J. 2014, 1, 349–359. [Google Scholar] [CrossRef]
- Qiu, T.; Chen, N.; Li, K.; Atiquzzaman, M.; Zhao, W. How Can Heterogeneous Internet of Things Build Our Future: A Survey. IEEE Commun. Surv. Tutor. 2018, 20, 2011–2027. [Google Scholar] [CrossRef]
- Pal, S.; Dorri, A.; Jurdak, R. Blockchain for IoT access control: Recent trends and future research directions. J. Netw. Comput. Appl. 2022, 203, 103371. [Google Scholar] [CrossRef]
- Yue, K.; Zhang, Y.; Chen, Y.; Li, Y.; Zhao, L.; Rong, C.; Chen, L. A survey of decentralizing applications via blockchain: The 5g and beyond perspective. IEEE Commun. Surv. Tutor. 2021, 23, 2191–2217. [Google Scholar] [CrossRef]
- Sandhu, R.S.; Samarati, P. Access control: Principle and practice. IEEE Commun. Mag. 1994, 32, 40–48. [Google Scholar] [CrossRef]
- Ragothaman, K.; Wang, Y.; Rimal, B.; Lawrence, M. Access Control for IoT: A Survey of Existing Research, Dynamic Policies and Future Directions. Sensors 2023, 23, 1805. [Google Scholar] [CrossRef]
- Lindqvist, H. Mandatory Access Control. Master’s Thesis, Department of Computing Science, Umeå University, Umeå, Sweden, 2006. [Google Scholar]
- Sandhu, R.S.; Coyne, E.J.; Feinstein, H.L.; Youman, C.E. Role-based access control models. Computer 1996, 29, 38–47. [Google Scholar] [CrossRef] [Green Version]
- Yuan, E.; Tong, J. Attributed based access control (ABAC) for web services. In Proceedings of the IEEE International Conference on Web Services (ICWS’05), Orlando, FL, USA, 11–15 July 2005. [Google Scholar]
- Gusmeroli, S.; Piccione, S.; Rotondi, D. A capability-based security approach to manage access control in the internet of things. Math. Comput. Model. 2013, 58, 1189–1205. [Google Scholar] [CrossRef]
- Ye, Q.; Zhuang, W. Distributed and adaptive medium access control for Internet-of-Things-enabled mobile networks. IEEE Internet Things J. 2016, 4, 446–460. [Google Scholar] [CrossRef]
- Novo, O. Blockchain meets IoT: An architecture for scalable access management in IoT. IEEE Internet Things J. 2018, 5, 1184–1195. [Google Scholar] [CrossRef]
- Zhang, Y.; Kasahara, S.; Shen, Y.; Jiang, X.; Wan, J. Smart contract-based access control for the internet of things. IEEE Internet Things J. 2018, 6, 1594–1605. [Google Scholar] [CrossRef] [Green Version]
- Pal, S.; Rabehaja, T.; Hitchens, M.; Varadharajan, V.; Hill, A. On the design of a flexible delegation model for the Internet of Things using blockchain. IEEE Trans. Ind. Inform. 2019, 16, 3521–3530. [Google Scholar] [CrossRef]
- Song, H.; Tu, Z.; Qin, Y. Blockchain-Based Access Control and Behavior Regulation System for IoT. Sensors 2022, 22, 8339. [Google Scholar] [CrossRef] [PubMed]
- Xu, R.; Chen, Y.; Blasch, E.; Chen, G. Blendcac: A blockchain-enabled decentralized capability-based access control for IoTs. In Proceedings of the 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), Halifax, NS, Canada, 30 July–3 August 2018; pp. 1027–1034. [Google Scholar]
- Nakamura, Y.; Zhang, Y.; Sasabe, M.; Kasahara, S. Exploiting smart contracts for capability-based access control in the internet of things. Sensors 2020, 20, 1793. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Chen, Y.; Tao, L.; Liang, B.; Sun, L.; Li, Y.; Xing, B.; Chen, L. Capability-& Blockchain-based Fine-grained and Flexible Access Control Model. IEEE Netw. 2023, 1–8. [Google Scholar] [CrossRef]
- Li, Q.; Xue, Z. A privacy-protecting authorization system based on blockchain and zk-SNARK. In Proceedings of the 2020 International Conference on Cyberspace Innovation of Advanced Technologies, Guangzhou China, 4–6 December 2020; pp. 439–444. [Google Scholar]
- Hu, Q.; Dai, Y.; Li, S.; Jiang, T. Enhancing Account Privacy in Blockchain-based IoT Access Control via Zero Knowledge Proof. IEEE Netw. 2022, 1–7. [Google Scholar] [CrossRef]
- Maesa, D.D.F.; Lisi, A.; Mori, P.; Ricci, L.; Boschi, G. Self sovereign and blockchain based access control: Supporting attributes privacy with zero knowledge. J. Netw. Comput. Appl. 2023, 212, 103577. [Google Scholar] [CrossRef]
- Petkus, M. Why and how zk-snark works. arXiv 2019, arXiv:1906.07221. [Google Scholar]
- Bitansky, N.; Chiesa, A.; Ishai, Y.; Ostrovsky, R.; Paneth, O. Succinct Non-interactive Arguments via Linear Interactive Proofs. In Proceedings of the TCC, 2013, Tokyo, Japan, 3–6 March 2013; Springer: Berlin/Heidelberg, Germany, 2013; Volume 7785, pp. 315–333. [Google Scholar]
- Lavaur, T.; Lacan, J.; Chanel, C.P. Enabling Blockchain Services for IoE with Zk-Rollups. Sensors 2022, 22, 6493. [Google Scholar] [CrossRef]
- Qiu, J.; Tian, Z.; Du, C.; Zuo, Q.; Su, S.; Fang, B. A survey on access control in the age of internet of things. IEEE Internet Things J. 2020, 7, 4682–4696. [Google Scholar] [CrossRef]
- Dramé-Maigné, S.; Laurent, M.; Castillo, L.; Ganem, H. Centralized, distributed, and everything in between: Reviewing access control solutions for the IoT. ACM Comput. Surv. (CSUR) 2021, 54, 1–34. [Google Scholar] [CrossRef]
- Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Decentralized Bus. Rev. 2008, 21260. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 27 February 2023).
- Zou, W.; Lo, D.; Kochhar, P.S.; Le, X.B.D.; Xia, X.; Feng, Y.; Chen, Z.; Xu, B. Smart contract development: Challenges and opportunities. IEEE Trans. Softw. Eng. 2019, 47, 2084–2106. [Google Scholar] [CrossRef]
- Partala, J.; Nguyen, T.H.; Pirttikangas, S. Non-interactive zero-knowledge for blockchain: A survey. IEEE Access 2020, 8, 227945–227961. [Google Scholar] [CrossRef]
- Goldwasser, S.; Micali, S.; Rackoff, C. The knowledge complexity of interactive proof-systems. In Providing Sound Foundations for Cryptography: On the Work of Shafi Goldwasser and Silvio Micali; Association for Computing Machinery: New York, NY, USA, 2019; pp. 203–225. [Google Scholar]
- Sguanci, C.; Spatafora, R.; Vergani, A.M. Layer 2 blockchain scaling: A survey. arXiv 2021, arXiv:2107.10881. [Google Scholar]
- Dannen, C. Introducing Ethereum and Solidity; Apress: Berkeley, CA, USA, 2017; Volume 1. [Google Scholar]
- Dedeoglu, V.; Jurdak, R.; Dorri, A.; Lunardi, R.; Michelin, R.; Zorzo, A.; Kanhere, S. Blockchain technologies for IoT. In Advanced Applications of Blockchain Technology; Springer: Singapore, 2020; pp. 55–89. [Google Scholar]
- Sasson, E.B.; Chiesa, A.; Garman, C.; Green, M.; Miers, I.; Tromer, E.; Virza, M. Zerocash: Decentralized anonymous payments from bitcoin. In Proceedings of the 2014 IEEE Symposium on Security and Privacy, Berkeley, CA, USA, 18–21 May 2014; pp. 459–474. [Google Scholar]
- Reid, F.; Harrigan, M. An Analysis of Anonymity in the Bitcoin System; Springer: New York, NY, USA, 2013. [Google Scholar]
- Barber, S.; Boyen, X.; Shi, E.; Uzun, E. Bitter to better—How to make bitcoin a better currency. In Proceedings of the Financial Cryptography and Data Security: 16th International Conference, FC 2012, Kralendijk, Bonaire, 27 February–2 March 2012; Revised Selected Papers 16. Springer: Berlin/Heidelberg, Germany, 2012; pp. 399–414. [Google Scholar]
- Soni, D.; Makwana, A. A survey on mqtt: A protocol of internet of things (IoT). In Proceedings of the International Conference on Telecommunication, Power Analysis and Computing Techniques (ICTPACT-2017), Chennai, India, 6–8 April 2017; Volume 20, pp. 173–177. [Google Scholar]
- Fovino, I.N.; Carcano, A.; Masera, M.; Trombetta, A. Design and implementation of a secure modbus protocol. In Proceedings of the Critical Infrastructure Protection III: Third Annual IFIP WG 11.10 International Conference on Critical Infrastructure Protection, Hanover, NH, USA, 23–25 March 2009; Revised Selected Papers 3. Springer: Berlin/Heidelberg, Germany, 2009; pp. 83–96. [Google Scholar]
- Szydlo, M. Merkle tree traversal in log space and time. In Proceedings of the Eurocrypt, Interlaken, Switzerland, 2–6 May 2004; Springer: Berlin/Heidelberg, Germany, 2004; Volume 3027, pp. 541–554. [Google Scholar]
- Yin, X.; He, J.; Guo, Y.; Han, D.; Li, K.C.; Castiglione, A. An efficient two-factor authentication scheme based on the Merkle tree. Sensors 2020, 20, 5735. [Google Scholar] [CrossRef]
- MacKenzie, P.; Patel, S.; Swaminathan, R. Password-authenticated key exchange based on RSA. In Proceedings of the Advances in Cryptology—ASIACRYPT 2000: 6th International Conference on the Theory and Application of Cryptology and Information Security, Kyoto, Japan, 3–7 December 2000; Springer: Berlin/Heidelberg, Germany, 2000; pp. 599–613. [Google Scholar]
- Bresson, E.; Chevassut, O.; Pointcheval, D. Provably secure authenticated group Diffie-Hellman key exchange. ACM Trans. Inf. Syst. Secur. (TISSEC) 2007, 10, 10-es. [Google Scholar] [CrossRef] [Green Version]
- Haakegaard, R.; Lang, J. The Elliptic Curve Diffie-Hellman (ECDH). 2015. Available online: https://koclab.cs.ucsb.edu/teaching/ecc/project/2015Projects/Haakegaard+Lang.pdf (accessed on 27 February 2023).
- Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; De Caro, A.; Enyeart, D.; Ferris, C.; Laventman, G.; Manevich, Y.; et al. Hyperledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, Porto, Portugal, 23–26 April 2018; pp. 1–15. [Google Scholar]
- Botrel, G.; Piellard, T.; Housni, Y.E.; Kubjas, I.; Tabaie, A. ConsenSys/Gnark: V0.6.4. 2022. Available online: https://zenodo.org/record/6093969#.ZBqKWxVBy3A (accessed on 27 February 2023).
- Albrecht, M.; Grassi, L.; Rechberger, C.; Roy, A.; Tiessen, T. MiMC: Efficient encryption and cryptographic hashing with minimal multiplicative complexity. In Proceedings of the Advances in Cryptology–ASIACRYPT 2016: 22nd International Conference on the Theory and Application of Cryptology and Information Security, Hanoi, Vietnam, 4–8 December 2016; Springer: Berlin/Heidelberg, Germany, 2016; pp. 191–219. [Google Scholar]
- Mallouli, F.; Hellal, A.; Saeed, N.S.; Alzahrani, F.A. A survey on cryptography: Comparative study between RSA vs. ECC algorithms, and RSA vs. El-Gamal algorithms. In Proceedings of the 2019 6th IEEE International Conference on Cyber Security and Cloud Computing (CSCloud)/2019 5th IEEE International Conference on Edge Computing and Scalable Cloud (EdgeCom), Paris, France, 21–23 June 2019; pp. 173–176. [Google Scholar]
- Semmouni, M.C.; Nitaj, A.; Belkasmi, M. Bitcoin security with a twisted Edwards curve. J. Discret. Math. Sci. Cryptogr. 2022, 25, 353–371. [Google Scholar] [CrossRef] [Green Version]
- AVISPA. Automated Validation of Internet Security Protocols and Applications. Available online: https://www.avispa-project.org/ (accessed on 10 March 2023).
- Cervesato, I. The Dolev-Yao intruder is the most powerful attacker. In Proceedings of the 16th Annual Symposium on Logic in Computer Science—LICS, Washington, DC, USA, 16–19 June 2001; Volume 1, pp. 1–2. [Google Scholar]
- Rasori, M.; La Manna, M.; Perazzo, P.; Dini, G. A survey on attribute-based encryption schemes suitable for the internet of things. IEEE Internet Things J. 2022, 9, 8269–8290. [Google Scholar] [CrossRef]
Notation | Description |
---|---|
A | The access attribute set used for authorization matching |
The ith access attribute in A | |
P | The policy set used for authorization matching |
The ith policy in P | |
C | The arithmetic circuit |
Hash function | |
h | The hash calculation result |
The “Device”data structure in the public ledger | |
The “Access” data structure in the public ledger | |
A list of leaf nodes in the Merkle tree | |
Sibling nodes needed to generate the Merkle proof of a leaf | |
The token required for the requester to perform access control on a device | |
Randomness used to generated | |
Public key for encryption or signature generation | |
Private key for encryption or signature generation | |
The generation function of pair | |
Encryption and decryption functions | |
The signature generation function | |
The signature verification function | |
Data structure describing the composition form of | |
Proving key and verification key of zkSNARK | |
x | Input message of zkSNARK |
w | Witness of zkSNARK |
The transactions of ZK-rollups | |
Generated non-interactive proof of zkSNARK | |
Symmetric session key for requester and IoT device |
Policy Type | Description |
---|---|
Requester Identity () | Used to specify the requester’s identity |
IoT Device Identity () | Used to specify the IoT device’s identity |
User Attributes () | Characteristics used to describe a requester, such as role, age, department, and job |
Environmental Attributes () | Used to describe the environmental characteristics of the IoT device when access control occurs, such as time, temperature, etc. |
Access Action () | Used to specify the IoT device operations that the requester is permitted to perform, such as read, write, execute, etc. |
Height of Tree | Batch Size = 5 | Batch Size = 10 | Batch Size = 25 | Batch Size = 35 | Batch Size = 50 |
---|---|---|---|---|---|
9 | 30 | 60 | 143 | 220 | 287 |
11 | 33 | 66 | 189 | 239 | 378 |
13 | 35 | 71 | 202 | 258 | 405 |
16 | 47 | 95 | 223 | 287 | 446 |
Batch Size = 5 | Batch Size = 10 | Batch Size = 25 | Batch Size = 35 | Batch Size = 50 |
---|---|---|---|---|
0.94 | 1.56 | 3.44 | 4.69 | 6.56 |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Lin, X.; Zhang, Y.; Huang, C.; Xing, B.; Chen, L.; Hu, D.; Chen, Y. An Access Control System Based on Blockchain with Zero-Knowledge Rollups in High-Traffic IoT Environments. Sensors 2023, 23, 3443. https://doi.org/10.3390/s23073443
Lin X, Zhang Y, Huang C, Xing B, Chen L, Hu D, Chen Y. An Access Control System Based on Blockchain with Zero-Knowledge Rollups in High-Traffic IoT Environments. Sensors. 2023; 23(7):3443. https://doi.org/10.3390/s23073443
Chicago/Turabian StyleLin, Xin, Yuanyuan Zhang, Changhai Huang, Bin Xing, Liangyin Chen, Dasha Hu, and Yanru Chen. 2023. "An Access Control System Based on Blockchain with Zero-Knowledge Rollups in High-Traffic IoT Environments" Sensors 23, no. 7: 3443. https://doi.org/10.3390/s23073443