Fine-grained data dynamic access control method based on attribute-based encryption

Abstract

The invention relates to a fine-grained data dynamic access control method based on attribute-based encryption. The method comprises the steps of obtaining to-be-shared data, and performing symmetric encryption on the to-be-shared data according to a randomly generated symmetric encryption key to obtain a data ciphertext; based on an access control strategy, encrypting the symmetric encryption key by using an ABE encryption algorithm to obtain a convertible ciphertext header; in response to the obtained data access request, performing user identity verification according to a user identity public key and an access data identifier in the data access request based on a current system state version number, a revocation list and metadata of to-be-shared data in the smart contract of the block chain to obtain a verification result; and if the verification result is that the verification is passed, obtaining a corresponding convertible ciphertext header according to the access data identifier, and performing re-encryption processing on the convertible ciphertext header according to the proxy re-encryption private key, the current system state version number and the revocation list to obtain a new ciphertext header. By adopting the method, large-scale and frequent permission change can be dealt with.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data encryption access, and particularly relates to a fine-grained data dynamic access control method based on attribute-based encryption. BACKGROUND

[0002] With the development of cloud storage and blockchain technology, attribute-based encryption (ABE) appears to realize fine-grained data sharing technology, which allows data owners to define access policies based on attributes, realizes attribute-based access control and sharing by using ABE.

[0003] In the traditional technology, the permission management of ABE is mainly through the direct revocation method, that is, the user revocation list or invalid identifier is directly embedded in the ciphertext, when revocation occurs, the list needs to be modified or re-encrypted to update the affected ciphertext, or the indirect revocation method is used, that is, the revocation is realized by key update or ciphertext update, which usually depends on the authority to regularly issue key update materials, and the private key of the user who is not revoked is updated, or the corresponding update is performed on the ciphertext.

[0004] However, the above method, in a large-scale system using blockchain technology, a single permission change may affect tens of thousands or even millions of historical ciphertexts, resulting in a large range of synchronous re-encryption and massive blockchain writing, and further generating unbearable off-chain computing load and on-chain transaction overhead, forming a computing avalanche, in addition, the various ABE revocation schemes proposed by existing researches cannot provide effective buffering or asynchronous mechanisms to alleviate the direct linkage of revocation on historical massive data when used with blockchain, and thus are difficult to be practically applied in large-scale deployment. SUMMARY

[0005] Therefore, it is necessary to provide a fine-grained data dynamic access control method based on attribute-based encryption which can cope with large-scale and frequent permission changes.

[0006] In a first aspect, the application provides a fine-grained data dynamic access control method based on attribute-based encryption, comprising:

[0007] Obtaining the data to be shared, and performing symmetric encryption on the data to be shared according to a randomly generated symmetric encryption key to obtain data ciphertext; the data ciphertext is stored in a cloud storage server through a corresponding storage identifier;

[0008] Based on a pre-defined access control policy, the symmetric encryption key is encrypted using an ABE encryption algorithm to obtain a convertible ciphertext header containing a proxy public key ciphertext component, and the hash corresponding to the access control policy, the hash corresponding to the proxy public key ciphertext component and the current system state version number are stored as metadata of the data to be shared in the smart contract of the blockchain;

[0009] In response to a data access request, the current system state version number, revocation list, and metadata of the data to be shared in the blockchain-based smart contract are used to authenticate the user based on the user's identity public key and the data access identifier in the data access request, and the authentication result is obtained.

[0010] If the verification result is successful, the corresponding convertible ciphertext header is obtained based on the access data identifier. The convertible ciphertext header is then re-encrypted based on the agent's re-encryption private key, the current system status version number, and the revocation list to obtain a new ciphertext header. The new ciphertext header is used by the requesting user to decrypt the corresponding data ciphertext to recover the corresponding data to be shared.

[0011] In one embodiment, based on a predefined access control policy, the symmetric encryption key is encrypted using the ABE encryption algorithm to obtain a convertible ciphertext header containing a proxy public key ciphertext component, including:

[0012] A secret value is randomly generated based on the access control policy. ,in, prime number An integer field of order 1;

[0013] Based on the system master public key, access control policies, and secret value Running the attribute-based encryption algorithm yields the standard ciphertext component and the first core component. and the first public component ,in, For symmetric encryption keys, Multiplication cyclic group generator, It is a bilinear mapping. It is a component of the system's master private key;

[0014] Based on the proxy, the public key and secret value are re-encrypted. Compute proxy public key ciphertext component ,in, Re-encrypt the private key for the proxy;

[0015] The access control policy, standard ciphertext component, first core component, first public component, and proxy public key ciphertext component are encapsulated together to form a convertible ciphertext header.

[0016] In one embodiment, the method further includes:

[0017] Obtain the user's public key and its verifiable set of attributes, and run the attribute-based encryption user key generation algorithm on the attribute set based on the system master private key and the user's public key to obtain the attribute private key bound to the user's public key; the attribute-based encryption user key generation algorithm uses the hash value corresponding to the user's public key as a generation factor to bind the attribute private key to the user's public key.

[0018] Upon receiving a request to revoke the target user's identity, the system adds a revocation record to the revocation list based on the hash value of the user's public key and / or attribute private key corresponding to the request, and updates the system status version number.

[0019] In one embodiment, the metadata of the current system state version number, revocation list, and data to be shared in the blockchain-based smart contract is used to authenticate the user based on the user's public key and access data identifier in the data access request, resulting in an authentication result including:

[0020] Based on the access data identifier, the metadata of the corresponding data to be shared is obtained from the smart contract of the blockchain, and the corresponding convertible ciphertext header is obtained from the cloud storage server;

[0021] Calculate the hash corresponding to the access control policy in the convertible ciphertext header and the hash corresponding to the proxy public key ciphertext component, and compare them with the hash corresponding to the access control policy and the hash corresponding to the proxy public key ciphertext component in the metadata to obtain the data integrity verification result;

[0022] The identity validity is verified based on the zero-knowledge proof of the user's identity public key, and the identity validity verification result is obtained. The zero-knowledge proof is used to prove that the user has an attribute private key bound to the user's identity public key, and that the set of verifiable attributes corresponding to the attribute private key meets the access control policy requirements.

[0023] If both the data integrity verification result and the identity validity verification result are successful, check if there is a revocation record in the revocation list identified by the hash value of the user's identity public key, and check if there is a revocation record identified by each attribute of the verifiable attribute set whose corresponding system status version number is not greater than the current system status version number, and obtain the verification result; if all checks are unsuccessful, the verification result is successful.

[0024] In one embodiment, the corresponding convertible ciphertext header is obtained based on the access data identifier, and the convertible ciphertext header is re-encrypted based on the proxy re-encryption private key, the current system state version number, and the revocation list to obtain a new ciphertext header, including:

[0025] The intermediate secret value is calculated based on the proxy re-encrypted private key and the proxy public key ciphertext component in the convertible ciphertext header.

[0026] Randomized state factors are generated based on the current system state version number and the cancellation list;

[0027] The new ciphertext component is constructed based on the intermediate secret value, the state factor, the convertible ciphertext header and the revocation list, and the partially re-encrypted intermediate ciphertext is generated according to the new ciphertext component; the new ciphertext component includes the second core component and the second public component restructured from the first core component and the first public component, and the attribute ciphertext component obtained by performing consistency transformation on the standard ciphertext component;

[0028] The state token is generated based on the state factor and the revocation list; the state token contains the generator of the multiplicative cyclic group corresponding to the state factor and the revocation state proof for the user identity public key and the attribute set thereof;

[0029] The intermediate ciphertext and the state token are combined to obtain the new ciphertext header.

[0030] In one of the embodiments, the attribute ciphertext component obtained by performing consistency transformation on the standard ciphertext component includes:

[0031] The original component pair of each attribute in the access control policy corresponding to the standard ciphertext component is obtained , wherein , , is the i th attribute, is a hash function, is the secret sharing value of the intermediate secret value on the attribute node ; and The adjustment value related to the revocation state and the state factor is calculated for each attribute based on the revocation list; the adjustment value satisfies that for an attribute set

[0032] , if the attribute set satisfies the access control policy A, there exist reconstruction coefficients such that , wherein is a function determined by the revocation list and the attribute set, when all attributes in the attribute set are not revoked , otherwise is a randomization value.

[0033] The attribute ciphertext component is obtained by adjusting the original component pair according to the adjustment value.

[0034] In one of the embodiments, the request user decrypts the corresponding data ciphertext according to the new ciphertext header to recover the corresponding data to be shared by the following method:

[0035] After verifying that the revocation state proof in the new ciphertext header is not revoked in the revocation list corresponding to the current system state version number, the attribute private key bound to the user identity public key is used to perform decryption calculation on the intermediate ciphertext to obtain a symmetric encryption key;

[0036] ​​The symmetric encryption key is obtained by the following formula:

[0037]

[0038]

[0039]

[0040] wherein, is a reconstruction factor; is a correction factor; is a second core component; is an attribute set; is a reconstruction coefficient corresponding to the attribute , and are a component pair of an attribute ciphertext component; the attribute private key pair attribute contains components and ; is a bilinear mapping; is a generator of a multiplicative cyclic group corresponding to a state factor pair; is a part of the attribute private key related to a component of the system master private key;

