Intelligent contract access control method and system based on block chain and attribute-based signature

Abstract

The invention discloses an intelligent contract access control method and system based on a block chain and an attribute-based signature, and the method specifically comprises the steps: S1, carrying out the initialization of parameters of a system, generating a master key msk of the system and a public parameter params = (G, q, g, H1, H2), wherein G is a cyclic group, g is a generator, and H1 and H2 are hash functions; s2, the access control contract layer deploys an access strategy gamma by accessing a tree structure; s3, the transaction layer performs attribute registration on the access subject; and S4, the access subject performs data access by calling the business contract layer. According to the embodiment of the invention, the dynamic fine-grained access control of the smart contract is realized, the security is ensured, the flexible updating of strategies and attributes is supported, and the contract does not need to be redeployed.

Description

Technical Field

[0001] This invention belongs to the field of blockchain-based access control, specifically relating to a smart contract access control method and system, computing device and storage medium based on blockchain and attribute-based signatures. Background Technology

[0002] Blockchain, with its decentralized and immutable characteristics, offers a new solution for data sharing. In blockchain data sharing, issues such as identity verification, data protection, and permission revocation all require access control technology. Fine-grained access control is crucial in blockchain data sharing. Blockchain access control technology has been applied in data sharing access control across multiple fields, such as healthcare, connected vehicles, and the industrial internet.

[0003] Blockchain access control technology is a crucial element in ensuring the secure operation of smart contracts, and its development is closely related to the characteristics of blockchain technology. Traditional access control models face numerous adaptation challenges in the blockchain environment, primarily due to the decentralized architecture of blockchain and the immutability of smart contracts. Discretionary Access Control (DAC) and Mandatory Access Control (MAC) models, widely used in centralized systems, are difficult to directly port to the blockchain environment because the former relies on centralized permission management mechanisms, and the latter requires pre-defined security level policies, both of which fundamentally conflict with the decentralized nature of blockchain.

[0004] In the field of blockchain access control, existing solutions generally face problems such as high computational overhead and insufficient flexibility. Traditional solutions based on attribute-based encryption (ABE) or zero-knowledge proofs typically rely on complex bilinear pairing operations, which are difficult to meet the needs of resource-constrained environments such as the Internet of Things (IoT). Especially in smart contract scenarios, existing access control mechanisms often require redeployment of contracts as policies change, severely restricting the system's scalability and dynamism.

[0005] Meanwhile, existing research has significant limitations in fine-grained access control. Most schemes embed user attributes directly into signatures or certificates, requiring credential reissue when attributes are updated, thus failing to support dynamic policy adjustments. While some schemes based on ring signatures or group signatures achieve a degree of anonymity, their verification process remains tightly coupled to specific attribute sets, making it difficult to adapt to the frequently changing access requirements in edge computing environments. Furthermore, these methods typically require maintaining a complex attribute authority center, increasing system complexity and the risk of single points of failure. Summary of the Invention

[0006] One objective of this invention is to address the shortcomings of existing technologies by providing a smart contract access control method and system based on blockchain and attribute-based signatures. This method enables dynamic, fine-grained access control for smart contracts, ensuring security while supporting flexible updates of policies and attributes without requiring contract redeployment. Experiments show that this method has high execution efficiency in resource-constrained blockchain nodes and edge computing environments, making it suitable for scenarios with strict access control requirements.

[0007] To address the aforementioned technical problems, in a first aspect, embodiments of the present invention provide a smart contract access control system based on blockchain and attribute-based signatures, the system comprising:

[0008] The transaction layer, access control contract layer, business contract layer, and consensus layer are as follows:

[0009] The transaction layer includes three types of access control transactions: strategy transactions, attribute transactions, and contract transactions;

[0010] The access control contract layer includes four types of smart contracts: access control policy management contract, user attribute management contract, permission verification contract, and policy NFT management contract, wherein:

[0011] Access control policy management contracts are used to convert the access policies of business contracts into policy keys;

[0012] The user attribute management contract is used to register user attributes to the blockchain and generate unique attribute keys for users based on the attribute values;

