A cross-domain access control method based on power and multiple blockchains

Abstract

The purpose of this invention is to propose a lightweight and flexible cross-domain access control method (CMCAC) based on power tokens and multiple blockchains. This mechanism utilizes blockchain sharding technology to split the original blockchain network into domain-based units, constructing a main chain responsible for inter-domain interactions and multiple slave chains containing devices within each domain. In this way, power tokens are distributed across various domains according to their ownership, reducing the storage pressure on the blockchain and improving the scalability of the entire system. Furthermore, this model effectively reduces computational burden and management costs by optimizing the operation of power tokens.

Description

Technical Field

[0001] This invention proposes a cross-domain access control method based on power and multiple blockchains. This mechanism utilizes blockchain sharding technology to split the original blockchain network into domains, constructing a main chain responsible for inter-domain interactions and multiple slave chains containing devices within each domain. An oracle node is introduced to achieve communication and data synchronization between the main chain and slave chains. Simultaneously, a marker-deletion method is used to revoke power tokens, and an on-demand creation method is used to create root power tokens. Background Technology

[0002] The Capability-Based Access Control (CapBAC) model manages access permissions by defining and using capability tokens, eliminating the need for unified attribute definitions across different domains and significantly simplifying the complexity of cross-domain access control. More importantly, CapBAC supports permission delegation and proxying, providing users with more flexible access control management. Therefore, the Capability-Based Access Control model has attracted increasing attention from researchers and has gradually become a research hotspot in the field of access control.

[0003] In recent years, researchers have begun to combine authority-based access control with blockchain. Gusmeroli et al. granted access tokens for specific operations to access control subjects according to the principle of least privilege, supporting the delegation and revocation of authority. However, the authority tokens in this scheme are stored in SAML / XACML format, which requires significant resources and time to parse, making it unsuitable for some low-performance IoT devices. Xu et al. used JSON format to store authority tokens, solving the problem of high resource consumption in SAML / XACML format, and dynamically displayed the delegation and revocation process of authority through an authority tree. However, in this scheme, authority tokens and authorization relationships are defined separately, resulting in the problem of non-synchronous updates, and when a subject requests permissions from multiple subjects, the problem of authorization subject confusion may occur. Nakamura et al. merged authority tokens and authorization relationships into a single token, thereby achieving synchronous updates of authority tokens and authorization relationships. At the same time, this scheme further subdivided authority tokens, defining authority tokens by authorized operation type, effectively solving the problem of authorization subject confusion. However, this scheme divides a single authority token into multiple tokens, greatly increasing the storage pressure on the blockchain. Furthermore, this scheme binds smart contracts to object devices, resulting in numerous contracts, and its direct deletion method during cascading deletion of powers incurs significant resource and time overhead. Liu et al. introduced decentralized identifiers (DIDs) to provide richer human-readable information for IoT devices. However, their power management module can only generate power tokens and does not support power delegation or proxying. Pal et al. proposed an IoT access control scheme that does not rely on specific identity information, combining attribute-based delegation methods. However, this scheme also binds smart contracts to object devices, and its cascading deletion operation also uses direct deletion. Deepthi et al. adopted an MQTT-based publish-subscribe pattern to provide a lightweight authorization mechanism for IoT devices, but this scheme also does not support power delegation or proxying and may suffer from single points of failure. Chen et al. addressed the issue of authorization subject confusion by passing the authorization subject upwards, and introduced a pending revocation list to accelerate the revocation of power tokens. However, this scheme's upward passing of the authorization subject causes the original authorization relationship to disappear and increases the complexity of the authorization operation. Furthermore, the introduction of a data structure for the list to be revoked, and the generation of root authority during object device registration, introduces additional storage burdens.

[0004] In summary, current blockchain-based CapBAC access control schemes still have several issues. First, the blockchain faces significant storage pressure. Power tokens are typically issued on a principal-by-principal basis, requiring the generation of a corresponding power token for each principal's access control request. Furthermore, to address the issue of authorization principal confusion, power tokens need to be broken down from principal to operation, further exacerbating the blockchain's storage burden. Second, the computational burden and resource consumption are substantial. The execution of smart contracts is limited by blockchain performance; a single-blockchain structure may face performance bottlenecks in large-scale, cross-domain IoT scenarios. Simultaneously, power operations involve numerous modifications to the power tree structure, resulting in significant computational overhead. Summary of the Invention

