Cross-domain access control method based on capability and multi-block chain

Abstract

The invention aims to provide a lightweight and flexible cross-domain access control (CMCAC) method based on capabilities and multiple block chains. According to the mechanism, a block chain fragmentation technology is utilized, an original block chain network is split by taking a domain as a unit, and a main chain responsible for inter-domain interaction and a plurality of slave chains containing intra-domain equipment are constructed. Through the mode, the capability tokens are dispersed into each domain according to the main body, the storage pressure of the block chain is reduced, and the expandability of the whole system is improved. In addition, the model also optimizes the operation of the capability token, so that the calculation burden and the management cost are effectively reduced.

Description

Technical Field

[0001] The present invention proposes a cross-domain access control method based on capabilities and multiple blockchains. The mechanism uses blockchain sharding technology to split the original blockchain network by domain, builds a main chain responsible for inter-domain interaction and multiple slave chains containing devices within the domain, and introduces oracle nodes to achieve communication and data synchronization between the main chain and the slave chain. At the same time, the capability token is revoked using the mark deletion method, and the root capability token is created using the on-demand creation method. Background Art

[0002] The Capability-Based Access Control (CapBAC) model manages access rights by defining and using capability tokens, without the need to unify the attribute definitions between different domains, which greatly simplifies the complexity of cross-domain access control. More importantly, CapBAC supports delegation and proxy of permissions, providing users with more flexible access control management. Therefore, the capability-based access control model has begun to attract the attention of more and more researchers and has gradually become a research hotspot in the field of access control.

[0003] In recent years, researchers have begun to combine capability-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 capabilities. However, the capability tokens in this scheme are stored in the SAML / XACML format, which requires a lot of resources and time to parse, and are not applicable to some low-performance IoT devices. Xu et al. used JSON format to store capability tokens, solving the problem of high resource overhead in the SAML / XACML format, and dynamically displayed the delegation and revocation process of capabilities through the capability tree. However, in this scheme, the capability token and the authorization relationship are defined separately, which has the problem of not being able to be updated synchronously, and when a subject applies for permissions to multiple subjects, the problem of confusion of the authorized subject may occur. Nakamura et al. merged the capability token and the authorization relationship into a token, thereby realizing the synchronous update of the capability token and the authorization relationship. At the same time, the scheme further subdivided the capability token and defined the capability token based on the authorized operation type, effectively solving the problem of confusion of the authorized subject. However, the scheme divides a single capability token into multiple ones, which greatly increases the storage pressure of the blockchain. In addition, the scheme binds smart contracts to object devices, resulting in numerous contracts, and adopts a direct deletion method for cascading deletion of capabilities, resulting in a large amount of resource and time overhead. Liu et al. introduced a decentralized identifier DID to provide richer human-readable information for IoT devices. However, the capability management module of this scheme can only generate capability tokens, and does not support the proxy and delegation of capabilities. Pal et al. combined the attribute-based delegation method to propose an IoT access control scheme that does not rely on specific identity information. However, this scheme also binds smart contracts to object devices, and the cascading deletion operation also adopts a direct deletion method. Deepthi et al. adopted a publish-subscribe model based on MQTT to provide a lightweight authorization mechanism for IoT devices, but this scheme also does not support the delegation and proxy of capabilities, and may have problems such as single point failure. Chen et al. adopted the method of passing the authorization subject upward to solve the problem of confusion of the authorization subject. At the same time, the logical structure of the list to be revoked was introduced to speed up the revocation of the capability token. However, this scheme passes the authorization subject upward, resulting in the disappearance of the original authorization relationship and increasing the complexity of the authorization operation. In addition, the data structure of the to-be-revoked list is introduced, and the root capability is generated when the object device is registered, which brings additional storage burden.

[0004] In summary, the current blockchain-based CapBAC access control scheme still has some problems. First, the blockchain has high storage pressure. Capability tokens are generally based on subjects, and corresponding capability tokens need to be generated for each subject's access control request. Moreover, in order to solve the problem of confusion of authorized subjects, capability tokens need to be subdivided from subjects to operations, which further aggravates the storage pressure of the blockchain. Secondly, the computational burden and resource overhead are high. The execution of smart contracts will be limited by the performance of the blockchain, and the structure of a single blockchain may face performance bottlenecks in cross-domain IoT scenarios with large amounts of data. At the same time, the operation of capabilities will involve a large number of changes to the capability tree structure, which has high computational overhead. Summary of the invention