[0013] The access control policy management contract uses the policy key generated by the access control policy management contract to verify the legitimacy of the access token in order to check whether the user has the right to invoke the business contract;

[0014] The policy NFT management contract is used to visualize and dynamically manage policies by encapsulating policy keys as dynamic NFTs.

[0015] The business contract layer consists of smart contracts with different functions released by blockchain platform developers. The business contracts are called by users to complete the business functions specified in the contract code.

[0016] The consensus layer is mainly composed of a consensus mechanism consisting of various consensus algorithms to ensure the consistency of policy keys generated by different types of business contracts and attribute keys generated by users in a distributed environment.

[0017] Secondly, embodiments of the present invention also provide a smart contract access control method based on blockchain and attribute-based signatures, the method specifically including:

[0018] S1. Initialize the system parameters and generate the system's master key msk and public parameters params = (G, q, g, H1, H2), where G is a cyclic group, g is a generator, and H1 and H2 are hash functions.

[0019] S2, The access control contract layer deploys access policies in an access tree structure;

[0020] S3. The transaction layer registers the attributes of the accessing entity;

[0021] S4. The accessing entity accesses data by calling the business contract layer.

[0022] In a preferred embodiment, the deployment of the access strategy using an access tree structure specifically includes:

[0023] S21. Represent the access strategy Γ of the smart contract as an access tree structure, where non-leaf nodes are threshold nodes and leaf nodes store attribute values.

[0024] S22. Generate a polynomial f for each non-leaf node. v (x) The system synchronously constructs policy metadata for policy NFTs. The policy metadata includes: an access tree structure compressed and encoded using the Merkle-Patricia Trie algorithm, a policy effective time window defined by the validAfter and validUntil timestamps, and the IPFS storage address for calculating the policy key components of the leaf nodes.

[0025] S23. Generate the final strategy key The system calls the strategy NFT management contract to perform NFT construction operations. The NFT includes the strategy metadata and records the strategy creator as the initial owner address with a configurable transfer lock-up period. Finally, the generated NFT contract address and corresponding TokenID are written into the permission configuration module of the business contract layer to complete the conversion and binding of the strategy key to on-chain digital assets.

[0026] In a preferred embodiment, the attribute registration for the access subject specifically includes:

[0027] S31. The access subject sends the attribute information that needs to be verified to the application client;

[0028] S32. The application client receives the user's attribute information to form an attribute transaction, performs hash processing on the attribute information and stores the original certificate in the IPFS distributed storage system, generates the corresponding content addressing identifier (CID), and then encapsulates the attribute hash, CID and subject identifier into structured data and publishes it to the consensus group in the blockchain to reach a consensus on the user's attribute information.

[0029] S33. The attribute authority contract generates an attribute key for the access subject based on the user's attribute information, and then performs a public key PK on the attribute key. ω After being bound to the attribute certificate hash, it is uploaded to the key management module KM, along with the attribute private key sk. ω The information is returned to the user via a secure channel.

[0030] In a preferred embodiment, the attribute authority contract generates attribute keys for the access subject based on the user's attribute information, specifically including:

[0031] The attribute authority contract generates a corresponding attribute key pair (sk) based on the user's attribute set ω. ω ,pk ω ), where the attribute private key sk ω This is a random number, used to prevent collusive attacks; pk ω This is then used for subsequent signature verification;

