Blockchain-based user behavior attribute access control method

Abstract

The present application relates to the technical field of blockchain, and particularly relates to a user behavior attribute access control method based on blockchain, wherein the PolicyManager contract and the AttributeAuthority contract are used to respectively manage access control strategies and user attribute information, and a version number is maintained for each strategy and user key; then, when a user initiates an access request, the request is signed by using an attribute private key, the Gatekeeper performs a lightweight ABS algorithm to verify whether the signature meets the strategy, and issues an ECDSA access license after verification; finally, the user submits the license to the AccessDecision contract, the contract verifies the validity of the license, checks the version consistency and consumes the nonce, and returns an IPFS CID for the user to download data; the present application solves the technical problems of insufficient dynamic updating capability of strategies, large attribute verification overhead, insufficient user attribute privacy protection and weak trustworthiness of the access authorization process in the prior art.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain-based method for access control of user behavior attributes. Background Technology

[0002] With the rapid development of digital office and cloud computing, enterprises and organizations are continuously generating a large amount of user behavior data (such as login logs, file access records, etc.). This data is not only the foundation of security audits but also a sensitive resource. Existing access control methods mainly include discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based access control (ABAC).

[0003] While ABAC can perform fine-grained authorization based on subject, object, and environmental attributes, traditional ABAC typically relies on centralized policy management components, posing a single point of failure risk and making it difficult to guarantee reliable auditing of the access process. In recent years, blockchain technology has been introduced into the field of access control, utilizing smart contracts to achieve decentralization and immutability. However, existing blockchain-based access control schemes still face the following difficulties: First, policy updates are difficult: most schemes hardcode policies into smart contracts, and policy updates often require redeploying the contract, lacking flexibility. Second, attribute privacy leaks: traditional attribute verification usually requires recording user attributes in plaintext on the blockchain or comparing them on-chain, easily leading to user privacy leaks. Third, high on-chain computational overhead: complex attribute verification algorithms (such as attribute-based signature verification) are computationally intensive; executing them directly on-chain results in extremely high gas consumption and verification latency, making them impractical.

[0004] Therefore, there is an urgent need for a new blockchain-based user behavior attribute access control method to solve the technical problems of insufficient dynamic policy update capability, high attribute verification overhead, insufficient protection of user attribute privacy, and weak trustworthiness of access authorization process in existing technologies. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain-based user behavior attribute access control method, which aims to solve the technical problems of insufficient dynamic policy update capability, high attribute verification overhead, insufficient protection of user attribute privacy, and weak credibility of access authorization process in the existing technology.

[0006] To achieve the above objectives, the present invention provides a blockchain-based user behavior attribute access control method, comprising:

[0007] S1 is based on smart contracts on the blockchain. It maintains a policy version number for each access control policy and a user key version number for each user's attribute key. When the policy content or user attributes are updated, the policy / attribute status and its corresponding version information on the chain are updated without redeploying the smart contract. During the access authorization process, the current policy version number and user key version number are bound to the access credential. The on-chain decision verifies the version consistency. If they are inconsistent, access is denied.

[0008] S2 employs a lightweight attribute-based signature algorithm based on SM2 elliptic curves. Users use their attribute private keys to sign access requests and generate attribute signatures. Verifiers use attribute public keys and policy keys to verify whether the signatures meet the access policy.

[0009] S3 employs a complex, lightweight ABS verification performed by an off-chain trusted entity. Once the verification is successful, the off-chain trusted entity issues a lightweight access license. The user then submits a request to the on-chain smart contract with this license. The contract only needs to perform lightweight ECDSA signature verification and version number verification.

[0010] In step S1, the smart contract includes an AttributeAuthority contract, a PolicyManager contract, and an AccessDecision contract. The AttributeAuthority contract, as the attribute authority, is responsible for managing the user's public key and attribute information; the PolicyManager contract, as the policy manager, is responsible for managing access control policies and policy keys; and the AccessDecision contract, as the policy decision-maker, is responsible for access control decisions and access record management. IPFS is used as the distributed storage system to store encrypted user behavior data.

[0011] Specifically, step S1 includes:

[0012] The policy version number is automatically incremented with each policy update, and the policy version number is bound to the policy scope.

[0013] Maintain a monotonically increasing key version number for each user, and automatically update the user's key version when the user's attributes change;

