A multi-keyword sorted encrypted retrieval method under a multi-owner, multi-data user model

Abstract

This invention discloses a multi-keyword sorted encrypted retrieval method under a multi-owner, multi-data user model. The method performs system initialization, key generation, data outsourcing, query trapdoor generation, cloud server permission verification and encrypted retrieval, pre-decryption and final decryption, and permission update and revocation. This invention significantly reduces communication and computational overhead.

Description

Technical Field

[0001] This invention relates to the field of data security related to data outsourcing storage and encrypted retrieval, specifically to a multi-keyword sorted encrypted retrieval method under a multi-owner, multi-data-user model. Background Technology

[0002] With the rapid development of the internet, more and more data users are storing their data in cloud environments to easily store and access shared data resources. The multi-owner, multi-user data sharing model is a crucial architecture in the current field of distributed data collaboration, particularly valuable in sectors like healthcare and finance. For example, in the healthcare scenario, geographically dispersed hospitals outsource patient data to a unified cloud service provider. Cross-institutional data interoperability allows for the integration of complete patient medical information, supporting doctors in accurate diagnosis and treatment.

[0003] Traditional solutions suffer from two major drawbacks: first, data users must submit query trapdoors to each owner individually, resulting in significant communication overhead; second, while using shared-key encryption simplifies the query process, it also introduces the risk of data misuse. Furthermore, current multi-owner, multi-data-user models still face limitations in secure multi-keyword ranking searches: on the one hand, some solutions rely on trusted third parties (TTPs) to collect encrypted indexes and authorize search permissions, increasing maintenance costs and creating single points of failure; on the other hand, in scenarios without TTPs, each data owner encrypts the index using their own key, making it difficult for data users to generate trapdoors suitable for multiple owners, hindering the ability to retrieve data from multiple owners simultaneously and rank them by relevance. Therefore, constructing a secure and efficient encrypted retrieval method adapted to multi-owner, multi-data-user models has become a pressing technical challenge. Summary of the Invention

[0004] This invention provides a multi-keyword sorted encrypted retrieval method under a multi-owner, multi-data-user model, applicable to a multi-owner, multi-data-user data sharing system comprising an authoritative center, data owners, data users, and a cloud server. The method sequentially executes the following steps:

[0005] Step 1: System initialization, where the authoritative center completes the configuration of basic system parameters, key system construction, and key distribution, laying the foundation for the secure operation of the entire retrieval method;

[0006] Step 2: Key generation, which is completed collaboratively by the authority center, data owner, and data user, generates permission level keys and search keys for each level of entity, which are used for subsequent encryption, retrieval, and permission verification;

[0007] Step 3: Data outsourcing. The data owner completes index generation and file encryption, and outsources the encrypted data, encrypted index tree, and owner-level access control ciphertext to cloud server storage.

[0008] Step 4: Query trapdoor generation. Data users generate query trapdoors and pre-decryption keys based on their own search keys and query requirements, and submit them to the cloud server to initiate a retrieval request.

[0009] Step 5: Cloud server permission verification and encrypted retrieval. After receiving the query trap, the cloud server performs owner-level permission verification in sequence. After successful verification, it performs encrypted retrieval based on the secure KNN algorithm and sorts the retrieval results by relevance.

[0010] Step 6: Pre-decryption and final decryption. The cloud server performs a pre-decryption operation on the sorted search results. After receiving the pre-decryption result, the data user completes the final decryption to obtain the original file.

[0011] Step 7: Permission Update and Revocation. When a data user's access permissions change, the authority center updates the permission version number and related keys, the data owner updates the public key, and the cloud server updates the storage information, achieving efficient permission update and revocation and ensuring that users whose permissions have been revoked cannot access the data.

[0012] The technical effects of this invention are as follows:

[0013] 1. This solution addresses the issue of high communication overhead in traditional solutions, enabling data users to query data from all owners within their authorized scope at once by submitting only one trapdoor, eliminating the need to submit separate query requests to each owner and significantly reducing communication and computational costs.

