Cross-chain Access Control for Permissioned Blockchain Interoperation

1

Cross-chain Access Control for Permissioned Blockchain Interoperation

arXiv:2610.05054v1 [cs.CR] 4 Oct 2026

Tirthankar Sengupta, Bishakh Chandra Ghosh, Sandip Chakraborty, and Shamik Sural

Abstract—As enterprise blockchains become increasingly interconnected, access control must extend beyond the boundaries of a single network. Existing approaches mainly focus on controlling access within one blockchain, while cross-chain interactions involve multiple networks that may follow different access-control policies and administrative rules. In this paper, we propose InterAcct, an end-to-end access-control framework for secure interactions across permissioned blockchain networks. To avoid exposing sensitive internal information, InterAcct converts outgoing requests into a consortium-level representation before they are shared with another network. When a response is returned, the framework securely maps it back to the original requester within the source consortium, preserving confidentiality throughout the interaction. Our experimental results show that InterAcct can enforce end-to-end access control for cross-chain request-response interactions with low additional overhead and can continue to operate effectively as the workload increases. Index Terms—blockchain; interoperability; permissioned blockchain; cross-chain; access control; decentralized systems

I. I NTRODUCTION In cross-blockchain communications, strong access control is essential to protect sensitive data. If a supply chain ledger is compromised, information such as shipping schedules or client details could be exposed. In the healthcare domain, weak access control could lead to the disclosure of patient records, increasing the risk of identity theft and data misuse. Exchanging data and assets between consortiums is complicated, involving distinct networks, each consisting of multiple organizations, as illustrated in Fig. 1. Each phase of the interoperation process must be governed by appropriate access control mechanisms and policies. In centralized enterprise systems like ERP and CRM, access is typically managed using Role-Based Access Control (RBAC) [1], which relies on user roles and adheres to principles such as least privilege and separation of duties [2], [3], [4]. For more granular control, Attribute-Based Access Control (ABAC) [5] is also employed. ABAC uses additional contextual attributes such as time of access, department affiliation, or data sensitivity level to enforce more dynamic and flexible access policies. Most of these approaches focus on a single blockchain rather than cross-chain communication, and they fail to adequately address access control across enterprise-level consortiums. To address the limitations, we propose InterAcct, an access Tirthankar Sengupta (mailtisen03@kgpian.iitkgp.ac.in), Sandip Chakraborty (sandipc@cse.iitkgp.ac.in) , and Shamik Sural (shamik@cse.iitkgp.ac.in) are with the Department of Computer Science and Engineering, Indian Institute of Technology, Kharagpur, India. Bishakh Chandra Ghosh (ghoshbishakh@gmail.com) is with Pinggy Technology Private Limited, India.

Fig. 1: Cross-Consortium Access control framework for permissioned blockchain interoperation. To address the limitations above, we propose InterAcct, an access control model for permissioned blockchain interoperation. InterAcct implements endorsement policies based on access request source and access types. The key contributions of this work, are the following. • Access control for the originating network: InterAcct introduces a flexible access control policy that effectively handles varying types of access requirements for the source consortium. such as individual employees, entire companies, or even joint requests from multiple organizations. • Defending Requester Bias: This is achieved by omitting internal details, such as the requesting organization’s or employee’s identity, thus maintaining privacy. • Request unification and privacy: It is important to present each inter-consortium message as originating from the consortium as a whole. This is achieved by consolidating outgoing requests while omitting internal details, such as the requesting organization’s or actor’s identity, thus maintaining privacy. The proposed framework builds on a preliminary version of a cross-chain access control method that we have introduced in our earlier work [6]. We test the prototype implementation based on Hyperledger Fabric with Hyperledger Cacti through extensive experiments. II. R ELATED W ORK Recent research has explored various blockchain interoperability approaches. Atomic swaps [7], [8] facilitate cross-chain asset transfers but they face challenges like locking issues. Han et al. [9] proposed VMs for unified smart contract verifications, which improve functionality but suffer from scalability limitations. Side-chain solutions [7], [10], [11], [12], [13]

2

