A Blockchain-Enabled Decentralized Autonomous Access Control Scheme for Data Sharing

Abstract

With the rapid development of artificial intelligence, multi-party collaboration based on data sharing has become an inevitable trend. However, in practical applications, shared data often originate from multiple providers. Therefore, achieving secure and efficient data sharing while protecting the rights and interests of each data provider is a key challenge currently faced. Existing access control methods have the following shortcomings in multi-owner data scenarios. Most methods rely on centralized management, which makes it difficult to solve conflicts caused by inconsistent permission policies among multiple owners. There are problems such as poor consistency of permission management, low security, and lack of protection for the autonomous will of each owner. To this end, our paper proposes a fine-grained decentralized autonomous access control scheme based on blockchain, which includes three core stages: formulation, deployment, and execution of access control policies. In the access control policy formulation stage, the scheme constructs a multi-owner data policy matrix and introduces a benefit function based on a Stackelberg game to balance conflicting attributes to form a unified access policy. Secondly, in the access control policy deployment stage based on smart contracts, all data owners vote on the access control policy by calculating their own benefits to achieve a consensus on joint decision-making on the policy. Finally, in the policy execution and joint authorization phase, a decentralized authorization method based on threshold passwords is used to distribute access keys to each owner, ensuring that data is only granted after receiving authorization from a sufficient number of owners, thereby ensuring the ultimate control of each owner and the fine-grained access control. Finally, we verified the feasibility of the solution through case analysis and experiments.

1. Introduction

The rapid advancement in information technology and networking has catalyzed explosive growth in data generation. The extensive adoption of cloud computing and big data technologies further enhances data sharing capabilities [1,2]. In practical applications, these shared data are typically generated not by a single entity but through collaboration among multiple participants. To fully harness the potential of such data, it is typically necessary to aggregate, share, and circulate data from multiple participating entities. The aggregated data is referred to as multi-owner data, and in this paper the users who contribute the data are called data owners. However, data is often processed and managed by third-party institutions, making it difficult to protect the rights and interests of each contributor in multi-owner data. This results in a low willingness among data owners to contribute data, thereby increasing the difficulty of data aggregation and sharing.

Access control constitutes a vital mechanism for securing data. By setting the access control policy, the authorizer can limit the access ability and scope of the requester and control its access behavior and operation. Access control mainly includes mandatory access control, discretionary access control, role-based access control, and attribute-based access control [3,4,5]. Mandatory access control (MAC) determines access rights based on predefined security policies and data security levels. In this model, the access control policy is enforced by the system, which has the merit of high security, but the user or data owner change the permissions, leading to a lack of flexibility [6]. In discretionary access control (DAC), the owner of a resource or data typically sets an access control list; this list determines which users are allowed to access the owner’s resources. The advantage is that the power of the resource owner is fully considered, but because each resource owner can set permissions independently, it may lead to confusion and inconsistency in rights management, which in turn leads to security risks. In addition, in complex scenarios, especially in distributed scenarios such as multi-node collaboration, it is difficult for DAC to provide sufficient flexibility and fine-grained access control [7]. Role-based access control (RBAC) assigns roles to users, each of which has a predefined set of permissions. Its merits are that it is simple and easy to manage, but the shortcomings are poor flexibility and low security [8]. Attribute-based access control (ABAC) is a dynamic fine-grained access control scheme that determines whether users are allowed to access by defining access policies for multiple attributes such as users, environment, and resources. It has the merits of high flexibility, good dynamics, and fine-grained access control. It is the most commonly used method in recent years, especially in centralized access control environments such as cloud computing. However, ABAC is difficult to apply in distributed environments, particularly when multiple data owners define conflicting access control policies [9].

In addition to the mainstream access control methods mentioned above, there are also dynamic access control methods based on risk or trust evaluation [10,11], which are typically tailored to specific application requirements. Such methods have strong dynamic adaptability but poor versatility. Therefore, they are not as widely used as the above four access control methods (DAC, MAC, RBAC, and ABAC) [12].

With the increasing demand for multi-party collaboration, research on access control methods such as multi-node and multi-source data sharing is still insufficient. Regarding how to protect the access control rights of each data contributor and ensure the consistency and security of access control management, there is still a lack of effective solutions.

To address the above challenges, this paper proposes a decentralized autonomous access control scheme based on blockchain. The scheme effectively integrates the advantages of both DAC and ABAC, ensuring that the access control rights of all data owners from multiple sources are protected. At the same time, it enables consistency in access permissions for multi-owner data, supports fine-grained access control, and enhances the security of traditional DAC mechanisms.

The main contributions of our paper are as follows:

• We construct a decentralized autonomous access control model based on blockchain. This model includes three stages: policy formulation, policy voting, and policy execution. It allows multiple resource owners to define attribute-based access control policies according to their own needs. This enables the joint formulation, execution, and authorization of decentralized policies, effectively addressing the security shortcomings of traditional centralized access control.
• Aiming at the special needs of multi-owner access control scenarios, an access control policy formulation method that balances conflicting attributes is designed. First, this method constructs a policy matrix for multi-owner access control attributes. Then, based on the owners’ preferences and mutual influence regarding the conflicting attributes, a benefit function is introduced to balance these conflicts. Thus, a fine-grained access control policy that takes into account multi-owner data requirements is obtained.
• An access control policy consensus method based on a Stackelberg game is proposed. This method constructs a leader and follower model for the access control policy after attribute conflict balance, in which the followers make voting decisions according to their own calculated benefits. When the benefits exceed the set threshold, they vote for it. Through the majority voting mechanism, the consistency of multi-owner data access control policy management is realized.
• We design a decentralized joint authorization mechanism based on blockchain and threshold cryptography. Each data owner provides an access control decryption key share according to the results of attribute-based access control smart contract running locally. On the basis of guaranteeing the owner’s autonomous access control right, the security of autonomous access control is further enhanced.

2. Related Work

