An attribute-based encryption data fine-grained dynamic access control method and system

CN122933012APending Publication Date: 2026-10-16BEIJING UNIV OF POSTS & TELECOMM
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611183044.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-08-05
Publication Date
2026-10-16

AI Technical Summary

Technical Problem

[0005]鉴于此,本发明实施例提供了一种基于属性加密的数据细粒度动态访问控制方法及系统,以消除或改善现有技术中存在的一个或更多个缺陷,解决现有多机构属性基加密方案在数据访问阶段缺乏实时动态授权验证、难以及时限制权限变更用户后续访问行为的问题

Benefits of technology

[0016] This invention provides a fine-grained dynamic access control method and system for data based on attribute encryption. When access occurs, a collaborative authorization coordinator receives access requests for ciphertext, parses the associated access control policy, and narrows the verification scope to targeted verification by the target attribute authorization agency. This ensures that authorization decisions are based on the latest attribute state, changing the authorization mode that relies on static attribute states during key issuance and avoiding communication redundancy caused by network-wide broadcasting. Furthermore, it receives the attribute state and the latest attribute version number, verifies the validity of the state and the mutual exclusion of combinations, and promptly intercepts cross-agency attribute conflicts and collusion to exceed authority, alleviating the problem of attribute state isolation among multiple agencies. After successful verification, an attribute version list is generated and an attribute digest is calculated, solidifying the attribute state at the time of authorization as a version snapshot, making the authorization basis tamper-proof. Finally, each target attribute authorization agency uses a secure authentication private key to segment and sign, and aggregates to generate secure authentication information. A single agency cannot forge authorization credentials, solving the problems of key escrow and single point of trust. By issuing a federated attribute token, the cloud server verifies the security authentication information and releases the ciphertext after comparing the attribute version list with the global latest attribute version status baseline table. Revoking permissions only requires updating the attribute version number to make the token instantly invalid, without the need for re-encryption, thus achieving fine-grained dynamic access control and instant permission revokement. The ciphertext is decrypted locally by the data user using the user attribute private key bound to their identity identifier. The cloud server does not access the plaintext or the key, mitigating the risk of data leakage in a semi-trusted cloud environment.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122933012A_ABST
    Figure CN122933012A_ABST
Patent Text Reader

Abstract

The application provides a data fine-grained dynamic access control method and system based on attribute encryption, which receives an access request of a data user for ciphertext by a collaborative authorization coordinator, analyzes an access control strategy associated with the ciphertext to extract a target attribute, and determines a target attribute authorization agency that manages the target attribute; only sends an attribute verification request to the target attribute authorization agency and receives an attribute state and a latest attribute version number; when the attribute state is valid and the attribute combination has no mutual exclusion, an attribute version list is generated and an attribute digest is calculated, security authentication information is generated by aggregation of fragment signatures of each target attribute authorization agency; a joint attribute token is generated and issued to the data user. The cloud server verifies the security authentication information and compares the attribute version list with a global latest attribute version state baseline table, and releases the ciphertext when the comparison is consistent, and the data user decrypts locally using a user attribute private key. The application can dynamically verify the latest state of the attribute at the time of access, and only needs to update the attribute version number to revoke the right, without re-encryption for immediate recovery.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of data security and cryptographic access control technology, and in particular to a fine-grained dynamic access control method and system for data based on attribute encryption. Background Technology

[0002] With the widespread application of cloud computing and big data technologies, data owners tend to outsource the storage and sharing of massive amounts of data to cloud servers to reduce local management costs. However, cloud servers are often considered semi-trusted entities, posing security risks such as data leakage and unauthorized access. Therefore, data must be encrypted before being uploaded.

[0003] To achieve fine-grained access control, Cited Policy Attribute-Based Encryption (CP-ABE) technology has been proposed and widely used. This technology allows data owners to embed access control policies directly into ciphertext, and decryption can only be completed when the attributes held by the data user satisfy the access control policy. To address the single point of failure and key escrow issues of single attribute authorization agencies, Multi-Agency Attribute-Based Encryption (MA-ABE) schemes have been further developed. Multiple independent attribute authorization agencies manage user attributes in different attribute domains and issue their own attribute private keys, achieving fine-grained data access control across agencies.

[0004] Existing multi-institutional attribute-based encryption schemes typically employ a static access control model. After completing attribute authentication and obtaining the attribute private key during registration, users can independently decrypt ciphertext during data access, without real-time authorization verification by the system. Under this static access control model, when user permissions change, the system struggles to promptly restrict subsequent data access behavior by users with altered permissions, failing to meet the real-time management needs of dynamic scenarios such as medical data sharing and joint financial risk control. Furthermore, the independent nature of each attribute authorization institution and the lack of a unified collaborative authentication and state synchronization mechanism allow malicious users to combine attribute private keys issued at different times and by different institutions, constructing attribute sets that superficially satisfy access policies but are substantively illegitimate, enabling cross-institutional collusion attacks. In addition, existing permission revocation mechanisms often rely on re-encrypting or updating keys on massive amounts of ciphertext in the cloud, incurring huge computational and communication overhead, making them inefficient in large-scale data sharing environments. Some schemes also use broadcasting to the entire network to obtain user attribute status, leading to severe network communication redundancy and reducing the system's concurrent processing capabilities. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a data fine-grained dynamic access control method and system based on attribute encryption, in order to eliminate or improve one or more defects existing in the prior art, and solve the problem that existing multi-organization attribute-based encryption schemes lack real-time dynamic authorization verification during the data access stage and are difficult to restrict subsequent access behavior of users with changed permissions in a timely manner.

[0006] One aspect of the present invention provides a fine-grained dynamic access control method for data based on attribute encryption, the method being executed by a cooperative authorization coordinator, the method comprising the following steps: The system receives access requests from data users for encrypted data. The access requests include at least the identity identifier of the data user. The encrypted data is obtained by the data owner through attribute-based encryption of the data to be shared according to the access control policy and then uploaded to the cloud server. The access control policy is stored in association with the encrypted data. Obtain and parse the access control policy associated with the ciphertext, extract the target attributes involved in the access control policy, and determine the target attribute authorization authority that manages each of the target attributes; Only send attribute verification requests to the authorized agency of the target attribute, and the attribute verification request includes at least the identity identifier of the data user and each of the target attributes to be verified; The system receives the attribute status and latest attribute version number of the data user returned by each of the target attribute authorization agencies. The latest attribute version number is updated by the target attribute authorization agency and synchronized to the cloud server when the attribute status changes. Verify whether all attribute states are valid, and according to preset cross-domain security rules, verify whether there are mutually exclusive attributes in the combination of target attributes; When all the attribute states are valid and there are no mutually exclusive attributes in the combination of the target attributes, extract the latest attribute version number combination to generate an attribute version list, and calculate the attribute summary containing the attribute version list; The attribute digest is distributed to each of the target attribute authorization agencies. The signature fragments obtained by each target attribute authorization agency signing the attribute digest using their respective security authentication private key fragments are collected. The signature fragments are aggregated to generate security authentication information. The security authentication private key fragments are jointly generated by multiple attribute authorization agencies through a distributed protocol. A joint attribute token, including at least the attribute version list and the security authentication information, is generated and sent to the data user. The cloud server verifies the security authentication information and, after comparing the attribute version list with the global latest attribute version status baseline table maintained by the cloud server, releases the ciphertext to the data user. The ciphertext is then locally decrypted by the data user using a user attribute private key obtained in advance from each of the target attribute authorization authorities. The user attribute private key is bound to the identity identifier.

[0007] In some embodiments of the present invention, determining the target attribute authorization organization that manages each of the target attributes includes: The preset attribute mapping index is queried to obtain the target attribute authorization agency that manages each target attribute. The preset attribute mapping index records the mapping relationship between each attribute and each attribute authorization agency.

[0008] In some embodiments of the present invention, the synchronization to the cloud server includes: When the attribute status changes, the target attribute authorization agency immediately pushes the latest attribute version number to the cloud server and responds to the synchronization calibration initiated by the cloud server according to a preset period, synchronizing the latest attribute version number to the cloud server.

[0009] In some embodiments of the present invention, the preset cross-domain security rule is a set of conflicting rules stored in a preset cross-domain security rule base, and each of the conflicting rules defines mutually exclusive attribute combinations; the step of verifying whether there are mutually exclusive attributes in each combination of target attributes according to the preset cross-domain security rule includes: The preset cross-domain security rule base is invoked to perform conflict rule matching on the combination of each target attribute. When any of the conflict rules is matched, it is determined that there are mutually exclusive attributes in the combination of each target attribute.

[0010] In some embodiments of the present invention, the aggregation of each signature fragment to generate security authentication information includes: Based on the threshold signature mechanism, at least a preset number of signature fragments obtained by the signatures of the target attribute authorization authorities are collected, and the collected signature fragments are aggregated to generate the security authentication information.

[0011] In some embodiments of the present invention, the attribute digest is calculated from the attribute version list, expiration time, one-time random number and the file identifier of the ciphertext; the combined attribute token further includes the issuance time, the expiration time and the one-time random number, and the combined attribute token automatically expires after the expiration time is reached.