rely on auxiliary chains to handle tasks independently. Notary schemes, relying on trusted nodes [14], introduce risks of third-party bias. In contrast, blockchain agonistic relay-based inter-blockchain-connector framework is used in Hyperledger Cacti [15]. On the other hand, provenance architectures such as global views [16], healthcare EHR systems [17], and collaborative system solutions [18], [19], [20], [21] are used to ensure exchange of blockchain states with endorsement proofs. On the other side, various access control models have evolved over the years, addressing security challenges. RoleBased Access Control (RBAC) [1], [2], [3], a widely used model, adheres to principles like least privilege and duty separation. However, RBAC struggles with granular and dynamic access requirements. Attribute-Based Access Control (ABAC) [22], [23] overcomes these limitations by associating policies with user and resource attributes, enabling dynamic and context-aware decisions. In blockchain contexts, decentralized access control is vital. Rouhani et al. [24] proposed a distributed ABAC system using permissioned blockchains and chaincode. Several decentralized access control approaches [25], [26], [27] advocated SSI-based access control frameworks for authentication and authorization. Si et al. [28] proposed a cross-chain access scheme for access policies and attributes using relay nodes and homomorphic threshold encryption. Gai et al. [29] proposed RBAC protocol with multi-signature for cross-organizational data exchange. These existing systems are often siloed and do not address the inter-consortium access control mechanism for blockchain interoperation. III. P ROPOSED M ETHODOLOGY The InterAcct framework is comprised of the following components: (A) Forming Access Request, (B) Extracting and Saving Request Details, (C) Interoperable Access RequestResponse Data Transfer, (D) Access Control in Responding Consortium, and (E) Encrypting and Routing Access Response. The overall workflow is depicted in Fig. 2. Typically, an access request originates from an individual actor within an organization. Using the intra-organization ACL policy, InterAcct verifies whether the requester has the necessary permissions to initiate such a request, after which the signature of the organization’s director is affixed. However, if the director (i.e., the head of the organization) directly initiates the request, no additional organizational-level endorsement is required. In case of multilateral requests, endorsements from the directors of the required organizations are verified. In the next step, the request is evaluated against the consortium ACL policy, which determines whether the required endorsements from a sufficient number of organizations are present to initiate the crossblockchain request. Then the access request (R) is processed to strip internal metadata and an access request transaction Tacc req is invoked by the consortium (N1 ). It is transmitted to foreign blockchain (N2 ) via an interoperability framework, where it undergoes cross-consortium ACL verification and processing to generate a response. Internal metadata of the responder is filtered out and the access response is encrypted. Next a response transaction Tacc resp is generated forwarded to

N1 via the interoperability framework. Finally, the response is routed back to the original requester Ejk in N1 . We detail the components of our proposed framework in the below sub-sections.

Fig. 2: InterAcct Process Flow Diagram

A. Forming and Validating Access Request When a cross-chain access request transaction Tacc req is invoked, it is first signed by the actor Ejk . Next, the director of the organization ψdirectorOij , verifies it as per the Intra-Org ACL(R) policy and finally endorses it. The Algorithm 1 describes how the access requests are formed, endorsed and validated against the access control polices. For unilateral requests, once an actor Ejk forms and signs an access request as ψEjk (R), the organization director’s signature ψdirector Oij (R) is sought to represent the organization-level endorsement ψOij (R). The director’s endorsement is considered as an organization’s endorsement, ψdirectorOij (R) = ψOij (R) (refer steps 1-6 in Algorithm 1). In the case of multilateral requests, where S(R) = [Ekp , Ekp+1 , . . . , Ekq ], the request R must be endorsed collectively by multiple organizations (Ekp , Ekp+1 , . . . , Ekq ) within N1 (refer steps 7-11 in Algorithm 1), ensuring that no party can single-handedly approve R. The algorithm verifies that all mandated organizations have provided valid endorsements before approving the request, verifying V (ψOip ∩ · · · ∩ ψOiq (R)) is true or not, as part of the consortium ACL policy Consortium ACL(R) (refer steps 12-24 in Algorithm 1). The consortium ACL validation is implemented through smart contract logic, and the corresponding ACL policies are pre-configured in the ledger, defining which organizations are permitted to initiate unilateral requests and which combinations of organizations can jointly initiate multilateral requests. If all the consortium endorsement rules are met and VOij (ψ) evaluates to true, the access request R, along with its attribute values, is committed to the ledger of N1 with endorsement details ψOij . If the ConsortiumACLValidation is not satisfied within the stipulated time frame, the request R is marked as invalid and forfeited. B. Extracting and Saving Request Details Directly transmitting an access request R as it is to a foreign network N2 may expose the internal details of the requester and the organizational structure of consortium N1 . A foreign

3