As the cornerstone of information security, access control guarantees the use of system resources within the scope of authorization through a permission constraint mechanism. In the traditional model, discretionary access control and mandatory access control constitute two basic models, which adapt to different security requirements scenarios. Discretionary access control realizes object access restriction based on subject identity recognition, and its core mechanism is derived from the access matrix model of a time-sharing system [13]. Typical implementations, such as the UNIX 9-bit permission model and ACL-based control tables, enable flexible management through owner-defined authorizations. However, DAC has the inherent defects of decentralized management: the user can arbitrarily pass permissions, resulting in permission diffusion (such as sending sensitive files by mail) and a lack of a unified security baseline. This limitation gives rise to a more stringent access control paradigm—mandatory access control. Aiming at the risk of privilege abuse of DAC, mandatory access control achieves rigid constraints through system-level security attribute binding. MAC adopts the dynamic matching mechanism between the subject security label and the object security label and strictly follows the confidentiality rules of ‘no reading, no writing’. With the complexity of application scenarios, the MAC model continues to evolve into a multi-dimensional expansion. Ray et al. [14] proposed a location-enhanced MAC architecture, which associates the location with the security level and controls the disclosure of the location information of the subject and the object to ensure that only people with appropriate security permissions can enter a specific location and prevent illegal information flow. On this basis, McCune et al. [15] focused on the security requirements of a distributed computing environment, integrated virtualization technology and trusted computing technology, and used a virtual machine monitor and MAC virtual machine to control communication, combined with a secure MAC tag tunnel and remote attestation technology, to ensure that cross-machine communication and resource sharing conform to MAC policy so as to realize mandatory access control in a distributed environment. At the same time, in view of the security challenges of mobile intelligent terminals, Bugiel et al. [16] proposed a hierarchical reinforcement policy. On the basis of inheriting the mandatory access control of the SE Android kernel layer, the type enforcement mechanism of the middleware layer is designed, and the type enforcement mechanism is extended in the middleware layer. With context-aware dynamic policy switching, a fine-grained access control system covering Android dual software layers is constructed.

However, most existing access control policies are formulated for individual entities and fail to account for the heterogeneous requirements of different data owners in multi-owner scenarios. For example, Ghafoorian et al. [17] proposed a new RBAC model based on trust and reputation in their research, which aims to effectively solve the security threats related to the trust-based RBAC model and provide scalability within a reasonable execution time. By analyzing the distributed data distribution service (DDS) security model and determining the integration point of attribute-based access control (ABAC), Kim et al. [18] proposed a new method to improve the authorization of the DDS security model by using ABAC. The ABAC entity is merged into the security model, which can control the access in DDS more flexibly according to the entity attributes and behaviors. Wei et al. [19] proposed an open, trusted, and decentralized access control mechanism based on ABE to address the challenge of privilege management in software-defined networks. The mechanism supports effective authorization of applications in heterogeneous and untrusted domains and records all interactions between applications and resources for further billing, analysis, and auditing. Ding et al. [3] used sharding technology to distribute the attribute management and access control processes on multiple shards based on the access control system of the sharded blockchain, which greatly improved system efficiency and security. However, the access policies of the above schemes are formulated by a single party, and how to protect the rights of all parties participating in access control in the case of multi-party cooperation is not considered.

Aiming at the access control problem under multi-party collaboration, P. Ilia et al. [20] designed a collaborative multi-party access control model based on the social relationship of users, allowing all relevant users to participate in the formulation of access control policies and setting trusted friends to be responsible for the implementation of policies. S.V. et al. [21] proposed an improved multi-party access control mechanism, which can include user groups or multiple users participating in the formulation of sharing policies, in which access rights can also be granted to multiple users. The hybrid filtering mechanism only recommends the corresponding content of the sharing policy to the user, thereby enhancing the security of the data. Miao et al. [22] designed a keyword search scheme based on CP-ABE technology, in which data is jointly managed by multiple data owners, and a user can only retrieve data by obtaining the authorization key of all data owners. In order to ensure the sustainability of multi-user-centric access control in the cloud environment, Davy et al. [23] proposed a policy-based multi-party access control solution, which delegates access control decisions to multiple stakeholders in cloud and edge microservices to ensure dynamic fine-grained access control. Hongxin et al. [24] proposed a method to identify privacy conflicts in multi-user data sharing so that multiple owners of data can trade off between privacy protection and data sharing by quantifying the degree of sharing, so as to support data owners’ privacy control in online social networks (OSNs). The aforementioned schemes address specific problems but suffer from limited generalizability and rely on centralized architectures, making them unsuitable for distributed collaboration environments.

Blockchain has the characteristics of decentralization, transparency, and non-tampering. Integrating blockchain with access control reduces reliance on third-party authorities and ensures the immutability of access policies and logs [25]. In addition, smart contracts can be used to realize the automatic and strict implementation of access control policies in the chain [26]. At present, researchers have proposed to use blockchain to implement access control [27,28,29] to ensure data security sharing in cloud computing, big data, and other scenarios. For example, Liu et al. [30] proposed a privacy protection scheme based on CP-ABE. The scheme stores ciphertext in the cloud, indexes on the consortium chain, and keyword searches on the chain to ensure the accuracy of the search results. Pournaghi et al. [31] focused on the privacy and security issues of electronic medical record (EMR) data and proposed a secure on-chain medical data sharing solution with the help of private blockchain and attribute-based encryption to ensure the privacy protection of patient data and support fine-grained access control. In addition, there is also some work on smart contracts in the blockchain to achieve the correct automatic execution of access control policies in the chain. Chen et al. [32] proposed an EMR system based on consortium blockchain and proxy re-encryption. By connecting electronic devices to the blockchain network, the security of data access is ensured by the automatic execution of blockchain codes. Although the above scheme makes good use of the characteristics of blockchain decentralization to make up for the centralization problem, it does not consider the access control problem under multi-party cooperation.

To this end, our paper proposes a fine-grained autonomous access control scheme based on blockchain for the autonomous access control requirements of each collaborator for the contributed data and other resources in a distributed environment or multi-party collaboration. The scheme fully guarantees the autonomous access control power of each owner and realizes attribute-based fine-grained access control in combination with smart contracts, which solves the problems of poor consistency of authority management, lack of fine-grained control, and low security in traditional autonomous access control methods.

3. Scheme Model

The proposed scheme consists of three components: users, data providers, and the blockchain. The data resource provider is both the data owner and the blockchain node. Based on their respective data contributions, data owners are categorized into one policy leader and multiple policy followers. The followers who agree to deploy and execute the access control policy are designated as executors.