[0014] When issuing an access license, Gatekeeper obtains the current policy version number and user key version number from the PolicyManager contract and the AttributeAuthority contract, and encodes these two version numbers into the license;

[0015] When verifying a license, the AccessDecision contract checks whether the version number in the license matches the current version number on the blockchain. If the versions do not match, the access request is rejected.

[0016] Specifically, step S2 includes:

[0017] The Setup algorithm takes security parameters as input and outputs system parameters and the master key.

[0018] An access tree structure is constructed based on the access control policy. The access tree consists of multiple nodes. Leaf nodes represent a single attribute, while internal nodes are logical operators and contain threshold parameters. By parsing the policy string, the access tree is constructed and a polynomial is generated. The policy key is generated through polynomial operations.

[0019] Generate an attribute key that includes an attribute private key and an attribute public key based on the user attribute set;

[0020] When a user initiates an access request, they use their attribute private key to sign the access request message and generate an attribute signature.

[0021] The verifier uses the policy key and the user attribute public key to verify the signature submitted by the user and determine whether the user meets the access policy requirements.

[0022] The specific steps involved in inputting security parameters and outputting system parameters and the master key using the Setup algorithm include:

[0023] During the system initialization phase, security parameters are input using the Setup algorithm. The output is system parameters. and master key The curve parameters were obtained using the SM2 national standard curve P-256. ,in For prime number fields, and For the parameters of the curve equation, Based on, With the order of the base point, the time complexity of this process is O(1), and only one random number generation operation is performed. The calculation formula is as follows:

[0024] .

[0025] The specific steps for generating an attribute key, including an attribute private key and an attribute public key, based on a user attribute set include:

[0026] For each user attribute First, calculate the attribute key parameters:

[0027]

[0028] Then generate the attribute public key:

[0029]

[0030] Generated attribute private key for:

[0031]

[0032] in, The algorithm's time complexity is O(n^2), which is the sum of all attribute keys. ),in The number of user attributes.

[0033] When a user initiates an access request, they sign the access request message using their attribute private key. The specific steps for generating the attribute signature include:

[0034] When a user initiates an access request, they use their attribute private key to sign the access request message and generate an attribute signature:

[0035]

[0036] in For the message, For the user's attribute private key, the signature result Contains two values and By calling the SM2 signature algorithm, first randomly select... ,calculate Calculate separately:

[0037]

[0038] in:

[0039]

[0040]

[0041] in .

[0042] The specific steps by which the verifier uses the policy key and the user attribute public key to verify the signature submitted by the user and determine whether the user meets the access policy requirements include:

[0043] For each leaf node of the access tree, if the user possesses the attribute, a verification point is calculated. :

[0044]

[0045] For each internal node, aggregate the verification results of its child nodes; if the number of child nodes meets the threshold... Then, Lagrange interpolation is used for calculation:

[0046]

[0047] If the root node meets the threshold condition, then calculate the final verification point and verify the SM2 signature:

[0048]

[0049]

[0050] Finally, let's verify if the signature is valid:

[0051]

[0052]

[0053]

[0054]

[0055] if If the result is positive, the verification passes; otherwise, the verification fails.

[0056] Specifically, step S3 includes:

[0057] On the user side, the user constructs an access request based on the log to be accessed, signs the request message with their own attribute private key to generate a user signature userSig, and submits the access request and signature result to the off-chain verification component Gatekeeper.

[0058] During the off-chain verification phase, after receiving a user request, Gatekeeper queries the current access policy, public key information, and corresponding version number from the on-chain PolicyManager contract and AttributeAuthority contract, and calls the lightweight ABS for verification. When the Permit is consumed, the nonce will be updated. If the verification fails, the access request will be rejected directly. If the verification succeeds, the access permit will be signed and issued to the user and returned to the user.

[0059] During the on-chain access decision phase, the user submits the Permit to the AccessDecision contract. The AccessDecision contract verifies the validity of the Permit. If the verification conditions are met, the AccessDecision contract calls the LogIndex contract to query the content identifier (CID) corresponding to the target log and returns the result to the off-chain IPFS. Otherwise, the access request will be directly rejected.

[0060] During the log retrieval phase, IPFS uses the CID returned by the contract to find the corresponding log data and returns it to the user.