[0032] Generate attribute key pairs (sk ω ,pk ω Specifically, this includes: selecting a random value. Calculate user private key sk ω PK with public key ω :

[0033] sk ω =msk·z·∑ a∈ω H1(a);

[0034]

[0035] Users generate signatures using their private keys; verifiers use the access policy NFT and the user's public key to verify the validity of the signature, and then determine whether the user's attributes satisfy the access policy behind the policy NFT.

[0036] In a preferred embodiment, accessing the service contract layer by invoking specifically includes:

[0037] S41. The accessing subject uses its own attribute private key sk ω Generate an access token for a specific message and send it to the business contract layer;

[0038] S42. After receiving the access token, the business contract layer forwards the access token to the permission verification contract to determine whether the access subject has the access permission.

[0039] S43. Permission verification contract query business contract layer strategy NFT and attribute public key pk in KM. ωThe system retrieves the original attribute certificate from the distributed storage using the CID and verifies its signature and validity period. It then executes a verification algorithm to check whether the signature of the access token matches the requirements of the current attribute set and the policy NFT.

[0040] In a preferred embodiment, the method further includes:

[0041] S44. The authorization verification contract additionally checks the validity of the policy NFT, including verifying that the NFT is active, the current time is within the validity period, and the caller has the right to use it. If the attribute certificate or policy NFT has expired, it will be forcibly invalidated, and the comprehensive verification result will be returned to the business contract layer.

[0042] In a preferred embodiment, the policy key It consists of the policy key components of all leaf nodes, and the calculation process of the policy key component of each leaf node v is as follows:

[0043] For each non-leaf node v, a random (t) is generated. v -1) degree polynomial Where t v The threshold for this node:

[0044] For the root node r, let f r (0) = msk, which is the master private key. For other non-leaf nodes, set... Where p v The parent node of node v. This is the index value of node v in the set of its parent node's children;

[0045] Calculate the policy key component for each leaf node v Where a v This refers to the attribute value corresponding to the leaf node.

[0046] In a preferred embodiment, the permission verification contract execution verification algorithm checks whether the signature of the access token matches the requirements of the current attribute set and the policy NFT, specifically including:

[0047] For each leaf node v in the access tree, check its attribute value a. v Does the user's attribute public key pk exist? ω If it exists, then calculate the verification component. Otherwise, mark it as invalid;

[0048] Validating non-leaf nodes using a bottom-up approach, if a node has at least t child nodes... v If each verification component is valid, then the verification component of that node is calculated using Lagrange interpolation. If the verification component d of the root node rIf it works, then further verification is needed. If the conditions are met, the user's attributes are deemed to satisfy the access policy, and the user is allowed to call the target contract; otherwise, access is denied.

[0049] Thirdly, in an embodiment of the present invention, a computing device is also provided, comprising a processor and a memory, the memory being used to store a computer program, the computer program including program instructions, and the processor being configured to invoke the program instructions to execute the method described above.

[0050] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor or calculator, cause the processor to perform the method described above.

[0051] Compared with existing technologies, the smart contract access control method and system based on blockchain and attribute-based signatures provided by this invention have at least the following advantages: This invention achieves dynamic fine-grained access control for smart contracts, ensuring security while supporting flexible updates of policies and attributes without requiring contract redeployment. Experiments show that this method has high execution efficiency in resource-constrained blockchain nodes and edge computing environments, and is suitable for scenarios with strict access control requirements. Attached Figure Description

[0052] The preferred embodiments will now be described in a clear and easy-to-understand manner, in conjunction with the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of the present invention.

[0053] Figure 1 This is a flowchart illustrating a smart contract access control method based on blockchain and attribute-based signatures according to an embodiment of the present invention.

[0054] Figure 2 This is a schematic diagram of a smart contract access control system based on blockchain and attribute-based signatures according to an embodiment of the present invention;

[0055] Figure 3 This is a schematic diagram of a computing device structure according to an embodiment of the present invention. Detailed Implementation

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0057] To keep the drawings concise, only the parts relevant to the invention are shown schematically in each figure, and they do not represent the actual structure of the product. Furthermore, to facilitate understanding, in some figures, only one of components with the same structure or function is schematically depicted, or only one is labeled. In the embodiments of this invention, "one" not only means "only one," but can also mean "more than one." The following detailed description of the implementation of the technical solution of this invention will primarily use some specific embodiments as examples.

[0058] like Figure 1 As shown, in order to achieve the objective of this invention, an embodiment of this invention provides a smart contract access control method based on blockchain and attribute-based signatures. The method specifically includes:

[0059] S1. Initialize the system parameters and generate the system's master key msk and public parameters params = (G, q, g, H1, H2), where G is a cyclic group, g is a generator, and H1 and H2 are hash functions.