consortium could exploit this metadata to infer sensitive roles, hierarchies, or access patterns, and take malicious advantage of this information. To mitigate this, after endorsement, the signed request ψOij ||R is parsed for extracting critical details such as the original requester’s identity, access request reference, node information, and organization details. These details are then recorded in a smart contract of the source network ledger. This process helps in routing the response back to the original requester later. The resulting request therefore represents consortium N1 as a collective entity as the source, rather than exposing its internal participants. Algorithm 1: Consortium ACL Validation Access Request Formation: if Request Type == Individual Request then 2 Actor Ejk generates a unilateral request R; 3 S(R) ← Ejk ; /* Set request source of the request */ 4 ψEjk (R) ← Sign(Ejk (R)); /* Actor signs the request */ 5 Director verifies R against Intra-Org ACL; 6 ψOij (R) ← ψEjk =director (R||ψEjk (R)); /* Director provides org-level endorsement*/;

1

else if Request Type == multilateral Request then Actor Ekp , Ekp+1 , . . . , Ekq generate an access request R; 9 S(R) ← [Ekp , Ekp+1 , . . . , Ekq ]; 10 ψEkp ∪Ekp+1 ∪...Ekq (R) ← Sign(Ekp ∪Ekp+1 ∪...Ekq ) (R); 11 ψOip ∪···∪Oiq (R) ← ψ(Ekp =director∪Ekp+1 ...Ekq =director) (R||ψEkp ∪Ekp+1 ∪...Ekq (R)); 7

8

Function ConsortiumACLValidation(R, S(R)): /* For unilateral requester’s request */ 14 if S(R) == Ejk then 15 /* Return True if organization level endorsement is valid */ 16 if Validate(ψOij (R)) == True then 17 return True;

12

13

18 19 20 21 22 23 24

/* For multilateral requests */ else if S(R) == [Ekp , Ekp+1 , . . . , Ekq ] then /* Verify endorsement of each requester’s organizations */ foreach Ol ∈ [Oip , Oip+1 , . . . , Oiq ] do if Validate(ψOl (R)) ̸= True then return False; return True;

C. Interoperable Access Request-Response Data Transfer Once the access request transaction Tacc req is transmitted by the source consortium N1 , or the access response Tacc resp is dispatched by the destination consortium N2 , an interoperability tool is needed to facilitate the data exchange. The InterAcct approach incorporates a permissioned blockchain interoperability framework that employs drivers, relays, and attestation-based proof mechanisms to establish cross-chain trust, as initially proposed by Abebe et al. [30]. This protocol has been further refined in the Hyperledger Cacti project [15]. When transferring Tacc req and Tacc resp between N1 and N2 , the interoperability smart contract first initiates the cross-chain transaction. It prepares the data and associates the proof of consensus on the data as attestations using digital signatures of the consensus participants. The driver component converts the prepared data into a format compatible with any consortium and transmits it to the corresponding relay. The relay, in turn, forwards the data to the driver module of the destination

network, which delivers it to the interoperability smart contract on the destination ledger for further processing. If either the access request transaction Tacc req or the corresponding access response transaction Tacc resp does not reach the destination consortium N2 or the source consortium N1 , respectively, within a stipulated time limit, both the request and the response are marked as invalid in the ledgers of both consortiums. D. Access Control in Responding Consortium The interoperability framework Cacti [15] provides the transport and attestation proof for identification for crossconsortium data [31], but does not include a native authentication mechanism to fully verify the legitimacy of the request. So, InterAcct ensures that, upon the arrival of the access request transaction Tacc req at the destination consortium N2 , the verification process begins by authenticating its origin through validation of N1 ’s public key. Next, Cross-consortium ACL evaluates the validation rules for processing access requests that arrive from another consortium. The policy checks the minimum number of organizations in N1 that must endorse the access request by determining whether F evaluates to true. Hence, the request is checked for the necessary endorsements as stipulated by N2 ’s access control policy by verifying Eval (Expr(P), ψN1 )). Similar to N1 , an ACL is defined in N2 to manage permissions. After verifying the source and legitimacy, the attributes mentioned in the external request are assessed against N2 ’s ACL, which incorporates ABAC [22]. This entire verification process is performed at the smart-contract level by validating the endorsements and cross-checking the corresponding ACL rules. It evaluates the identifier attributes, resource category, and type of attached endorsements. E. Encrypting and Routing Access Response Apart from sending the access response, encrypting the response to maintain its confidentiality is also critical. When an access request is initiated, a temporary encryption key is generated by the requester. The responding consortium uses this key to encrypt the response payload. Thus, even when the response reaches the requesting network, participants other than the original requester cannot decrypt it. For multilateral access requests involving multiple requesters, we employ Threshold Encryption [28]. Threshold encryption is a cryptographic technique in which a secret key is divided into multiple shares and distributed among several parties such that only a predefined subset (threshold) of them can collaboratively reconstruct the decryption key. In our framework, this ensures that no single requester can decrypt the access response independently; the data can only be revealed when a sufficient number of authorized requesters jointly participate in the decryption process, thereby preserving confidentiality and enforcing joint custodianship of the shared resource. An encryption key is generated and attached to the request payload, while the shares of the decryption key are distributed across all the requesters. Depending on the consortium policy, at least t out of n requesters need to cooperate to decrypt the response. Before consortium N1 sends the payload along