[0012] In some embodiments of the present invention, the user attribute private key is generated by each of the target attribute authorization authorities based on the hash value of the identity identifier and the attribute master private key of each of the target attributes.

[0013] In some embodiments of the present invention, an attribute state matrix is ​​constructed based on the received attribute states, and the attribute state matrix includes at least the identity identifier, each of the target attributes, each of the attribute states, each of the latest attribute version numbers, the return time, and the organization number of each of the target attribute authorization organizations; The step of verifying whether each attribute state is a valid state includes: traversing the attribute state matrix and verifying whether each attribute state is a valid state one by one. The conflict rule matching is performed on the combination of each of the target attributes in the attribute state matrix; The step of extracting the latest attribute version numbers to generate an attribute version list includes: extracting the latest attribute version numbers from the attribute state matrix, arranging them in order of appearance of the target attributes in the policy tree of the access control policy, and generating the attribute version list.

[0014] On the other hand, the present invention also provides a fine-grained dynamic access control method for data based on attribute encryption. This method is executed on a cloud server and is used to verify the combined attribute token generated by the method described in any of the above embodiments. The method includes the following steps: Receive the latest attribute version number synchronized by multiple attribute licensing agencies, maintain a global latest attribute version status baseline table, wherein the latest attribute version number is updated and synchronized by the attribute licensing agency when the attribute status changes; The system receives encrypted text uploaded by the data owner, associates the encrypted text with an access control policy, and stores the encrypted text. The encrypted text is obtained by the data owner through attribute-based encryption of the data to be shared in accordance with the access control policy. Receive an access request for the encrypted text submitted by a data user and the associated attribute token, wherein the access request includes at least the identity identifier of the data user; The security authentication information in the combined attribute token is verified, and the attribute version list in the combined attribute token is compared with the global latest attribute version status baseline table; When the security authentication information is verified and the comparison results are consistent, the ciphertext is released to the data user. The ciphertext is then decrypted locally by the data user using the user attribute private key obtained in advance from each of the attribute authorization agencies. The user attribute private key is bound to the identity identifier.

[0015] On the other hand, the present invention also provides a fine-grained dynamic access control system for data based on attribute encryption, including a collaborative authorization coordinator, a cloud server, multiple attribute authorization agencies, a data owner terminal, and a data user terminal; The collaborative authorization coordinator is configured to perform the attribute-encrypted-based fine-grained dynamic access control method for data as described in any of the above. The cloud server is configured to execute the fine-grained dynamic access control method for data based on attribute encryption as described above. Each of the attribute authorization authorities is configured to maintain the latest attribute version number, update the latest attribute version number and synchronize it to the cloud server when the attribute status changes, and issue user attribute private keys bound to identity identifiers to the data user terminal; The data owner's end is configured to perform attribute-based encryption on the data to be shared according to the access control policy to obtain ciphertext, and then upload the ciphertext to the cloud server; The data user terminal is configured to send an access request to the collaborative authorization coordinator, receive a joint attribute token and submit the joint attribute token to the cloud server, and use the user attribute private key to locally decrypt the obtained ciphertext.

[0016] This invention provides a fine-grained dynamic access control method and system for data based on attribute encryption. When access occurs, a collaborative authorization coordinator receives access requests for ciphertext, parses the associated access control policy, and narrows the verification scope to targeted verification by the target attribute authorization agency. This ensures that authorization decisions are based on the latest attribute state, changing the authorization mode that relies on static attribute states during key issuance and avoiding communication redundancy caused by network-wide broadcasting. Furthermore, it receives the attribute state and the latest attribute version number, verifies the validity of the state and the mutual exclusion of combinations, and promptly intercepts cross-agency attribute conflicts and collusion to exceed authority, alleviating the problem of attribute state isolation among multiple agencies. After successful verification, an attribute version list is generated and an attribute digest is calculated, solidifying the attribute state at the time of authorization as a version snapshot, making the authorization basis tamper-proof. Finally, each target attribute authorization agency uses a secure authentication private key to segment and sign, and aggregates to generate secure authentication information. A single agency cannot forge authorization credentials, solving the problems of key escrow and single point of trust. By issuing a federated attribute token, the cloud server verifies the security authentication information and releases the ciphertext after comparing the attribute version list with the global latest attribute version status baseline table. Revoking permissions only requires updating the attribute version number to make the token instantly invalid, without the need for re-encryption, thus achieving fine-grained dynamic access control and instant permission revokement. The ciphertext is decrypted locally by the data user using the user attribute private key bound to their identity identifier. The cloud server does not access the plaintext or the key, mitigating the risk of data leakage in a semi-trusted cloud environment.

[0017] Furthermore, the present invention employs a version synchronization mechanism that combines real-time push and periodic calibration to avoid inconsistent version status and revocation delays; it adopts a threshold signature mechanism so that aggregation can still be completed even when some institutions do not respond; and it incorporates the expiration time and a one-time random number into the digest calculation so that the token automatically expires and resists replay attacks.

[0018] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0019] Those skilled in the art will understand that the objectives and advantages achievable with this invention are not limited to those specifically described above, and that the above and other objectives achievable with this invention will become clearer from the following detailed description. Attached Figure Description

[0020] The accompanying drawings, which are provided to further illustrate the invention and form part of this application, are not intended to limit the scope of the invention.

[0021] Figure 1 This is a flowchart illustrating a fine-grained dynamic access control method for data based on attribute encryption according to an embodiment of the present invention.

[0022] Figure 2 This is a schematic diagram of the architecture of a data fine-grained dynamic access control system based on attribute encryption according to an embodiment of the present invention.

[0023] Figure 3 This is a schematic diagram of the internal logic processing of the Cooperative Authorization Coordinator's Execution Policy Dynamic Parsing (PDP) and Cooperative Authorization Decision (CADA) according to an embodiment of the present invention.

[0024] Figure 4 This is a schematic diagram of the execution flow of the Policy Dynamic Parsing (PDP) algorithm according to an embodiment of the present invention.

[0025] Figure 5 This is a schematic diagram of the computation process of the Collaborative Authorization Decision (CADA) algorithm according to an embodiment of the present invention.

[0026] Figure 6 This is a timing diagram illustrating the cloud-based dynamic access verification and local data decryption based on a joint attribute token, as described in an embodiment of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0028] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0029] In existing multi-agency attribute-based encryption systems, each attribute-authorizing agency is independently responsible for authenticating user attributes and issuing private keys within its respective attribute domain. There is a lack of a unified state synchronization and collaborative authentication mechanism among agencies. When user attributes change, agencies struggle to obtain timely information about the latest attribute status of other agencies, easily leading to inconsistencies in cross-agency attribute information, which in turn can cause cross-agency attribute conflicts and collusion to overstep authority.

[0030] Meanwhile, existing authorization decisions rely heavily on the static attribute status at the time of key issuance. When access actually occurs, the latest status of user attributes cannot be dynamically verified. If permission needs to be revoked, data often needs to be re-encrypted or the ciphertext updated, resulting in significant system overhead and making it difficult to achieve fine-grained dynamic access control and immediate permission revokement.

[0031] In view of this, the present invention proposes a fine-grained dynamic access control method for data based on attribute encryption. This method is executed by a cooperative authorization coordinator, such as... Figure 1 As shown, steps S101 to S108 are included: S101: Receive access requests sent by data users for ciphertext. The access requests include at least the data user's identity identifier. The ciphertext is obtained by the data owner through attribute-based encryption of the data to be shared in accordance with the access control policy and uploaded to the cloud server. The access control policy is stored in association with the ciphertext.

[0032] S102: Obtain and parse the access control policy associated with the ciphertext, extract the target attributes involved in the access control policy, and determine the target attribute authorization authority that manages each target attribute.

[0033] S103: Send attribute verification requests only to the target attribute authorization authority. The attribute verification request shall include at least the data user's identity identifier and each target attribute to be verified.

[0034] S104: Receive the attribute status and latest attribute version number of the data user returned by each target attribute authorization agency. The latest attribute version number is updated by the target attribute authorization agency and synchronized to the cloud server when the attribute status changes.

[0035] S105: Verify that all attribute states are valid, and according to the preset cross-domain security rules, verify whether there are mutually exclusive attributes in the combination of target attributes.

[0036] S106: When all attribute states are valid and there are no mutually exclusive attributes in the combination of target attributes, extract the latest attribute version number combination to generate an attribute version list, and calculate the attribute summary containing the attribute version list.

[0037] S107: Distribute the attribute digest to each target attribute authorization authority, collect the signature fragments obtained by each target attribute authorization authority using its own security authentication private key fragments to sign the attribute digest, aggregate the signature fragments to generate security authentication information, and the security authentication private key fragments are jointly generated by multiple attribute authorization authorities through a distributed protocol.

[0038] S108: Generate a joint attribute token that includes at least an attribute version list and security authentication information and distribute it to the data user so that the cloud server can verify the security authentication information. After the attribute version list is matched with the global latest attribute version status baseline table maintained by the cloud server, the encrypted text is released to the data user. The encrypted text is decrypted locally by the data user using the user attribute private key obtained in advance from each target attribute authorization authority. The user attribute private key is bound to the identity identifier.