The scheme includes three stages, access control policy formulation, policy deployment voting, and policy execution and joint authorization, as shown in Figure 1. In the stage of access control policy formulation, the access control policy is proposed by each data owner, and the leader constructs a multi-owner and multi-attribute policy matrix for policy fusion calculation to obtain a unified access control policy. During the deployment phase, each data owner evaluates the proposed policy based on a calculated benefit function and participates in a collective voting process. If the vote exceeds the $4/5$ threshold, the access control policy is approved; otherwise the access control policy is abandoned and re-formulated from the first stage. The adopted access control policy will be written as a smart contract and deployed on the master node of the follower data that agrees to the policy. These followers are called executors. The leader then generates the access key K of the shared data and encrypts the shared data under the chain. K is used to generate individual key shares $K_i$, which are then distributed to each follower. In the access control policy execution and joint authorization phase, the attribute-based access control smart contract is used to ensure fine-grained access, and the threshold password is used to achieve strict and secure access control. After each executor executes the smart contract, it sends its own key share to the user, which indicates the recognition of the access. After collecting the key share that exceeds the threshold, the user can restore the access control key so as to obtain data access authority and realize the joint authorization of each data owner for resource access. In the stage of access control execution, the leader, as the leader of access control policy formulation and the generator of the access control key, does not participate in access control execution and final decision-making. All key operations during the access process are recorded on the blockchain. Owing to the transparent nature of blockchain, any malicious behavior or key leakage by the leader can be easily traced and attributed. In summary, our scheme realizes decentralized, fine-grained, and autonomous access control through active participation of all data contributors.

3.1. Fine-Grained and Autonomous Access Control Policy Formulation Under Multi-Owner Data

During the policy formulation stage, each data owner defines their access control policy based on their individual requirements and preferences. On this basis, the preliminary integration of the policy is carried out, and the conflicting policy items are deleted. Based on the Stackelberg game, the conflict resolution is completed, and the fine-grained autonomous access control policy that takes into account all the owner’s power is generated. To ensure clarity during the mathematical description, we first summarize the key symbols used throughout this section in

Table 1. Table of notations used in policy formulation.

Symbol	Description
$\mathcal{O}$	Set of all data owners $\{O_1,O_2,\dots ,O_n\}$
$M_i$	Proportion of data resources owned by data owner i
${\mathrm{stra}}_i$	Strategy vector proposed by data owner i
${\mathrm{att}}_i^j$	jth attribute value proposed by data owner i
STRA	Multi-owner data access attribute policy matrix
$b_j$	Conflicting strategy option
Conf	Set of conflicting strategy options
${\alpha }_{ij}$	Influence coefficient of owner i on strategy option $b_j$
$x_i\left(b_j\right)$	Initial preference score of owner i for conflicting strategy $b_j$
$p_j$	Final preference score for strategy $b_j$ after mutual influence fusion
${\mathrm{pay}}_i$	Payoff or income of owner i for the selected strategy

.

3.1.1. Access Policy Preliminary Fusion Method

The set of n data owners is denoted as $O_n=\{O_1,O_2,\dots ,O_n\}$. Each data owner $O_i$ first formulates a data access policy based on their individual preferences. These policies are then pairwise merged using a preliminary fusion algorithm.

First, for the n contributors of a piece of data, we divide the access control policy into m attributes, and each owner formulates an access control policy. For example, the data owner $O_i$ formulates an access policy $str{a}_i=\{at{t}_i^1,at{t}_i^2,\dots ,at{t}_i^m\}$, where $i\in (1,n)$ and if $at{t}_i^m$ is null, it means it has a null value. Finally, the access control policy set $STRA={\{str{a}_1,str{a}_2,\dots ,str{a}_n\}}^T$ is formed, and its matrix representation is shown in

Table 2. Multi-owner data access attribute policy matrix diagram.

	Attribute	1	…	m
Owner Revision.
$O_1$		$at{t}_1^1$	…	$at{t}_1^m$
⋮		⋮	⋱	⋮
$O_n$		$at{t}_n^1$	…	$at{t}_n^m$

.

The value set $At{t}_i^1$ of the j th attribute can be expressed as $At{t}^j={(at{t}_1^j,at{t}_2^j,\dots ,at{t}_n^j)}^T$, and all the attribute values in the pair are judged as follows:

• If $at{t}_i^j=at{t}_{i+1}^j$, then retain $at{t}_i^j$, $at{t}_{i+1}^j=0$;
• If $at{t}_i^j\subseteq at{t}_{i+1}^j$, then $at{t}_{i+1}^j=0$.

Perform the above operation for each column in the above access policy set matrix until the column vector fusion of all attributes is completed. Collate conflict policies to form a conflict policy set $Conf=(b_1,b_2,\dots ,b_r)$, and execute the policy generation algorithm, where $b_i$ is the i th policy and r is the number of policies that still have conflicts.

3.1.2. Policy Generation for Fine-Grained and Self-Governed Access Control Under Multi-Owner Data

In the scheme proposed in this paper, the policy leader and the policy follower are the two entities participating in the game. The policy conflict game models a sequential strategic interaction, where both the policy leader and followers iteratively adjust their preferences based on mutual influence and expected payoffs. In the process of the game, both sides show rational behavior, which is described by the income function, and the optimal policy is determined by multiple rounds of the game.

As shown in

Table 3. Schematic diagram of conflict policy preference value.

	Policy Policy	$b_1$	…	$b_r$
Owner Conflict
$O_1$		$x_1\left(b_1\right)$	…	$x_1\left(b_r\right)$
⋮		⋮	⋱	⋮
$O_n$		$x_n\left(b_1\right)$	…	$x_n\left(b_r\right)$

, $x_{le}\left(b_j\right),x_{fe}\left(b_j\right)$ are the initial preference values of the policy leader and the policy follower set for the conflict policy $b_i$, respectively, where the preference values can be divided into high, medium, and low according to their values. Using the preference value matrix, policy leaders and followers engage in conflict resolution games to determine mutually acceptable policies; $p_{le}\left(b_j\right),p_{fe}\left(b_j\right)$ are the preference values of policy leaders and policy followers for modifying the conflict policy after considering each other’s decision-making. $x_i\left(b_j\right)p_i\left(b_j\right)$ is the direct benefit of the choice of conflict policy; $-{\displaystyle \frac{1}{2}}{\left(p_i\left(b_j\right)\right)}^2+{\alpha }_{ij}{p}_i\left(b_j\right)x_j\left(b_j\right)$ refers to the income generated by the choice made by the game party under the influence of other game parties in the process of Stackelberg’s strategic game. ${\alpha }_{ij}$ is the influence coefficient of user i by j. In this scheme, the influence coefficient is determined by the data share of the game party.