4

with the encryption keys to N2 , it is encrypted using N2 ’s public key. This ensures secure transmission of data across consortium boundaries, as we formally prove next. IV. S ECURITY A NALYSIS In addition, InterAcct prevents three major categories of attacks: defending insider threats, preventing carry-forward of internal information, and guarding against sniffing attacks. We further analyze how InterAcct mitigates these threats below. A. Defending Insider Threat In InterAcct every access request R is subject to a multistage access control process. The intra-organization ACL blocks unauthorized requests that have not been validated and endorsed by the directorOij of the organization Oij . Consortium ACL ensures that no access request from consortium N1 can be transmitted to a foreign consortium N2 unless it carries the requisite consortium-level endorsements, thereby preventing bypass of consortium approval. Finally, the crossconsortium ACL ensures that access requests failing to comply with agreed cross-chain access norms are also rejected. In the following we prove InterAcct successfully deters insiders threats. Proof: Assume that an insider participant in consortium N1 attempts to gain access to data/resources of N2 without valid authorization. Case 1: An actor Ejk ∈ O1j of N1 tries to send a direct request R to N2 without the director’s endorsement. The Intra-Org ACL(R) requires that ψdirectorOij (R) be attached. Since this endorsement is absent, the request is rejected locally in N1 . This contradicts the assumption that the actor can bypass intra-organization ACL and succeed to gain external access. Case 2: Suppose the director of an organization within N1 does not obey consortium level endorsement norms and maliciously attempts to invoke R directly towards consortium N2 . The ConsortiumACLValidation(R) (refer Algorithm 1) requires that signatures from the required organizations in N1 to be present. Since the necessary collective endorsements are missing, the request is rejected at the consortium boundary. This contradicts the assumption. Hence, InterAcct prevents unauthorized access attempts of malicious insiders. B. Preventing Carry-forward of Internal Information If confidential internal metadata of the source consortium is exposed in inter-consortium data exchange, malicious participants could reverse-engineer these. InterAcct defends against this by stripping internal metadata Rϵ from each access request, transforming it into R = R − Rϵ before transmission(refer to Sec.III-B). C. Guarding against Sniffing Attack In InterAcct, all cross-consortium responses are encrypted using the temporary key or key shares generated at request

time. Thus, even if data is tried to be intercepted, it cannot be accessed by unauthorized organizations (refer to Sec.III-E). Proof: Consider a malicious outsider tries to sniff the network for retrieving access-request and/or access-response details between two interoperating permissioned networks N1 and N2 . Case 1: Assume that the adversary intercepts an encrypted access response and retrieves the response payload for a unilateral access request transmitted from N2 to N1 . In InterAcct, each unilateral access response is encrypted using the requester’s temporary private key, which is not transmitted or exposed over the network and remains solely under the custody of the requester. Since this private key is not shared or included in the ciphertext, successful retrieval by the adversary would contradict the assumed security of the publickey cryptographic principles. Therefore, the adversary cannot retrieve or reconstruct the actual response content from the intercepted ciphertext. Case 2: Assume that the adversary successfully extracts plain-text from an encrypted access response for a multilateral access request transmitted from N2 to N1 . In InterAcct, each multilateral request employs a fresh t-of-n threshold encryption scheme, where fewer than t key shares yield no useful information about the decryption key. Since the shares are distributed only among the legitimate requesters and never reused across transactions, the adversary, lacks the threshold number of key shares. Hence they cannot decrypt or fabricate a valid response transaction. Therefore, InterAcct prevents sniffing attacks by design. D. Safety and Liveness Guarantees The InterAcct architecture ensures several critical security guarantees by combining multi-faceted ACL validation, threshold encryption, secure response routing, and immutable recording of access request–response transactions on consortium blockchains. In the following, we discuss the safety and liveness guarantees that InterAcct provides for interconsortium access control. 1) Safety: In InterAcct an access request is only allowed if it passes (a) signature verification and (b) ACL validation. This validation is enforced in three phases of the interoperability flow: (i) within an organization, where the director validates the intra-organization ACL before signing a request; (ii) within a consortium, where the ConsortiumACLValidation validates endorsements ψOij (R) from the originating organization Oij for unilateral requests, and for multilateral requests (refer Tq to Algorithm 1). In multilateral requests, endorsements l=p ψOil (R) from multiple organizations (Oip , . . . , Oiq ) are scrutinized; (iii) across consortium boundaries, where Cross-consortium ACL(R) ensures that the destination consortium verifies the attributes of R. Apart from these, the encryption technique is used to secure the custody of the access responses. These rigorous validations collectively preserve safety against unauthorized access and malicious faults. We further elaborate on the individual safety properties: • Confidentiality: Both the request payload, as well as the response data/asset are encrypted to ensure confidentiality. For multilateral requests from more than