[0039] The execution of steps S101 to S108 depends on the public system parameters generated during the system initialization phase, as well as the ciphertext that the data owner pre-encrypts and uploads to the cloud server. Before describing the execution process of each of the above steps in detail, the entities involved in the access control system of this embodiment, the basic cryptographic environment, the system initialization process, and the data encryption and uploading process will be explained first.

[0040] The access control system in this embodiment involves five types of entities: Data Owner (DO), Data User (DU), Attribute Authority (AA), Collaborative Authorization Coordinator (CAC), and Cloud Server (CS).

[0041] The data owner is the source node of private data in the system, possessing basic computing resources and responsible for formulating fine-grained data access control policies. The data owner uses a symmetric encryption algorithm to confidentially encapsulate the original private file data. Then, based on the access policy, the symmetric key is cryptographically re-encrypted using the Ciphertext-Policy Attribute-Based Encryption (CP-ABE) algorithm, generating ciphertext containing the access structure and cryptographic components. This ciphertext data is then transmitted and stored on a cloud server. The data owner is trusted by the system and is the starting point for secure data flow.

[0042] Data users are the terminal nodes that initiate data access and decryption requests in the system. During the system registration phase, data users apply for and obtain user attribute private keys that match their real identity and qualifications from various attribute authorization agencies. During the data access phase, data users first obtain dynamically generated joint attribute tokens and submit them to the cloud server. After receiving the encrypted file released by the cloud server, data users use the pre-obtained user attribute private keys to perform bilinear pairing decryption operations on their local terminals to recover the original plaintext data.

[0043] Attribute authorization authorities, physically and logically composed of multiple independent organizations, replace the traditional single key generation center. Each authority is responsible for authoritative authentication of attributes and issuance of user attribute private keys within its jurisdiction. Each authority initializes and maintains an integer attribute version number in its local security database for each attribute under its jurisdiction. When a data user's specific attribute changes or is revoked, the corresponding authority updates its local version number and cooperates with the collaborative authorization coordinator to perform real-time status verification. Attribute authorization authorities are trusted entities.

[0044] The collaborative authorization coordinator is the core logical hub introduced in this embodiment and can be deployed in a highly available microservice cluster. As a semi-trusted entity, the collaborative authorization coordinator is responsible for receiving access requests from data users, performing dynamic policy parsing and collaborative authorization decisions, and, after confirming that there are no attribute conflicts and that the attribute status is valid, aggregating the version numbers of each attribute authorization authority and scheduling the generation of a joint attribute token with a secure authentication signature.

[0045] The cloud server, a semi-trusted entity, aggregates massive storage resources and computing power. Upon receiving the encrypted data and cryptographic components uploaded by the data owner, it persistently stores them. The cloud server maintains a global baseline table of the latest attribute version status. Version records in this table are updated instantly by attribute authorization organizations when version numbers change, and a daemon deployed on the cloud server periodically initiates synchronization calibration with each attribute authorization organization. Upon receiving the federated attribute token submitted by the data user, the cloud server performs dynamic verification. Only after successful verification is the target encrypted file precisely released to the data user. The architecture and data interaction relationships of the access control system comprised of these five entities are as follows: Figure 2 As shown.

[0046] The system's global mathematical parameters and basic cryptographic data structures are defined as follows.

[0047] Definition 1: Basic Cryptographic Environment. Choose a security parameter λ and define... and Let p be a multiplicative cyclic group of two large prime numbers of order p. Define a bilinear mapping function with the expression: ; Where e represents a bilinear mapping function; This represents a multiplicative cyclic group of order p; Let p denote the multiplicative cyclic group of order p, where p represents a large prime number. Bilinear mapping functions satisfy bilinearity, non-degeneracy, and computability in polynomial time.

[0048] The expression for bilinearity is: ; Where u represents the group Any element in; v represents the group. Any element in; 'a' represents the multiplication group. Any element in; b represents the multiplication group. Any element in; Let represent the multiplication group consisting of non-zero residue classes modulo p.

[0049] The expression for nondegeneracy is: ; Where g represents the group A random generator.

[0050] Definition 2: Collision-resistant hash function. The system defines a one-way hash function with the following expression: ; Where H represents a one-way hash function; A one-way hash function represents a bit string of arbitrary length. It is used to securely map variable-length strings, such as globally unique identifiers (UIDs) of data users, to a group. The elements on.

[0051] Definition 3: Global Attributes and Version Structure. The expression for the set of all possible global attributes in the system is: ; in, Represents a global set of system attributes; This represents the i-th attribute. The system binds a version status indicator to each attribute; the version status indicator is a non-negative integer counter. For the current data access, an attribute version list is constructed from the attribute version numbers corresponding to each target attribute involved in the access control policy, expressed as: ; Where VersionList represents a list of attribute versions; represents the attribute version number corresponding to the i-th target attribute; m represents the number of target attributes involved in this data access.

[0052] To ensure that the attribute version number can still correctly correspond to the attribute and remain consistent across the entire network when the number of attribute authorization authorities changes, the attribute version number in the attribute version list is arranged in the following order: according to the order in which the attribute appears in the access control policy tree corresponding to the current data access. Throughout the entire system lifecycle, the collaborative authorization coordinator, cloud server, and data user uniformly follow this ordering rule when generating, referencing, and resolving the attribute version list.

[0053] Definition 4: Linear Secret Sharing Scheme (LSSS). The tree-structured access control policy defined by the data owner is transformed into a linear secret sharing scheme structure, expressed as: ; in, Indicates the access control policy; M indicates the dimension. The access control shared matrix; l represents the number of rows after the policy logic is split; n represents the dimension of the internal variables related to the system attribute domain; ρ represents the mapping function, used to precisely map each row x of matrix M to a specific attribute in the global attribute set A, denoted as ρ. .

[0054] Definition 5: Attribute Mapping Index (AMI). The system maintains a high-frequency query routing table in memory, recording the physical network mapping relationship between system-wide attribute tags and corresponding management attribute authorization agency entities. The data structure expression is as follows: ; Where AMI stands for Attribute Mapping Index; Represents attributes With management attributes This index maps the attributes of the authorizing organization to the physical network IP addresses. It is a core dependency for enabling on-demand network communication.

[0055] After completing the above definitions, the system executes an initialization algorithm to generate common system parameters and complete entity initialization. The system initialization algorithm takes the security parameter λ as input and outputs global common parameters, key pairs for each attribute, globally shared security authentication public keys, and security authentication private key fragments held by the authorization authorities of each attribute. The expression is: ; in, The initialization input is generated by the security parameter λ; params represents the global common parameters. Represents attributes The attribute public key; Represents attributes The attribute of the master private key; This represents a globally shared public key for security authentication. This represents the security authentication private key fragment held by the k-th attribute authorization authority; Setup represents the system initialization operator.

[0056] The system exposes globally common parameters, expressed as follows: ; Here, params represents globally common parameters.

[0057] Multiple independent attribute licensing agencies Each runs its own independent initialization algorithm for each attribute it governs. Randomly select attribute master private key component and , .

[0058] The expression for the attribute public key is: ; in, Represents attributes The attribute public key; Represents attributes The first component of the master private key; Represents attributes The second component of the master private key.

[0059] The expression for the master private key attribute is: ; in, Represents attributes The attribute of the master private key.

[0060] Each attribute authorization body establishes an attribute version number in its local database for each attribute it manages, and assigns the initial value of the attribute version number to the constant 0.

[0061] To ensure the unforgeability of the joint attribute token, all attribute authorization authorities jointly participate in running a distributed key generation protocol (DKG) based on the Shamir secret sharing mechanism. Once this protocol interaction is complete, a globally shared secure authentication public key for digital signatures is generated across the entire network. The corresponding signing private key does not exist completely in any single entity; each authorized authority secretly keeps a fragment of the secure authentication private key. .

[0062] During the initialization phase, the collaborative authorization coordinator loads the complete attribute mapping index into the local memory database and establishes a cache of attributes to IP addresses; the cloud server completes the registration of the verification component API; each attribute authorization agency executes the attribute private key generation algorithm KeyGen() based on the set of data user attributes that have passed identity authentication, and issues user attribute private keys bound to globally unique identifiers (UIDs) to legitimate data users; the system completes the parameter registration between the collaborative authorization coordinator and the cloud server, and the system is ready.

[0063] During the data sharing phase, the data owner encrypts the private data using a data encryption algorithm and uploads it to the cloud server. The expression for the data encryption algorithm is: ; Where CT represents ciphertext; Encrypt represents data encryption operator; and F represents plaintext data file.

[0064] The data owner, on their local terminal, uses the system's secure random number generator to generate a 256-bit symmetric key κ for the plaintext data file F to be shared. They then use the AES-256-GCM advanced symmetric encryption standard to stream-encrypt file F, generating the basic ciphertext data. The calculation formula is as follows: ; in, This represents encrypted underlying data. κ represents a symmetric encryption operator; F represents a symmetric key of length 256 bits; and F represents the plaintext data file to be shared.