[0005] The purpose of the present invention is to propose a lightweight and flexible cross-domain access control method CMCAC based on capabilities and multiple blockchains. The mechanism uses blockchain sharding technology to split the original blockchain network by domain, and constructs a main chain responsible for inter-domain interaction and multiple slave chains containing devices within the domain. In this way, the capability tokens are dispersed to each domain according to the subject, reducing the storage pressure of the blockchain and improving the scalability of the entire system. In addition, the model also effectively reduces the computing burden and management costs by optimizing the operation of capability tokens.

[0006] The technical solution adopted by the present invention comprises the following steps:

[0007] Step 1: Smart contract definition and deployment. Deploy the domain management contract, capability forwarding contract, subject management contract, object management contract, and capability management contract on the main chain and slave chain respectively.

[0008] Step 2: Define the capability token structure. The capability token specifically defines the access rights that the subject has to the object. The capability token contains a delegation relationship DR. Using this field, a logical structure - capability tree - can be generated to represent the delegation and agency relationship of capabilities.

[0009] Step 3: Create a root capability token. Create a root capability token on demand to ensure that the token is created based entirely on the actual access request.

[0010] Step 4: Delegation of capability tokens. Defining capability tokens based on the type of authorized operations solves the problem of confusion among authorized entities.

[0011] Step 5: Revocation of the capability token: Use the mark-to-delete method to logically delete the capability token, and then actually delete it.

[0012] Step 6: Verify the capability token. The smart contract on the blockchain is called to obtain the corresponding capability token based on the subject address, object address, and requested operation behavior. The object will decide whether to grant the subject access rights based on the specific content of the capability token.

[0013] Step 7: Aggregation of capability delegation traces: All capability tokens in each domain are collected and aggregated to obtain the complete delegation trace of the access object.

[0014] Positive effects of the present invention:

[0015] (1) Sharding technology is used to split the power tokens by domain and store them separately in the slave chains within each domain, which greatly reduces the computing and storage pressure of the blockchain.

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

[0017] (3) The root capability token for device operation is created when it 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, and traceability and immutability are guaranteed. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 2 is an example of confusion of authorization principals.

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

[0022] Figure 4 It is the system interaction process of revoking the capability token.

[0023] Figure 5 It is the system interaction process of capability token verification.

[0024] Figure 6 is an example of a delegated track aggregation. DETAILED DESCRIPTION

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

[0026] Step 1: Smart contract definition and deployment. Deploy the domain management contract, capability forwarding contract, subject management contract, object management contract, and capability 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 domain management contracts and power forwarding contracts.