5

one stakeholder, the decryption key is split into shares using threshold cryptography (refer to Section III-E). The access response is encrypted so that only the originator can possess the response. Routing of encrypted access response and internal metadata filtering (refer to Section III-B) collectively ensure that any sensitive information remains confidential. • Integrity: Integrity is maintained by digital signatures at every stage of the workflow, from actors within an organization, to directors, to the responding consortium. Access requests and responses, along with endorsements, are committed as Tacc req and Tacc resp in the ledgers LN1 and LN2 (refer to Section III-B). These records are stored immutably, making them tamper-proof. • Authenticity: Each request R is signed by the requester and the designated endorsers. The ConsortiumACLValidation sub-routine (refer to Algorithm 1 in Section III-A) ensures that only legitimate participants can originate access requests. • Non-repudiation: Once transactions Tacc req and Tacc resp are recorded on the ledgers with attached endorsements (refer to Section III-B), neither consortium can deny their involvement. Immutable storage of endorsements and responses ensures that all participants remain accountable. 2) Liveness: Liveness denotes the system’s ability to make continual progress despite faults or delays. In InterAcct, this property is preserved through timeout-based validation and the underlying consensus of permissioned blockchains. Transaction Handling: Failures or unreasonable delays in completing an access request-response are handled by stipulated time limits, ensuring that the system continues without indefinite blocking. If they do not reach beyond the limit, they are marked as invalid. • Consensus Progress: The liveness of request and response execution depends on the consensus underlying blockchain platform (e.g., Hyperledger Fabric). As long as a majority of peers remain honest and active, consensus guarantees that valid transactions Tacc req and Tacc resp are eventually committed. •

Collectively, these validation mechanisms ensure that InterAcct maintains safety while guaranteeing liveness so that legitimate access requests are eventually processed and responded to. V. I MPLEMENTATION D ETAILS We have implemented InterAcct using Hyperledger Fabric as the permissioned blockchain network and used Hyperledger Cacti [15] for data interoperation. The Hyperledger Cacti [15] based interoperability framework enables cross-chain communication of access request-response via relays, drivers, and interoperability chaincode in the data interoperability layer. We have registered and enrolled the roles for different employees and directors of the organizations, and the associated attributes at the CA certificate level using native Hyperledger Fabric ABAC offering [32]. The core components of InterAcct are detailed below.

Access Request Formation: The process begins with a participant from a consortium generating a cross-chain access request. The private and public keys of the request generator are stored in .pem files, and the signing is performed using the Elliptic Curve Digital Signature Algorithm (ECDSA) [33] with SHA-256 [34] hashing. To enforce the rules governing request submission, an Access Control List (ACL) is created and maintained by ManageAccessContol chaincode. The participant’s request generation is handled through our SubmitAccessRequest chaincode. The intra-organization endorsements of the request is verified by the verifySignature function within the chaincode. ACL verification by consortiumACLValidation subroutine verifies whether the request has been authenticated by the participant and includes the necessary co-signature reference details. Saving and Filtering Access Request: A unique request ID is generated for each access request by a participant of N1 , and the request details are recorded as a transaction in the ledger of N1 , after satisfying the endorsement policy of N1 . The majority endorsement rule is applied at the chaincode level, requiring approval from more than two-thirds of the participants of N1 before the access request transaction can be committed to the ledger. Once committed, the request is stored in a private data collection (PDC) [35] repository. PDC stores sensitive data privately among the authorized parties while maintaining a hash of the data on the ledger for integrity verification. We deploy saveRequestPDC subroutine to privately save the request based on our permission configuration setup defined in MaintainCollectionConfig config file. The repository stores the following information: requester name, request ID, peer/node ID, organization ID, object requested, etc. Next, personal information, such as the requester’s organization ID, internal role, peer ID, etc. is filtered out from the original access request to prevent potential bias from the responder consortium, N2 . Consortium-level tagging is appended to the request. The interoperability framework [15] is then invoked to transfer the request to N2 . Receiving Incoming Access Request: We utilize Cacti [15] based interoperability framework on both networks N1 and N2 . The interoperability service routine is enabled for both outward and inward data/asset transfer through the relay mechanism. The interoperable relay, serving as an intermediary service, invokes the gRPC1 based lightweight message exchange protocol to transmit the access response payload from N2 to N1 . Upon receipt of the incoming access request, N2 extracts the relevant attributes including source network ID, destination network ID, request ID, endorsement details, the object requested, etc., using extractAccessReuest service of our ManageInteropRequest chaincode. These attributes are subjected to verification against the cross-consortium access control policies of N2 . We ensure these validations using checkAccessResponder subroutine. If the request meets the necessary conditions and is approved, the requested resource is retrieved and the access response transaction is marked as complete. Transfer of Inter-Chain Access Response: After the 1 https://grpc.io/ (Accessed: October 6, 2026)