[0065] Data owners from multiplication groups A scalar *s* is randomly selected as the core secret for this encryption process. Secret *s* is used to blind the symmetric key *k*. The data owner constructs a policy tree based on fine-grained access control policies, and then calls a linear secret sharing scheme transformation algorithm to convert the policy tree into a linear secret sharing scheme structure. .

[0066] The data owner randomly selects a column vector, expressed as follows: ; Where v represents a column vector of length n; s represents the core secret scalar; Indicates from The n-1 random scalars selected from the list; Representing a finite field The n-dimensional vector space is given. The first element of the column vector v is set to the secret s.

[0067] For each row x of the access matrix M, the data owner calculates the row secret partition, using the following formula: ; in, This represents the row secret fragment of row x; This indicates the x-th row of the access matrix M.

[0068] For each row x of the access matrix M, the data owner randomly selects a scalar to prevent collusion and blinding. Query the attribute mapped to row x The attribute public key, combined with the global public parameters and the attribute public key, is used to calculate the cryptographic cover shell component and the three line ciphertext components respectively.

[0069] The formula for calculating the cryptographic covert shell component is: ; Where C represents the cryptographic covert shell component used to blind the symmetric key κ with the secret s; κ represents the symmetric key with a length of 256 bits; and s represents the core secret scalar.

[0070] The calculation formula for the secret blinding component is: ; in, This represents the row secret blinding component for row x; This represents the row secret fragment of row x; Represents attributes The first component of the master private key; Let x represent the anti-collusion blinding scalar value for the x-th row. .

[0071] The formula for calculating the random number recovery component is: ; in, This represents the random number recovery component for the x-th row.

[0072] The formula for calculating the private key binding component is: ; in, This indicates that the private key attribute in row x is bound to the component. Represents attributes The second component of the master private key.

[0073] The data owner serializes and packages all the data structures generated above and uploads them to the cloud server. The ciphertext composition expression is as follows: ; Where x represents the row number of the access matrix M, and its value is an integer from 1 to l.

[0074] At this point, the system has completed initialization and encrypted uploading of the data to be shared, and has entered the data access phase.

[0075] In step S101, in response to the shortcomings of existing schemes that rely on the static attribute state at the time of key issuance for authorization and cannot verify the latest attribute state when access actually occurs, the collaborative authorization coordinator starts the access control process when the data user actually initiates access, receives the access request sent by the data user for the ciphertext, and clarifies the source of the ciphertext to be accessed and the storage method of the access control policy.

[0076] The access request must include at least the data user's identity identifier, which is a globally unique identifier (UID) for the data user within the system. The access request also carries a file identifier for the encrypted data, which indicates the encrypted data that the access request is targeting.

[0077] The ciphertext is obtained by the data owner through attribute-based encryption of the shared data in accordance with the access control policy and then uploaded to the cloud server. The access control policy restricts the attribute combinations that can decrypt the ciphertext.

[0078] When a data owner uploads encrypted data, the access control policy is associated with the encrypted data and stored on a cloud server. The access control policy stored on the cloud server can be read based on the encrypted data.

[0079] In step S102, in response to the shortcomings of existing collaborative authentication schemes that broadcast authentication requests to all attribute authorization agencies and generate redundant requests to a large number of irrelevant agencies, the collaborative authorization coordinator dynamically parses the access control policy associated with the ciphertext, extracts the target attributes involved in the access control policy, and precisely converges the verification scope to the target attribute authorization agency that manages each target attribute.

[0080] The internal logic processing of the collaborative authorization coordinator's execution strategy dynamic analysis and collaborative authorization decision-making is as follows: Figure 3 As shown, this specifically includes sub-steps S1021~S1023: S1021: The collaborative authorization coordinator retrieves the access control policy associated with the encrypted file from the cloud server based on the file identifier in the access request. The access control policy is organized in the form of a policy tree, where leaf nodes carry attribute tags and non-leaf nodes carry threshold logic for combinations of limiting attributes. (The policy tree is similar to the access control policy in Definition 4.) For the equivalent representation of the same access control policy, the access matrix M is obtained by transforming the policy tree through a linear secret sharing scheme.

[0081] S1022: Starting from the root node of the policy tree, the collaborative authorization coordinator performs a top-down full traversal of the policy tree using a depth-first search, extracting the attribute labels carried by all leaf nodes to form a leaf node set. The extracted attribute labels are then deduplicated and normalized to obtain the target attribute set. .in, Each target attribute in the dataset belongs to the global attribute set A.

[0082] S1023: The collaborative authorization coordinator queries the preset attribute mapping index to determine the attribute authorization agency for each target attribute in the set of management target attributes, and converges the determined attribute authorization agencies into a subset of target attribute authorization agencies. .

[0083] In some embodiments, a preset attribute mapping index resides in the memory of the collaborative licensing coordinator. The preset attribute mapping index also records the network addresses of each attribute licensing authority. The collaborative licensing coordinator queries the preset attribute mapping index to obtain the network addresses of the target attribute licensing authorities that manage each target attribute.

[0084] Through the dynamic analysis of the strategy in steps S1021 to S1023, the verification scope is narrowed from all attribute authorization agencies in the system to a subset of the target attribute authorization agencies, and the communication complexity is reduced from that of the broadcast authentication method. Reduce to Where N represents the total number of attribute authorization agencies in the system. This indicates the number of target attribute authorization agencies in the target attribute authorization agency subset. Much smaller than N. The execution logic of dynamic strategy parsing is as follows: Figure 4 As shown.

[0085] In step S103, the collaborative authorization coordinator only grants permissions to a subset of the target attribute authorization agencies. Each target attribute authorization agency sends an attribute verification request.

[0086] An attribute verification request must include at least the data user's identity identifier and the target attributes to be verified. The identity identifier is used by the authorized authority to locate the data user's attribute record in the local database, and the target attributes to be verified indicate the scope of attributes to be verified in this request.

[0087] In some embodiments, the collaborative authorization coordinator sends attribute verification requests to each target attribute authorization agency according to the network address of each target attribute authorization agency obtained by querying the preset attribute mapping index.

[0088] In step S104, after receiving the attribute verification request, each target attribute authorization agency queries its local database. The collaborative authorization coordinator receives the attribute status of the data user and the latest attribute version number of each target attribute returned by each target attribute authorization agency.

[0089] Each target attribute authorization agency locates the data user's attribute record in its local database based on the identity identifier in the attribute verification request. For each target attribute to be verified in the attribute verification request, each agency independently and asynchronously returns a status response to the collaborative authorization coordinator. The status response includes at least the attribute label of the target attribute, the data user's attribute status under the corresponding target attribute, and the latest attribute version number of the corresponding target attribute. The attribute label is used to map the status response to each target attribute to be verified, and the attribute status indicates whether the data user's attribute under the corresponding target attribute is currently valid.

[0090] The latest attribute version number is established and maintained by each target attribute authorization organization in its local database. When the attribute status of a data user changes, the target attribute authorization organization updates the latest attribute version number of the corresponding target attribute and synchronizes the updated latest attribute version number to the cloud server, so that the latest attribute version number recorded in the cloud server is consistent with the local record of each target attribute authorization organization.

[0091] In some embodiments, the latest attribute version number is an integer value. When the attribute status changes, the target attribute licensing authority increments the latest attribute version number of the corresponding target attribute by 1 to obtain the updated latest attribute version number.

[0092] In some embodiments, the latest attribute version number is synchronized to the cloud server using a combination of real-time push and periodic synchronization: the target attribute authorization organization pushes an update in real-time when the attribute status changes, and sends the updated latest attribute version number to the cloud server in real-time; the daemon deployed on the cloud server actively initiates periodic synchronization calibration to each target attribute authorization organization according to a preset period, obtains the latest attribute version number maintained locally by each target attribute authorization organization, verifies and corrects the records in the cloud server, and avoids inconsistencies between the records in the cloud server and the records locally of the target attribute authorization organization due to omissions in real-time push.

[0093] In some embodiments, the attribute state includes a valid state, a canceled state, and a suspended state.

[0094] In step S105, addressing the shortcomings of existing multi-agency schemes where the attribute states of each attribute-authorizing agency are isolated and unable to identify cross-agency attribute conflicts and collusion to overstep authority, the collaborative authorization coordinator constructs an attribute state matrix based on the received attribute states and performs dual verification of state validity and conflict rule matching based on the attribute state matrix. Specifically, this includes sub-steps S1051~S1053: S1051: After receiving status responses from all target attribute authorization agencies, the collaborative authorization coordinator constructs an attribute status matrix based on the received attribute statuses. The attribute status matrix includes at least the data user's identity identifier, each target attribute, each attribute status, each latest attribute version number, the return time of each status response, and the agency number of each target attribute authorization agency. Each row of the attribute status matrix corresponds to a target attribute, recording the data user's verification information for that target attribute.

[0095] In some embodiments, the attribute state matrix is ​​constructed in the main memory of the cooperative authorization coordinator.