[0041] The symmetric decryption is performed on the data ciphertext by using the recovered symmetric encryption key to obtain the to-be-shared data.

[0042] In a second aspect, the application further provides a fine-grained data dynamic access control device based on attribute-based encryption, comprising:

[0043] A data encryption module is configured to obtain to-be-shared data, and perform symmetric encryption on the to-be-shared data according to a randomly generated symmetric encryption key to obtain data ciphertext; the data ciphertext is stored in a cloud storage server through a corresponding storage identifier;

[0044] A ciphertext header module is configured to encrypt the symmetric encryption key by using an ABE encryption algorithm based on a predefined access control policy to obtain a convertible ciphertext header containing an agent public key ciphertext component, and store a hash corresponding to the access control policy, a hash corresponding to the agent public key ciphertext component and a current system state version number as metadata of the to-be-shared data in a smart contract of a blockchain;

[0045] A data access module is configured to, in response to obtaining a data access request, perform user identity authentication according to a user identity public key and an access data identifier in the data access request based on a current system state version number, a revocation list and metadata of the to-be-shared data in the smart contract of the blockchain to obtain an authentication result;

[0046] The proxy re-encryption module is used to obtain the corresponding convertible ciphertext header based on the access data identifier if the verification result is successful. Then, it re-encrypts the convertible ciphertext header based on the proxy re-encryption private key, the current system status version number, and the revocation list to obtain a new ciphertext header. The new ciphertext header is used by the requesting user to decrypt the corresponding data ciphertext to recover the corresponding data to be shared.

[0047] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above-described fine-grained data dynamic access control methods based on attribute-based encryption.

[0048] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the above-described fine-grained data dynamic access control methods based on attribute-based encryption.

[0049] The aforementioned fine-grained dynamic data access control method based on attribute-based encryption combines symmetric encryption and attribute-based encryption to encrypt and protect data. It anchors the access control policy and the hashes of key ciphertext components, along with the system state version number, to the blockchain as metadata. When a user requests access, the system verifies the user's identity and attributes based on the latest system state version number and revocation list maintained in the blockchain smart contract. Upon successful verification, instead of directly using the original ciphertext, the system uses a proxy re-encryption private key, combined with the current revocation state, to perform immediate, on-demand re-encryption of the original ciphertext header, generating a new ciphertext header incorporating the latest permission state for the user to decrypt. This constitutes the core mechanism of lightweight on-chain recording of permission changes and on-demand off-chain triggering of ciphertext conversion. This transforms the heavy computational and on-chain storage load of traditional solutions, which require immediate batch re-encryption of massive amounts of historical ciphertext due to permission revocation, into distributed and lightweight instantaneous re-encryption operations that occur with each actual access request. While ensuring forward security and fine-grained access control, it completely avoids computational avalanche and blockchain performance bottlenecks, achieving efficient, dynamic, and scalable secure data sharing. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a flowchart illustrating the fine-grained dynamic data access control method based on attribute-based encryption of the present invention.

[0052] Figure 2 This is a flowchart illustrating the steps of step S103.

[0053] Figure 3 This is a flowchart illustrating the steps of step S104.

[0054] Figure 4 This is a structural diagram of the fine-grained data dynamic access control device based on attribute-based encryption according to the present invention. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0056] In one embodiment, such as Figure 1 As shown, a fine-grained dynamic data access control method based on attribute-based encryption is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0057] S101. Obtain the data to be shared, and symmetrically encrypt the data to be shared using a randomly generated symmetric encryption key to obtain the ciphertext; the ciphertext is stored in the cloud storage server using the corresponding storage identifier.

[0058] Indicatively, the acquisition of shared data supports multi-source input scenarios, including local file system reading, distributed file storage retrieval, and API interface reception. Data types cover text, structured database files, audio / video streams, and binary firmware. Optionally, during the acquisition process, cyclic redundancy check (CR) ensures data transmission integrity, preventing loss or tampering of original data. The check mechanism generates a check value by performing a polynomial operation on the transmitted data, and the receiving end verifies data consistency through the same operation. The generation of the symmetric encryption key is fundamental to ensuring data confidentiality. A cryptographically secure random number generator conforming to the NIST SP 800-132 standard can be used; for example, CTR-DRBG, or Counter Mode Deterministic Random Bit Generator, is selected. The seed entropy source is derived from hardware noise and software entropy sources. Hardware noise includes physical random signals such as processor temperature sensors and memory access latency, while software entropy sources include dynamic system information such as system process IDs and network packet timestamps. The generated symmetric encryption key... The length meets the security requirements of the AES-GCM algorithm, that is, the key length conforms to the symmetric encryption security standard.

[0059] Symmetric encryption operations strictly adhere to the AES-GCM specification. This mode provides both confidentiality and integrity protection. Specifically, it generates an initialization vector that conforms to the best practice length of GCM. The length of the initialization vector balances security and performance, avoiding the risk of duplication due to being too short or the impact of efficiency due to being too long. The data to be shared is encrypted using the CTR mode of the AES algorithm to obtain the ciphertext body. The CTR mode generates an encrypted stream by incrementing a counter, achieving high efficiency in stream encryption. Subsequently, the authentication function of GCM is used to perform authentication calculations on the initialization vector, encryption algorithm parameters, and additional authentication data to generate an authentication tag. The additional authentication data here is the filename and creation timestamp of the data to be shared, used to bind the ciphertext and data metadata to prevent malicious replacement of the ciphertext. Data Ciphertext The structure is defined as an initialization vector, including the ciphertext body and an authentication tag. Each part is separated by a fixed length to facilitate parsing during decryption. The separation method is based on the preset length field of each component. The encryption process calls the hardware acceleration interface of the open-source cryptographic library and utilizes the CPU's built-in AES-NI instruction set to improve encryption efficiency. For large-scale files, a block encryption strategy is adopted. The block size is dynamically adapted according to the data size and memory performance. Each block generates an independent temporary initialization vector. Finally, the ciphertext of each block is associated through the block index to avoid excessive memory consumption when loading large files at once.

[0060] Encrypted data storage and identification management can balance availability and security. When selecting cloud storage servers, prioritize commercial or private cloud storage services that support access control lists and server-side encryption, such as AWS S3, Alibaba Cloud OSS, or self-built MinIO clusters. Storage Identification The generation uses a composite algorithm with negligible hash collision probability. ,in The public key of the user DO who owns the data is used to uniquely identify the subject to which the data belongs. Create timestamps for the data to distinguish data generated by the same owner at different times; This is the SHA-256 hash value of the original data, used to ensure the uniqueness of the data content. The generated hash... The data is converted to a string format using Base64 encoding to ensure the uniqueness and readability of the identifier. Base64 encoding converts binary hash values ​​into printable characters, facilitating storage and transmission. When the encrypted data is uploaded to cloud storage, it is encrypted using the TLS protocol to ensure that the data is not eavesdropped on or tampered with during transmission. The cloud storage server enables server-side encryption mechanisms, such as SSE-S3 or a compatible encryption scheme, to protect the data on the storage medium. The data is encrypted again, creating a double encryption protection system for both transmission and storage. After the upload is complete, the cloud storage server returns a response containing... The response information includes the storage path and upload timestamp. The data owner can verify the information in the response. Ensure the uploaded value matches the locally generated value to guarantee accuracy, then... The association between the data and the encrypted data is cached locally for use when subsequent metadata is uploaded to the blockchain.

[0061] S102. Based on a predefined access control policy, the symmetric encryption key is encrypted using the ABE encryption algorithm to obtain a convertible ciphertext header containing the proxy public key ciphertext component. The hash corresponding to the access control policy, the hash corresponding to the proxy public key ciphertext component, and the current system state version number are stored as metadata of the data to be shared in the blockchain's smart contract.

[0062] Indicatively, access control policies can adopt fine-grained and scalable expressions, preferably using a linear secret sharing scheme matrix as the mathematical carrier of the policy. The policy logic supports AND, OR, NOT, and threshold operations, such as the logical judgment of "a specified number of multiple attributes satisfying the condition". (Department: R&D) Job Rank: Senior Taking "Role: Project Manager" as an example, the specific process of constructing its linear secret sharing scheme matrix involves transforming the strategy into a disjunctive paradigm, that is, for "(Department: R&D)..." Job Rank: Senior Role: Project Manager. Each conjunct term constructs a submatrix. The first submatrix corresponds to "Department: R&D". The first submatrix, "Job Level: Senior," has one row and one column, corresponding to the number of attributes and the number of secret values ​​and their auxiliary variables. Matrix elements define the rules for splitting secret values, ensuring that only users who simultaneously satisfy two attributes can reconstruct secret values ​​through share allocation. The second submatrix, "Role: Project Manager," has one row and one column, with single coefficients representing secret values ​​directly assigned to that attribute. The final linear secret sharing scheme matrix is ​​a vertical concatenation of the two submatrixes. The set of attributes for the strategy is clearly defined through the mapping between matrix row indices and attribute strings.