Let $M_i$ denote the amount of information contributed by data owner $O_i$, which is used to compute the influence coefficients ${\alpha }_{ij}$ in the income functions. First, we determine the roles of leader and follower in the conflict policy fusion process based on the value of $M_i$ for each owner. Then, the influence coefficient between data owners is calculated based on their respective shares of information, as shown in Equation (1). Specifically, the influence coefficient ${\alpha }_{ij}$, indicating the influence of owner $O_j$ on owner $O_i$, is computed as follows:

$${\alpha }_{ij}={\displaystyle \frac{M_i}{{\sum }_{i=1}^h{M}_i}}$$

(1)

The value of ${\alpha }_{ij}$ falls within the range [0,1].

For the conflict resolution set $Conf=(b_1,b_2,\dots ,b_r)$, the policy leader and follower initially determine their preference values for the conflicting policies. Then, for each conflicting attribute $l\in (1,\dots ,r)$, a conflict matrix $b^l={(b_1^l\dots b_r^l)}^T$ is constructed. Let $At{t}_m^l$ denote the lth conflict attribute and let $x_t\left(b_i^l\right)$ represent data owner $O_i$’s preference evaluation score for attribute $b_i$, where $t\in n$. Then, the income function of the policy leader for the conflicting attribute $b_i$ can be expressed as follows:

$$pa{y}_{le}=x_{le}\left(b_i\right)p_{le}\left(b_i\right)-{\displaystyle \frac{1}{2}}{\left(p_{le}\left(b_i\right)\right)}^2+\sum _{f\ne 1}{\alpha }_{lefe}{p}_{le}\left(b_i\right)p_{fe}\left(b_i\right)$$

(2)

The policy follower set fe adjusts its own preference scores for the conflicting policy $b_i$ based on the leader’s willingness value $p_{le}\left(b_i\right)$. The income function for the follower with respect to the conflicting attribute $b_i$ can be expressed as follows:

$$pa{y}_{fe}=x_{fe}\left(b_i\right)p_{fe}\left(b_i\right)-{\displaystyle \frac{1}{2}}{\left(p_{fe}\left(b_i\right)\right)}^2+{\alpha }_{fele}{p}_{fe}\left(b_i\right)p_{le}\left(b_i\right)$$

(3)

The objective of both the policy leader and the policy follower in the conflict resolution game is to maximize their respective income functions. This requires computing the partial derivative of the follower’s income function with respect to its preference score and setting the derivative to zero. By solving this condition, the optimal preference score of the follower—under the influence of the leader—can be derived. This yields the follower’s best reaction function, which determines the preference score selected at the equilibrium of the game. The detailed derivation is shown in Equations (4)–(6).

The derivation of the objective function of the policy follower can be obtained:

$${\displaystyle \frac{\partial pa{y}_{fe}}{\partial p_{fe}\left(b_i\right)}}=x_{fe}\left(b_i\right)-p_{fe}\left(b_i\right)+{\alpha }_{fele}{p}_{le}\left(b_i\right)$$

(4)

Let it be equal to 0:

$$p_{fe}\left(b_i\right)=x_{fe}\left(b_i\right)+{\alpha }_{fele}{p}_{le}\left(b_i\right)$$

(5)

This represents the follower’s reaction function, indicating the condition under which the follower’s income is maximized. After substituting the follower’s reaction function into the leader’s preference payoff function, it can be seen that for the conflict attribute $b_i$, the leader’s partial praise at the maximum preference payoff is

$$p_l\left(b_i\right)={\displaystyle \frac{x_{le}\left(b_i\right)+{\sum }_{fe\ne le}{\alpha }_{fele}{x}_j\left(b_i\right)}{(1-2\left({\sum }_{fe\ne le}{\alpha }_{lefe}\right){\alpha }_{fele})}}$$

(6)

For the conflict policy of a certain attribute, the leader and the follower play a game until the policy corresponding to the maximum value of each owner’s preference score is the same, and the game ends and the conflict resolution is completed.

3.1.3. Case Analysis of Policy Fusion

In the field of scientific research data sharing, the application example of a multi-owner data self-sovereign access control scheme (MMD-SSAC) involves the sharing of team research results. It is assumed that three different research teams (Team 1, Team 2, and Team 3) participate in a project together, and they jointly generate an important scientific research data set. The policies include profession, professional title, and time, which are represented by A, B, and C, respectively. $\mathrm{A}=\{\mathrm{A}1;\mathrm{A}2;\mathrm{A}3\},$ where A1 = bioinformatics, A2 = biomedical engineering, and A3 = pharmaceutical chemistry; $\mathrm{B}=\{\mathrm{B}1;\mathrm{B}2;\mathrm{B}3\},$ where B1 = postgraduate, B2 = doctoral, and B3 = professor; and $\mathrm{C}=\{\mathrm{C}1;\mathrm{C}2\},$ where C1 = before 12:00 and C2 = before 14:00. In order to protect research results and ensure data security, each research team has developed attribute-based access policies for this data:

• Team 1: For graduate students of A1, access is granted at C1 on weekdays. Only researchers who meet the professional background of A1 and are graduate students can view and use data during this period.
• Team 2: Only those who meet (A2, B2, C1) can obtain and analyze this data.
• Team 3: For researchers majoring in medicinal chemistry, the policy is more stringent, allowing only people who meet B3 and C2 to access data.

Therefore, the access control policy sets generated by Team 1, Team 2, and Team 3 are $\mathrm{straA}=\{\mathrm{A}1,\mathrm{B}1\&\mathrm{B}2,\mathrm{C}1\}$, $\mathrm{straB}=\{\mathrm{A}2,\mathrm{B}2,\mathrm{C}1\}$, and $\mathrm{straC}=\{\mathrm{A}3,\mathrm{B}3,\mathrm{C}2\}$, respectively.

First, the access control policy sets of Team 1, Team 2, and Team 3 are preliminarily fused. For attribute A, since $\mathrm{A}1\ne \mathrm{A}2\ne \mathrm{A}3$, these three policy values conflict and are thus placed into the conflict set $At{t}_1$, denoted as $\mathrm{Att}1=\{\mathrm{A}1,\mathrm{A}2,\mathrm{A}3\}.$ For attribute B, since $B2\in B$, but $B2\ne B3$, B2 and B3 are added to the conflict set $\mathrm{Att}2=\{0,\mathrm{B}2,\mathrm{B}3\}$. For attribute C, since $C1=C1$, but $C2\subseteq C1$, the attribute values are not considered conflicting. Thus, $\mathrm{Att}3=\{0,0,0\}$, and C2 is placed into the policy set $str{a}_T=\{0,0,C2\}$.