[0096] S1052: The collaborative authorization coordinator traverses the attribute state matrix, verifying that each attribute state in the matrix is ​​valid. If any attribute state is not valid, the validity check fails, a denial notification is returned to the data user, and the current access control process terminates.

[0097] S1053: When all attribute states are valid, the collaborative authorization coordinator calls the preset cross-domain security rule base to perform conflict rule matching on the combinations of target attributes in the attribute state matrix. The preset cross-domain security rule base stores multiple conflict rules, each limiting mutually exclusive attribute combinations. If any combination of target attributes matches any conflict rule, it is determined that there are mutually exclusive attributes in the combination, a denial notification is returned to the data user, and the current access control process terminates; if no combination of target attributes matches any conflict rule, it is determined that there are no mutually exclusive attributes in the combination, and the double verification passes. The determination logic for state validity verification and conflict rule matching is as follows: Figure 5 As shown.

[0098] Thus far, step S105 has completed the dual verification of the validity of the attribute state and the mutual exclusion of the target attribute combination based on the attribute state matrix, which can promptly identify and intercept abnormal attribute combinations and reduce the risk of cross-organization attribute collusion attacks.

[0099] In step S106, the collaborative authorization coordinator extracts the latest attribute version number corresponding to each target attribute from the attribute state matrix, and arranges the extracted latest attribute version numbers in order of appearance of each target attribute in the access control policy tree to generate an attribute version list VersionList.

[0100] The collaborative authorization coordinator generates a one-time random number (Nonce) and determines the issuance time (IssueTime) and expiration time (ExpireTime) of the joint attribute token. Then, it concatenates the data user's identity, the encrypted file identifier, the attribute version list, the expiration time, and the one-time random number in sequence, and performs a hash calculation on the concatenation result to obtain the attribute digest.

[0101] In some embodiments, the one-time random number is a 128-bit high-entropy random number, and the issuance time and expiration time are absolute times.

[0102] In some embodiments, the attribute summary is calculated as follows: ; Where Digest represents an attribute digest; H represents a hash function, and the output of the hash function H is a group. The elements in the array include: UID (identifier of the data user), FID (file identifier of the encrypted data), VersionList (list of attribute versions), ExpireTime (expiration time of the combined attribute token), and Nonce (one-time random number). This represents the concatenation operator.

[0103] The attribute digest is a one-way hash value. The plaintext attribute information cannot be reversed after hash calculation, which avoids the exposure of plaintext attribute information and protects the attribute privacy of data users.

[0104] At this point, after the double verification is passed, step S106 generates an attribute version list arranged in a unified order and calculates the attribute summary. The unified order of the attribute version list ensures the consistency between the attribute version list generated by the collaborative authorization coordinator and the attribute version list parsed by the cloud server.

[0105] In step S107, the collaborative authorization coordinator distributes the attribute digest to each target attribute authorization authority for fragmented signing and aggregates the signed fragments to generate security authentication information. This specifically includes sub-steps S1071-S1073: S1071: The collaborative authorization coordinator distributes attribute summaries to each target attribute authorization agency. The target attribute authorization agencies receiving the attribute summaries are the same as those receiving the attribute verification requests; both are subsets of the target attribute authorization agencies. The institutions within.

[0106] S1072: Each target attribute authorization authority calls its locally held secure authentication private key fragment to sign the attribute digest, generating a signed fragment, and returns the signed fragment to the collaborative authorization coordinator. The secure authentication private key fragment is jointly generated by multiple attribute authorization authorities through a distributed protocol. No single target attribute authorization authority can independently recover the complete secure authentication private key from its own held secure authentication private key fragment.

[0107] S1073: The collaborative authorization coordinator collects the signature fragments returned by the authorization authorities of each target attribute, and aggregates the signature fragments to generate security authentication information.

[0108] In some embodiments, security authentication information uses a joint signature. The formula for calculating security authentication information is as follows: ; Wherein, SecurityAuthentication represents security authentication information; in this embodiment, the security authentication information is a joint signature. Sign indicates signature operation; The secure authentication private key is not fully held by any single entity. The aggregated secure authentication information is equivalent to a complete signature of the attribute digest signed using the secure authentication private key. Digest represents the attribute digest.

[0109] In some embodiments, security authentication information is implemented using aggregated signatures or threshold signatures. When using a threshold signature mechanism, the collaborative authorization coordinator collects signature fragments obtained from signatures of at least a preset number of target attribute authorization agencies, and aggregates the collected signature fragments to generate security authentication information. Even if some target attribute authorization agencies do not return signature fragments, aggregation can still be completed based on the preset number of signature fragments.

[0110] The security authentication information is generated by the joint signing of the security authentication private key fragments of multiple target attribute authorization agencies. No single attribute authorization agency can independently forge the security authentication information, thus ensuring the unforgeability of the joint attribute token.

[0111] In step S108, the collaborative authorization coordinator generates a joint attribute token and distributes it to the data user. After the cloud server dynamically verifies the joint attribute token, it releases the ciphertext to the data user. The data user decrypts the ciphertext locally using the user attribute private key.

[0112] The timing process of cloud-based dynamic access verification and local data decryption based on federated attribute tokens is as follows: Figure 6 As shown, this specifically includes sub-steps S1081~S1083: S1081: The collaborative authorization coordinator generates a federated attribute token that includes at least a list of attribute versions and security authentication information, and distributes the federated attribute token to the data user.

[0113] In some embodiments, the associated attribute token further includes an issuance time, an expiration time, and a one-time random number. The associated attribute token automatically expires after the expiration time. The encapsulation structure of the associated attribute token is as follows: ; Wherein, JAT represents the federated attribute token; UID represents the data user's identity identifier; FID represents the encrypted file identifier; Digest represents the attribute digest; VersionList represents the attribute version list; IssueTime represents the issuance time of the federated attribute token; ExpireTime represents the expiration time of the federated attribute token; Nonce represents a one-time random number; and SecurityAuthentication represents the security authentication information.

[0114] In some embodiments, the federated attribute token participates in access authorization verification only once or a specified number of times within its validity period, and no longer participates in any access control process after the expiration time.

[0115] S1082: The data user submits an access request for encrypted data and a federated attribute token to the cloud server. The cloud server maintains a global latest attribute version status baseline table, which records the latest attribute version number of each attribute synchronized by each attribute authorization authority. After receiving the access request and federated attribute token submitted by the data user, the cloud server performs dynamic verification in the following five progressive steps. Failure at any step will trigger a short circuit, directly blocking access.

[0116] First, verify the security authentication information. The cloud server extracts the identity identifier, file identifier, attribute version list, expiration time, and one-time random number from the federated attribute token, recalculates the attribute digest, and uses the security authentication public key to perform signature verification. The verification equation for the security authentication information is: ; Where VerifySign represents the signature verification operation; Represents the public key for security authentication; SecurityAuthentication represents the security authentication information; This indicates that the cloud server recalculates the attribute digest based on the plaintext fields in the federated attribute token. Verification fails if the verification equation is not true.

[0117] Second, verify the timeliness. Extract the current system time from the cloud server. Check the time-sensitive expressions If the condition is not met, the joint attribute token is deemed expired and the verification fails.

[0118] Third, verify the one-time random number. The cloud server checks whether the one-time random number in the combined attribute token already exists in the history. If it does, it is determined that a replay attack has occurred, and the verification fails.

[0119] In some embodiments, the cloud server queries the key-value pairs resident in memory to verify the database. If the one-time random number does not exist in the history, the one-time random number is written to the history and set to a lifespan that is the same as the expiration time.

[0120] Fourth, compare the attribute version list. The cloud server extracts the attribute version list from the federated attribute token. For each target attribute covered in the attribute version list, it performs an integer equality comparison with the corresponding record in the global latest attribute version status baseline table. The version consistency comparison equation is: ; Where Check_Condition represents the version consistency check result; ∧ represents a logical AND operation; and i represents the index of the target attribute, with a value ranging from 1 to... Integers; Represents the set of target attributes; Indicates the number of target attributes in the target attribute set; This represents the i-th target attribute in the target attribute set; The target attribute in the attribute version list of the combined attribute token The corresponding attribute version number; Indicates the target attribute in the global latest attribute version status baseline table. The corresponding latest attribute version number. When Check_Condition is true, the comparison result is considered to be consistent; when Check_Condition is false, the verification is considered to have failed.

[0121] When a target attribute is revoked, the authority managing that attribute updates the corresponding latest attribute version number and immediately pushes it to the cloud server. The global latest attribute version status baseline table is updated accordingly. However, the attribute version number already obtained by the data user still records the previous version number in the joint attribute token. The version consistency comparison equation no longer holds, Check_Condition outputs false, and the joint attribute token is deemed invalid. Therefore, the authority managing the target attribute only needs to update the attribute version number; there is no need to re-encrypt the encrypted data on the cloud server to achieve immediate permission revocation.

[0122] Fifth, release the ciphertext.

[0123] When all four verification steps above pass, the cloud server retrieves the encrypted data from the underlying storage and releases it to the data user.

[0124] S1083: The data user uses the user attribute private key obtained in advance from the authorization authority of each target attribute to decrypt the ciphertext locally. The user attribute private key is bound to the data user's identity identifier.