[0063] The ABE encryption algorithm employs a ciphertext policy attribute-based encryption framework, with the encryption process using a symmetric encryption key. With the core as the key, combined with the proxy re-encryption public key Generate convertible ciphertext header Specifically, the data owner obtains the public key for the trusted proxy re-encryption service from the system registry. ,in , for Generators of a group For a large prime number Multiplication cyclic group, This is the proxy re-encryption private key for the trusted proxy re-encryption service. This private key is sealed and stored in a trusted execution environment such as a TEE. A secret value is randomly selected. , For a large prime number The integer field is used to compute the core ciphertext components. The expression for the first core component is: ,in This is a symmetric encryption key used to encrypt data to be shared; This represents a bilinear mapping, and its mapping relationship is: , To and The corresponding pairing group, bilinear mapping, possesses three major properties: bilinearity, nondegeneracy, and computability. yes The generators of the group serve as the fundamental elements of the bilinear mapping; It is the core secret value of the system master private key MSK, used to generate global encryption parameters; It is a randomly selected secret value used to achieve randomness in encryption. The expression for the first common component is: This component is used to reconstruct the secret value during subsequent decryption. Based on the linear secret sharing scheme matrix, for each matrix row... Corresponding attributes Calculate two standard ciphertext components. The expression for the first standard ciphertext component is: The expression for the second standard ciphertext component is: ,in, The first element of the row vector of the matrix. The second element of the matrix row vector, together with the first element, defines the secret value. Share in the corresponding attribute, The SHA-256 hash function is used to hash attribute strings. Mapped to Group elements ensure the association between attributes and cryptographic groups. Furthermore, a proxy re-encryption component is introduced. ,in, For the proxy public key, A random secret value. This component provides a "hook" for on-demand reencryption of the private key via a proxy, ensuring the transmissibility of the ciphertext. Ultimately... The complete structure is a linear secret sharing scheme matrix. Components , proxy components Standard Ciphertext Components Collection Each component is serialized using the ASN.1 encoding rule, which facilitates consistent parsing during storage and transmission. ASN.1 defines the data structure through clear syntax rules, ensuring compatibility between different systems.

[0064] The generation and on-chaining of metadata are crucial for achieving state traceability. Metadata includes hashes of access control policies. Hash of the proxy public key ciphertext component Current system status version number . The matrix of the serialized linear secret sharing scheme is calculated using the SHA-256 hash function, thus avoiding the leakage of privacy by sending the policy in plaintext on the blockchain. Similarly, SHA-256 is used to serialize the data. The calculation is used for subsequent trusted proxy re-encryption services to verify the integrity of the ciphertext; The version lookup function of the smart contract is used to obtain the metadata, ensuring a strong bond between the metadata and the system state. The metadata upload process is implemented through blockchain transactions; when the data owner constructs a transaction, they can package the metadata into... , , , The structure, using its own private key The transaction is signed using ECDSA, employing a curve conforming to the elliptic curve cryptography standard. The signature information is appended to the end of the transaction and used by blockchain nodes to verify the identity of the transaction initiator. After the transaction is sent to the blockchain network, miners or endorsing nodes verify the legality of the transaction signature and the data owner's permissions through the permission verification function in the smart contract. The transaction is then packaged into a block, and the contract's metadata storage function is executed to store the metadata in the contract. In the mapping structure, that is ,in for The SHA-256 hash value is used for fast indexing of metadata. for The structure contains three core fields of metadata. Once a transaction is successfully recorded on the blockchain, the smart contract executes automatically. The atomic operations ensure that the system state version number monotonically increases, providing a baseline for the association between subsequent undo events and ciphertext states.

[0065] S103. In response to receiving a data access request, based on the current system state version number, revocation list, and metadata of the data to be shared in the blockchain smart contract, user authentication is performed according to the user identity public key and access data identifier in the data access request, and the authentication result is obtained.

[0066] Data access requests are initiated by data users. The structure of the request message meets security and integrity requirements, and it is encapsulated in JSON format, including: the user's public key. Access Data Identifier timestamp Random numbers Zero-knowledge proof Digital signatures of data users .in, The proof data generated for the Groth16 algorithm includes , , Three components are used to prove that a data user possesses attributes that comply with the policy without revealing specific attribute information; For user private keys Except for the request message All fields except the request itself are ECDSA-signed to verify the integrity of the request and the identity of the initiator. For example, the request is sent via HTTPS to the access gateway of the trusted proxy re-encryption service. The gateway first verifies the validity of the request's timestamp by comparing it with the local time of the trusted proxy re-encryption service to ensure the time difference is within a reasonable threshold, preventing replay attacks. Further verification... The uniqueness of the trusted proxy re-encryption service maintains a recent one. The cache pool uses a distributed cache service for storage and is automatically cleaned up when expired. If the request already exists, it will be rejected.

[0067] The trusted proxy re-encryption service executes verification logic within a trusted execution environment enclave. Specifically, it calls the smart contract's query function via the blockchain node's JSON-RPC interface to obtain the current system state version number. Call the undo list query function to get the complete list. The list uses an append-only storage structure to record all undo events, including undo records for attributes. , With revocation records related to user identity ,in, To revert the system state version number at the time the event occurred; call the metadata query function to retrieve the version number from the request. Use the index to retrieve the corresponding , , .

[0068] As an illustration, in the identity and attribute verification process, the trusted proxy re-encryption service first verifies the registration status of the data user by querying the user registry on the blockchain to check... The system checks whether registration has been completed and whether the registration information is valid. The user registry stores the association between the user's public key and their list of authorized attributes. Furthermore, it verifies the validity of zero-knowledge proofs. Proofs generated by the Groth16 algorithm satisfy specific pairwise equality verifications. The trusted proxy re-encryption service calls the proof verification interface in the cryptography library, inputting public parameters and... , , If the component passes validation, it indicates that the data user possesses a set of attributes that satisfy the access policy. Furthermore, it did not disclose specific attribute values. Undo status checks can be combined with... and The execution logic for checking user identity is as follows: retrieval. Does it exist in China? For the record identified, if it exists, compare its... and ,like This indicates that the user has been revoked; the logic for checking attributes involves iterating through the set of user attributes. Each attribute in retrieval Does a corresponding record exist in the database? If it does, then... This indicates that the attribute has been revoked.

[0069] Encryption integrity verification requires the integration of cloud storage services and blockchain metadata. Trusted proxy re-encryption services are based on… Get the corresponding from cloud storage service and First of all Perform ASN.1 deserialization to extract the linear secret sharing scheme matrix. With proxy components ,calculate and Subsequently, with data obtained from the blockchain , A comparison is performed; if they match, it indicates that the ciphertext has not been tampered with; otherwise, the data access request is rejected. All verification steps are completed within a trusted execution environment to ensure that the verification process is not subject to malicious external interference. Verification results are divided into two categories: pass and rejection. Verification passes if the user registration is valid, the zero-knowledge proof is legitimate, it has not been revoked, and the ciphertext is complete; verification is rejected if any of these conditions are not met.

[0070] S104. If the verification result is successful, obtain the corresponding convertible ciphertext header according to the access data identifier, and re-encrypt the convertible ciphertext header according to the agent re-encryption private key, the current system status version number and the revocation list to obtain a new ciphertext header; the new ciphertext header is used for the requesting user to decrypt the corresponding data ciphertext to recover the corresponding data to be shared.

[0071] As an illustration, when the verification result is successful, the Trusted Proxy Re-encryption Service (TPRS) performs a convertible ciphertext header. The acquisition and preprocessing operations, specifically, TPRS uses access data identifiers. For indexing, a request to retrieve the encrypted header is sent to the cloud storage server (CSS) via HTTPS protocol. The request message contains... The TPRS identity certificate and timestamp are used to ensure the authenticity and replay resistance of the request. Upon receiving the request, CSS verifies the validity of the TPRS identity certificate and then retrieves the encrypted index table stored locally. For a hash table with keys, locate The storage path will The data is returned to TPRS as a binary stream via the TLS 1.3 protocol. Furthermore, TPRS processes the received data within a Trusted Execution Environment (TEE). Preprocessing is performed, namely, the ASN.1 deserialization operation is executed to parse out the Linear Secret Sharing Scheme (LSSS) matrix. Components and Proxy components and attribute ciphertext component collection This ensures that each component conforms to the preset cryptographic structure specifications. To further eliminate the risk of potential tampering during transmission, TPRS is recalculated. SHA-256 hash value and obtained from blockchain smart contracts The two are compared; if they do not match, the process is terminated and an exception log is recorded; if they match, confirmation is performed. If the data is complete and unaltered, it can proceed to the subsequent re-encryption stage.