From the above, $\mathrm{Att}1=\{C1,C2,C3\},$ $\mathrm{Att}2=\{0,B2,B3\}$, and $\mathrm{Att}3=\{0,0,0\}$ form a policy fusion set to perform the following policy conflict resolution algorithm.

We calculate the contributions of Team 1, Team 2, and Team 3 by Formula (1), which are $0.6$, $0.3$, and $0.1$, respectively. Therefore, Team 1 is the policy leader, and Team 2 and Team 3 are the policy followers. That is, the reaction of the policy followers Team 2 and Team 3 to the policy leader Team 1 is ${\alpha }_{12}=0.3$ and ${\alpha }_{13}=0.1$. The impact of policy leader Team 1 on policy followers Team 2 and Team 3 is ${\alpha }_{21}={\alpha }_{31}=0.6$.

For the conflict set $\mathrm{Att}1=\{\mathrm{A}1,\mathrm{A}2,\mathrm{A}3\}$ of attribute A, the preference scores of Team 1, Team 2, and Team 3 are set and represented as a matrix ${\mathbf{X}}_1=\left[\begin{array}{ccc}0.9& 0.2& 0.1\\ 0.5& 0.7& 0.3\\ 0.5& 0& 0.7\end{array}\right]$. That is X1 (A1) = 0.9, X1 (A2) = 0.2, X1 (A3) = 0.1; x2 (A1) = 0.5, X2 (A2) = 0.7, X2 (A3) = 0.3; x3 (A1) = 0.5, X3 (A2) = 0, and X3 (A3) = 0.7.

According to the initial preference score, the leader first adjusts their own preference score and considers the preference score of the follower under their influence in the process of adjustment. After the leader adjusts their preference score, the policy follower adjusts their preference score according to the reaction function.

According to Chapter 3, when the leader’s strategic preference for $b_i$ is divided into Equation (6), the leader’s preference gain is the largest:

P1 (A1) = 2.11, P1 (A2) = 0.79, and P1 (A3) = 0.50. Then according to the leader’s preference score, substituted into the reaction function Equation (5), we can get

P2 (A1) = 1.76, P2 (A2) = 1.17, P2 (A3) = 0.60.

P3 (A1) = 1.76, P3 (A2) = 0.47, P3 (A3) = 1.00.

At this time, under the influence of the leader, the follower makes a preference score that maximizes their preference income function according to the reaction function. Comparing the preference scores of all the owners of the policy, the maximum value is A1. Similarly, the conflict set of attribute B is calculated, and finally the value of attribute B is B2.

3.2. Access Control Policy Deployment Voting Phase

After the access control policy is formulated, the policy is sent to all followers for review. In this process, the follower will evaluate the received policy through a pre-set feedback scheme based on the revenue and give feedback on whether to agree or not. If the policy does not reach $4/5$ in the consent feedback, the leader needs to re-formulate the policy. If the policy proposed several times in a row fails to meet the standard, the resource contribution is followed, and the owner with the second resource contribution is selected to replace the current leader role, and the policy formulation process is re-established. The follower voting feedback calculation method is as follows, in which the variable parameters for calculating the income are shown in

Table 4. Parameter variable.

Parameter	Description
R	Reward for On-chain Submission
C	Cost of Privacy/Exposure Ratio
${\theta }_i$	Reward for Compliance
P	Penalty for Breach
t	Incentive Coefficient for Ensuring Information Security
$\lambda$	Risk Coefficient of Key Sharing

.

Assume that the policy follower agrees to policy Pd with a probability of ${\mathrm{S}}_{\mathrm{fe}}$ and rejects policy Pd with a probability of $1-{\mathrm{S}}_{\mathrm{fe}}$. The policy leader guarantees the safety of the policy with a probability of ${\mathrm{S}}_{\mathrm{le}}$ and fails to guarantee safety with a probability of $1-{\mathrm{S}}_{\mathrm{le}}$. When the follower agrees to Pd, they can obtain the corresponding revenue from the compliant policy, denoted as $\lambda {\theta }_a$. However, since agreeing to Pd ultimately involves sharing desensitized private data, there is a risk of privacy leakage. Meanwhile, data hiding also incurs a cost. Therefore, the final revenue is $R+\lambda {\theta }_a-C$. Similarly, the leader receives a corresponding reward $s{\theta }_b$ for ensuring the safety of the policy. If the follower refuses Pd while the leader chooses to leak the data, then both parties receive a one-time payoff of R. The payoff matrix is shown in

Table 5. Profit matrix.

	Leader	Secure	Leak
Follower
Agree		$(R+\lambda {\theta }_i,R+t{\theta }_i)$	$(R+\lambda {\theta }_i,R-P)$
Reject		$(R-P,R+t{\theta }_i)$	$(R,R)$

.

Calculate the payoff function when the policy follower agrees with the policy Pd:

$$\begin{array}{cc}\hfill E_1\left(s_{fe}\right)& =s_{le}(R+\lambda {\theta }_a-C)+(1-s_{le})(R+\lambda {\theta }_a-C)\hfill \\ & =\mathrm{R}+\lambda {\theta }_a-C\hfill \end{array}$$

(7)

Calculate the payoff function when the policy follower rejects the policy Pd:

$$\begin{array}{cc}\hfill E_2\left(s_{fe}\right)& =s_{le}(R-P)+(1-s_{le})R\hfill \\ & =\mathrm{R}-s_{le}\mathrm{P}\hfill \end{array}$$

(8)

Calculate the average revenue function:

$$\overline{E\left(s_{fe}\right)}=s_{fe}{E}_1\left(s_{fe}\right)+(1-s_{fe})E_2\left(s_{fe}\right)$$

(9)

Then the replication dynamic equation is

$$\begin{array}{cc}\hfill F\left(s_{fe}\right)& =s_{fe}(E_1\left(s_{fe}\right)-\overline{E\left(s_{fe}\right)})\hfill \\ & =s_{fe}(1-s_{fe})(\lambda {\theta }_a-C+s_{le}P)\hfill \end{array}$$

(10)