[0061] The user behavior attribute access control method based on blockchain of the present invention has the following advantages compared with the prior art:

[0062] (1) A versioned management mechanism based on smart contracts is proposed by mapping the PAP, AA, and PDP of traditional ABAC to blockchain smart contracts. This mechanism supports dynamic updates of policies and attributes without redeploying the contracts by maintaining a version number for each access control policy and user attribute key, which significantly improves the flexibility of the system. At the same time, by binding the currently valid policy version and user key version to the access license, it effectively prevents attackers from using old credentials to access resources through time windows, thereby improving the security and maintainability of the access control system.

[0063] (2) This invention employs a lightweight attribute-based signature algorithm, which, referencing the attribute-based signature concept, designs a lightweight attribute signature verification mechanism based on the SM2 curve. This significantly reduces key size and computational complexity. In terms of policy expression, an access tree structure is used to support flexible combinations of AND, OR, and threshold policies. Threshold verification of the access tree is achieved through threshold secret sharing and Lagrange interpolation. Users sign access requests using their attribute private keys, and verifiers only need the attribute public key and policy key to verify whether the user meets the policy requirements. The user's specific attribute values ​​are never uploaded to the blockchain. This design changes the traditional "plaintext attribute judgment" to a "signature verification" mechanism, providing more comprehensive protection for user attribute privacy.

[0064] (3) This invention establishes a two-stage authentication architecture of off-chain verification and on-chain decision-making. First, the Gatekeeper role is introduced as an off-chain trusted entity, responsible for performing computationally intensive lightweight ABS attribute signature verification. Subsequently, after successful verification, the Gatekeeper issues a lightweight ECDSA access license, and the user obtains the resource identifier in the on-chain AccessDecision contract using the license. The on-chain contract only needs to verify the ECDSA signature, check version consistency, and consume the nonce. By binding parameters such as policy version, user key version, nonce, deadline, chainId, and contract address to the license, and adopting a hybrid storage architecture of IPFS and blockchain, this design ensures the high performance and security of the access control system, effectively improving the practicality and applicability of the method. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0066] Figure 1 This is an architecture diagram of the blockchain-based user behavior attribute access control method of the present invention.

[0067] Figure 2 This is a structural diagram of the versioning strategy management module of the present invention.

[0068] Figure 3 This is a structural diagram of the on-chain and off-chain dual authentication module of the present invention.

[0069] Figure 4 This is a schematic diagram of the blockchain-based user behavior attribute access control method of the present invention.

[0070] Figure 5 This is a flowchart of the blockchain-based user behavior attribute access control method of the present invention. Detailed Implementation

[0071] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, but should not be construed as limiting the present invention.

[0072] Please see Figures 1-5 This invention provides a blockchain-based user behavior attribute access control method, comprising:

[0073] S1 is based on smart contracts on the blockchain. It maintains a policy version number for each access control policy and a user key version number for each user's attribute key. When the policy content or user attributes are updated, the policy / attribute status and its corresponding version information on the chain are updated without redeploying the smart contract. During the access authorization process, the current policy version number and user key version number are bound to the access credential. The on-chain decision verifies the version consistency. If they are inconsistent, access is denied.

[0074] In this step, the smart contracts include the AttributeAuthority contract, the PolicyManager contract, and the AccessDecision contract. The AttributeAuthority contract, as the attribute authority, is responsible for managing the user's public key and attribute information; the PolicyManager contract, as the policy manager, is responsible for managing access control policies and policy keys; and the AccessDecision contract, as the policy decision-maker, is responsible for access control decisions and access record management. IPFS is used as the distributed storage system to store encrypted user behavior data.

[0075] Step S1 specifically includes:

[0076] S11 automatically increments the policy version number with each policy update and binds the policy version number to the policy scope;

[0077] S12 maintains a monotonically increasing key version number for each user and automatically updates the user's key version when the user's attributes change.

[0078] When issuing an access permit, S13 obtains the current policy version number and user key version number from the PolicyManager contract and the AttributeAuthority contract, and encodes these two version numbers into the permit;

[0079] When validating a license, the S14 AccessDecision contract checks whether the version number in the license matches the current version number on the chain. If the versions do not match, the access request is rejected.