[0072] Proxy re-encrypts private key Secure calls are a prerequisite for re-encryption processing. The sealed key is stored in the protected memory of the TEE and protected using the TEE's key management mechanism. Before re-encryption is initiated, TPRS triggers the key desealing process through authorized instructions within the TEE: The TEE first verifies the legitimacy of the current re-encryption task, i.e., checks whether the task context was initialized within the enclave and whether it has key access permissions. Then, it calls the hardware encryption engine and uses the root key bound to the TEE to deseal the sealed key. Decrypt, and then... A temporary secure memory area is loaded into the enclave, and this memory region is only accessible to the re-encryption algorithm process, prohibiting other processes from reading or modifying it, to ensure... It will not leak during use. The core of the re-encryption process is to ensure that the original... Transform into the current system state Withdrawal List New encrypted header of the information Specifically, from Extracting intermediate values Without revealing the secret value , TPRS utilizes Perform the inverse operation of group elements This operation is based on The multiplicative inverse property of a group, due to Regarding The result of the inverse operation is TPRS can only obtain Unable to pass Reverse deduction At the same time, they cannot access the symmetric encryption key. This ensures that TPRS only has ciphertext conversion capabilities and no data decryption permissions. Furthermore, a state difference factor is constructed. With The revocation information and the current system state are encoded as cryptographic factors and incorporated into the new ciphertext component to ensure that the revoked user or attribute cannot be decrypted. The construction is based on the LSSS matrix and bilinear mapping; specifically, TPRS analysis. Filter out in to Valid revocation events occurring during the period are The revocation record maps the revocation event to an "invalid row identifier" in the LSSS matrix. Specifically, for attribute revocation, the row corresponding to the attribute is marked; for user revocation, the row matching the user's attribute set is marked. TPRS randomly selects a state secret. This secret is only bound to the current re-encryption task and is used to encode the current system state. The generation uses CSPRNG to ensure randomness. This is based on invalid row identifiers and... Construct state difference factor Simultaneously generate with Corresponding auxiliary verification components , The core secret value of the system master private key MSK. Used to verify the validity of the status when users decrypt the data later.

[0073] Furthermore, the generation of new ciphertext components, in which, and The expressions for the new components are as follows: , ,in Incorporating primal secrets With state secrets , Then The encryption scope has been expanded to This ensures that only users who have passed the status verification can solve the problem. Secondly, update the standard ciphertext component set. For "valid rows" in the LSSS matrix that have not been marked with undo events, the original components remain unchanged; for "invalid rows" that have been marked, based on... The component was adjusted, and the adjusted property component expression is as follows: , The adjusted attribute component ensures that the share corresponding to the revoked attribute cannot participate in secret reconstruction, thus preventing the revoked user from decrypting. New ciphertext header. The assembly includes the re-encrypted ciphertext body. ,Include , , , and includes a status verification token , Its purpose is to provide user verification. The corresponding system status validity is determined by factors including the current system status version number. Merkel's proof of the withdrawal list TPRS digital signature. Based on The constructed Merkle tree verification path allows users to quickly verify whether a specific revocation event has been recorded on the chain; TPRS digital signatures employ... corresponding private key Generate, signature object is hash value and The splicing result, i.e. This signature is used for user authentication. Whether it was generated by a legitimate TPRS and whether it has been tampered with. Ultimately... The structure is After being encoded using ASN.1, it is stored in the temporary memory of the TEE. (This is incomplete.) After generation, TPRS performs the delivery operation of the new ciphertext header and data ciphertext. Specifically, it retrieves the data from the cloud storage server. Corresponding to the original data ciphertext ,Will and The information is returned to the requesting user (DU) via the TLS 1.3 protocol. Optionally, to ensure traceability of the delivery process, TPRS may selectively include key information from this access event. , , , The hash value is recorded in the smart contract's audit log via blockchain transactions. Transactions can be signed with the TPRS private key, and after the smart contract verifies the signature, the information is stored in the AccessLog mapping structure. , For transaction hash, This is a structure containing access event information, for use in subsequent auditing or dispute tracing. (User access) and Afterwards, the data to be shared can be recovered through a local decryption process. Specifically, verification... In Signature with TPRS, confirmation The legitimacy and integrity of the state are ensured by using its own attribute private key. Execute the ABE decryption algorithm to In , , Perform calculations and reconstruct the structure using the properties of bilinear mappings. And then from Solution ; Use last right Perform AES-GCM decryption to obtain the data to be shared, thus completing the entire access process.

[0074] The aforementioned fine-grained dynamic data access control method based on attribute-based encryption completely eliminates the "computation avalanche" problem caused by a single permission change in the traditional permission revocation mechanism by decoupling the storage of encrypted data from permission status management and changing the encrypted update from "active batch" to "on-demand single". The ciphertext obtained through symmetric encryption is independently stored on a cloud storage server, associated only by a storage identifier. Core permission-related information is generated using ABE encryption to create a convertible ciphertext header containing a proxy public key ciphertext component. Metadata only records the access control policy hash, the proxy public key ciphertext component hash, and the system state version number, and is stored in a blockchain smart contract. This ensures that revocation operations cannot trigger synchronous re-encryption of any historical ciphertext; only the revocation list and system state version number are updated on the blockchain. When a user initiates a data access request, targeted re-encryption is performed on the convertible ciphertext header of the target file based on the latest system state and revocation list. This transforms the original O(N) level computational overhead, proportional to the number of affected files, into an O(k) level overhead proportional to the number of actual data access requests, effectively supporting stable system operation in scenarios with large-scale and frequent permission changes. Simultaneously, by storing only lightweight metadata and revocation records on the blockchain, it avoids the explosive growth of on-chain transactions caused by massive ciphertext updates in traditional solutions, significantly reducing on-chain storage load and transaction gas consumption, eliminating the blockchain state bloat problem, and greatly improving the feasibility of technology implementation. By employing a proxy re-encryption mechanism to achieve on-demand conversion of ciphertext, and combining this with the blockchain's immutable storage of metadata and revocation records, the global auditability and unforgeability of permission states are ensured. Forward security is guaranteed by instantly incorporating the latest revocation state when re-encryption is triggered by a data access request. Backward security relies on the cryptographic security of the attribute-based encryption algorithm itself and the strong binding relationship between data encryption and key management, effectively resisting security risks such as permission forgery and ciphertext tampering. Data owners can complete a revocation operation by submitting only a simple on-chain record transaction, without waiting for the re-encryption process of massive amounts of historical ciphertext; the data will be returned instantly. The storage of ciphertext is independent of the amount of historical data, and the processing of data access requests is only for a single target file. This makes the overall system performance no longer constrained by the scale of historical data, enabling smooth support for massive data storage and flexible adjustments to complex dynamic access strategies. By storing the hash value of access control policies on the blockchain instead of plaintext, and combining it with compliance verification of user identity and attributes during the data access request verification process, the public disclosure of specific access policies and user attribute details is avoided. While achieving fine-grained access control, it fully protects the policy privacy of data owners and the attribute privacy of users. This results in a high-performance, scalable, secure, reliable, and privacy-protected data sharing and access control solution, effectively solving the core performance bottleneck caused by permission revocation in the blockchain and attribute-based encryption combined system.

[0075] In one embodiment, based on a predefined access control policy, the symmetric encryption key is encrypted using the ABE encryption algorithm to obtain a convertible ciphertext header containing a proxy public key ciphertext component, including:

[0076] S11. Randomly generate a secret value according to the access control policy. ,in, prime number An integer field of order 1.