[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, slave chain contract deployment. The domain administrator deploys a series of smart contracts on the slave 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 are registered by calling the subject management contract and object management contract on the slave chain, respectively, so that the system can identify and verify their identities.

[0031] Step 2: Define the capability token structure. The capability token specifically defines the access rights that the subject has to the object. The capability token includes a unique identifier TokenID, an access request AR, a delegation relationship DR, context-aware information Contexts, and a deletion mark isDel. Use AR to generate TokenID. Specifically, the subject address, subject domain address, object address, object domain address, and requested operation in 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 capability token, a logical structure - a capability tree can be generated to represent the delegation and agency relationship of capabilities.

[0032] Step 3: Creation of root capability token. The CMCAC mechanism adopts a demand-driven approach. When subject S makes an access request to perform an operation action on object device O, the system will first check to determine whether a root capability token for the operation already exists on the blockchain. If such a root capability token does not yet exist, the system will create a new root capability token specifically for this operation, ensuring that the creation of the token is entirely based on the actual access request. Subsequently, the capability token of subject S is attached as a child node to this newly created root capability token. If the root capability token for this operation already exists, the system will directly add the capability token of subject S as its child node.

[0033] Step 4: Delegation of capability tokens. The CMCAC mechanism defines capability tokens based on the type of operation authorized, solving the problem of confusion among authorized entities. Figure 2As shown in the figure, a typical situation of confusion of authorized subjects is shown. N1, as the root capability node of object device O1, has the control authority for all operations. At this time, subject S1 initiates an access request for the read operation to object device O1 and generates capability token N2. Subject S2 initiates a request for the read operation of object device O1 to subject S1 and generates capability token N3 through proxy. However, at this time, subject S2 needs to apply for the permission of the write operation to object device O1. At this time, the operation set of node N3 will become {read, write}, but because there are two authorized subjects (object device O1 and subject S1), two parent nodes N1 and N2 appear, and the structure of the capability tree is confused. The CMCAC mechanism subdivides the capability token according to the operation, and the read and write operations form two different capability tokens respectively, and their delegation relationship also forms two different capability trees. When subject S2 applies for the permission of the write operation to object device O1, it is directly added to the capability tree of the write operation, which will not cause the structure of the read operation capability tree to change. The specific interaction process of power token delegation is as follows Figure 3 shown.

[0034] Step 5, revocation of capability token. When a capability token is revoked, all its descendant nodes need to be revoked, which is called cascading revocation of capability. In the CMCAC model, the mark-deletion method is used to perform cascading revocation of capability. The specific operations are: modify the child node list of the authorization node, then put the capability token node to be revoked into the list to be deleted, and finally set the deletion mark isDel field of the capability token node to be revoked and all its descendant nodes to 1. The capability token node is only logically deleted during the above revocation operation, and the actual time of deletion is: the capability token is deleted the next time it is accessed; scheduled deletion, set a scheduled task on the oracle node to delete the capability node that has been marked for deletion; active deletion when the system is idle, and the domain administrator actively initiates the deletion and cleanup of the capability nodes marked for deletion. The specific interactive process of capability token revocation is as follows: Figure 4 shown.

[0035] Step 6: Verify the capability token. When the object receives the access request from the subject, it first calls the smart contract on the blockchain to obtain the corresponding capability token based on the subject address, object address, and requested operation behavior. The smart contract mainly determines whether the token is valid based on three factors: whether it exists, whether it has been marked for deletion, and whether it is within the validity period. When the object receives the returned capability token, it will decide whether to grant the subject access rights based on the specific content of the capability token. The specific interactive process of revoking the capability token is as follows: Figure 6 shown.

[0036] Step 7: Aggregate the capability delegation track. In the CMCAC mechanism, although the capability tokens are scattered in the slave chains in each domain according to the domain where the subject is located, the CMCAC model can collect all capability tokens in each domain and aggregate them to obtain the complete delegation track of the access object. Figure 6 As shown in the figure, N1, N2, N3 and N4 are stored in four different domains as capability token nodes. N1, as the root capability node, distributes the capability to N2 and N4. N2 delegates the capability to N3. Each capability token is scattered in each domain in turn. However, the capability tokens in each domain are associated with other domains through the parent node and child node attributes in the token. Therefore, starting from the root capability node N1, traversing the child nodes of each node in turn and aggregating them, the complete delegation trajectory corresponding to the object can be obtained.

Claims

1. A cross-domain access control method based on capabilities and multiple blockchains, characterized in that: The method comprises the following steps: Step 1: Define and deploy smart contracts. Deploy domain management contracts, capability forwarding contracts, subject management contracts, object management contracts, and capability management contracts on the main chain and slave chain respectively. Step 2: Define the capability token structure. The capability token specifically defines the access rights that the subject has to the object. The capability token contains a delegation relationship DR. Using this field, a logical structure - capability tree - can be generated to represent the delegation and agency relationship of the capability. Step 3: Create a root capability token. Create a root capability token on demand to ensure that the token is created based on the actual access request. Step 4: Delegation of capability tokens: defining capability tokens based on the type of authorized operations, which solves the problem of confusion among authorized entities. Step 5: Revocation of the capability token: logically delete the capability token by marking it for deletion, and then actually delete it. Step 6: Verify the capability token. Call the smart contract on the blockchain to obtain the corresponding capability token based on the subject address, object address, and requested operation behavior. The object will decide whether to grant the subject access rights based on the specific content of the capability token. Step 7: Aggregate the capability delegation trace. Collect all capability tokens in each domain and aggregate them to obtain the complete delegation trace of the access object.

2. According to the cross-domain access control method based on capabilities and multiple blockchains described in claim 1, it is characterized in that: By using sharding technology, the power tokens are split by domain and stored in slave chains in each domain respectively, which greatly reduces the computing and storage pressure of the blockchain.

3. According to the cross-domain access control method based on capabilities and multiple blockchains described in claim 1, it is characterized in that: The mark deletion method is used to revoke the capability token, which speeds up the token revocation and reduces the computational burden.

4. According to the cross-domain access control method based on capabilities and multiple blockchains described in claim 1, it is characterized in that: The root capability token for device operation is created when it is used, rather than when the device is registered, which reduces the resource overhead of the blockchain.

5. According to the cross-domain access control method based on capabilities and multiple blockchains described in claim 1, it is characterized in that: All access control operations are transparently recorded on the blockchain, and traceability and non-tamperability are guaranteed.

Images