[0060] S2, The access control contract layer deploys access policies in an access tree structure;

[0061] S3. The transaction layer registers the attributes of the accessing entity;

[0062] S4. The accessing entity accesses data by calling the business contract layer.

[0063] like Figure 1 and Figure 2 As shown, this invention provides a dynamic fine-grained smart contract access control method based on blockchain and policy-based NFTs, specifically including the following steps:

[0064] S1. The administrator initializes the system;

[0065] The initialization process is as follows: Using the input security parameter λ, the system's master key msk and public parameters params = (G, q, g, H1, H2) are generated, where G is a cyclic group, g is a generator, and H1 and H2 are hash functions.

[0066] S2. Deploy access policies Γ using an access tree structure, specifically including:

[0067] S21. Represent the access strategy Γ of the smart contract as an access tree structure, where non-leaf nodes are threshold nodes and leaf nodes store attribute values.

[0068] S22. Generate a polynomial f for each non-leaf node. v (x) The system synchronously constructs the metadata structure of the policy NFT, and the metadata structure includes:

[0069] The IPFS storage address of the policy key component of the leaf node is calculated using the access tree structure compressed and encoded by the Merkle-Patricia Trie algorithm and the policy effective time window defined by the validAfter and validUntil timestamps.

[0070] S23. Generating the final strategy key Afterwards, the system calls the strategy NFT management contract to perform NFT minting operations. The NFT fully contains strategy metadata consisting of access tree compression encoding, strategy effective time window and encrypted IPFS storage address. At the same time, it records the strategy creator as the initial owner address and sets a configurable transfer lock-up period (default 72 hours). Finally, the generated NFT contract address and corresponding TokenID are written into the permission configuration module of the business contract layer to complete the conversion and binding of the strategy key to on-chain digital assets.

[0071] S3. Access Subject Attribute Registration: The access subject attribute registration process includes:

[0072] S31. The access subject sends the attribute information that needs to be verified to the application client;

[0073] When an accessing entity invokes a protected business contract layer, it needs to register its attribute information in the blockchain system. The authentication process of the accessing entity's attributes can be carried out offline. After registration, the attribute authority issues an attribute authentication certificate to the user. The attribute authentication certificate must clearly specify core fields such as the entity identifier, attribute key-value pairs, issuer's public key, and validity period to ensure the credibility of subsequent on-chain verification.

[0074] S32. The application client receives the user's attribute information to form an attribute certificate, performs hash processing on the attribute certificate, stores the original certificate in the IPFS distributed storage system, generates the corresponding content addressing identifier (CID), and then encapsulates the attribute hash, CID and subject identifier into structured data and publishes it to the consensus group in the blockchain to reach a consensus on the user's attribute information.

[0075] S33. The attribute authority contract generates an attribute key for the access subject based on the user's attribute information, and then performs a public key PK on the attribute key. ω After being bound to the attribute certificate hash, it is uploaded to KM, along with the attribute private key sk. ω Returned to the user via a secure channel;

[0076] The private key generation process must ensure that it cannot be reconstructed by KM or a third party.

[0077] S4: Call the business contract layer, specifically including:

[0078] S41. The accessing subject uses its own attribute private key sk ω Generate an access token for a specific message (such as a timestamp) and send it to the business contract layer along with a list of parameters;

[0079] S42. After receiving the access request, the business contract layer forwards the access request to the permission verification contract to determine whether the access subject has the right to access.

[0080] S43. Authentication Contract Query Business Contract Strategy NFT and Attribute Public Key pk in KM ω The system retrieves the original attribute certificate from the distributed storage via CID, verifies its signature and validity period, and executes a verification algorithm to check whether the signature of the access token matches the requirements of the current attribute set and the policy NFT.

[0081] S44. The authorization verification contract additionally checks the validity of the policy NFT, including verifying that the NFT is active, the current time is within the validity period, and the caller has the right to use it. If the attribute certificate or policy NFT has expired, it will be forcibly invalidated, and the comprehensive verification result will be returned to the business contract.