[0014] 2. By abandoning reliance on trusted third parties (TTPs), the data owner independently generates a secure index. At the same time, through two-level access control (owner-level permission verification and attribute-level permission verification), fine-grained access control is achieved, which avoids the risk of single point of failure and prevents data abuse, thus ensuring the security and privacy of data sharing.

[0015] 3. By combining the secure KNN algorithm with a multi-keyword ranking mechanism, the relevance ranking of search results is achieved, meeting data users' needs for accurate retrieval and efficient filtering, and improving the retrieval experience and efficiency.

[0016] 4. Design an owner-level permission update and revocation mechanism based on permission version number. When a data user's access permissions change, the key can be updated efficiently to prevent users whose permissions have been revoked from accessing data using old keys, thus ensuring the flexibility and security of permission management.

[0017] 5. By transferring part of the decryption calculation to the cloud server through the pre-decryption mechanism, the computational burden on the data user end is reduced, balancing retrieval efficiency and the user end's need for lightweight operation, and adapting to the data sharing and usage needs of multiple scenarios. Detailed Implementation

[0018] I. System Composition for Application of This Method

[0019] This method is applied to a multi-owner, multi-data user data sharing system, and includes four core entities. The core functions of each entity are as follows, and the specific parameters and generation logic will be explained in detail in subsequent method steps:

[0020] 1. Trusted Authority (TA)

[0021] As the trusted core of the system, it is mainly responsible for system initialization, generation and distribution of various keys, permission version management and permission update, ensuring the key security and permission control of the entire system, which is the foundation for the normal operation of the system.

[0022] 2. Data Owner (DO)

[0023] It is responsible for encrypting its own data, building a secure index tree, outsourcing the encrypted data and index to a cloud server, managing access permissions for its own data, and responding to permission update instructions from the authority center.

[0024] 3. Data User (DU)

[0025] Apply for access permissions from the authoritative center, generate a query trap and submit it to the cloud server to initiate a search request, receive and decrypt the search results returned by the cloud server, complete data access, and at the same time receive the permission update key to adapt to permission changes.

[0026] 4. Cloud Server (CS, Cloud Server)

[0027] It stores encrypted data and encrypted indexes outsourced by the data owner, receives query traps submitted by data users, performs permission verification, encrypted retrieval and pre-decryption operations, and returns the retrieval results and pre-decrypted data to the data user.

[0028] II. Steps of the Multi-Keyword Sorting Ciphertext Retrieval Method of the Present Invention

[0029] This method sequentially executes the following steps: system initialization, key generation, data outsourcing (index generation + data encryption), query trapdoor generation, cloud server permission verification, encrypted retrieval, pre-decryption, final decryption, and permission update and revocation, as detailed below:

[0030] Step 1: System Initialization

[0031] The main tasks of this step are: to complete the configuration of basic system parameters, the construction of the key system, and the distribution of keys, laying the foundation for the secure operation of the entire retrieval method. Detailed explanations of the sub-steps are as follows:

[0032] S1.1: TA first inputs the security parameter λ (a fundamental system security parameter used to determine the security strength of the encryption algorithm), selects a multiplication group G with g (the generator of the cyclic multiplication group G) as its generator based on λ, and determines the multiplication group G and the target group. The order p (a large prime number, ensuring the safety of group operations) of the target group (corresponding to group G, used to store the result of the bilinear mapping) is defined as the bilinear mapping e: G×G→ ;

[0033] S1.2: TA defines two collision-resistant hash functions: (Used to map attribute values ​​to elements in group G, ensuring the uniqueness and security of the mapping results) and (Used to map inputs of arbitrary length to a set of non-zero integers modulo p, providing randomization support for key generation). It is a multiplicative group modulo p.

[0034] S1.3: TA sets the global attribute set (Contains all available attribute names in the system, where n is the number of attribute names) and the corresponding set of attribute values. (Corresponding one-to-one with elements within U, representing the specific attribute values ​​corresponding to elements with the same label within att), targeting Randomly select a number (Used for the generation and verification of subsequent attribute-level keys), calculation x is the element number of the set.