[0080] S2 employs a lightweight attribute-based signature algorithm based on SM2 elliptic curves. Users use their attribute private keys to sign access requests and generate attribute signatures. Verifiers use attribute public keys and policy keys to verify whether the signatures meet the access policy.

[0081] Specifically, it includes:

[0082] S21 takes security parameters as input via the Setup algorithm and outputs system parameters and the master key; the specific steps include:

[0083] During the system initialization phase, security parameters are input using the Setup algorithm. The output is system parameters. and master key The curve parameters were obtained using the SM2 national standard curve P-256. ,in For prime number fields, and For the parameters of the curve equation, Based on, With the order of the base point, the time complexity of this process is O(1), and only one random number generation operation is performed. The calculation formula is as follows:

[0084] .

[0085] S22 constructs an access tree structure based on the access control policy. The access tree consists of multiple nodes. The leaf nodes represent a single attribute, while the internal nodes are logical operators and contain threshold parameters. By parsing the policy string, the access tree is constructed and a polynomial is generated. The policy key is generated through polynomial operations.

[0086] S23 generates an attribute key, including an attribute private key and an attribute public key, based on the user attribute set; the specific steps include:

[0087] For each user attribute First, calculate the attribute key parameters:

[0088]

[0089] Then generate the attribute public key:

[0090]

[0091] Generated attribute private key for:

[0092]

[0093] in, The algorithm's time complexity is O(n^2), which is the sum of all attribute keys. ),in The number of user attributes.

[0094] When user S24 initiates an access request, they use their attribute private key to sign the access request message and generate an attribute signature; the specific steps include:

[0095] When a user initiates an access request, they use their attribute private key to sign the access request message and generate an attribute signature:

[0096]

[0097] in For the message, For the user's attribute private key, the signature result Contains two values and By calling the SM2 signature algorithm, first randomly select... ,calculate Calculate separately:

[0098]

[0099] in:

[0100]

[0101]

[0102] in .

[0103] The S25 verifier uses the policy key and the user attribute public key to verify the signature submitted by the user and determine whether the user meets the access policy requirements. Specific steps include:

[0104] For each leaf node of the access tree, if the user possesses the attribute, a verification point is calculated. :

[0105]

[0106] For each internal node, aggregate the verification results of its child nodes; if the number of child nodes meets the threshold... Then, Lagrange interpolation is used for calculation:

[0107]

[0108] If the root node meets the threshold condition, then calculate the final verification point and verify the SM2 signature:

[0109]

[0110]

[0111] Finally, let's verify if the signature is valid:

[0112]

[0113]

[0114]

[0115]

[0116] if If the result is positive, the verification passes; otherwise, the verification fails.

[0117] S3 employs a complex, lightweight ABS verification performed by an off-chain trusted entity. Once the verification is successful, the off-chain trusted entity issues a lightweight access license. The user then submits a request to the on-chain smart contract with this license. The contract only needs to perform lightweight ECDSA signature verification and version number verification.

[0118] Specifically, it includes:

[0119] On the user side, S31 constructs an access request based on the log to be accessed, signs the request message with its own attribute private key to generate a user signature userSig, and submits the access request and signature result to the off-chain verification component Gatekeeper.

[0120] During the off-chain verification phase, after receiving a user request, Gatekeeper queries the current access policy, public key information, and corresponding version number from the on-chain PolicyManager contract and AttributeAuthority contract, and calls the lightweight ABS for verification. If the verification fails, the access request is directly rejected. If the verification succeeds, an access license Permit is signed and issued to the user and returned to the user.

[0121] In this step, the access permit must be bound to at least userAddr, logId, scopeKey, policyVersion, userKeyVersion, nonce, deadline, chainId, and the AccessDecision contract address. The AccessDecision contract completes ECDSA signature verification, deadline validity verification, one-time consumption of nonce, and version consistency verification. After the verification is successful, it returns the target log CID and records the access event.

[0122] In the on-chain access decision phase of S33, the user submits the Permit to the AccessDecision contract. The AccessDecision contract verifies the validity of the Permit. When the Permit is consumed, the nonce is updated. If the verification conditions are met, the AccessDecision contract calls the LogIndex contract to query the content identifier CID corresponding to the target log and returns the result to the off-chain IPFS. Otherwise, the access request will be directly rejected.

[0123] During the log retrieval phase, IPFS uses the CID returned by the contract to find the corresponding log data and returns it to the user.