[0077] Secret Value The generation of [something] can be adapted to the logical structure of the access control policy, ensuring its randomness and cryptographic security. The access control policy, while defining attribute association rules, also [does something else]. The generation provides a security context, specifically, From prime numbers Integer field of order Selected from, The selection can be related to the bilinear mapping group determined during the system initialization phase ( , To ensure the closure and validity of subsequent group operations, the order of the random number generator is kept consistent. The generation process employs a cryptographically secure random number generator (CSPRNG), which uses hardware noise and software dynamic information as entropy sources to avoid... Insufficient randomness leads to encryption vulnerabilities, resulting in... It is only used temporarily during this encryption process and will be removed from memory immediately after encryption is complete to prevent leakage.

[0078] S12, based on the system master public key, access control policy, and secret value. Running the attribute-based encryption algorithm yields the standard ciphertext component and the first core component. and the first public component ,in, For symmetric encryption keys, Multiplication cyclic group generator, It is a bilinear mapping. It is a component of the system's master private key.

[0079] Furthermore, the system master public key is a public parameter generated during the global initialization phase, containing... , , These key elements provide the basic cryptographic environment for ABE encryption. When running the attribute-based encryption algorithm, the access control policy is transformed into a mathematically computable form, such as an LSSS matrix. The algorithm generates standard ciphertext components based on the correspondence between the matrix's row vectors and attributes. These components are typically in the form of a set. The algorithm exists in a specific form, with each element corresponding to an attribute in the strategy, used for subsequent verification of whether the user possesses that attribute. Simultaneously, the algorithm incorporates a symmetric encryption key. Bilinear mapping , Group generator Components of the system master private key and secret value The first core component and the first common component are calculated. middle, It is an encryption factor constructed based on bilinear mapping, which will With system secret parameters Temporary secret value Deep binding ensures Only users with matching attributes can decrypt it; First common component It serves as a "bridge" for reconstructing secret-related information during subsequent decryption; its value is public but cannot be deduced. This provides support for verifying the secret share during decryption.

[0080] S13. Re-encrypt the public key and secret value based on the proxy. Compute proxy public key ciphertext component ,in, Re-encrypt the private key for the proxy.

[0081] Proxy re-encryption public key It is the public identity identifier of the Trusted Proxy Re-encryption Service (TPRS), which was previously generated and published within the Trusted Execution Environment (TEE) through TPRS. , The TPRS agent's private key is re-encrypted and stored in a sealed container within the TEE. The agent's public key ciphertext component is then computed. At that time, it can be With secret value Perform group exponent operation, i.e. This operation strictly follows The rules of group multiplication ensure Still belongs to Group elements. Provides technical support for subsequent re-encryption: TPRS can use its own private key right Perform partial decryption to obtain Thus, without contact and Adjust the ciphertext state under the premise of [the following conditions].

[0082] S14. The access control policy, standard ciphertext component, first core component, first public component and proxy public key ciphertext component are encapsulated together to form a convertible ciphertext header.

[0083] The encapsulation operation integrates access control policies, standard ciphertext components, the first core component, the first public component, and the proxy public key ciphertext component into structured data, ensuring logical coherence and consistent formatting across all parts. The access control policy can be incorporated in a parsable format to ensure accurate extraction of attribute association rules during subsequent verification. The standard ciphertext component, the first core component, and the first public component are core elements of traditional ABE encryption, guaranteeing basic attribute verification and key encryption functions; the proxy public key ciphertext component... This is the key new addition, which gives the ciphertext a "convertible" property, allowing it to adapt to subsequent dynamic permission adjustments.

[0084] In one embodiment, the method further includes:

[0085] S21. Obtain the user's public key and its verifiable set of attributes, and run the attribute-based encryption user key generation algorithm on the attribute set based on the system master private key and the user's public key to obtain the attribute private key bound to the user's public key; the attribute-based encryption user key generation algorithm uses the hash value corresponding to the user's public key as a generation factor to bind the attribute private key to the user's public key.

[0086] When requesting access permissions, users submit their public key and a verifiable set of attributes to the key distributor (i.e., the data owner or an independent attribute authority). The attribute set is presented as an attribute certificate, which can be signed by an authority and contains user attribute information and a signature validity period, used to prove the authenticity of the attributes. The key distributor can verify the validity of the attribute set by checking the signature of the attribute certificate and verifying its validity period, thus eliminating forged or expired attribute information. After confirming the validity of the attributes, the key distributor invokes the Attribute-Based Encryption (ABE) user key generation algorithm. This algorithm uses the system master private key, the user attribute set, and the hash value of the user's public key as core input parameters. To achieve a strong binding between the attribute private key and the user's public key, the algorithm incorporates the hash value of the user's public key as a generation factor into the key generation process. Specifically, a cryptographically secure hash function is used to hash the user's public key to obtain a fixed-length hash value. This hash value is collision-resistant and one-way, and can uniquely identify a user's public key. Secret components in the system master private key The components of the attribute private key are generated by merging and calculating the group elements corresponding to the attribute, that is, for each attribute... key fragment The final generated attribute private key is deeply bound to the user's identity public key. This means that if another user obtains this attribute private key, they will be unable to provide the corresponding user identity private key for matching. This will prevent the private key from being used for decryption, effectively preventing key misuse or illegal transfer.

[0087] S22. Upon receiving a request to revoke the target user's request, add a revocation record to the revocation list based on the hash value of the user's identity public key and / or attribute private key corresponding to the request, and update the system status version number.

[0088] When access permissions for a specific user can be revoked, such as when a user leaves the company or their permissions expire, the entity with the revocation authority initiates a request to revoke the target user's access. This request can clearly identify the object to be revoked. Specifically, if revoking the permissions for the entire user, the identifier is the user's public key; if revoking permissions for a specific attribute, the identifier is the hash value of the attribute's associated private key. Upon receiving the revocation request, the key distributor or smart contract verifies the requester's authority through digital signature verification, confirming the initiator's eligibility to perform the revocation operation. Subsequently, a revocation record is appended to a pre-defined revocation list. This record contains the unique identifier of the object to be revoked—the user's public key or attribute private key hash value—and the current system version number—the system version at the time of the revocation operation. This is used to determine the effectiveness of the revocation during subsequent access verification. The revocation list uses an append-only storage model, without deleting historical records, ensuring the traceability of revocation actions and providing a complete log for subsequent auditing. After adding the revocation record, the system version number can be updated immediately. For example, the current version number can be adjusted according to a monotonically increasing rule, and the new version number will serve as the status benchmark for all subsequent encryption and access verification operations. This version number update mechanism does not modify the historical encrypted data. It only marks the change in system permission status by changing the version number. When a user accesses data later, the system status version number at the time of access can be compared with the version number in the revocation record to determine whether the user's permission has been revoked.

[0089] In one embodiment, such as Figure 2 As shown, the current system state version number, revocation list, and metadata of the data to be shared in the blockchain-based smart contract are used to authenticate the user based on the user's public key and access data identifier in the data access request, resulting in the following verification results:

[0090] S201. Obtain the metadata of the corresponding data to be shared from the smart contract of the blockchain according to the access data identifier, and obtain the corresponding convertible ciphertext header from the cloud storage server.

[0091] Access Data Identifier It is a unique index for locating target data. The Trusted Proxy Re-encryption Service (TPRS) uses this identifier as a core parameter to call the smart contract's metadata query function through the blockchain node's JSON-RPC interface, retrieving data from the contract's metadata. In the mapping structure, metadata corresponding to the data to be shared is extracted, including the hash value of the access control policy, the hash value of the proxy public key ciphertext component, and the system state version number at the time of data encryption. Simultaneously, the verification subject, based on the access data identifier, initiates a request to the cloud storage server to obtain a convertible ciphertext header via the TLS encryption protocol. The request includes the verification subject's identity certificate. After verifying the certificate signature and validity period, the cloud storage server retrieves the convertible ciphertext header bound to the access data identifier locally and returns it to the verification subject in binary stream form.

[0092] S202. Calculate the hash corresponding to the access control policy in the convertible ciphertext header and the hash corresponding to the proxy public key ciphertext component, and compare them with the hash corresponding to the access control policy in the metadata and the hash corresponding to the proxy public key ciphertext component to obtain the data integrity verification result.

[0093] Furthermore, the verification entity performs structured parsing on the convertible ciphertext header to extract the access control policy and the proxy public key ciphertext component. Cryptographically secure hash functions are used to perform hash operations on both types of information. For example, for access control policies, the hash value is calculated on the serialized policy content. For the proxy public key ciphertext component, directly to Calculate hash value from binary data The calculated , The access control policy hash corresponding to the metadata obtained from the smart contract. Proxy public key ciphertext component hash Perform byte-level comparison one by one: if the two sets of hash values ​​are completely consistent, it indicates that the convertible ciphertext header has not been tampered with or replaced during storage and transmission, and the data integrity verification result is passed; if any set of hash values ​​is inconsistent, it is determined that the ciphertext has been corrupted, the verification process is immediately terminated and the anomaly is recorded.

[0094] S203. Verify the identity validity based on the zero-knowledge proof of the user's identity public key to obtain the identity validity verification result; the zero-knowledge proof is used to prove that the user has an attribute private key bound to the user's identity public key, and that the set of verifiable attributes corresponding to the attribute private key meets the access control policy requirements.

[0095] Zero-knowledge proofs are pre-generated by the requesting user. They can verify two core facts without exposing the specific content of the user's attribute private key or revealing details of the verifiable attribute set: the user possesses an attribute private key strongly bound to their identity public key, and the set of verifiable attributes corresponding to this private key satisfies the access control policy of the data to be shared. The verification entity, within a Trusted Execution Environment (TEE), invokes the zero-knowledge proof verification algorithm, inputting pre-defined public parameters, including the LSSS matrix information of the access control policy, components related to the system master public key, and the proof data submitted by the user. , , The component verifies whether the data satisfies the equation through a bilinear mapping operation. If the verification passes, it indicates that the user's attribute private key is valid and the attribute set meets the access requirements, and the identity validity verification result is passed. If the verification fails, it determines that the user does not have the legitimate access qualifications and rejects subsequent operations.

[0096] S204. If both the data integrity verification result and the identity validity verification result are successful, check whether there is a revocation record identified by the hash value of the user's identity public key in the revocation list, and check whether there is a revocation record identified by each attribute of the verifiable attribute set whose corresponding system status version number is not greater than the current system status version number, and obtain the verification result; when all checks are unsuccessful, the verification result is successful.

[0097] If both data integrity verification and identity validity verification pass, the verification entity can further retrieve the revocation list from the blockchain smart contract. Specifically, calculate the hash value of the requesting user's public key. The system uses the hash value as the key to query the revocation list. If a corresponding revocation record exists, it indicates that the user's account has been globally revoked, and the verification result is "rejected." If no revocation record exists for the user's identity, the system iterates through each attribute in the user's verifiable attribute set, using the attribute string as the key to query the revocation list one by one. For existing attribute revocation records, the system status version number in the record can be compared. With the current system status version number ,like If the attribute is revoked before the data access request is initiated, the user cannot meet the access policy due to the lack of a valid attribute, and the verification result is rejected. If there is no corresponding revocation record for any attribute, and the version number of the existing record is greater than the current version number, the revocation has not taken effect. Then the revocation status check is deemed to have passed, and the final overall verification result is that the verification has passed.

[0098] In one embodiment, such as Figure 3As shown, the corresponding convertible ciphertext header is obtained based on the access data identifier, and then re-encrypted based on the proxy re-encryption private key, the current system state version number, and the revocation list to obtain a new ciphertext header, including:

[0099] S301. Based on the proxy re-encryption private key, calculate the intermediate secret value according to the proxy public key ciphertext component in the convertible ciphertext header.

[0100] The proxy re-encryption private key is a core key that was previously stored within the Trusted Execution Environment (TEE), and its value is... ( , prime number The ciphertext contains an integer field and is always sealed within the protected memory of the TEE, allowing only re-encryption procedure calls and preventing its export. The proxy public key ciphertext component in the convertible ciphertext header is... Its initial generation logic is as follows When calculating the intermediate secret value, the private key is re-encrypted using a proxy. right Perform the inverse operation of group elements, based on The multiplicative inverse property of a group, through get This value is the intermediate secret value.

[0101] S302. Generate randomized state factors based on the current system state version number and the cancellation list.

[0102] This example illustrates how to filter "valid" revocation events in the revocation list, meaning records whose corresponding system state version number is not greater than the current system state version number. These records represent revocation operations that have taken effect up to the current time. A cryptographically secure random number generator (CSPRNG) is used to generate random numbers. ,Will By fusing the identifier of the valid revocation event with the randomized state factor, a randomized state factor is obtained, denoted as . The randomness of the state factor ensures that the factor generated in each re-encryption is unique, preventing attackers from inferring the ciphertext pattern through repeated factors; while the association with the revocation list ensures that the state factor carries the validity information of the current permissions, providing a basis for subsequent decryption verification.

[0103] S303. Construct a new ciphertext component based on the intermediate secret value, state factor, convertible ciphertext header and revocation list, and generate a partially re-encrypted intermediate ciphertext based on the new ciphertext component; the new ciphertext component includes a second core component and a second common component reconstructed from the first core component and the first common component, as well as an attribute ciphertext component obtained by performing a consistency transformation on the standard ciphertext component.

[0104] The construction of the new ciphertext component can be based on an intermediate secret value, a state factor, the original convertible ciphertext header component, and a reversal list. The core is to reconstruct and transform the original ciphertext component, incorporating the current state information. For the core component, the original first core component is... Combined with intermediate secret value With state factors The second core component was obtained through reconstruction. The original first public component is The second common component is obtained through reconstruction. Both are achieved by using the original secret value Expand to This allows for the integration of the current state factors. For standard ciphertext components, this is the original set of attribute ciphertext components. Consistency transformation can be performed using a cancellation list. This involves filtering out components corresponding to attributes unrelated to valid cancellation events and preserving their original structure; for components corresponding to attributes associated with valid cancellation events, a state factor can be used. The transformation ensures that components with revoked attributes cannot participate in subsequent decryption. After all the new ciphertext components are integrated, they form a partially re-encrypted intermediate ciphertext. This ciphertext is capable of adapting to the current system permission state, but can be verified in conjunction with a status token.

[0105] S304. Generate a verifiable state token based on the state factor and the cancellation list; the state token contains the multiplicative cyclic group corresponding to the state factor. The generator and the revocation status proof for the user's identity public key and its attribute set.

[0106] State factor corresponding Group generator association value, i.e. This value is used by the user in conjunction with their own attribute private key during decryption to complete the decryption of the second core component. The decryption calculation, specifically for proving the revocation status of the user's public key and its attribute set, employs a Merkle proof. This involves constructing a Merkle tree based on the revocation list, extracting the verification path of the user's public key hash and attribute identifiers within the Merkle tree, and forming the proof data. Users can quickly verify their identity and attributes to ensure they are on the revocation list using this certificate, and can download the complete revocation list if none is available, reducing verification overhead. Furthermore, the status token can be signed with the private key of the proxy re-encryption service, ensuring the token has not been tampered with or forged.

[0107] S305. Combine the intermediate ciphertext with the status token to obtain the new ciphertext header.

[0108] The partially re-encrypted intermediate ciphertext is structurally integrated with the generated state token to form a new ciphertext header.

[0109] In one embodiment, the attribute ciphertext component obtained by performing a consistency transformation on the standard ciphertext component includes:

[0110] S31. Obtain the original component pairs of each attribute within the access control policy corresponding to the standard encrypted component. ,in , , For the first One attribute, For hash functions, The intermediate secret value in the attribute node The secret sharing value on it.

[0111] Standard ciphertext components are attribute-associative encrypted fragments generated based on access control policies in the early stages. Their core form is the original component pair of each attribute within the corresponding policy. Each component is associated with the first access control policy. Attributes Binding, in which and The expressions correspond to the intermediate secret values ​​in the attribute nodes. The results of the secret sharing on the platform intermediate secret value In the attribute node The secret sharing value follows the sharing rules of the Linear Secret Sharing Scheme (LSSS), ensuring that the set of attributes that satisfy the policy can reconstruct the original secret through the sharing value; Multiplication cyclic group generator, A pre-defined cryptographically secure hash function is used to hash attribute strings. Mapped to Elements within a group allow attribute information to be incorporated into cryptographic operations.

[0112] S32. Based on the cancellation list, calculate the adjustment value related to the cancellation state and state factor for each attribute; the adjustment value satisfies the following conditions for a set of attributes. If the attribute set satisfies access control policy A, then a reconstruction coefficient exists. Make ,in It is a function determined by the undo list and the property set; it is active when all properties in the property set have not been undoed. ,otherwise This is a randomized value.

[0113] The generation of adjustment values ​​can be closely linked to the permission status of the revocation list records, ensuring that the transformed component only allows the normal use of attribute sets that have not been revoked and meet the access control policy. A refactoring coefficient can be introduced during the calculation process. AND function , It is for satisfying access control policies attribute set ,Right now The combination of attributes conforms to the reconstruction coefficients set by the strategy logic and follows the reconstruction rules of LSSS, ensuring... The equation holds true. For each attribute node An adjustment index, defined as the adjustment value, is associated with the secret sharing value and the revocation status. State factor; This is used to identify the undo status of an attribute, when the attribute set... If none of the attributes are recorded in the revocation list, or if the recorded revocation version number is greater than the current system state version number, At this point, the equation satisfies the conventional secret reconstruction condition; if the attribute set If the system contains a "revoked" attribute (i.e., a corresponding record exists in the revoked list and its version number is not greater than the current system state version number), then... Set as Randomized values ​​within the group prevent the equation from satisfying normal reconstruction logic, thus preventing revoked attributes from participating in decryption. The calculation of adjustment values ​​can strictly adhere to this consistency condition, ensuring that the transformed component accurately reflects the revocation state.

[0114] S33. Adjust the original component pair according to the adjustment value to obtain the attribute encrypted component.

[0115] Furthermore, based on the adjustment values ​​calculated above... For each attribute, the corresponding original component pair Perform targeted transformations. Adjustments can preserve component properties. The binding relationship is established, and the effects of undoing state information and state factors are integrated into the component. .

[0116] In one embodiment, the user is requested to decrypt the corresponding ciphertext based on the new ciphertext header to recover the corresponding data to be shared using the following method:

[0117] S41. After verifying that the revocation status proof in the new ciphertext header has not been revoked in the revocation list of the corresponding current system status version number, use the attribute private key bound to the user's identity public key to perform decryption calculation on the intermediate ciphertext to obtain the symmetric encryption key.

[0118] The symmetric encryption key can be obtained using the following formula:

[0119]

[0120]

[0121]

[0122] in, Reconstruction factor; As a correction factor; As the second core component; A collection of attributes; For the corresponding attribute The reconstruction coefficients, and For component pairs of encrypted attributes; for attribute private key pairs of attributes. Includes components and ; It is a bilinear mapping; The multiplicative cyclic group corresponding to the state factor Generators; The component of the attribute private key that is related to the system master private key. The relevant parts.

[0123] As an illustration, the state token contained in the new ciphertext header carries a revocation state proof, which is a concise verification credential generated based on the current system state version number and the revocation list. Before decryption, the user is requested to verify the validity and relevance of this proof. Specifically, the user accesses the blockchain smart contract to obtain the complete revocation list corresponding to the current system state version number, compares the key information in the revocation state proof with the revocation list, and confirms that their own user identity public key does not appear in the user's revocation record, and that all attributes in the verifiable attribute set corresponding to the attribute private key do not appear in the attribute revocation record. Only when the revocation state verification passes, indicating that the user currently has legitimate access rights, will the subsequent decryption calculation proceed; if the verification fails, the decryption process is terminated directly to avoid invalid calculations.

[0124] After the revocation status verification is successful, the user is requested to invoke the local decryption algorithm, using the attribute private key bound to their own user identity public key to perform decryption calculations on the intermediate ciphertext. The core process involves deriving the symmetric encryption key through a preset formula. Specifically, the attribute private key is configured for each attribute... It contains two core components and ,in Used to match ciphertext components , Used to match the adjusted attribute ciphertext component ; This refers to a subset of user attributes that satisfy the access control policy, i.e., only... Only attributes within the specified data can participate in the decryption calculation; For the corresponding attributes The reconstruction coefficients are determined by the Linear Secret Sharing Scheme (LSSS) matrix of the access control policy and are used to reconstruct the secret share of each attribute into complete secret information. The multiplicative cyclic group corresponding to the state factor The generator, derived from the state token in the new ciphertext header, is used to incorporate the current system state to adapt to the revocation rules; The component of the attribute private key that is related to the system master private key. The relevant fixed components are the key inputs for calculating the correction factor; The second core component is the encrypted result obtained by fusing the original symmetric encryption key with system secret information and state factors. Among them, the reconstruction factor... In and The association between the ciphertext component and the private key component is established through bilinear mapping, and the ratio of the two eliminates irrelevant interference terms. Then, through... The weights of each attribute are adjusted by exponentiation, and the final product yields the information that can reconstruct the intermediate secret information. Correction factor Through bilinear mapping generator of state factors With private key component By association, the components of the system's master private key are obtained. Related correction terms compensate for additional factors introduced by state updates in the intermediate ciphertext. Symmetric encryption key. The calculation process is achieved through offsetting The system secrets and state factors contained within are used to ultimately reconstruct the original symmetric encryption key, and this is only possible if the user attributes meet the policy and the encryption has not been revoked. and Only then can accurate calculations be performed to ensure the legitimacy of key recovery.

[0125] S42. Use the recovered symmetric encryption key to perform symmetric decryption on the ciphertext to obtain the data to be shared.

[0126] Furthermore, after requesting the user to obtain the encrypted data, the algorithm invokes the same symmetric encryption algorithm as the encryption phase, using the recovered symmetric encryption key as the decryption key input to the algorithm. During decryption, the algorithm first verifies the integrity of the encrypted data, confirming that the encrypted data has not been tampered with during storage or transmission. If the integrity verification passes, the algorithm decrypts the encrypted body of the encrypted data, restoring the original data to be shared. If the integrity verification fails, it indicates that the data may have been maliciously modified, and the decryption can be terminated with a data anomaly warning, ensuring the authenticity and validity of the data obtained by the user.

[0127] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0128] Based on the same inventive concept, this application also provides an attribute-based encryption-based fine-grained data dynamic access control device for implementing the attribute-based encryption-based fine-grained data dynamic access control method described above. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations of one or more attribute-based encryption-based fine-grained data dynamic access control device embodiments provided below can be found in the limitations of the attribute-based encryption-based fine-grained data dynamic access control method described above, and will not be repeated here.

[0129] In one exemplary embodiment, such as Figure 4 As shown, a fine-grained dynamic data access control device based on attribute-based encryption is provided, comprising:

[0130] The data encryption module 401 is used to acquire the data to be shared and to perform symmetric encryption on the data to be shared according to the randomly generated symmetric encryption key to obtain the ciphertext; the ciphertext is stored in the cloud storage server through the corresponding storage identifier;

[0131] The ciphertext header module 402 is used to encrypt the symmetric encryption key using the ABE encryption algorithm based on a predefined access control policy, to obtain a convertible ciphertext header containing a proxy public key ciphertext component, and to store the hash corresponding to the access control policy, the hash corresponding to the proxy public key ciphertext component, and the current system state version number as metadata of the data to be shared in the blockchain's smart contract.

[0132] The data access module 403 is used to respond to a data access request by using the current system state version number, revocation list and metadata of the data to be shared in the blockchain smart contract to authenticate the user based on the user identity public key and access data identifier in the data access request, and obtain the authentication result.

[0133] The proxy re-encryption module 404 is used to obtain the corresponding convertible ciphertext header based on the access data identifier if the verification result is successful, and to re-encrypt the convertible ciphertext header based on the proxy re-encryption private key, the current system status version number, and the revocation list to obtain a new ciphertext header; the new ciphertext header is used for the requesting user to decrypt the corresponding data ciphertext to recover the corresponding data to be shared.

[0134] In one embodiment, the ciphertext header module 402 is further configured to:

[0135] A secret value is randomly generated based on the access control policy. ,in, prime number An integer field of order 1;

[0136] Based on the system master public key, access control policies, and secret value Running the attribute-based encryption algorithm yields the standard ciphertext component and the first core component. and the first public component ,in, For symmetric encryption keys, Multiplication cyclic group generator, It is a bilinear mapping. It is a component of the system's master private key;

[0137] Based on the proxy, the public key and secret value are re-encrypted. Compute proxy public key ciphertext component ,in, Re-encrypt the private key for the proxy;

[0138] The access control policy, standard ciphertext component, first core component, first public component, and proxy public key ciphertext component are encapsulated together to form a convertible ciphertext header.

[0139] In one embodiment, a user dynamic permission module is also included, for:

[0140] Obtain the user's public key and its verifiable set of attributes, and run the attribute-based encryption user key generation algorithm on the attribute set based on the system master private key and the user's public key to obtain the attribute private key bound to the user's public key; the attribute-based encryption user key generation algorithm uses the hash value corresponding to the user's public key as a generation factor to bind the attribute private key to the user's public key.

[0141] Upon receiving a request to revoke the target user's identity, the system adds a revocation record to the revocation list based on the hash value of the user's public key and / or attribute private key corresponding to the request, and updates the system status version number.

[0142] In one embodiment, the data access module 403 is further configured to:

[0143] Based on the access data identifier, the metadata of the corresponding data to be shared is obtained from the smart contract of the blockchain, and the corresponding convertible ciphertext header is obtained from the cloud storage server;

[0144] Calculate the hash corresponding to the access control policy in the convertible ciphertext header and the hash corresponding to the proxy public key ciphertext component, and compare them with the hash corresponding to the access control policy and the hash corresponding to the proxy public key ciphertext component in the metadata to obtain the data integrity verification result;

[0145] The identity validity is verified based on the zero-knowledge proof of the user's identity public key, and the identity validity verification result is obtained. The zero-knowledge proof is used to prove that the user has an attribute private key bound to the user's identity public key, and that the set of verifiable attributes corresponding to the attribute private key meets the access control policy requirements.

[0146] If both the data integrity verification result and the identity validity verification result are successful, check if there is a revocation record in the revocation list identified by the hash value of the user's identity public key, and check if there is a revocation record identified by each attribute of the verifiable attribute set whose corresponding system status version number is not greater than the current system status version number, and obtain the verification result; if all checks are unsuccessful, the verification result is successful.

[0147] In one embodiment, the proxy re-encryption module 404 is further configured to:

[0148] The intermediate secret value is calculated based on the proxy re-encrypted private key and the proxy public key ciphertext component in the convertible ciphertext header.

[0149] Randomized state factors are generated based on the current system state version number and the cancellation list;

[0150] A new ciphertext component is constructed based on the intermediate secret value, state factor, convertible ciphertext header and revocation list, and a partially re-encrypted intermediate ciphertext is generated based on the new ciphertext component; the new ciphertext component includes a second core component and a second common component reconstructed from the first core component and the first common component, as well as an attribute ciphertext component obtained by performing a consistency transformation on the standard ciphertext component;

[0151] A verifiable state token is generated based on the state factor and the cancellation list; the state token contains a multiplicative cyclic group corresponding to the state factor. The generator and the revocation status proof for the user's public key and its attribute set;

[0152] Combine the intermediate ciphertext with the status token to obtain the new ciphertext header.

[0153] In one embodiment, a property adjustment module is also included, for:

[0154] Retrieve the original component pairs of each attribute within the access control policy corresponding to the standard encrypted component. ,in , , For the first One attribute, For hash functions, The intermediate secret value in the attribute node The secret sharing value on;

[0155] Based on the cancellation list, calculate adjustment values ​​for each attribute related to the cancellation status and status factor; the adjustment values ​​satisfy the following for a set of attributes. If the attribute set satisfies access control policy A, then a reconstruction coefficient exists. Make ,in It is a function determined by the undo list and the property set; it is active when all properties in the property set have not been undoed. ,otherwise These are randomized values;

[0156] Adjust the original component pair according to the adjustment value to obtain the attribute encrypted component.

[0157] In one embodiment, a user decryption module is also included, for:

[0158] After verifying that the revocation status proof in the new ciphertext header has not been revoked in the revocation list of the corresponding current system status version number, the attribute private key bound to the user's identity public key is used to perform decryption calculation on the intermediate ciphertext to obtain the symmetric encryption key;

[0159] The symmetric encryption key can be obtained using the following formula:

[0160]

[0161]

[0162]

[0163] in, Reconstruction factor; As a correction factor; As the second core component; A collection of attributes; For the corresponding attribute The reconstruction coefficients, and For component pairs of encrypted attributes; for attribute private key pairs of attributes. Includes components and ; It is a bilinear mapping; The multiplicative cyclic group corresponding to the state factor Generators; The component of the attribute private key that is related to the system master private key. The relevant parts;

[0164] The recovered symmetric encryption key is used to symmetrically decrypt the ciphertext to obtain the data to be shared.

[0165] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps in the above method embodiments.

[0166] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0167] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0168] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A method for fine-grained dynamic access control of data based on attribute-based encryption, characterized in that, The method comprises: obtaining to-be-shared data, and performing symmetric encryption on the to-be-shared data according to a randomly generated symmetric encryption key to obtain data ciphertext; the data ciphertext is stored in a cloud storage server through a corresponding storage identifier; based on a predefined access control policy, using an ABE encryption algorithm to encrypt the symmetric encryption key to obtain a convertible ciphertext header containing a proxy public key ciphertext component, and storing the hash corresponding to the access control policy, the hash corresponding to the proxy public key ciphertext component, and the current system state version number in the smart contract of the blockchain as metadata of the to-be-shared data; in response to obtaining a data access request, based on the current system state version number, the revocation list and the metadata of the to-be-shared data in the smart contract of the blockchain, performing user identity authentication according to the user identity public key and the access data identifier in the data access request to obtain an authentication result; if the authentication result is verified, obtaining the corresponding convertible ciphertext header according to the access data identifier, and performing re-encryption processing on the convertible ciphertext header according to the proxy re-encryption private key, the current system state version number and the revocation list to obtain a new ciphertext header; the new ciphertext header is used for the requesting user to decrypt the corresponding data ciphertext to recover the to-be-shared data.