[0035] S1.4: TA is randomly selected (Used for master key generation and attribute-level access control) (System encryption core parameters, used for generating master key, public key, and various other keys), select (Permission version number, used for updating and revoking owner-level permissions, preventing revoked users from accessing data using old keys), Build the master key (A key held solely by the TA and used to generate various types of entities).

[0036] S1.5: TA generates the master public key based on msk:

[0037]

[0038] It is made public to all entities in the system for operations such as encryption and trapdoor generation. The msk is kept separately by the TA to complete system initialization.

[0039] Step 2: Key Generation Phase

[0040] The main task of this step is to generate and distribute various keys for cloud servers, data owners, and data users. It is divided into two sub-steps: "Permission-Level Key Generation" and "Search Key Generation." Each sub-step contains several sub-sub-steps, detailed below:

[0041] 2.1 Permission Level Key Generation Stage

[0042] This phase is led by the Authoritative Controller (TA), which generates keys related to access permissions and distributes them to the Cloud Server (CS), Data Owner (DO), and Data User (DU) to ensure access control and authentication for each level of entity. The sub-steps are as follows:

[0043] 2.1.1 Cloud Server Key Generation

[0044] TA randomly selects one ∈ Use it as the private key for the cloud server. Simultaneously calculate the public key of the cloud server. ,Will Secretly distributed to CS, It is made public to all DOs and DUs.

[0045] 2.1.2 Data Owner Key Generation

[0046] For each data owner (i∈[1,m], where i is the data owner number and m is the total number of data owners), TA performs the following operations:

[0047] S2.1.2.1: Randomly select two random numbers , ;

[0048] S2.1.2.2: Calculate the components of the public key based on the selected random number and the system permission version number ver. ;

[0049] S2.1.2.3: Construction private key public key ; This represents the owner of the i-th data.

[0050] S2.1.2.4: Transfer the private key Secretly sent to the corresponding data owner , public key Open to cloud server CS and all data users .

[0051] 2.1.3 Data User Key Generation

[0052] The authorization key for a data user consists of two parts: an "owner-level permission key" and an "attribute-level permission key." The specific generation process is as follows:

[0053] S2.1.3.1: Data User Submit its own set of attributes to TA (in For attribute names, (for corresponding attribute values) and the authorized data owner set S (S⊆{1,2,…,m}, representing Accessible DO range);

[0054] S2.1.3.2: Owner-level permission key generation: TA aggregates the public key information of all DOs in the authorization set S to generate two owner-level permission keys:

[0055] ;

[0056] ;

[0057] like (That is, if the data user is not authorized to access any DO), then TA will not generate the owner-level permission key. Unable to initiate a search request;

[0058] S2.1.3.3: Attribute-level permission key generation: TA is randomly selected. ,based on Submitted attribute set Generate attribute-level permission keys

[0059] S2.1.3.4: TA will transfer the owner-level permission key ( , ) and attribute-level permission keys Secretly sent to data users .

[0060] 2.2 Search Key Generation Stage

[0061] The keys generated in this stage are divided into two categories: keys used by the data owner (DO) to encrypt the index, and keys used by the data user (DU) to generate query trapdoors. The specific generation process is as follows:

[0062] S2.2.1: Generate a public binary vector: Generate a random binary vector D of length n (n corresponds to the size of the keyword dictionary), and make D public to all data owners DO and data users DU for subsequent segmentation and encoding of index vector and query vector;

[0063] S2.2.2: Generation of search keys for the data owner (DO): Each Perform the following operations:

[0064] S2.2.2.1: Generate two n×n invertible matrices , as its own private index encryption key;

[0065] S2.2.2.2: Random selection ,generate , ;

[0066] S2.2.2.3: Generate indicator matrix (where E is an n×n identity matrix);

[0067] S2.2.2.4: Stores its own search key components {D, }, used for the construction of subsequent encrypted indexes;

[0068] S2.2.3: Data User Search Key Generation: Each Based on its own set of authorized data owners S⊆{1,2,…,m}, perform the following operations:

[0069] S2.2.3.1: Aggregate all elements in S of , Two matrices are generated by combining them according to specific rules:

[0070] ;

[0071] ;

[0072] S2.2.3.2: Each Storage key components This is used for subsequent queries to generate trapdoors.

[0073] Step 3: Data Outsourcing Stage

[0074] The main tasks of this step are: to generate the index for the data owner, encrypt the file, and outsource the encrypted data, index, and related ciphertext to the cloud server. This step is divided into two sub-steps: the "index generation stage" and the "encryption stage," detailed below:

[0075] 3.1 Index Generation Stage

[0076] Each data owner Perform the following operations to complete the generation of ciphertext for owner-level access permissions and the construction of the encrypted index tree:

[0077] S3.1.1: Generate owner-level access permission ciphertext Random selection Calculate ciphertext ;

[0078] S3.1.2: Constructing an encrypted index tree: Based on the secure KNN (k-nearest neighbor) algorithm, for its own file set. Build an encrypted index tree The specific process is as follows:

[0079] S3.1.2.1: For each node η in the index tree, calculate the encrypted index vector. ;

[0080] S3.1.2.2: Based on the binary vector D, Divide into two sub-vectors and The segmentation rules are as follows:

[0081]

[0082] S3.1.2.3: Use its own search key , The two sub-vectors after splitting are encoded to obtain the encoded index vector. ;

[0083] S3.1.2.4: Using all encoded index vectors Build an encrypted index tree for the nodes. The leaf nodes correspond to the encrypted files, and the non-leaf nodes are the cluster centers of the child nodes, thus completing the construction of the index tree.

[0084] 3.2 Encryption Phase

[0085] Each data owner The file itself is encrypted, and the encryption key is also encrypted using attribute-based encryption. The specific steps are as follows:

[0086] S3.2.1: File encryption: for its own set of files Each file in Generate a symmetric key ,use right Perform symmetric encryption to obtain the encrypted file;

[0087] S3.2.2: Symmetric key encryption: using an access policy Attribute-based encryption is performed on the symmetric key K (where A is...). The access structure matrix (ρ maps each row of A to the corresponding attribute name, and π corresponds to the attribute value) is as follows:

[0088] S3.2.2.1: Randomly generated vectors ,in ,calculate ;

[0089] S3.2.2.2: Randomly select parameters (x∈[1,l]), generate attribute-based encrypted ciphertext of K. The components are defined as follows:

[0090]

[0091] S3.2.3: Outsourced Data Storage: Each Encrypt its own files and encrypted index tree Owner-level access encryption and symmetric key ciphertext The entire process is outsourced to a cloud server (CS), which then receives the data and performs the storage.

[0092] Step 4: Query trapdoor generation

[0093] The main task of this step is for data users to generate a query trap based on their own search key and query requirements, submit it to the cloud server, and initiate a retrieval request. The specific sub-steps are as follows:

[0094] S4.1: Data User Input multiple keywords to be queried, calculate the weight of each keyword based on the TF-IDF algorithm, and construct an n-dimensional query vector by combining the keyword dictionary size n. ; Use a keyword set To generate query vectors This vector is used to search for relevant files on the cloud server. Each keyword corresponds to an IDF (Inverse Document Frequency) value. The IDF value is 0 when the keyword is irrelevant.

[0095] S4.2: Based on the common binary vector D, the query vector Divide into two sub-vectors and The segmentation rules are consistent with the index vector segmentation rules:

[0096]

[0097] S4.3: DU calls its own stored search key , The segmented subvectors are encoded to obtain the encrypted query vector. ;

[0098] S4.4: DU integrates the encrypted query vector with its own authorization key to generate a query trapdoor:

[0099]

[0100] S4.5: Random selection The pre-decryption key for outsourced decryption of the cloud server:

[0101]

[0102] pre-decryption key Send to the cloud server, This serves as the decryption key for data users.

[0103] S4.6: DU will query trapdoors, The request is submitted to the cloud server CS to initiate a encrypted retrieval request, thus completing the generation of the query trapdoor.

[0104] Step 5: Cloud Server Permission Verification and Encrypted Text Retrieval

[0105] The main tasks of this step are as follows: After receiving the query trap, the cloud server sequentially completes owner-level and attribute-level permission verification, performs encrypted retrieval, and sorts the results by relevance. The specific sub-steps are as follows:

[0106] S5.1: Owner-level permission verification: CS receives the Trap and extracts... By combining the public keys (pk) of all stored DOs, the owner-level access permissions of the DU are verified:

[0107] S5.1.1: Verification =1

[0108] If the above formula holds true, it means that the data owner... Allow this data user Access the data; otherwise, reject the retrieval request and terminate subsequent operations.

[0109] S5.2: Encrypted Text Retrieval and Relevance Ranking: After successful authorization verification, the CS performs the following operations:

[0110] S5.2.1: Extract the encrypted query vector from the trapdoor Iterate through all those that have passed permission verification. Encrypted index tree ;

[0111] S5.2.2: Calculate based on the secure KNN algorithm. Encoding vector for each inode The relevance score is calculated using the following formula:

[0112] S5.2.3: Sort all index nodes from high to low according to the relevance score, select the top k nodes (k is the preset number of KNN nearest neighbors), and obtain the encrypted file, symmetric key ciphertext CK and the public key pk of the corresponding DO for these nodes;

[0113] Step 6: Pre-decryption and final decryption

[0114] The main tasks of this step are: the cloud server performs a pre-decryption operation to reduce the computational burden on the data user's end, and the data user completes the final decryption to obtain the original file. The specific sub-steps are as follows:

[0115] S6.1: Cloud Server Pre-decryption: CS performs a pre-decryption operation on each symmetric key ciphertext CK in the final result set:

[0116] S6.1.1: Calculate the pre-decryption result:

[0117]

[0118] );