[0124] To better understand this invention, a specific embodiment is provided below for detailed explanation. The overall architecture of the blockchain-based user behavior attribute access control method of this invention is as follows: Figure 1 As shown, it mainly consists of a strategy and attribute management module based on smart contracts, an attribute signature verification module based on lightweight ABS, and an on-chain and off-chain dual authentication module based on Gatekeeper.

[0125] The versioned policy management module is primarily used to address the difficulties in updating policies and the abuse of old permissions in traditional access control. Its specific structure is as follows: Figure 2 As shown. The specific implementation is as follows:

[0126] Policy version management ensures that the policy version number (policyVersion) is automatically incremented and bound to the policy scope (scopeKey) each time a policy is updated. This way, after a policy change, all access credentials (Permits) that rely on that policy will be validated based on the new version. Whenever an administrator updates a policy, the system ensures that old access credentials become invalid by updating the version number.

[0127] User key version management ensures that a user's attribute public key is always up-to-date by maintaining a monotonically increasing key version number (userKeyVersion) for each user. Whenever a user's attributes change, the contract automatically updates the user's key version, preventing attackers from bypassing access controls using expired attribute public keys.

[0128] The version binding mechanism ensures that each access credential (Permit) includes a `policyVersion` and a `userKeyVersion`. When issuing an access credential, Gatekeeper obtains the current policy version number and user key version number from the PAP and AA contracts and encodes these two version numbers into the permit. When verifying the permit, the AccessDecision contract checks whether the version number in the permit matches the current version number on the blockchain. If the versions do not match, the access request is rejected, effectively preventing time window attacks.

[0129] The lightweight attribute signature verification module addresses the problems of plaintext attribute leakage and high overhead of complex verification in traditional attribute access control. The specific implementation is as follows:

[0130] (1) During the system initialization phase, security parameters are input through the Setup algorithm. The output is system parameters. and master key The curve parameters were obtained using the SM2 national standard curve P-256. ,in For prime number fields, and For the parameters of the curve equation, Based on, Let the order of the base point be . The time complexity of this process is O(1), requiring only one random number generation operation. The calculation formula is as follows:

[0131]

[0132] (2) Construct an access tree structure based on the access control policy. The access tree consists of multiple nodes. The leaf nodes represent a single attribute, while the internal nodes are logical operators and contain threshold parameters. The access tree is constructed by parsing the policy string, and a polynomial is generated. Then, the policy key is generated through polynomial operations. The calculation formula is as follows:

[0133]

[0134] (3) Generate attribute keys based on the user attribute set, including attribute private keys and attribute public keys:

[0135]

[0136] For each user attribute First, calculate the attribute key parameters:

[0137]

[0138] Then generate the attribute public key:

[0139]

[0140] Generated attribute private key for:

[0141]

[0142] in, This is the sum of all attribute keys. The algorithm's time complexity is O(n). ),in The number of user attributes.

[0143] (4) When a user initiates an access request, they use their attribute private key to sign the access request message and generate an attribute signature:

[0144]

[0145] in For the message, For the user's attribute private key, the signature result Contains two values and By calling the SM2 signature algorithm, first randomly select... ,calculate Calculate separately:

[0146]

[0147] in:

[0148]

[0149]

[0150] in .

[0151] (5) The verifier uses the policy key and the user attribute public key to verify the signature submitted by the user and determine whether the user meets the access policy requirements:

[0152]

[0153] For each leaf node of the access tree, if the user possesses the attribute, a verification point is calculated. :

[0154]

[0155] For each internal node, aggregate the verification results of its child nodes; if the number of child nodes meets the threshold... Then, Lagrange interpolation is used for calculation:

[0156]

[0157] If the root node meets the threshold condition, then calculate the final verification point and verify the SM2 signature:

[0158]

[0159]

[0160] Finally, let's verify if the signature is valid:

[0161]

[0162]

[0163]

[0164]

[0165] if If the result is positive, the verification passes; otherwise, the verification fails.

[0166] The on-chain and off-chain dual authentication module is used to resolve the contradiction between limited on-chain computing resources and complex verification overhead. Its structure diagram is shown in Figure 3.