[0005] The purpose of this invention is to propose a lightweight and flexible cross-domain access control method (CMCAC) based on power tokens and multiple blockchains. This mechanism utilizes blockchain sharding technology to split the original blockchain network into domain-based units, constructing a main chain responsible for inter-domain interactions and multiple slave chains containing devices within each domain. In this way, power tokens are distributed across various domains according to their ownership, reducing the storage pressure on the blockchain and improving the scalability of the entire system. Furthermore, this model effectively reduces computational burden and management costs by optimizing the operation of power tokens.

[0006] The technical solution adopted in this invention includes the following steps:

[0007] Step 1: Smart Contract Definition and Deployment. Deploy the domain management contract, power forwarding contract, subject management contract, object management contract, and power management contract on the main chain and slave chain respectively.

[0008] Step 2: Define the Power Token Structure. The power token specifically defines the access permissions a subject has over an object. The power token contains a delegation relationship (DR). Using this field, a logical structure—the power tree—can be generated to represent the delegation and proxy relationships of powers.

[0009] Step 3: Root Power Token Creation. Root power tokens are created on demand, ensuring that token creation is based entirely on actual access requests.

[0010] Step 4: Power Token Delegation. Power tokens are defined based on the type of authorized operation, resolving the issue of confusion regarding the authorizing entity.

[0011] Step 5: Revoke the Power Token. Logically delete the power token using a mark-and-delete method, and then actually delete it.

[0012] Step 6: Power Token Verification. Based on the subject address, object address, and requested operation, a smart contract on the blockchain is invoked to obtain the corresponding power token. The object will then determine whether to grant the subject access rights based on the specific content of the power token.

[0013] Step 7: Aggregate Power Delegation Trajectory. By collecting all power tokens from various domains and aggregating them, a complete delegation trajectory of the accessed object can be obtained.

[0014] The positive effects of this invention:

[0015] (1) By using sharding technology, the power tokens are split by domain and stored in the sub-chains of each domain, which greatly reduces the computation and storage pressure of the blockchain.

[0016] (2) Using the mark-deletion method to revoke the power token speeds up the token revocation process and reduces the computational burden.

[0017] (3) The root power token for device operation is created only when the device is used, rather than when the device is registered, which reduces the resource overhead of the blockchain.

[0018] (4) All access control operations are transparently recorded on the blockchain, ensuring traceability and immutability. Attached Figure Description

[0019] Figure 1 This is a system architecture diagram.

[0020] Figure 2 This is an example of confusion regarding the authorizing entity.

[0021] Figure 3 It is the system interaction process of power token delegation.

[0022] Figure 4 It is the system interaction process for revoking the power token.

[0023] Figure 5 It is the system interaction process for verifying power tokens.

[0024] Figure 6 This is an example of delegated trajectory aggregation. Detailed Implementation

[0025] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Figure 1 This is an architecture diagram of the CMCAC system.

[0026] Step 1: Smart Contract Definition and Deployment. Deploy the domain management contract, power forwarding contract, subject management contract, object management contract, and power management contract on the main chain and slave chain respectively.

[0027] Step 1.1, Main Chain Contract Deployment. The system administrator deploys smart contracts on the main chain, mainly including the domain management contract and the power forwarding contract.

[0028] Step 1.2, Domain Administrator Registration. Domain administrators register themselves by calling the domain management contract on the main chain to ensure that they can be identified and verified in the system.

[0029] Step 1.3, Deployment of Sub-Chain Contracts. The domain administrator deploys a series of smart contracts on the sub-chain within the domain, mainly including subject management contracts, object management contracts, and power management contracts.

[0030] Step 1.4, User and Device Registration. Users and devices within the domain register by calling the on-chain subject management contract and object management contract, respectively, so that the system can identify and verify their identities.

[0031] Step 2: Define the Power Token Structure. The power token specifically defines the access permissions a subject has over an object. The power token includes a unique identifier (TokenID), an access request (AR), a delegation relationship (DR), context-aware information (Contexts), and a deletion flag (isDel). The AR is used to generate the TokenID. Specifically, the subject address, subject domain address, object address, object domain address, and the requested operation in the AR are encoded and passed to the Keccak-256 algorithm to calculate a unique hash value as the TokenID. Using the delegation relationship (DR) in the power token, a logical structure—the power tree—can be generated to represent the delegation and proxy relationships of powers.

[0032] Step 3: Root Power Token Creation. The CMCAC mechanism employs a demand-driven approach. When subject S requests access to perform an operation (action) on object device O, the system first checks whether a root power token for that operation already exists on the blockchain. If such a root power token does not exist, the system creates a new one specifically for that operation, ensuring that token creation is entirely based on the actual access request. Subsequently, subject S's power token is attached as a child node to this newly created root power token. If the root power token for this operation already exists, the system directly adds subject S's power token as its child node.