[0082] During the initialization phase, the administrator inputs the security parameter λ, runs the system initialization algorithm, and generates the system's master private key msk and public parameters params. The public parameters params include a cyclic multiplicative group G of order q (a large prime number), a group generator g, and two collision-resistant hash functions H1 and H2. Specifically, a cyclic multiplicative group G, order q, and generator g are first defined, where q is a large prime number. Two collision-resistant hash functions are then selected. from Randomly select a non-zero value as the master private key msk, and then params = (G, q, g, H1, H2) as the public parameters.

[0083] These parameters will serve as the basis for subsequent signature generation and verification. The master private key msk is kept strictly confidential by the administrator, while the public parameters params are made public and available to all participants.

[0084] Next, the access policy of the smart contract needs to be deployed on the blockchain in a structured manner. The access policy is represented by a tree structure, where non-leaf nodes are threshold nodes, used to define the logical combination of access control (such as "choose 2 out of 3"), while leaf nodes store the specific attribute values.

[0085] During the strategy deployment phase, the administrator randomly generates a (t) for each non-leaf node v. v -1) degree polynomial Where t v The threshold for this node:

[0086] For the root node r, let fr (0) = msk, which is the master private key;

[0087] For other non-leaf nodes, set Where p v The parent node of node v. This is the index of node v in the set of its parent node's children.

[0088] After completing the polynomial construction, calculate the policy key component for each leaf node v. Where a v This refers to the attribute value corresponding to the leaf node.

[0089] Finally, the policy key Composed of the policy key components of all leaf nodes, the system calls the policy NFT management contract to perform NFT minting operations, generating policy metadata containing access tree compressed encoding, policy effective time window and encrypted IPFS storage address. At the same time, it records the policy creator as the initial owner address and sets a configurable transfer lock-up period (default 72 hours). Finally, the generated NFT contract address and corresponding TokenID are written to the permission configuration module of the business contract layer to complete the conversion and binding of the policy key to on-chain digital assets.

[0090] During the user registration phase, users need to register their attribute information on the blockchain in order to generate access tokens later. Users first apply for attribute certification from an attribute authority offline and obtain an attribute certification certificate.

[0091] Subsequently, users submit the authenticated attribute information to the blockchain application client, which is responsible for collecting and integrating this information to form attribute transactions.

[0092] The attribute transaction is submitted to the consensus node group of the blockchain network. After consensus verification, the user's attribute information is recorded on the blockchain.

[0093] The attribute authority contract generates a corresponding attribute key pair (sk) based on the user's attribute set ω. ω ,pk ω The private key is a random number used to prevent collusion attacks; the public key is used for subsequent signature verification. (Private key sk) ω Returned to the user, and the public key PK ω Then it is uploaded to KeyManager storage.

[0094] The specific method for generating the attribute key is as follows: First, select a random value. Then calculate the user's private key sk. ω PK with public key ω :

[0095]

[0096]

[0097] Each user attribute is hashed and multiplied by a secret value. These values ​​are then summed to obtain the user's attribute private key. The user's attribute public key is an array of strings, with each element corresponding to a value of each user attribute. The user uses their private key to generate a signature; the verifier uses the policy NFT of the access policy and the user's public key to verify the signature's validity and then determines whether the user's attribute satisfies the access policy behind the policy NFT. This effectively decouples the size of the user's signing key from the size of the attribute.

[0098] When a user needs to invoke a protected smart contract, they must first generate an access token to prove their access rights.

[0099] Users use their own attribute private key sk ω Signing a specific message (such as a timestamp or transaction hash) to generate an access token ξ = (R, s) is performed as follows:

[0100] User randomly selected Calculate R = g r And calculate the hash value h = H2(R||m), where m is the message to be signed;

[0101] Then, calculate s = r + sk ω ·h, and finally obtain the access token ξ=(R,s).

[0102] The user sends the access token along with the call parameters to the business contract layer.

[0103] Upon receiving a user's request, the business contract layer does not directly execute the business logic. Instead, it forwards the access token to the authorization verification contract for authorization verification. The authorization verification process in the authorization verification contract is as follows:

[0104] First, query the target contract's policy NFT and the user's attribute public key PK. ω Then, the verification algorithm is executed.

[0105] The verification process consists of two phases:

[0106] First, for each leaf node v in the access tree, check its attribute value a. v Does the user's attribute public key pk exist? ω If it exists, then calculate the verification component. Otherwise, mark it as invalid;

[0107] Next, a bottom-up approach is used to verify non-leaf nodes. If a node has at least t children... v If each verification component is valid, then the verification component of that node is calculated using Lagrange interpolation. If the verification component d of the root node r If it works, then further verification is needed. Check if the conditions are met. If met, the user's attributes satisfy the access policy, and the user is allowed to call the target contract; otherwise, access is denied.

[0108] To prevent malicious users from launching attacks by replaying the access tokens of legitimate users, a Bloom filter mechanism can be introduced. This involves maintaining a binary vector V and a set of independent hash functions H = {H1, H2, ..., H} within the authorization contract. n Whenever a user submits an access token ξ, the permission determination contract first calculates l hash values ​​H of ξ. i (ξ) is used to check if all corresponding positions in V are 1. If at least one position is 0, it is considered a first-time use and verification is allowed; otherwise, it is considered a repeated use and access is denied. For a valid token used for the first time, its corresponding binary bit is set to 1 after successful verification to ensure that subsequent replay attacks cannot pass verification.

[0109] This invention implements dynamic, fine-grained access control for smart contracts, ensuring security while supporting flexible updates to policies and attributes without requiring contract redeployment. Experiments show that this method has high execution efficiency in resource-constrained blockchain nodes and edge computing environments, making it suitable for scenarios with strict access control requirements.

[0110] Secondly, such as Figure 2 As shown, this embodiment of the invention also provides a smart contract access control system based on blockchain and attribute-based signatures, the system comprising:

[0111] The transaction layer, access control contract layer, business contract layer, and consensus layer are as follows:

[0112] The transaction layer includes three types of access control transactions: strategy transactions, attribute transactions, and contract transactions;

[0113] The access control contract layer includes four types of smart contracts: access control policy management contract, user attribute management contract, permission verification contract, and policy NFT management contract, wherein:

[0114] Access control policy management contracts are used to convert the access policies of business contracts into policy keys;

[0115] The user attribute management contract is used to register user attributes to the blockchain and generate unique attribute keys for users based on the attribute values;

[0116] The access control policy management contract uses the policy key generated by the access control policy management contract to verify the legitimacy of the access token in order to check whether the user has the right to invoke the business contract;

[0117] The policy NFT management contract is used to visualize and dynamically manage policies by encapsulating policy keys as dynamic NFTs.

[0118] The business contract layer consists of smart contracts with different functions released by blockchain platform developers. The business contracts are called by users to complete the business functions specified in the contract code.

[0119] The consensus layer is mainly composed of a consensus mechanism consisting of various consensus algorithms to ensure the consistency of policy keys generated by different types of business contracts and attribute keys generated by users in a distributed environment.

[0120] Compared with existing technologies, the smart contract access control method and system based on blockchain and attribute-based signatures provided by this invention have at least the following advantages: This invention achieves dynamic fine-grained access control for smart contracts, ensuring security while supporting flexible updates of policies and attributes without requiring contract redeployment. Experiments show that this method has high execution efficiency in resource-constrained blockchain nodes and edge computing environments, and is suitable for scenarios with strict access control requirements.

[0121] Thirdly, in an embodiment of the present invention, a computing device is also provided, the computing device including a processor and a memory, the memory being used to store a computer program, the computer program including program instructions, and the processor or calculator being configured to invoke the program instructions to execute the method described above.

[0122] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor or calculator, cause the processor or calculator to perform the method described above.