6

Fig. 3: Signature Generation and Verification

Fig. 4: Access Policy Evaluation response is created by the participant in the responding consortium, we create response transaction and record in N2 ’s ledger. Next, we invoke interoperability chaincode to send the response from N2 to N1 . Upon receipt of the access response, N1 processes and verifies the authenticity of received data. Based on the originating request ID, the original request details are fetched from the request store, and a chaincodebased event is invoked to notify the originating party. The originating requester obtains the access response, and the response transaction is marked as complete. VI. E XPERIMENTAL R ESULTS To evaluate InterAcct, we have experimented extensively with two Hyperledger Fabric test networks. The testbed is set up using four physical machines with Intel i5-4570 CPU, 8 GB RAM, and 64-bit Ubuntu 20.04 LTS environment, connected through Docker Swarm [36] based overlay networks. Signature Generation and Verification: As depicted. Fig. 3 represents the average time taken to generate the attestation signature accompanying the access request. We test this with a varying set of signature generation requests in terms of director signature, joint-organization-level signatures, etc. The signature generation time remains consistently low at approximately 2 milliseconds for up to 100 users. Beyond this point, an increase is observed, with the time reaching up to 4 milliseconds by around 160 users, after which it again stabilizes. Fig. 3 also presents the signature verification latency trend with respect to increasing user load. It is observed that the graph stabilizes at 3 milliseconds from 140 users onward

Fig. 5: Request Filtering

Fig. 6: Ledger Save Time

and remains steady. Both signature generation and verification are efficient. Even under a load of 200 users, the maximum observed overhead is only 4 milliseconds, and does not contain any significant fluctuations. Access Policy Evaluation: InterAcct employs access policy validation at three levels: intra-organization, consortium, and cross-consortium. Fetching the ACL and validating it against each access request is a critical step for enforcing interoperation governance. We evaluated the average policy evaluation time at both the source (requester) consortium and the destination (responder) consortium, as shown in Fig. 4. The results show that requester-side evaluation grows only moderately, from about 67 milliseconds at 10 users to 80 milliseconds at 100 users. On the responder side, validation remains nearly constant between 74 milliseconds and 80 milliseconds across the same load range. Consequently, the combined evaluation time increases slightly from around 141 milliseconds to 156 milliseconds as user concurrency increases. These results demonstrate that the validation function P performs steadily, adding only marginal overhead even under higher loads. Request Filtering: Fig. 5 illustrates the time required for filtering access requests to remove internal role details. We have tested with a growing number of users (from 10 to 100) and noticed that the filtering time completes under 0.2 seconds. This demonstrates that filtering introduces no performance bottleneck and completes with minimal latency. To evaluate the ledger commit performance for access requests in Hyperledger Fabric, we analyze how varying payload sizes impact the save time across different user counts, as

7

Fig. 7: Unauthorized Access Validation