[0125] The expression for the local decryption algorithm is: ; Where F represents plaintext data; Decrypt represents the local decryption algorithm; and CT represents the ciphertext released by the cloud server. This represents the set of private keys for user attributes that the data user holds in advance.

[0126] User attribute private keys are generated by the authorizing authority of each target attribute based on the hash value of the identity identifier and the attribute master private key of each target attribute.

[0127] In some embodiments, the set of attributes held by a data user is denoted as ,for any attribute in Data users correspond to attributes The expression for the user's private key attribute is: ; in, Represents the set of attributes held by the data user; This indicates that the data user corresponds to the attribute. The user's private key; This indicates that the data user corresponds to the attribute. The first component of the user's private key; This indicates that the data user corresponds to the attribute. The second component of the user's private key; g represents the group. Generators; Represents attributes The first component of the master private key; Represents attributes The second component of the master private key is represented by H; H represents the hash function; and UID represents the identity identifier of the data user.

[0128] During decryption, the data user performs a bilinear pairing operation on each row x of the access matrix that satisfies the access control policy, eliminating random numbers and restoring the blinding factor. The formula for calculating the row pairing result is: ; in, This represents the pairing result for row x; This represents the row secret blinding component of line x in the ciphertext; This represents the random number recovery component for line x in the ciphertext; This indicates that the attribute of line x in the ciphertext is a private key bound component; , This represents the two components of the user's private key corresponding to attribute ρ(x). e denotes a bilinear mapping; g denotes a group. The generators. After simplification, , This represents the secret slice corresponding to the x-th row of the access matrix.

[0129] The secret restorative formula is: ; in, This indicates that the rows x that satisfy the access control policy are multiplied together. This represents the Lagrange interpolation coefficient corresponding to row x; represents the secret fragment corresponding to the x-th row of the access matrix; s represents the secret chosen by the data owner during encryption.

[0130] The extraction formula for the symmetric key is: ; Where κ represents the symmetric key; C represents the cryptographic covert component; This represents the blinding factor.

[0131] The decryption formula for plaintext data is: ; Where F represents plaintext data; This represents a symmetric decryption operation; κ represents the ciphertext of the underlying data; κ represents the symmetric key.

[0132] Thus far, step S108 has completed the generation and distribution of the joint attribute token, cloud-based dynamic verification, and local decryption, constructing a two-level access control model in which the cloud holds the joint attribute token to control the release of ciphertext, and the local user holds the user attribute private key to complete mathematical decryption, thereby realizing the separation of dynamic authorization verification and cryptographic decryption.

[0133] On the other hand, the present invention also provides a fine-grained dynamic access control method for data based on attribute encryption. This method is executed on a cloud server and is used to verify the combined attribute token generated by any of the above methods, including steps S201 to S205: Step S201: Receive the latest attribute version number synchronized by multiple attribute licensing organizations, maintain a global latest attribute version status baseline table, and synchronize the latest attribute version number after it is updated by the attribute licensing organization when the attribute status changes.

[0134] Step S202: Receive the ciphertext uploaded by the data owner, associate the ciphertext with the access control policy and store it. The ciphertext is obtained by the data owner through attribute-based encryption of the data to be shared in accordance with the access control policy.

[0135] Step S203: Receive the data user's access request for the encrypted text and the associated attribute token. The access request includes at least the data user's identity identifier.

[0136] Step S204: Verify the security authentication information in the federated attribute token and compare the attribute version list in the federated attribute token with the global latest attribute version status baseline table.

[0137] Step S205: When the security authentication information is verified and the comparison results are consistent, the ciphertext is released to the data user. The data user decrypts the ciphertext locally using the user attribute private key obtained in advance from each attribute authorization authority. The user attribute private key is bound to the identity identifier.

[0138] In step S201, the cloud server continuously receives the latest attribute version number synchronized by multiple attribute authorization agencies, and updates the corresponding record of each attribute in the global latest attribute version status baseline table with the latest received attribute version number, so that the global latest attribute version status baseline table always remains up-to-date.

[0139] In some embodiments, a daemon process is deployed on the cloud server side. The daemon process initiates synchronous calibration to each attribute authorization agency according to a preset period, obtains the latest attribute version number maintained locally by each attribute authorization agency, and verifies and corrects the records in the global latest attribute version status baseline table.

[0140] In step S202, the cloud server persistently stores the ciphertext to support the reading of corresponding access control policies based on the ciphertext.

[0141] In step S203, the combined attribute token is used to indicate that the data user's access has been authorized by the collaborative authorization coordinator.

[0142] In step S204, the verification of security authentication information is used to confirm that the joint attribute token has been jointly signed by the authorization authorities of each target attribute and has not been tampered with, and the comparison of the attribute version list is used to confirm that the attribute version number of each target attribute has not changed when the access occurs.

[0143] In step S205, if the security authentication information verification fails or the comparison results are inconsistent, the cloud server blocks the data user's access.

[0144] Thus far, steps S201 to S205 have completed the cloud server's control over the receipt, verification, and ciphertext release of the federated attribute token, which, together with steps S101 to S108, constitutes a complete fine-grained dynamic access control process for data.

[0145] On the other hand, the present invention also provides a fine-grained dynamic access control system for data based on attribute encryption, including a collaborative authorization coordinator, a cloud server, multiple attribute authorization agencies, a data owner terminal, and a data user terminal; The collaborative authorization coordinator is configured to implement a fine-grained dynamic access control method for data based on attribute encryption, as described above. The cloud server is configured to execute the fine-grained dynamic access control method for data based on attribute encryption as described above; Each attribute authorization authority is configured to maintain the latest attribute version number, update the latest attribute version number and synchronize it to the cloud server when the attribute status changes, and issue user attribute private keys bound to identity identifiers to data user terminals; The data owner's end is configured to perform attribute-based encryption on the shared data according to the access control policy to obtain ciphertext, and then upload the ciphertext to the cloud server; The data user client is configured to send an access request to the collaborative authorization coordinator, receive a federated attribute token and submit the federated attribute token to the cloud server, and use the user attribute private key to locally decrypt the obtained ciphertext.

[0146] The present invention will now be described with reference to a specific embodiment: This embodiment is applied to a cloud storage data sharing scenario involving collaborative management by multiple attribute-authorized organizations. Addressing the need for dynamic verification of attribute status and fine-grained permission management during data access, it constructs a fine-grained dynamic access control system based on attribute encryption. This system involves five types of entities: data owners, data users, attribute-authorized organizations, collaborative authorization coordinators, and cloud servers. The main technical solution is as follows: system initialization generates common system parameters and various keys; the data owner performs attribute-based encryption on the data to be shared and uploads it to the cloud server; when a data user initiates access, the collaborative authorization coordinator performs dynamic policy parsing and collaborative authorization decisions, generating and issuing a joint attribute token; the cloud server dynamically verifies the joint attribute token, releasing the ciphertext upon successful verification; the data user decrypts the ciphertext locally using their user attribute private key to recover the plaintext data. The specific technical solution is as follows: Step 1. The system executes the initialization algorithm to generate common system parameters and completes entity initialization.

[0147] The expression for the system initialization algorithm is: ; Each attribute-authorizing agency jointly selects the group through a distributed network. , The system includes a bilinear mapping e, a generator g, and a hash function H. The system officially releases its global public parameter set, expressed as: ; The entire network does not rely on any centralized key generation center (KGC) or trusted third party. Each attribute authorization authority... Each independently runs its local key generation algorithm, targeting each attribute under its jurisdiction. The master private key component is randomly selected in the local trusted execution environment using a hardware random number generator. and , .

[0148] The expression for the attribute public key is: ; The expression for the master private key attribute is: ; The attribute authorization agencies will generate Broadcast to the system's global directory tree for data owners to query.

[0149] Each attribute authorization authority initializes a unique attribute version number for each attribute under its jurisdiction in its local permission relational database, with the initial value of the attribute version number being a constant 0.

[0150] To ensure the unforgeability of the joint attribute token in subsequent steps, all attribute authorities jointly participate in running a distributed key generation protocol (DKG) based on the Shamir secret sharing mechanism. Once this protocol interaction is complete, a globally shared secure authentication public key for digital signatures is generated across the entire network. The corresponding signing private key does not exist completely on any single node; each attribute authorization authority only secretly keeps one fragment of the secure authentication private key. .

[0151] The Collaborative Authorization Coordinator (CAC) loads the complete Attribute Mapping Index (AMI) into the local in-memory database and establishes a cache of attributes to IP addresses. The cloud server completes the registration of the verification component API. Simultaneously, each attribute authorization authority, based on the set of attributes of authenticated data users, executes the KeyGen() attribute private key generation algorithm to distribute user attribute private keys bound to globally unique identifiers (UIDs) to legitimate data users, and the system is ready.

[0152] Step 2. The data owner (DO) executes a data encryption algorithm to encrypt the privacy data and uploads it to the cloud server.