[0033] Step 4: Power Token Delegation. The CMCAC mechanism defines power tokens based on the type of authorized operation, resolving the issue of confusion regarding the authorizing entity. For example... Figure 2The diagram illustrates a typical scenario of authorization subject confusion. N1, as the root authority node of object device O1, possesses control over all operations. At this time, subject S1 initiates a read access request to object device O1, generating authority token N2. Subject S2 then initiates a read access request to object device O1 from subject S1, generating authority token N3 through a proxy. However, subject S2 then needs to request write access from object device O1. The operation set of node N3 becomes {read, write}, but due to the presence of two authorizing subjects (object device O1 and subject S1), two parent nodes, N1 and N2, appear, causing confusion in the authority tree structure. The CMCAC mechanism subdivides authority tokens by operation, creating two different authority tokens for read and write operations, and their delegation relationships form two different authority trees. When subject S2 requests write access from object device O1, it is directly added to the write operation authority tree, without causing structural changes to the read operation authority tree. The specific interaction process of power token delegation is as follows: Figure 3 As shown.

[0034] Step 5: Power Token Revocation. When a power token is revoked, all its descendant nodes need to be revoked as well; this is called cascading power revocation. In the CMCAC model, a mark-and-delete method is used for cascading power revocation. Specifically, the following steps are taken: modify the child node list of the authorizing node, add the power token node to be revoked to the deletion list, and finally set the `isDel` field of the power token node to be revoked and all its descendant nodes to 1. The power token node is only logically deleted during the above revocation operation; its actual deletion occurs when: it is deleted the next time the power token is accessed; it is also deleted on a scheduled basis by setting a timed task on the oracle node to delete power nodes marked for deletion; or it is actively deleted when the system is idle, initiated by the domain administrator. The specific interaction process for power token revocation is as follows: Figure 4 As shown.

[0035] Step 6: Power Token Verification. When the object receives the access request from the subject, it first invokes the smart contract on the blockchain to obtain the corresponding power token based on the subject's address, the object's address, and the requested operation. The smart contract primarily determines the token's validity based on three factors: token existence, whether it has been marked for deletion, and whether it is within its valid timeframe. Upon receiving the returned power token, the object decides whether to grant the subject access based on the token's specific content. The specific interaction process for power token revocation is as follows... Figure 6 As shown.

[0036] Step 7: Power Delegation Trajectory Aggregation. In the CMCAC mechanism, although power tokens are distributed sequentially across subchains within each domain according to the domain of their principal, the CMCAC model can obtain the complete delegation trajectory of the accessed object by collecting all power tokens from each domain and aggregating them. For example... Figure 6 As shown, N1, N2, N3, and N4 are stored as power token nodes in four different domains. N1, as the root power node, distributes power to N2 and N4, and N2 then delegates power to N3. Each power token is scattered across the various domains. However, the power tokens in each domain are associated with other domains through the parent and child node attributes of the token. Therefore, starting from the root power node N1, traversing the child nodes of each node in turn and aggregating them, we can obtain the complete delegation trajectory corresponding to the object.

Claims

1. A capability and multi-blockchain based cross-domain access control method, characterized in that, The method comprises the following steps: Step 1, smart contract definition and deployment, domain management contract, right forwarding contract, subject management contract, object management contract and right management contract are respectively deployed on the main chain and the slave chain; Step 2, right token structure definition, the right token specifically defines the access permission of the subject to the object, and the delegation relationship DR exists in the right token, by using the field, a logical structure, i.e. right tree, can be generated to represent the delegation and agency relationship of the right; Step 3, root right token creation, the root right token is created in a manner of on-demand creation, so that the creation of the token is completely based on the actual access request; Step 4, right token delegation, the right token is defined in the unit of authorized operation type, so that the problem of authorized subject confusion is solved; Step 5, right token revocation, the right token is logically deleted by using the method of mark deletion, and then it is actually deleted; Step 6, right token verification, the corresponding right token is obtained by calling the smart contract on the blockchain according to the subject address, object address and requested operation behavior, and the object decides whether to grant the access permission of the subject according to the specific content of the right token; Step 7, right delegation track aggregation, all right tokens in each domain are collected and aggregated, so that the complete delegation track of the access object is obtained. 2.The cross-domain access control method based on capability and multi-blockchain according to claim 1, wherein, By using the sharding technology, the right token is split according to the domain and stored in the slave chain in each domain. 3.The cross-domain access control method based on capability and multi-blockchain of claim 1, wherein, All access control operations are transparently recorded on the blockchain, and have traceability and non-tamperability.

Images