illustrated in Fig. 6. The results demonstrate that as the payload size increases from 50 KB to 500 KB, the ledger save time follows linear trend. Unauthorized Access Validation: We also assess the impact of unauthorized access based on InterAcct under high load to verify the effectiveness of access policy validation against invalid or malicious requests, as depicted in Fig. 7. It is observed that, with the increase in user load from 10 to 100 users, all the invalid access requests are handled by the access policy validation without any erroneous access granting. We noticed that the average ACL policy validation time increases under load, following a gradual linear increase in policy evaluation response time due to concurrent validation requests. VII. C ONCLUSION AND F UTURE D IRECTIONS We have presented InterAcct, a decentralized and secure cross-network access control framework for permissioned blockchain interoperation. The proposed solution introduces a novel attribute-centric access control mechanism that enforces fine-grained authorization across consortium boundaries, while enabling encrypted and verifiable transfer of access responses between networks. InterAcct ensures end-to-end data integrity and privacy by combining data filtering, encryption, and multi-level endorsements with cryptographic attestations. In future work, we aim to extend the framework with real-time monitoring and auditing capabilities to facilitate continuous oversight of access requests, approvals, and resource sharing across interconnected consortium networks. R EFERENCES [1] A. J. Akbarfam, M. Heidaripour, H. Maleki, G. Dorai, and G. Agrawal, “ForensiBlock: A provenance-driven blockchain framework for data forensics and auditability,” in In Proceedings of the IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS-ISA). IEEE, 2023, pp. 136–145. [2] P. Samarati and S. C. d. Vimercati, “Access control: Policies, models, and mechanisms,” in International School on Foundations of Security Analysis and Design. Springer, 2000, pp. 137–196. [3] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Rolebased access control models,” Computer, vol. 29, no. 2, pp. 38–47, 1996. [4] G. Zhang and J. Tian, “An extended role based access control model for the internet of things,” in Proceedings of the IEEE International conference on Information, Networking and Automation (ICINA), vol. 1. IEEE, 2010, pp. 319–323.

[5] N. Wu, L. Xu, and L. Zhu, “A blockchain based access control scheme with hidden policy and attribute,” Future Generation Computer Systems, vol. 141, pp. 186–196, 2023. [6] T. Sengupta, B. C. Ghosh, S. Chakraborty, and S. Sural, “InterAcct: Access control for permissioned blockchain interoperation,” in 2025 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE, 2025, pp. 1–5. [7] M. Herlihy, “Atomic cross-chain swaps,” in Proceedings of the ACM symposium on principles of distributed computing. ACM, 2019, pp. 1317–1326. [8] K. Ren, N.-M. Ho, D. Loghin, T.-T. Nguyen, B. C. Ooi, Q.-T. Ta, and F. Zhu, “Interoperability in blockchain: A survey,” IEEE Transactions on Knowledge and Data Engineering, vol. 35, no. 12, pp. 12 750–12 769, 2023. [9] T. Han, J. Mao, S. Xie, Q. Gao, Q. Wang, P. Zhang, and Y. Fang, “VMStudio: A universal crosschain smart contract verification and execution scheme,” Security and Communication Networks, vol. 2023, no. 1, p. 2413532, 2023. [10] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille, “Enabling blockchain innovations with pegged sidechains,” opensciencereview, vol. 72, pp. 201–224, 2014. [11] H. Jin, X. Dai, and J. Xiao, “Towards a novel architecture for enabling interoperability amongst multiple blockchains,” in Proceedings of the IEEE International Conference on Distributed Computing Systems (ICDCS). IEEE, 2018, pp. 1203–1211. [12] J. Kwon and E. Buchman, “Cosmos whitepaper,” A Network of Distributed Ledgers, vol. 27, 2019. [13] G. Wood, “Polkadot: Vision for a heterogenous multi-chain framework,” URL: https://polkadot. network/PolkaDotPaper.pdf, 2016. [14] E. J. Scheid, P. Kiechl, M. Franco, B. Rodrigues, C. Killer, and B. Stiller, “Security and standardization of a notary-based blockchain interoperability api,” in In Proceedings of the IEEE International Conference on Blockchain Computing and Applications (BCCA). IEEE, 2021, pp. 42–48. [15] ”Hyperledger-Community”, “Hyperledger-cacti,” Hyperledger-Cacti, 2024, accessed: October 6, 2026. [Online]. Available: https://github.com/hyperledger/cacti/ [16] R. Belchior, L. Torres, J. Pfannschmidt, A. Vasconcelos, and M. Correia, “BUNGEE: Dependable blockchain views for interoperability,” Distributed Ledger Technologies: Research and Practice, vol. 3, no. 1, pp. 1–25, 2024. [17] A. Margheri, M. Masi, A. Miladi, V. Sassone, and J. Rosenzweig, “Decentralised provenance for healthcare data,” International Journal of Medical Informatics, vol. 141, p. 104197, 2020. [18] R. Han, J. Xiao, X. Dai, S. Zhang, Y. Sun, B. Li, and H. Jin, “Vassago: Efficient and authenticated provenance query on multiple blockchains,” in 2021 40th International Symposium on Reliable Distributed Systems (SRDS). IEEE, 2021, pp. 132–142. [19] B. Pan, N. Stakhanova, and S. Ray, “Data provenance in security and privacy,” ACM Computing Surveys, vol. 55, no. 14s, pp. 1–35, 2023. [20] A. Augusto, R. Belchior, A. Vasconcelos, M. Correia, and T. Hardjono, “Multi-party cross-chain asset transfers,” in In Proceedings of the IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE, 2024, pp. 259–263. [21] T. Sengupta, S. Chakraborty, and S. Sural, “Cross-chain transfer of snapshot archives for low-overhead peer management in web 3.0,” in Proceedings of the IEEE International Conference On Web Services WIP Paper. IEEE, 2023, pp. 710–712. [22] E. Yuan and J. Tong, “Attributed based access control (abac) for web services,” in Proceedings of the IEEE International Conference on Web Services (ICWS). IEEE, 2005. [23] V. C. Hu, D. Ferraiolo, R. Kuhn, A. R. Friedman, A. J. Lang, M. M. Cogdell, A. Schnitzer, K. Sandlin, R. Miller, K. Scarfone et al., “Guide to attribute based access control (abac) definition and considerations (draft),” NIST special publication, vol. 800, no. 162, pp. 1–54, 2013. [24] S. Rouhani, R. Belchior, R. S. Cruz, and R. Deters, “Distributed attribute-based access control system using permissioned blockchain,” World Wide Web, pp. 1–28, 2021. [25] H. Saidi, N. Labraoui, A. A. A. Ari, L. A. Maglaras, and J. H. M. Emati, “DSMAC: Privacy-aware decentralized self-management of data access control based on blockchain for health data”,” IEEE Access, vol. 10, pp. 101 011–101 028, 2022. [26] R. Belchior, B. Putz, G. Pernul, M. Correia, A. Vasconcelos, and S. Guerreiro, “Ssibac: self-sovereign identity based access control,” in Proceedings of the IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, 2020, pp. 1935–1943.