2. The method of claim 1, wherein, The method comprises: randomly generating a secret value according to the access control policy wherein, is a prime number integer field of order based on a system master public key, the access control policy and the secret value running an attribute-based encryption algorithm to obtain a standard ciphertext component, a first core component and a first public component and a first public component wherein, is the symmetric encryption key, is a multiplicative cyclic group a generator of the multiplicative cyclic group, is a bilinear mapping, is a component of the system master private key; based on a proxy re-encryption public key and the secret value computing a proxy public key ciphertext component wherein, for the proxy re-encryption private key; obtaining a user identity public key and a verifiable attribute set thereof, and performing an attribute-based encryption user key generation algorithm on the attribute set based on a system master private key and the user identity public key to obtain an attribute private key bound to the user identity public key; the attribute-based encryption user key generation algorithm binds the attribute private key to the user identity public key by taking the hash value corresponding to the user identity public key as a generation factor; 3. The method of claim 2, wherein, in response to obtaining a revocation target user request, adding a revocation record of the user identity public key and / or the hash value of the attribute private key corresponding to the revocation target user request in the revocation list, and updating the system state version number. The method comprises: obtaining a user identity public key and a verifiable attribute set thereof, and performing an attribute-based encryption user key generation algorithm on the attribute set based on a system master private key and the user identity public key to obtain an attribute private key bound to the user identity public key; the attribute-based encryption user key generation algorithm binds the attribute private key to the user identity public key by taking the hash value corresponding to the user identity public key as a generation factor; 4. The method of claim 3, wherein, in response to obtaining a revocation target user request, adding a revocation record of the user identity public key and / or the hash value of the attribute private key corresponding to the revocation target user request in the revocation list, and updating the system state version number. The method comprises: obtaining a user identity public key and a verifiable attribute set thereof, and performing an attribute-based encryption user key generation algorithm on the attribute set based on a system master private key and the user identity public key to obtain an attribute private key bound to the user identity public key; the attribute-based encryption user key generation algorithm binds the attribute private key to the user identity public key by taking the hash value corresponding to the user identity public key as a generation factor; in response to obtaining a revocation target user request, adding a revocation record of the user identity public key and / or the hash value of the attribute private key corresponding to the revocation target user request in the revocation list, and updating the system state version number. The method comprises: obtaining a user identity public key and a verifiable attribute set thereof, and performing an attribute-based encryption user key generation algorithm on the attribute set based on a system master private key and the user identity public key to obtain an attribute private key bound to the user identity public key; the attribute-based encryption user key generation algorithm binds the attribute private key to the user identity public key by taking the hash value corresponding to the user identity public key as a generation factor; in response to obtaining a revocation target user request, adding a revocation record of the user identity public key and / or the hash value of the attribute private key corresponding to the revocation target user request in the revocation list, and updating the system state version number. The identity validity verification is performed according to the zero-knowledge proof of the user identity public key, and an identity validity verification result is obtained; the zero-knowledge proof is used to prove that the user has an attribute private key bound to the user identity public key, and a verifiable attribute set corresponding to the attribute private key meets the access control policy requirement; If the data integrity verification result and the identity validity verification result are both verified, it is checked whether the revocation record identified by the hash value of the user identity public key exists in the revocation list, and it is checked whether the system state version number corresponding to the revocation record identified by each attribute of the verifiable attribute set is not greater than the current system state version number, and the verification result is obtained; when the checks are all missed, the verification result is the verification pass.