[0153] The expression for the data encryption algorithm is: ; The data owner, DO, uses the system's secure random number generator on their local terminal to generate a 256-bit symmetric key for the plaintext data file F to be shared. DO invokes the AES-256-GCM advanced symmetric encryption standard to perform efficient streaming encryption on file F, generating basic data ciphertext. The formula for calculating the basic data ciphertext is: ; DO from the multiplication group A scalar *s* is randomly selected as the core secret for this encryption process. This secret *s* will be used to directly blind the symmetric key *k*. The calculation formula for the cryptographic covert shell component is: ; The DO (Directory of Access) first constructs a policy tree based on fine-grained access control policies, and then calls the Linear Secret Sharing Scheme (LSSS) transformation algorithm to convert the policy tree into a linear secret sharing scheme structure. The expression for the access control policy is: ; Subsequently, DO performs a secret sharing operation based on the LSSS matrix M. DO randomly selects a column vector of length n, expressed as: ; The first element of the vector v is set to the aforementioned secret s, and the remaining n-1 elements are all derived from the multiplicative group. A random scalar is selected from the matrix M. For each row x of the access matrix M, x takes the value of an integer from 1 to 1. DO calculates the inner product to obtain the secret slice for each row. The formula for calculating the row secret slice is: ; For each row x of the matrix, DO again starts from... Randomly selected anti-collusion blinding scalar DO queries the public key corresponding to the mapped attribute ρ(x). The expression for the public key is: ; The calculation formula for the secret blinding component is: ; The formula for calculating the random number recovery component is: ; The formula for calculating the private key binding component is: ; The data owner serializes and packages all the data structures generated above and uploads them to the cloud server. The ciphertext composition expression is as follows: ; Step 3. The Collaborative Authorization Coordinator (CAC) executes the collaborative authorization and token generation algorithm.

[0154] The expression for the collaborative authorization and token generation algorithm is: ; The execution of the Policy Dynamic Resolution (PDP) mechanism. When CAC receives a request from a data user, it no longer blindly broadcasts to all organizations across the network. Instead, it precisely identifies the verification scope by invoking the Policy Dynamic Resolution algorithm. The specific execution steps are as follows: Read the root node of the access control policy tree corresponding to the file prefetched from the cloud; The depth-first search (DFS) algorithm is used to perform a top-down full path traversal of the access control policy tree; Extract all attribute tags located at leaf nodes in the strategy tree; All extracted attribute tags are deduplicated and normalized to establish a set of target attributes that must be verified for this access. ; The system queries the pre-defined attribute mapping index that resides in memory to retrieve the physical network IP addresses that manage each attribute in the target attribute set, thereby converging to obtain a subset of the target attribute authorization agencies. CAC sends targeted verification messages based on this subset list.

[0155] In terms of communication complexity, the network communication complexity of the traditional broadcast authentication mode is: Where N represents the total number of attribute authorization agencies in the system; and the policy dynamic parsing mechanism in this embodiment, through the aforementioned precise convergence, significantly reduces the communication complexity to That is, it is only related to the number of authorized agencies with attributes that actually participate in the strategy, and Much smaller than N, reducing communication redundancy in the distributed network. The execution logic of this process is as follows: Figure 4 As shown.

[0156] Dynamic construction of the attribute state matrix. Located in a subset of the target attribute authorization authority. Upon receiving a targeted request, the internal attribute licensing authority queries its local database and returns to the CAC a result containing the attribute tag, validity status identifier, and latest integer version number. The structured response package. After receiving all asynchronous responses, CAC establishes a two-dimensional attribute state matrix in main memory to store the baseline data for conflict determination. The matrix fields are standardized as follows: UID: User identifier, Attribute: Attribute name, State: Current state, with values ​​such as Valid, Revoked, Suspended, etc., Version: Attribute version number, Timestamp: Return time, AAID: Attribute authorization agency number.

[0157] The Collaborative Authorization Decision Algorithm (CADA) executes its decisions. The CADA algorithm uses the attribute state matrix as its core input. To reduce the risk of cross-domain attribute conflicts and collusion exceeding authority, it performs closed-loop decisions according to the following decision order and calculation process. The logical processing flow is as follows: Figure 5 As shown: Step 1: State Validity Check. The algorithm iterates through all rows of the matrix, verifying the State field item by item. If any row is found to be invalid... The algorithm triggers short-circuit evaluation logic and directly outputs the decision result. The algorithm terminates when a rejection notification is sent to the data user.

[0158] Step 2: Cross-domain mutual exclusion rule matching. If all attribute states are valid, the algorithm calls the system's preset cross-domain security rule library for matching. If the attribute combination in the matrix matches any conflicting rule, for example, if a data user simultaneously possesses the "left-behind" attribute and the "core R&D personnel" attribute, the algorithm outputs... The algorithm terminates.

[0159] Step 3: Version Consistency Check. After confirming that the full state is valid and there are no cross-domain conflicts, the algorithm determines that the initial authorization is passed. CAC sequentially extracts the Version field corresponding to each attribute in the matrix and arranges them in order of appearance of the attributes in the policy tree to generate the core verification data structure, namely the attribute version list. , where m represents the number of target attributes involved in the current data access.

[0160] Step 4: Comprehensive authorization determination and output. After the decision is approved, the algorithm finally outputs... This triggers the subsequent token generation and encapsulation process. Then, the cryptographic encapsulation of the Joint Attribute Token (JAT) is performed: to defend against network replay attacks, CAC generates a 128-bit high-entropy one-time random number (Nonce); simultaneously, it assigns the token an absolute issuance time (IssueTime) and a short expiration time (ExpireTime). CAC calls a hash function to calculate a unified digital digest; the formula for calculating the attribute digest is: ; CAC will distribute the summary to a subset of authorized agencies participating in the verification of the target attributes. Each attribute-authorized authority in the system calls its locally held security authentication private key fragment to generate a signature fragment and sends it back. CAC ultimately aggregates and generates a global security authentication information, SecurityAuthentication, equivalent to a complete private key signature. This embodiment uses a federated signature. Alternatively, aggregate signatures or threshold signatures can be used. Finally, CAC encapsulates the above fields into a serialized data structure. The encapsulation structure of the combined attribute token is as follows: ; JAT only needs to participate in access authorization verification once or a specified number of times within the validity period to meet the requirements. ,in, It represents the current system time; it automatically expires after ExpireTime is reached and will no longer participate in any access control process.

[0161] Step 4. The cloud server (CS) executes the cloud-based dynamic verification algorithm.

[0162] The expression for the cloud-based dynamic verification algorithm is: ; After receiving the Joint Attribute Token (JAT) submitted by the user via network request, the cloud server (CS) must execute the cloud-based dynamic verification algorithm in the following progressive five-step verification sequence to ensure real-time dynamic interception and high security. Failure at any step will cause the algorithm to short-circuit and directly output 0, blocking access: Step 1: Verify security authentication information. CS first extracts the plaintext field from the token and recalculates the digest, then calls the public security authentication key. Execute the verification algorithm. If the verification result is false, the algorithm outputs 0 and disconnects.