8

[27] C. H.-J. Braun, V. Papanchev, and T. Käfer, “SISSI: An architecture for semantic interoperable self-sovereign identity-based access control on the web,” in Proceedings of the ACM Web Conference, 2023, pp. 3011–3021. [28] H. Si, W. Li, N. Su, T. Li, Y. Li, C. Zhang, B. Fernando, and C. Sun, “A cross-chain access control mechanism based on blockchain and the threshold paillier cryptosystem,” Computer Communications, vol. 223, pp. 68–80, 2024. [29] K. Gai, Y. She, L. Zhu, K.-K. R. Choo, and Z. Wan, “A blockchain-based access control scheme for zero trust cross-organizational data sharing,” ACM Transactions on Internet Technology, vol. 23, no. 3, pp. 1–25, 2023. [30] E. Abebe, D. Behl, C. Govindarajan, Y. Hu, D. Karunamoorthy, P. Novotny, V. Pandit, V. Ramakrishna, and C. Vecchiola, “Enabling enterprise blockchain interoperability with trusted data transfer (industry track),” in Proceedings of the International middleware conference industrial track. ACM, 2019, pp. 29–35. [31] Hyperledger Cacti Community, “Cryptographic proofs in ledger interoperability,” Hyperledger, 2023, accessed: October 6, 2026. [Online]. Available: https://github.com/hyperledger-cacti/cacti/blob/ main/weaver/rfcs/models/ledger/cryptographic-proofs.md [32] H. F. Community”, “HLF ABAC,” Hyperledger, 2024, accessed: October 6, 2026. [Online]. Available: https://hyperledger-fabric-ca. readthedocs.io/en/latest/users-guide.html#attribute-based-access-control [33] D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digital signature algorithm,” Certicom Whitepaper, http://www. certicom. com, 1999. [34] NIST, “Secure-hash-algorithm (sha),” SHA, 2015, accessed: October 6, 2026. [Online]. Available: https://csrc.nist.gov/projects/hash-functions [35] H. F. Community”, “HLF PDC,” Hyperledger, 2024, accessed: October 6, 2026. [Online]. Available: https://hyperledger-fabric.readthedocs.io/ en/latest/private-data/private-data.html [36] Docker, “Docker-swarm,” ”https://docs.docker.com/engine/swarm/, 2024.

Related documents

• Cross-chain Access Control for Permissioned Blockchain Interoperation#1201067
• Simulation-Based Performance Evaluation of Sharded Blockchain Architectures#271776
• Blockchain Enterprise Ontologies: TOVE and DEMO#79707
• Extending Binary Byzantine Agreement to Multivalued Byzantine Agreement#464644
• BlockEmulator: An Emulator Enabling to Test Blockchain Sharding Protocols#1013368