[0123] like Figure 3As shown in the figure, an embodiment of this application provides a computing device 1000, which includes a processor or calculator (not shown) 1001 and a memory 1002. The processor or calculator 1001 and the memory 1002 can be interconnected via a communication bus 1003. The communication bus 1003 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 1003 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the memory 1002 is used to store a computer program, which includes program instructions. The processor 1001 is configured to call the program instructions, and the program includes steps for executing some or all of the steps in the aforementioned methods.

[0124] The processor 1001 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the above-mentioned program.

[0125] The memory 1002 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory may exist independently and be connected to the processor via a bus. The memory may also be integrated with the processor.

[0126] The computing device 1000 may further include a communication module 1004 and a display 1005. The communication module 1004 can communicate with the optical tracking device. The communication module 1004 can be a wireless communication module (e.g., a WiFi module, a Bluetooth module, etc.) or a wired communication module.

[0127] In addition, the computing device 1000 may also include general components such as communication interfaces (e.g., USB interfaces, microphone interfaces, etc.) and antennas, which will not be described in detail here.

[0128] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0129] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0131] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0132] Furthermore, the functional units in the various embodiments of the application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0133] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0134] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory, a random access memory, a magnetic disk, or an optical disk, etc.

[0135] The embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this invention to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0136] It should be noted that the above embodiments can be freely combined as needed. The above are merely preferred embodiments of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A smart contract access control method based on blockchain and attribute-based signatures, characterized in that, The method specifically includes: S1. Initialize the system parameters and generate the system's master key msk and public parameters params = (G, q, g, H1, H2), where G is a cyclic group, g is a generator, and H1 and H2 are hash functions. S2, The access control contract layer deploys access policies in an access tree structure; S3. The transaction layer registers the attributes of the accessing entity; S4. The accessing entity accesses data by calling the business contract layer.

2. The smart contract access control method based on blockchain and attribute-based signatures as described in claim 1, characterized in that, The deployment of access strategies using an access tree structure specifically includes: S21. The access control contract layer represents the access strategy Γ of the smart contract as an access tree structure, where non-leaf nodes are threshold nodes and leaf nodes store attribute values. S22. Generate a polynomial f for each non-leaf node. v (x) The system synchronously constructs policy metadata for the policy NFT, which includes: an access tree structure compressed and encoded using the Merkle-PatriciaTrie algorithm, a policy effective time window defined by the validAfter and validUntil timestamps, and the IPFS storage address for calculating the policy key component of the leaf node. S23. Generate the final strategy key The system calls the strategy NFT management contract to perform NFT construction operations. The NFT includes the strategy metadata and records the strategy creator as the initial owner address with a configurable transfer lock-up period. Finally, the generated NFT contract address and corresponding TokenID are written into the permission configuration module of the business contract layer to complete the conversion and binding of the strategy key to on-chain digital assets.

3. The smart contract access control method based on blockchain and attribute-based signatures as described in claim 1, characterized in that, The specific steps of registering the attributes of the access subject include: S31. The access subject sends the attribute information that needs to be verified to the application client; S32. The application client receives the user's attribute information to form an attribute transaction, performs hash processing on the attribute information and stores the original certificate in the IPFS distributed storage system, generates the corresponding content addressing identifier (CID), and then encapsulates the attribute hash, CID and subject identifier into structured data and publishes it to the consensus group in the blockchain to reach a consensus on the user's attribute information. S33. The user attribute management contract generates an attribute key for the access subject based on the user's attribute information, and then PKs the attribute public key. ω After being bound to the attribute certificate hash, it is uploaded to the key management module KM, along with the attribute private key sk. ω The information is returned to the user via a secure channel.