[0163] Step 2: Verify the expiration time. CS extracts the current system absolute time. Check the logical expression ( If the token is deemed expired, the algorithm outputs 0 and blocks the operation.

[0164] Step 3: Verify the anti-replay flag. CS queries the high-performance key-value database resident in memory to check if JAT.Nonce already exists in the history pool. If it exists, it is determined that a replay attack has been intercepted, and the algorithm outputs 0; if it does not exist, the one-time random number is written to the history pool and a time-to-live (TTL) equal to the expiration time is set.

[0165] Step 4: Verify the attribute version list and fine-grained instant undo. Extract JAT.VersionList from the CS (Client / Server) database. For each specific attribute tag covered in this list... CS maintains a global baseline table of the latest attribute versions locally. The system searches for the latest corresponding record value in the baseline table, which is updated instantly by the attribute authorization authority when the version number changes and periodically synchronized and calibrated by the daemon process. CS performs integer equality checks; the comparison equation for version consistency is: ; If the identity logical expression outputs true, it means that no attribute deprivation event has occurred at any attribute granting authority. Conversely, if a required attribute is deregistered within a short period of time, the source attribute granting authority will immediately increment the local version number of that attribute by 1. This is then immediately pushed to the cloud. At this point, the equation becomes invalid, the entire logical expression Check_Condition outputs false, the old token is deemed invalid, and fine-grained permission revocation is achieved without the need for re-encryption.

[0166] Step 5: Release the ciphertext. The verification algorithm returns 1 only if all the verifications in Steps 1 through 4 pass sequentially. The cloud server retrieves the corresponding ciphertext data packet CT from the underlying storage system, releases it, and distributes it to the data user.

[0167] Step 5. The Data User (DU) executes the local decryption algorithm.

[0168] The expression for the local decryption algorithm is: ; The set of attributes held by a data user is denoted as .for any attribute in The expression for the user attribute private key held by the data user is: ; Blinding factor elimination based on bilinear pairing. For each row x that satisfies the access control policy, the following operation is performed, and the row pairing result is calculated as follows: ; By simplification, we get: ; Secret recovery and symmetric decryption. The data user performs a series of Lagrange exponentiation operations; the secret recovery formula is: ; The extraction formula for the symmetric key is: ; The decryption formula for plaintext data is: ; The complete original plaintext data file has been successfully read and restored. The two-level control model in this embodiment has now completed closed-loop operation throughout its entire lifecycle.

[0169] In summary, this invention provides a fine-grained dynamic access control method and system for data based on attribute encryption. When access occurs, a collaborative authorization coordinator receives access requests for ciphertext, parses the associated access control policies, and narrows the verification scope to targeted verification by the target attribute authorization agency. This ensures that authorization decisions are based on the latest attribute state, changing the authorization model that relies on static attribute states during key issuance and avoiding communication redundancy caused by network-wide broadcasting. Furthermore, it receives the attribute state and the latest attribute version number, verifies the validity of the state and the mutual exclusion of combinations, and promptly intercepts cross-agency attribute conflicts and collusion to exceed authority, alleviating the problem of attribute state isolation among multiple agencies. After successful verification, an attribute version list is generated and an attribute digest is calculated, solidifying the attribute state at the time of authorization as a version snapshot, making the authorization basis immutable. Finally, each target attribute authorization agency uses a secure authentication private key to segment and sign, and aggregates the signatures to generate secure authentication information. A single agency cannot forge authorization credentials, solving the problems of key escrow and single point of trust. By issuing a federated attribute token, the cloud server verifies the security authentication information and releases the ciphertext after comparing the attribute version list with the global latest attribute version status baseline table. Revoking permissions only requires updating the attribute version number to make the token instantly invalid, without the need for re-encryption, thus achieving fine-grained dynamic access control and instant permission revokement. The ciphertext is decrypted locally by the data user using the user attribute private key bound to their identity identifier. The cloud server does not access the plaintext or the key, mitigating the risk of data leakage in a semi-trusted cloud environment.

[0170] Furthermore, the present invention employs a version synchronization mechanism that combines real-time push and periodic calibration to avoid inconsistent version status and revocation delays; it adopts a threshold signature mechanism so that aggregation can still be completed even when some institutions do not respond; and it incorporates the expiration time and a one-time random number into the digest calculation so that the token automatically expires and resists replay attacks.

[0171] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0172] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0173] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0174] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A fine-grained dynamic access control method for data based on attribute encryption, characterized in that, The method is executed by a collaborative authorization coordinator and includes the following steps: The system receives access requests from data users for encrypted data. The access requests include at least the identity identifier of the data user. The encrypted data is obtained by the data owner through attribute-based encryption of the data to be shared according to the access control policy and then uploaded to the cloud server. The access control policy is stored in association with the encrypted data. Obtain and parse the access control policy associated with the ciphertext, extract the target attributes involved in the access control policy, and determine the target attribute authorization authority that manages each of the target attributes; Only send attribute verification requests to the authorized agency of the target attribute, and the attribute verification request includes at least the identity identifier of the data user and each of the target attributes to be verified; The system receives the attribute status and latest attribute version number of the data user returned by each of the target attribute authorization agencies. The latest attribute version number is updated by the target attribute authorization agency and synchronized to the cloud server when the attribute status changes. Verify whether all attribute states are valid, and according to preset cross-domain security rules, verify whether there are mutually exclusive attributes in the combination of target attributes; When all the attribute states are valid and there are no mutually exclusive attributes in the combination of the target attributes, extract the latest attribute version number combination to generate an attribute version list, and calculate the attribute summary containing the attribute version list; The attribute digest is distributed to each of the target attribute authorization agencies. The signature fragments obtained by each target attribute authorization agency signing the attribute digest using their respective security authentication private key fragments are collected. The signature fragments are aggregated to generate security authentication information. The security authentication private key fragments are jointly generated by multiple attribute authorization agencies through a distributed protocol. A joint attribute token, including at least the attribute version list and the security authentication information, is generated and sent to the data user. The cloud server verifies the security authentication information and, after comparing the attribute version list with the global latest attribute version status baseline table maintained by the cloud server, releases the ciphertext to the data user. The ciphertext is then locally decrypted by the data user using a user attribute private key obtained in advance from each of the target attribute authorization authorities. The user attribute private key is bound to the identity identifier.

2. The fine-grained dynamic access control method for data based on attribute encryption according to claim 1, characterized in that, The determination of the target attribute authorization organization for managing each of the target attributes includes: The preset attribute mapping index is queried to obtain the target attribute authorization agency that manages each target attribute. The preset attribute mapping index records the mapping relationship between each attribute and each attribute authorization agency.

3. The fine-grained dynamic access control method for data based on attribute encryption according to claim 1, characterized in that, The synchronization to the cloud server includes: When the attribute status changes, the target attribute authorization agency immediately pushes the latest attribute version number to the cloud server and responds to the synchronization calibration initiated by the cloud server according to a preset period, synchronizing the latest attribute version number to the cloud server.

4. The fine-grained dynamic access control method for data based on attribute encryption according to claim 1, characterized in that, The preset cross-domain security rules are multiple conflicting rules stored in the preset cross-domain security rule base, and each of the conflicting rules limits mutually exclusive attribute combinations; The step of verifying whether there are mutually exclusive attributes in the combination of target attributes according to preset cross-domain security rules includes: The preset cross-domain security rule base is invoked to perform conflict rule matching on the combination of each target attribute. When any of the conflict rules is matched, it is determined that there are mutually exclusive attributes in the combination of each target attribute.

5. The fine-grained dynamic access control method for data based on attribute encryption according to claim 1, characterized in that, The aggregation of each signature fragment to generate security authentication information includes: Based on the threshold signature mechanism, at least a preset number of signature fragments obtained by the signatures of the target attribute authorization authorities are collected, and the collected signature fragments are aggregated to generate the security authentication information.

6. The fine-grained dynamic access control method for data based on attribute encryption according to claim 1, characterized in that, The attribute digest is calculated from the attribute version list, expiration time, one-time random number and the file identifier of the ciphertext; the combined attribute token also includes the issuance time, the expiration time and the one-time random number, and the combined attribute token automatically expires after the expiration time.

7. The fine-grained dynamic access control method for data based on attribute encryption according to claim 1, characterized in that, The user attribute private key is generated by each of the target attribute authorization agencies based on the hash value of the identity identifier and the attribute master private key of each target attribute.

8. The fine-grained dynamic access control method for data based on attribute encryption according to claim 4, characterized in that, An attribute status matrix is ​​constructed based on the received attribute statuses. The attribute status matrix includes at least the identity identifier, each target attribute, each attribute status, each latest attribute version number, return time, and the organization number of the authorization organization for each target attribute. The step of verifying whether each attribute state is a valid state includes: traversing the attribute state matrix and verifying whether each attribute state is a valid state one by one. The conflict rule matching is performed on the combination of each of the target attributes in the attribute state matrix; The step of extracting the latest attribute version numbers to generate an attribute version list includes: extracting the latest attribute version numbers from the attribute state matrix, arranging them in order of appearance of the target attributes in the policy tree of the access control policy, and generating the attribute version list.

9. A fine-grained dynamic access control method for data based on attribute encryption, characterized in that, The method is executed on a cloud server and is used to verify the joint attribute token generated by the method according to any one of claims 1 to 8. The method includes the following steps: Receive the latest attribute version number synchronized by multiple attribute licensing agencies, maintain a global latest attribute version status baseline table, wherein the latest attribute version number is updated and synchronized by the attribute licensing agency when the attribute status changes; Receive ciphertext uploaded by the data owner, associate the ciphertext with the access control policy and store it. The ciphertext is obtained by the data owner through attribute-based encryption of the data to be shared in accordance with the access control policy. Receive an access request for the encrypted text submitted by a data user and the associated attribute token, wherein the access request includes at least the identity identifier of the data user; The security authentication information in the combined attribute token is verified, and the attribute version list in the combined attribute token is compared with the global latest attribute version status baseline table; When the security authentication information is verified and the comparison results are consistent, the ciphertext is released to the data user. The ciphertext is then decrypted locally by the data user using the user attribute private key obtained in advance from each of the attribute authorization agencies. The user attribute private key is bound to the identity identifier.

10. A fine-grained dynamic access control system for data based on attribute encryption, characterized in that, This includes a collaborative authorization coordinator, cloud servers, multiple attribute authorization agencies, data owner terminals, and data user terminals; The collaborative authorization coordinator is configured to perform the attribute-encryption-based fine-grained dynamic access control method for data as described in any one of claims 1 to 8; The cloud server is configured to execute the attribute-encrypted fine-grained dynamic access control method for data as described in claim 9; Each of the attribute authorization authorities is configured to maintain the latest attribute version number, update the latest attribute version number and synchronize it to the cloud server when the attribute status changes, and issue user attribute private keys bound to identity identifiers to the data user terminal; The data owner's end is configured to perform attribute-based encryption on the data to be shared according to the access control policy to obtain ciphertext, and then upload the ciphertext to the cloud server; The data user terminal is configured to send an access request to the collaborative authorization coordinator, receive a joint attribute token and submit the joint attribute token to the cloud server, and use the user attribute private key to locally decrypt the obtained ciphertext.