[0119] S6.1.2: CS will , The corresponding encrypted file is sent together with the data user DU who initiated the retrieval request;

[0120] S6.2: Data User Final decryption: Receive CS sent , After encrypting the file, perform the following operations:

[0121] S6.2.1: Extract the self-attribute level permission key SKu In the context of K, calculate the symmetric key:

[0122] ;

[0123] S6.2.2: Using a symmetric key Decrypt the encrypted file to obtain the original file;

[0124] S6.2.3: DU can view and use the decrypted original file according to its own needs, thus completing the entire retrieval and decryption process.

[0125] Step 7: Permission Update and Revocation

[0126] The main task of this step is to update the key and control permissions when a data user's access permissions change (adding / revoking DO access permissions, changing attributes), preventing users whose permissions have been revoked from accessing the data. The specific sub-steps are as follows:

[0127] S7.1: Permission Change Trigger: When the set of authorized data owners S of DU changes (adding / deleting DO), update to The TA receives a permission change request and initiates the permission update process;

[0128] S7.2: Key Update Generation: TA updates the system permission version number and generates a new one. ∈ Regenerate the owner-level permission key for the DU. ;

[0129] S7.3: Key and Version Number Distribution: The TA will distribute the updated permission version number. New key ( , Secretly sent to At the same time Notify all DOs and cloud server CSs;

[0130] S7.4: Data owner public key update: This covers all DOs whose association has changed due to access permission updates, and each DO receives the update. ,calculate Calculate its own public key components Update its own public key =( , ), and a portion of the data owner-level encrypted data. And send the updated public key to CS;

[0131] This refers to the set of elements that changed before and after the permission update. For example, if the original set was S={a,b,c} and the updated set is S*={b,c,d}, then SΔS*={a,d}. In this case, only the public keys of users a and d need to be updated synchronously; b and c are unaffected and do not require any operation.

[0132] S7.5: Cloud server update storage: CS updates the public key and system permission version number of all DOs in the storage;

[0133] Permission activation and revocation: When the CS receives a query trap submitted by the DU, it performs permission verification based on the updated version number and public key. DUs using the old version key (generated based on ver) will fail the verification, thus achieving efficient update and revocation of permissions.

Claims

1. A method for multi-keyword sorted encrypted retrieval under a multi-owner, multi-data user model, characterized in that, Applied to a multi-owner, multi-user data sharing system comprising an authority center, data owners, data users, and cloud servers, the method sequentially executes the following steps: Step 1: System initialization, where the authoritative center completes the configuration of basic system parameters, key system construction, and key distribution, laying the foundation for the secure operation of the entire retrieval method; Step 2: Key generation, which is completed collaboratively by the authority center, data owner, and data user, generates permission level keys and search keys for each level of entity, which are used for subsequent encryption, retrieval, and permission verification; Step 3: Data outsourcing. The data owner completes index generation and file encryption, and outsources the encrypted data, encrypted index tree, and owner-level access control ciphertext to cloud server storage. Step 4: Query trapdoor generation. Data users generate query trapdoors and pre-decryption keys based on their own search keys and query requirements, and submit them to the cloud server to initiate a retrieval request. Step 5: Cloud server permission verification and encrypted retrieval. After receiving the query trap, the cloud server performs owner-level permission verification in sequence. After successful verification, it performs encrypted retrieval based on the secure KNN algorithm and sorts the retrieval results by relevance. Step 6: Pre-decryption and final decryption. The cloud server performs a pre-decryption operation on the sorted search results. After receiving the pre-decryption result, the data user completes the final decryption to obtain the original file. Step 7: Permission Update and Revocation. When a data user's access permissions change, the authority center updates the permission version number and related keys, the data owner updates the public key, and the cloud server updates the storage information, achieving efficient permission update and revocation and ensuring that users whose permissions have been revoked cannot access the data.

2. The method according to claim 1, characterized in that, Step 1 specifically includes the following sub-steps: S1.1: The authoritative center inputs the security parameter λ, selects a multiplicative group G with g as the generator based on λ, and determines the multiplicative group G and the target group. Let the order p be a bilinear mapping e: G×G→ ; S1.2: The authority center defines two collision-resistant hash functions. and ,That It is a multiplicative group modulo p; S1.3: Authority Center sets global attribute sets and the corresponding set of attribute values ,against Randomly select a number ,calculate ; x is the element number of the set; S1.4: Random selection by the authoritative center , , Build master key The master key msk is held solely by the authority center; S1.5: The authoritative center generates the master public key based on the master key msk. The master public key mpk is made public to all entities in the system.

3. The method according to claim 2, characterized in that, Step 2 is divided into two sub-stages: permission level key generation and search key generation, as detailed below: S2.1: The permission level key generation phase is led by the authority center, which generates and distributes permission-related keys for cloud servers, data owners, and data users. S2.2: Search key generation stage, where the data owner and data user each generate their own search keys for encrypting the index and generating query trapdoors.

4. The method according to claim 3, characterized in that, Step 2.1 specifically includes the following sub-steps: S2.1.1: Authoritative centers are randomly selected. ∈ ,Will Private key for cloud server Compute cloud server public key ,Will Secretly distributed to cloud servers, It is made available to all data owners and data users; S2.1.2: For each data owner Authoritative centers randomly select , ,calculate Where i∈[1,m], and m is the total number of data owners; construct the private key of DOᵢ. Public key ,Will Secretly sent to , It is made available to cloud servers and all data users; S2.1.3: Data User Submit its own attribute set to the authoritative center Given a set S of authorized data owners, the authority center generates two owner-level permission keys based on S: ； Random selection Generate an attribute-level permission key The authoritative center secretly sent the aforementioned keys to... .

5. The method according to claim 4, characterized in that, Step 2.2 specifically includes the following sub-steps: S2.2.1: Generate a random binary vector D of length n, and make D public to all data owners and data users; n corresponds to the size of the keyword dictionary; S2.2.2: Each data owner DOᵢ generates two n×n invertible matrices. Random selection ,generate , Generate indicator matrix , store {D, } as its own search key; where It is an n×n identity matrix; S2.2.3: Each data user Based on the set of authorized data owners S, aggregate all data in S. of , Combining to generate matrices , ,storage Used as its own search key.

6. The method according to claim 5, characterized in that, Step 3 is divided into two sub-stages: index generation and encryption, as detailed below: S3.1: Index generation phase, each data owner Random selection Generate owner-level access control ciphertext Constructing an encrypted index tree based on the secure KNN algorithm In the encrypted index tree, the leaf nodes correspond to the encrypted files, and the non-leaf nodes are the cluster centers of the child nodes. S3.2: During the encryption phase, each data owner DOᵢ encrypted each file in their own file collection. Generate symmetric key ,use right The encrypted file is obtained by performing symmetric encryption, and then an access strategy is applied. right Perform attribute-based encryption to generate ciphertext. ; S3.3: Each Encrypt files, encrypt index trees Owner-level access encryption The storage is outsourced to cloud servers.

7. The method according to claim 6, characterized in that, Step 4 specifically includes the following sub-steps: S4.1: Data User Input multiple keywords to be queried, calculate the weight of each keyword based on the TF-IDF algorithm, and construct an n-dimensional query vector. ; S4.2: Based on the common binary vector D, the query vector Divide into two sub-vectors and The segmentation rules are consistent with the index vector segmentation rules; S4.3: DUᵢ calls its own search key , ,right , Encode to obtain the encrypted query vector. ; S4.4: DUᵢ integrates the encrypted query vector with its own authorization key to generate a query trap; S4.5: DUᵢ Random Selection Calculate the pre-decryption key And send it to the cloud server. As its own decryption key; S4.6: DUᵢ will query the trapdoor and pre-decryption key. Submit to the cloud server to initiate a encrypted retrieval request.

8. The method according to claim 7, characterized in that, Step 5 specifically includes the following sub-steps: S5.1: The cloud server receives and queries the trap and pre-decryption key. Combine the public keys of all data owners in the storage to verify the data user's owner-level access permissions. If the verification is successful, the subsequent operation is executed; otherwise, the retrieval request is rejected and the process is terminated. S5.2: After successful authorization verification, the cloud server extracts the encrypted query vector from the trapdoor. Iterate through all those that have passed permission verification. Encrypted index tree Based on the secure KNN algorithm, calculate The correlation score with the encoded vector of each index node is used to sort the nodes from high to low, and the top k nodes are selected to obtain the corresponding encrypted file, ciphertext CK, and the public key of the data owner, where k is the preset number of KNN nearest neighbors.

9. The method according to claim 8, characterized in that, Step 6 specifically includes the following sub-steps: S6.1: The cloud server performs a pre-decryption operation on each selected ciphertext CK and calculates the pre-decryption result. , ,Will , And the corresponding encrypted file is sent to DUᵢ; S6.2: Data User After receiving the pre-decryption result and the encrypted file, extract the permission key SK at its own attribute level. u Calculate the symmetric key Using a symmetric key Decrypt the encrypted file to obtain the original file, and then view and use it.

10. The method according to claim 9, characterized in that, Step 7 specifically includes the following sub-steps: S7.1: When the set of authorized data owners S for a data user is updated to... The authority center receives the permission change request and initiates the permission update process; S7.2: The Authority Center updates the system permission version number to [version number missing]. Regenerate the owner-level permission key for the data user. , ; S7.3: The authoritative center will , Secretly sent to data users, while... Notify all data owners and cloud servers; S7.4: Data owner reception related to permission changes Then, update its own public key. and owner-level ciphertext And send the updated public key to the cloud server; S7.5: The cloud server updates the public key and system permission version number of all data owners stored on the cloud server. Subsequent permission verification is based on the updated version number and public key to realize permission update and revocation.

Images