So, let $\lambda {\theta }_a-C+s_{le}P=0$; then $s_{le}={\displaystyle \frac{C-\lambda {\theta }_a}{P}}$.

When the probability that the policy leader guarantees data security is greater than or equal to ${\displaystyle \frac{C-\lambda {\theta }_a}{P}}$, the policy follower will agree to the policy. If the follower’s consent feedback to the policy reaches $4/5$, the policy is formulated, and the follower of the policy is agreed as the execution node in the fabric to deploy the attribute-based smart contract. It is important to note that when an access control policy reaches the consensus threshold in the voting process, it is applied only to the portion of data contributed by the data owners who approved the policy. For those who voted against it, their data continue to be governed by their original access control rules. This mechanism facilitates collaborative data sharing while fully preserving each data owner’s control over their own data, thereby enhancing the system’s flexibility and inclusiveness. To provide a clearer description of the policy formulation and fallback process, we formalize the procedure as Algorithm 1. This algorithm illustrates how data owners collaboratively formulate access control policies and iteratively adjust the proposals in case consensus is not reached.

Algorithm 1 Policy formulation mechanism

Require: Data owner set $\mathcal{O}=\{o_1,o_2,\dots ,o_n\}$ sorted by contribution weight; consensus threshold $\theta$; maximum retries per leader $N_{\mathrm{max\_retries}}$ Ensure: Final policy $P^{*}$ or Failure 1: Initialize PotentialLeaders $\leftarrow \mathcal{O}$ 2: while PotentialLeaders is not empty do 3:     $L\leftarrow$ PotentialLeaders.pop_front() 4:     for $i\leftarrow 1$ to $N_{\mathrm{max\_retries}}$ do 5:         Each owner proposes a policy: $\{P_1,\dots ,P_n\}$ 6:         $P_{\mathrm{draft}}\leftarrow \mathrm{FusePolicies}(L,\{P_1,\dots ,P_n\})$ 7:         Broadcast $P_{\mathrm{draft}}$ to all owners 8:         Collect votes $\{v_1,\dots ,v_n\}$ 9:         if $\mathrm{ApprovalRatio}\left(\left\{v_i\right\}\right)\ge \theta$ then 10:            return $P_{\mathrm{draft}}$ 11:         end if 12:     end for 13: end while 14: return Failure

3.3. Access Control Policy Execution and Joint Authorization Phase

We designed a blockchain-based data access joint authorization process. This process combines threshold cryptography technology to ensure that multiple data owners can jointly exercise access control power during the transfer and sharing of common data when the user U requests to access the data, so as to realize the access control of each data owner’s self-sovereignty, avoid the centralized control of data flow by a single subject, and ensure the decentralization and credibility of data sharing. The specific process is shown in Figure 2.

3.3.1. Distributed Joint Authorization Method Based on Threshold Cryptography

• In the access control policy voting phase, the agreed policy follower becomes the executor of the smart contract execution node, and the attribute-based access control smart contract is deployed to reach a consensus.
• The leader generates a symmetric key K to encrypt the shared data. Using the Shamir secret sharing scheme, the key is divided into h secret shares, with a threshold $t\ge {\displaystyle \frac{2}{3}}h$ (where h is the number of nodes that agree to execute the access control policy). These key shares $k_i$ are then distributed to the execution nodes (i.e., the data owners). Additionally, the leader’s behavior of distributing the key shares is recorded on the blockchain. In the event of key leakage, it is possible to trace whether the leaked key originated from the leader.
  The specific key distribution process is as shown in Algorithm 2. For the key K, take any random number ${\mathrm{a}}_1,\dots ,{\mathrm{a}}_{\mathrm{t}-1},$ and let ${\mathrm{a}}_0=\mathrm{key}$; construct $l\left(x\right)=a_0+a_{1}x+\dots +a_{k-1}{x}^{t-1}$.

  Algorithm 2 Creatpolynom$(t,key)$

  Input: Security threshold t, $key$     Output: t–degree polynomial $f\left(x\right)$ 1: $f\left(x\right)\leftarrow a_0$ 2: for $i=1$ to $t-1$ do 3:     $a_i\leftarrow \mathrm{getRandomNonZero}\left(\right)$ 4:     if $i=t-1$ and $a_i=0$ then 5:         repeat 6:            $a_i\leftarrow \mathrm{getRandomNonZero}\left(\right)$ 7:         until $a_i\ne 0$ 8:     end if 9:     $f\left(x\right)\leftarrow f\left(x\right)+a_i{x}^i$ 10: end for 11: return $f\left(x\right)$

• When user U sends an access request to the blockchain, the request is sent to all the data owners acting as the execution node. The execution node pre-executes the attribute-based access control policy smart contract. If the smart contract pre-runs to Yes, it will decide whether to return its key share during the execution phase. If it agrees to share the key share, the encrypted content of the key share is returned to the visitor U with its own private key signature. Otherwise it does not give its own key share. When U collects the key share after more than or equal to t (the threshold execution node signature), it can use the key reconstruction Algorithm 3 to restore the encryption key and obtain and decrypt the data. So far, the joint authorization of distributed autonomous access control has been completed. The key reconstruction process is shown in Algorithm 3.

  Algorithm 3 Reconstitution of key$(x_i,f\left(x_i\right))$

  Input: $x_i,f\left(x_i\right)(1\le i\le t)$ Output: key 1: $S\leftarrow 0$ 2: for $1\le i\le t$ do 3:     $l_i\left(x\right)\leftarrow 1$ 4:     for $1\le j\le t$ do 5:         if $j\ne i$ then 6:            $l_i\left(x\right)\leftarrow l_i\left(x\right)·{\displaystyle \frac{(0-x_j)}{(x_i-x_j)}}$ 7:         end if 8:     end for 9:     $S\leftarrow S+f_i\left(x\right)·l_i\left(x\right)$ 10: end for 11: return S

3.3.2. Attribute-Based Access Control Smart Contract

According to the algorithm in Section 3.3.1 above, three smart contracts, PIP, PAP, and PDP, are formulated. PIP, as an attribute data source, is responsible for collecting and managing the attribute information of the access control policy. PAP is the policy definition and publishing center, and encodes the policy as an executable contract rule. PDP is the implementation decision engine. When PDP accepts the access request, it integrates the attributes provided by PIP and the policy defined by PAP for dynamic evaluation, so as to realize decentralized and tamper-resistant access control, as shown in Figure 3.