[0167] On the user side, the user constructs an access request based on the log to be accessed, signs the request message with their own attribute private key to generate a user signature userSig, and submits the access request and signature result to the off-chain verification component Gatekeeper.

[0168] During the off-chain verification phase, after receiving a user request, Gatekeeper queries the current access policy, public key information, and corresponding version number from the on-chain PolicyManager and AttributeAuthority contracts, and calls the lightweight ABS for verification. If verification fails, the access request is directly rejected; if verification succeeds, an access permit (Permit) is signed and issued to the user and returned. Gatekeeper's design does not store the user's attribute private key; it only obtains the user's attribute public key and policy key for verification, thus effectively avoiding the leakage of the user's sensitive information.

[0169] During the on-chain access decision phase, the user submits a Permit to the AccessDecision contract. The contract verifies the validity of the Permit, primarily checking the signature validity, expiration deadline, the user's current nonce, and whether the policy version and user key version are consistent. If all conditions are met, the AccessDecision contract calls the LogIndex contract to query the Content Identifier (CID) corresponding to the target log and returns the result to the off-chain IPFS; otherwise, the access request is directly rejected.

[0170] During the log retrieval phase, IPFS locates the corresponding log data based on the CID returned by the contract and returns it to the user, thus completing the entire access control process. The AccessDecision contract recalculates and verifies the digest on-chain, so any tampering with the Permit field will cause verification failure. The version binding mechanism ensures that Permits issued under old policies or old attribute states become invalid after version updates. The nonce and deadline are used to prevent replay attacks and limit the effective time window of the license, respectively. Through these security mechanisms, the on-chain and off-chain dual authentication modules not only reduce the overhead of performing complex cryptographic verification on-chain but also ensure the trustworthiness and security of the access control process.

[0171] This dual authentication mechanism places complex attribute signature verification off-chain, while only executing lightweight verification logic on-chain. This significantly reduces on-chain computation costs while ensuring the trustworthiness of the access process.

[0172] The main method flow of this invention is as follows: Figure 4-5 As shown, the specific description is as follows:

[0173] (1) Off-chain user side: The user obtains the scope identifier scopeKey corresponding to the log to be accessed, and reads the current nonce from the chain. The user constructs a message m to be signed based on userAdder, logId, scopeKey, nonce and deadline, and signs the message using its own attribute private key to generate the user signature userSig.

[0174] (2) Off-chain Gatekeeper verification side: Gatekeeper receives the access request submitted by the user, reads the current policy version, user key version, policy public key and user public key from the chain, and calls the lightweight ABS verification algorithm to verify the user signature. If the attribute signature submitted by the user fails the verification, the system directly returns access denial; if the verification passes, Gatekeeper binds the fields such as userAdder, logId, scopeKey, policyVersion, userKeyVersion, nonce and deadline to generate permitHash, and uses its own ECDSA private key to align the signature to generate the access permit permitSig.

[0175] (3) On-chain decision-making and storage: The user submits the access request to the AccessDecision contract. The contract first verifies the validity of permitSig, and then checks in sequence whether the deadline has expired, whether the nonce matches, and whether the policyVersion and userKeyVersion are still consistent with the current on-chain state. Only when all conditions are met is it deemed valid, and the user nonce is updated. The contract calls the LogIndex contract to query the content identifier CID corresponding to the target log, and the user obtains the corresponding encrypted log content from IPFS based on the CID.

[0176] In summary, this method comprises three core smart contracts: the AttributeAuthority contract, acting as the Attribute Authority (AA), manages users' public keys and attribute information; the PolicyManager contract, acting as the Policy Manager (PAP), manages access control policies and policy keys; and the AccessDecision contract, acting as the Policy Decision Provider (PDP), manages access control decisions and access records. IPFS is used as the distributed storage system to store encrypted user behavior data. This method includes the following mechanisms:

[0177] (1) Versioning Strategy and Attribute Management Mechanism: Access control policies and user attribute keys are maintained with corresponding version numbers. When the policy content or user attributes are updated, only the on-chain version information needs to be updated, without redeploying the smart contract. During the access authorization process, the current policy version number and user key version number are bound to the access credential. On-chain decision-making verifies version consistency; if inconsistent, access is denied, thus solving the problem of dynamic policy updates and preventing the reuse of old credentials after policy updates (time window attack).