5. The method of claim 3, wherein, The corresponding convertible ciphertext header is obtained according to the access data identifier, and the convertible ciphertext header is re-encrypted based on the proxy re-encryption private key, the current system state version number and the revocation list, to obtain a new ciphertext header, including: Based on the proxy re-encryption private key, an intermediate secret value is calculated based on the proxy public key ciphertext component in the convertible ciphertext header; A randomized state factor is generated according to the current system state version number and the revocation list; Based on the intermediate secret value, the state factor, the convertible ciphertext header and the revocation list, a new ciphertext component is constructed, and a partially re-encrypted intermediate ciphertext is generated according to the new ciphertext component; the new ciphertext component includes a second core component and a second public component reconstructed from the first core component and the first public component, and an attribute ciphertext component obtained by consistent transformation of the standard ciphertext component; generating a verifiable state token based on the state factor and the revocation list; the state token comprises a multiplicative cyclic group corresponding to the state factor of the generation element and the revocation state proof for the user identity public key and its attribute set The intermediate ciphertext and the state token are combined to obtain the new ciphertext header.

6. The method of claim 5, wherein, The attribute ciphertext component obtained by consistent transformation of the standard ciphertext component includes: obtaining original components of the standard ciphertext components corresponding to each attribute in the access control policy wherein , , is the th attribute, is a hash function, is a secret share value of the intermediate secret value on the attribute node . based on the revocation list, compute for each attribute an adjustment value related to the revocation status and the state factor; the adjustment value satisfies for a set of attributes if the set of attributes satisfies the access control policy A, there exists a reconstruction coefficient such that where is a function determined by the revocation list and the set of attributes, when all attributes in the set of attributes are not revoked otherwise is a randomization value; The attribute ciphertext component is obtained by adjusting the original component pair according to the adjustment value.