In the pre-audit phase, the policy follower who agrees with the policy becomes the execution node follower, and the ABAC policy contract that takes into account all the ideas is deployed. The specific workflow is as follows: First, when U initiates the original access request, the execution node on the blockchain will perform a legitimacy test after receiving the transaction proposal, and then the node will call the smart contract to simulate the execution of the transaction. In this paper, we use smart contracts to reflect the functions of PEP, PIP, PAP, and PDP. Among them, the policy administration point (PAP) is responsible for formulating the policy set, and the policy enforcement point (PEP) is responsible for receiving the user’s authorization request for data. According to the decision results of policy decision point (PDP) feedback, the corresponding operation is performed. The policy information point (PIP) is responsible for obtaining relevant attribute information such as subject, resource, and environment, while PDP is responsible for access control decisions based on the policy in PAP and the relevant attribute information provided by PIP. The algorithm flow of this smart contract is described in detail below.

After receiving, the PEP node will send the attribute information query request attrRequest to PIP. PIP needs to collect and sort out the subject, resource, operation, and environment attribute information attrSet required by attrRequest and then return it to the PEP node. The specific contract is as shown in Algorithm 4.

Algorithm 4 PIP—policy information point

Input: attrRequest Output: attrSet 1: Attrs ← Read(attrRequest) 2: for block = 1 to blockchains.length do 3:     for j = 1 to block.attr_datablocks.length do 4:         if Attrs ∈ (AttrValue ∪ AttrRelation) then 5:            attrSet = AttrValue 6:         end if 7:     end for 8: end for 9: return attrSet

After obtaining the relevant attribute information, PEP needs to perform preliminary processing of the access request and access control policy. Firstly, the request is converted into AAR according to the attribute information attrSet returned by PIP. Then, PEP traverses the access policy transaction block, finds the policy related to the resource, and adds it to the policy matching set PolicyMatchSet; finally, the policy matching set PolicyMatchSet is returned to the policy decision point contract PDP for the next policy decision. The specific contract is as shown in Algorithm 5.

Algorithm 5 PAP policy matching set extraction

Input: NAR, attrSet Output: PolicyMatchSet 1: AAR ← NAR, attrSet{} 2: $(As,Ao,Ar)\leftarrow$ParseRequest(AAR) 3: PM$\leftarrow \varnothing$ 4: for block = 1 to blockchains.length do 5:     for all policy_data in block do 6:         if policy_data.Type = ’policy’ and $(As,Ao,Ar)=\mathtt{ExtractPolicy}(\mathtt{policy}\_\mathtt{data})$ then 7:            PM.add(policy_data) 8:         end if 9:     end for 10: end for 11: return PolicyMatchSet

The PDP contract is based on the policy matching set PolicyMatchSet provided by the PAP node and examines the policy rules one by one to ensure that the access request fully meets all relevant policy constraints. When the access request does not conform to any policy rule, the access right will be denied; conversely, if the request satisfies all policy rules, the access is authorized. The specific contract is shown in Algorithm 6.

Algorithm 6 PDP—policy decision point

Input: AAR, PolicyMatchSet Output: PERMIT or DENY 1: Decision ← “Access Denied” 2: for policy in RelevantPolicy do 3:     for rule in policy.rules do 4:         if not (AAR conforms to rule) then 5:            return DENY 6:         end if 7:     end for 8: end for 9: return PERMIT

4. Experimental Analysis

4.1. Experimental Deployment Environment

In this paper, all experiments were conducted on a server equipped with an Intel(R) Core(TM) i7-8750H CPU @ 2.20 GHz and 16 GB of memory, running the Ubuntu 20.04 LTS operating system.The implementation and validation of this scheme are based on the Hyperledger Fabric v2.4 LTS framework. We used Docker to containerize the fabric network to simulate a distributed consortium of multiple data owners. The network’s smart contracts were written in Go. Performance evaluation was conducted using a test client developed in the Eclipse IDE with Java and multithreading, which was responsible for simulating concurrent user requests and collecting performance data.

The experiments focus on the multi-owner data access control scenario, with an emphasis on evaluating the performance of the proposed MMD-SSAC scheme in terms of access control latency and smart contract execution efficiency. To comprehensively validate the effectiveness and advantages of the scheme, SATI [33] (Sidechain-based Access control and Trust mechanism for IoT networks) is selected as the distributed baseline, while a traditional centralized ABAC is introduced as the centralized comparison baseline. SATI adopts a sidechain architecture combined with trust-based decision-making, implementing decentralized and fine-grained access control by deploying ABAC smart contracts on Hyperledger Fabric, and supports dynamic policy adjustments based on node trustworthiness, making it suitable for secure access control in multi-entity collaborative environments. In contrast, the traditional centralized ABAC stores and matches policies at a single central node, handling all access requests in a unified manner and representing a typical centralized access control model. Our scheme implements multi-owner joint policy formulation, voting, and threshold encryption-based joint authorization on the blockchain. All three schemes are executed under identical hardware and network conditions, with the number of access control attributes kept constant to ensure fairness in performance comparisons.

4.2. Access Control Performance Testing

In blockchain-based access control, operational cost is a critical metric. It should be noted that Hyperledger Fabric, as a permissioned blockchain, does not rely on a “gas” mechanism for transaction processing. Consequently, we evaluate its performance overhead by measuring the transaction latency of core operations.

Table 6. Average latency of smart contract.

Smart Contract	Description	Avg. Latency (ms)
Policy Deployment	To store a new access policy on chain for the first time.	∼85 ms
Policy Voting	To submit a vote (agree/disagree) for a proposed policy.	∼55 ms
Joint Authorization	To execute the ABAC smart contract for a user’s access request.	∼580 ms

summarizes the average latency for three key on-chain operations in our scheme—policy deployment, policy voting, and joint authorization—thereby providing a baseline for the subsequent performance analysis.