[0178] (2) Lightweight ABS attribute-based signature verification mechanism: A lightweight attribute-based signature algorithm based on SM2 elliptic curves is adopted. Users sign access requests using attribute private keys. Verifiers only need to use attribute public keys and policy keys to verify whether the signature meets the access policy, without needing to know the user's specific attribute values. This significantly reduces key size and computational complexity while protecting user privacy.

[0179] (3) On-chain and off-chain dual authentication mechanism: Construct a two-stage architecture of "off-chain verification and on-chain decision-making". First, the off-chain trusted entity (Gatekeeper) performs complex lightweight ABS verification; after the verification is successful, Gatekeeper issues a lightweight access permit; the user submits a request to the on-chain smart contract with the permit, and the contract only needs to perform lightweight ECDSA signature verification and version number verification. This design places heavy computation off-chain and leaves only core auditing and decision-making on-chain, effectively reducing on-chain overhead.

[0180] The system administrator manages access control policies and user attribute information through the PolicyManager and AttributeAuthority contracts, respectively, and maintains a version number for each policy and user key. Then, when a user initiates an access request, the request is signed using the attribute private key. Gatekeeper executes a lightweight ABS algorithm off-chain to verify whether the signature meets the policy requirements, and issues an ECDSA access license after successful verification. Finally, the user submits the license to the AccessDecision contract. The contract verifies the validity of the license, checks version consistency, consumes the nonce, and returns an IPFS CID for the user to download the data.

[0181] This invention presents a blockchain-based user behavior attribute access control method. Through a versioned policy management mechanism, it achieves unified version control of access policies and user attribute keys, enabling dynamic policy updates and attribute adjustments without redeploying smart contracts, thus improving the flexibility and maintainability of the access control system. By employing a lightweight attribute-based signature mechanism, it transforms the traditional plaintext attribute matching method into a signature verification method, completing authorization determination without exposing specific user attribute values, effectively enhancing user attribute privacy protection. The method utilizes a dual authentication mechanism, performing complex attribute signature verification off-chain and lightweight license verification on-chain, ensuring the credibility and auditability of the authorization process while effectively reducing on-chain computational overhead and gas consumption. It effectively prevents time window attacks and replay attacks caused by policy updates, user attribute changes, or the reuse of old licenses, enhancing the security of the access control system. This invention solves the technical problems of insufficient dynamic policy update capabilities, high attribute verification overhead, insufficient user attribute privacy protection, and weak credibility of the access authorization process in existing technologies.

[0182] The above-disclosed embodiments are merely one or more preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art can understand that all or part of the processes for implementing the above embodiments and equivalent changes made in accordance with the claims of this application still fall within the scope of this application.

Claims

1. A blockchain-based user behavior attribute access control method, characterized in that, include: S1 is based on smart contracts on the blockchain. It maintains a policy version number for each access control policy and a user key version number for each user's attribute key. When the policy content or user attributes are updated, the policy / attribute status and its corresponding version information on the chain are updated without redeploying the smart contract. During the access authorization process, the current policy version number and user key version number are bound to the access credential. The on-chain decision verifies the version consistency. If they are inconsistent, access is denied. S2 employs a lightweight attribute-based signature algorithm based on SM2 elliptic curves. Users use their attribute private keys to sign access requests and generate attribute signatures. Verifiers use attribute public keys and policy keys to verify whether the signatures meet the access policy. S3 employs a complex, lightweight ABS verification performed by an off-chain trusted entity. Once the verification is successful, the off-chain trusted entity issues a lightweight access license. The user then submits a request to the on-chain smart contract with this license. The contract only needs to perform lightweight ECDSA signature verification and version number verification.

2. The blockchain-based user behavior attribute access control method as described in claim 1, characterized in that, In step S1, The smart contracts include the AttributeAuthority contract, the PolicyManager contract, and the AccessDecision contract. The AttributeAuthority contract, as the attribute authority, is responsible for managing the user's public key and attribute information; the PolicyManager contract, as the policy manager, is responsible for managing access control policies and policy keys; and the AccessDecision contract, as the policy decision-maker, is responsible for access control decisions and access record management. IPFS is used as the distributed storage system to store encrypted user behavior data.