7. The method of claim 5, wherein, The request user decrypts the corresponding data ciphertext according to the new ciphertext header to recover the corresponding to-be-shared data by the following method: After verifying that the revocation state proof in the new ciphertext header is not revoked in the revocation list corresponding to the current system state version number, the attribute private key bound to the user identity public key is used to perform decryption calculation on the intermediate ciphertext to obtain the symmetric encryption key; The symmetric encryption key is obtained by the following formula: wherein, is a reconstruction factor; is a correction factor; is a second core component; is a set of attributes; is a reconstruction coefficient corresponding to an attribute , and is a pair of components of an attribute ciphertext component; the attribute private key pair attribute contains components and ; is a bilinear map; is a generator of a multiplicative cyclic group corresponding to a state factor pair; is a part of the attribute private key related to the component of the system master private key; The to-be-shared data is obtained by symmetric decryption of the data ciphertext using the recovered symmetric encryption key.

8. An attribute-based encryption based fine-grained data dynamic access control device, characterized in that, The device includes: A data encryption module is configured to obtain to-be-shared data, and perform symmetric encryption on the to-be-shared data according to a randomly generated symmetric encryption key to obtain data ciphertext; the data ciphertext is stored in a cloud storage server through a corresponding storage identifier. The ciphertext header module is configured to encrypt the symmetric encryption key using an ABE encryption algorithm based on a predefined access control policy to obtain a convertible ciphertext header containing a proxy public key ciphertext component, and store a hash corresponding to the access control policy, a hash corresponding to the proxy public key ciphertext component, and a current system state version number as metadata of the data to be shared in a smart contract of a blockchain; The data access module is configured to, in response to obtaining a data access request, perform user identity verification according to a user identity public key and an access data identifier in the data access request based on the current system state version number, a revocation list, and the metadata of the data to be shared in the smart contract of the blockchain to obtain a verification result. The proxy re-encryption module is configured to, if the verification result is verified, obtain a corresponding convertible ciphertext header according to the access data identifier, and perform re-encryption processing on the convertible ciphertext header according to a proxy re-encryption private key, the current system state version number, and the revocation list to obtain a new ciphertext header; the new ciphertext header is used for a requesting user to decrypt a corresponding data ciphertext to recover the data to be shared. 9.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-8 when the computer program is executed by the processor. The computer program is executed by the processor to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1 to 7.

Images