In the access control performance test, the data access request sent by the user is analyzed in depth after the multi-owner data policy setting is completed. In order to explore the relationship between the number of user access requests and transaction delay, 300, 600, and 1000 access control requests are taken from the access requests to form three sets of test set samples. Since the ABAC algorithm used in this study is not improved, it is mainly used to solve the access control problem in multi-party collaborative data flow. Therefore, the number of attributes is fixed in the experiment to facilitate model verification and result comparison. Therefore, transaction delay is measured while keeping the number of attributes and policies constant. As shown in Figure 4, under different group sizes (three, five, and seven nodes) and varying request loads, our scheme consistently maintained a lower transaction latency, with the rate of increase being significantly smaller than that of SATI and centralized ABAC as the request volume grew. Under the three-node configuration, our scheme achieved the lowest latency due to minimal communication and coordination overhead. When the network scale expanded to five and seven nodes, although the complexity of collaboration increased, the multi-owner policy effectively curbed latency growth, demonstrating good scalability. In contrast, SATI exhibited noticeably higher latency across all three configurations, while the centralized ABAC showed the highest latency, with a pronounced upward trend as the request volume increased, indicating its susceptibility to processing bottlenecks under high concurrency. Overall, within the range of 300–1000 requests, our scheme reduced average latency by approximately 15% compared to SATI and by more than 25% compared to centralized ABAC.

In order to explore the relationship between the number of access requests and system throughput, the experimental design uses three cases in which the number of packet nodes is three, five, and seven, respectively, and five experimental groups are set up for each case for testing. Each round of the experiment conducted 50 access requests, and the experiment was repeated for 20 rounds to ensure that the data is reliable and statistically significant. As shown in Figure 5, the proposed scheme achieved significantly higher TPS than both SATI and centralized ABAC under all group size configurations. The centralized ABAC, constrained by the processing capacity of a single point, consistently exhibited low TPS and was unable to scale effectively under high concurrency. SATI demonstrated relatively stable performance under moderate loads; however, its overall TPS remained lower than that of the proposed scheme. Under the seven-node configuration, the proposed scheme improved TPS by approximately 26% compared to SATI and by more than 40% compared to centralized ABAC. In the three-node configuration, due to the optimized matching strategy, the maximum improvement over SATI reached approximately 28%.

4.3. Smart Contract Algorithm Performance Evaluation

To evaluate the performance differences between our scheme and existing solutions under practical operating conditions—particularly in terms of smart contract execution efficiency—we designed an experiment focusing on how transaction latency changes with increasing network scale and access request frequency. As shown in Figure 6, we grouped the network into configurations of 20, 30, and 40 nodes, and measured the smart contract execution latency under each setting. The results indicate that while latency naturally increases as the number of nodes grows from 20 to 40 and as the system handles more access requests per second, the latency growth in our proposed scheme remains significantly smaller than that of the baseline. This improvement is primarily attributed to our streamlined contract design, which avoids the overhead caused by the traditional attribute-based access control model used in FIoT [34]. In FIoT, policy retrieval and attribute verification require multiple queries across the blockchain network to collect the attributes of the target device and perform one-by-one matching with the requester’s attributes. This process involves frequent cross-node communication and results in higher latency. In contrast, our approach integrates attribute matching directly within the smart contract logic by iterating over the access control table during each execution round. This design eliminates unnecessary inter-node communication overhead. At a peak load of 600 requests per second, the latency of our scheme is nearly 58 ms lower than that of FIoT. Overall, our scheme demonstrates a steady and predictable increase in latency as the request rate rises, whereas the FIoT solution exhibits accelerated latency growth and stronger fluctuations beyond 600 requests per second. These results indicate that the optimized smart contract logic in our scheme delivers better performance and stability under high-load conditions.

4.4. Policy Fusion Analysis

Since the number of policy merges is a key factor affecting the running time of smart contracts, the experiment also tests the performance of the policy merge algorithm. We use the number of policy merges as a variable for testing. In order to test the performance of the policy fusion algorithm, this experiment takes 5–50 different policies from the policy set to form 10 sets of test set samples to test the running time of the smart contract. As shown in Figure 7, with the increase in the number of policy integrations, the running time of the policy integration contract shows an increasing trend, and with the increase in the number of policies, the growth in integration time is gradually obvious. This is due to the large number of integration bases, and the results grow proportionally as well.

4.5. Convergence Performance Analysis of Game Theory Strategy Fusion Mechanism

In the policy integration phase, the dynamic adjustment of access control preferences among multiple data owners constitutes a typical game-theoretic interaction. This paper constructs an integration model based on the Stackelberg game framework, where a leader–follower mechanism is employed to guide participants toward gradual convergence and achieve a unified policy. To systematically evaluate the computational efficiency and convergence behavior of this mechanism in multi-party environments, as well as to quantify the influence of key parameters on its performance, we conducted a large-scale simulation experiment focusing on two core variables: the number of participants and the number of conflicting policies. The results, as illustrated in Figure 8, show the trend of average convergence rounds as the number of conflicts increases from 10 to 100 under three different participant configurations (5, 10, and 15 owners). The results indicate that the proposed mechanism consistently converges across all configurations and exhibits clear regularity and interpretability. Specifically, the number of participants emerges as the dominant factor affecting convergence speed; as the number of collaborative nodes increases, the required convergence rounds grow accordingly, reflecting the rising coordination cost in larger-scale cooperative settings. For example, at 60 conflicts, the average number of convergence rounds is approximately 39 for 5 participants, around 55 for 10 participants, and about 75 for 15 participants, indicating increased negotiation complexity under high collaboration density. Additionally, all three curves demonstrate an approximately linear and monotonic growth pattern, suggesting a stable and predictable relationship between the number of conflicts and convergence rounds across different participant scales. For instance, in the case of five participants, increasing the number of conflicts from 10 to 100 leads to a rise in convergence rounds from approximately 27 to 50, with an average increment of about 2.5 rounds per 10 additional conflicts, demonstrating the mechanism’s sensitivity and controllability with respect to policy complexity.

5. Conclusions

Our paper proposes a decentralized autonomous access control scheme based on blockchain technology, effectively combining the strengths of attribute-based and discretionary access control models. This scheme robustly safeguards the rights and interests of multiple data owners involved in multi-source data sharing, while achieving consensus on access control policies to ensure fine-grained data security. To address policy conflicts among multiple resource owners, a method for formulating access control policies that balance conflicting attributes using revenue functions is introduced. Additionally, a Stackelberg game-based consensus voting method is proposed to resolve issues related to poor consistency in multi-party collaborative policy implementation. Finally, this study enhances the security of discretionary access control by integrating attribute-based fine-grained control, blockchain-enabled traceability of key operations, and threshold cryptography-based key authorization. The experimental evaluation confirms the scheme’s feasibility and highlights its superior effectiveness and performance in distributed collaborative environments.