3. The blockchain-based user behavior attribute access control method as described in claim 2, characterized in that, Step S1 specifically includes: The policy version number is automatically incremented with each policy update, and the policy version number is bound to the policy scope. Maintain a monotonically increasing key version number for each user, and automatically update the user's key version when the user's attributes change; When issuing an access license, Gatekeeper obtains the current policy version number and user key version number from the PolicyManager contract and the AttributeAuthority contract, and encodes these two version numbers into the license; When verifying a license, the AccessDecision contract checks whether the version number in the license matches the current version number on the blockchain. If the versions do not match, the access request is rejected.

4. The blockchain-based user behavior attribute access control method as described in claim 1, characterized in that, Step S2 specifically includes: The Setup algorithm takes security parameters as input and outputs system parameters and the master key. An access tree structure is constructed based on the access control policy. The access tree consists of multiple nodes. Leaf nodes represent a single attribute, while internal nodes are logical operators and contain threshold parameters. By parsing the policy string, the access tree is constructed and a polynomial is generated. The policy key is generated through polynomial operations. Generate an attribute key that includes an attribute private key and an attribute public key based on the user attribute set; When a user initiates an access request, they use their attribute private key to sign the access request message and generate an attribute signature. The verifier uses the policy key and the user attribute public key to verify the signature submitted by the user and determine whether the user meets the access policy requirements.

5. The blockchain-based user behavior attribute access control method as described in claim 4, characterized in that, The specific steps for using the Setup algorithm to input security parameters and output system parameters and the master key include: During the system initialization phase, security parameters are input using the Setup algorithm. The output is system parameters. and master key The curve parameters were obtained using the SM2 national standard curve P-256. ,in For prime number fields, and For the parameters of the curve equation, Based on, With the order of the base point, the time complexity of this process is O(1), and only one random number generation operation is performed. The calculation formula is as follows: 。 6. The blockchain-based user behavior attribute access control method as described in claim 5, characterized in that, The specific steps for generating an attribute key, including an attribute private key and an attribute public key, based on a user attribute set include: For each user attribute First, calculate the attribute key parameters: Then generate the attribute public key: Generated attribute private key for: in, The algorithm's time complexity is O(n^2), which is the sum of all attribute keys. ),in The number of user attributes.

7. The blockchain-based user behavior attribute access control method as described in claim 6, characterized in that, When a user initiates an access request, they sign the access request message using their attribute private key. The specific steps for generating the attribute signature include: When a user initiates an access request, they use their attribute private key to sign the access request message and generate an attribute signature: in For the message, For the user's attribute private key, the signature result Contains two values and By calling the SM2 signature algorithm, first randomly select... ,calculate Calculate separately: in: in .

8. The blockchain-based user behavior attribute access control method as described in claim 7, characterized in that, The verifier uses the policy key and the user attribute public key to verify the signature submitted by the user and determine whether the user meets the access policy requirements. The specific steps include: For each leaf node of the access tree, if the user possesses the attribute, a verification point is calculated. : For each internal node, aggregate the verification results of its child nodes; if the number of child nodes meets the threshold... Then, Lagrange interpolation is used for calculation: If the root node meets the threshold condition, then calculate the final verification point and verify the SM2 signature: Finally, let's verify if the signature is valid: if If the result is positive, the verification passes; otherwise, the verification fails.

9. The blockchain-based user behavior attribute access control method as described in claim 8, characterized in that, Step S3 specifically includes: On the user side, the user constructs an access request based on the log to be accessed, signs the request message with their own attribute private key to generate a user signature userSig, and submits the access request and signature result to the off-chain verification component Gatekeeper. During the off-chain verification phase, after receiving a user request, Gatekeeper queries the current access policy, public key information and corresponding version number from the on-chain PolicyManager contract and AttributeAuthority contract, and calls the lightweight ABS for verification. If the verification fails, the access request is directly rejected. If the verification is successful, an access license Permit is signed and issued to the user and returned to the user. During the on-chain access decision phase, the user submits the Permit to the AccessDecision contract. The AccessDecision contract verifies the validity of the Permit. When the Permit is consumed, the nonce is updated. If the verification conditions are met, the AccessDecision contract calls the LogIndex contract to query the content identifier CID corresponding to the target log and returns the result to the off-chain IPFS. Otherwise, the access request will be directly rejected. During the log retrieval phase, IPFS uses the CID returned by the contract to find the corresponding log data and returns it to the user.

Images