4. The smart contract access control method based on blockchain and attribute-based signatures as described in claim 1, characterized in that, The attribute authority contract generates attribute keys for the access subject based on the user's attribute information, specifically including: The attribute authority contract generates a corresponding attribute key pair (sk) based on the user's attribute set ω. ω ,pk ω ), where the attribute private key sk ω This is a random number, used to prevent collusive attacks; pk ω This is then used for subsequent signature verification; Generate attribute key pairs (sk ω ,pk ω Specifically, this includes: selecting a random value. Calculate user private key sk ω PK with public key ω : Users generate signatures using their private keys; verifiers use the access policy NFT and the user's public key to verify the validity of the signature, and then determine whether the user's attributes satisfy the access policy behind the policy NFT.

5. The smart contract access control method based on blockchain and attribute-based signatures as described in claim 4, characterized in that, The access entity accesses the service contract layer by invoking the following specific methods: S41. The accessing subject uses its own attribute private key sk ω Generate an access token for a specific message and send it to the business contract layer; S42. After receiving the access token, the business contract layer forwards the access token to the access control contract layer's permission verification contract to determine whether the access subject has the necessary access rights. S43. Access control, contract layer permission verification, contract query, business contract layer strategy, NFT and KM attribute public key pk ω The system retrieves the original attribute certificate from the distributed storage using the CID and verifies its signature and validity period. It then executes a verification algorithm to check whether the signature of the access token matches the requirements of the current attribute set and the policy NFT.

6. The smart contract access control method based on blockchain and attribute-based signatures as described in claim 1, characterized in that, The method further includes: S44. The access control contract layer's permission verification contract additionally checks the validity of the policy NFT, including verifying that the NFT is active, the current time is within the validity period, and the caller has the right to use it. If the attribute certificate or policy NFT has expired, it is forcibly invalidated, and the comprehensive verification result is returned to the business contract layer.

7. The smart contract access control method based on blockchain and attribute-based signatures as described in claim 1, characterized in that, The policy key It consists of the policy key components of all leaf nodes, and the calculation process of the policy key component of each leaf node v is as follows: For each non-leaf node v, a random (t) is generated. v -1) degree polynomial Where t v The threshold for this node: For the root node r, let f r (0) = msk, which is the master private key. For other non-leaf nodes, set... Where p v cp is the parent node of node v. v (v) is the index value of node v in the set of child nodes of the parent node; Calculate the policy key component for each leaf node v Where a v This refers to the attribute value corresponding to the leaf node.

8. The smart contract access control method based on blockchain and attribute-based signatures as described in claim 6, characterized in that, The permission verification contract executes a verification algorithm to check whether the signature of the access token matches the requirements of the current attribute set and the policy NFT, specifically including: For each leaf node v in the access tree, check its attribute value a. v Does the user's attribute public key pk exist? ω If it exists, then calculate the verification component. Otherwise, mark it as invalid; Validating non-leaf nodes using a bottom-up approach, if a node has at least t child nodes... v If each verification component is valid, then the verification component of that node is calculated using Lagrange interpolation. If the verification component d of the root node r If it works, then further verification is needed. If the conditions are met, the user's attributes are deemed to satisfy the access policy, and the user is allowed to call the target contract; otherwise, access is denied.

9. A smart contract access control system based on blockchain and attribute-based signatures, characterized in that, The system includes: The transaction layer, access control contract layer, business contract layer, and consensus layer are as follows: The transaction layer includes three types of access control transactions: strategy transactions, attribute transactions, and contract transactions; The access control contract layer includes four types of smart contracts: access control policy management contract, user attribute management contract, permission verification contract, and policy NFT management contract, wherein: Access control policy management contracts are used to convert the access policies of business contracts into policy keys; The user attribute management contract is used to register user attributes to the blockchain and generate unique attribute keys for users based on the attribute values; The access control policy management contract uses the policy key generated by the access control policy management contract to verify the legitimacy of the access token in order to check whether the user has the right to invoke the business contract; The policy NFT management contract is used to visualize and dynamically manage policies by encapsulating policy keys as dynamic NFTs. The business contract layer consists of smart contracts with different functions released by blockchain platform developers. The business contracts are called by users to complete the business functions specified in the contract code. The consensus layer is mainly composed of a consensus mechanism consisting of various consensus algorithms to ensure the consistency of policy keys generated by different types of business contracts and attribute keys generated by users in a distributed environment.

10. A computing device, characterized in that, The computing device includes a processor and a memory, the memory being used to store a computer program, the computer program including program instructions, and the processor being configured to invoke the program instructions to execute the method as described in any one of claims 1 to 8.

Images