Efficient searchable encryption method with data revocation function

Abstract

The application provides a high-efficiency searchable attribute encryption method with data revocation function, a data owner generates a sub-policy which needs to be reused, extracts a keyword from clear data for mapping processing, and encrypts the clear data and sends the encrypted data to a cloud server for storage, and the cloud server generates a corresponding inverted index structure; when the data owner needs to revoke the cloud index or the corresponding relationship between some keywords and the data, a revocation token is generated and sent to the cloud server; the cloud server verifies the revocation token in the request and the cloud encrypted data, and performs a corresponding revocation operation when the verification is passed. The application can meet the diversified search demand of the user in the cloud environment with massive data and support the revocation of the index.

Description

Technical Field

[0001] This invention relates to the fields of searchable encryption and attribute encryption technology, and in particular to an efficient searchable attribute encryption method with data revocation function. Background Technology

[0002] The rise and development of cloud computing has made outsourced data storage increasingly common. To maintain the confidentiality of certain data, data owners often encrypt the data in some form before storing it on cloud servers. However, uploading encrypted data makes it unreadable and difficult to retrieve. To achieve effective retrieval and fine-grained access control of encrypted data, searchable attribute encryption technology has emerged. Among them, ciphertext-based attribute encryption technology allows data owners to define a series of attribute combinations and set different access rules and restrictions for the data, thereby strengthening the protection of data privacy and security. This feature is particularly suitable for one-to-many and many-to-many data sharing scenarios, making this technology an ideal choice for encrypted data storage and sharing in a cloud environment. Searchable encryption achieves effective keyword-based retrieval of encrypted data by having the data owner extract keywords to generate a search index during encryption, and users generating a search token using their private key and keywords when querying the ciphertext. The cloud server then matches the search index and search token and returns the results to the user.

[0003] Most existing searchable attribute encryption methods are based on the following process: The data owner symmetrically encrypts the file, extracts keywords from the plaintext to form a search index, and stores it on a cloud server; when a user searches for keywords, they generate a search token based on their attribute private key and the keywords to be searched and send it to the cloud server; the cloud server performs a matching and attribute determination operation based on bilinear pairing operations on the search token and search index, and if successful, returns the encrypted file and symmetric key corresponding to the trapdoor to the user; after receiving the encrypted file and symmetric key, the user uses the attribute private key generated based on their attributes to decrypt the symmetric key, and finally uses the symmetric key to decrypt the file to obtain the original data. This scheme returns the corresponding ciphertext to the user based on the matching result of the search index and search token, and the computational method of symmetric encryption and decryption of data stored in the cloud has the advantages of high efficiency and low overhead. However, in this determination process, the semi-trusted cloud server cannot obtain any valid information about the plaintext and keywords.

[0004] In practice, while users can perform encrypted data retrieval operations in the cloud using generated keywords, they may not necessarily meet the data decryption permission requirements. If, after searching on the cloud server, the user lacks decryption permissions for the returned encrypted data, it leads to a waste of communication resources and computational overhead. Secondly, matching search indexes and search tokens in the cloud is often based on bilinear pairing operations, which is computationally expensive, time-consuming, inflexible, and difficult to revoke once the index is generated. Furthermore, when data owners encrypt different data containing a certain type of user, there is policy overlap. In most existing searchable attribute encryption methods, the computational overhead is directly proportional to the number of attributes in the access policy. Therefore, in this case, developing a separate access policy for each piece of data would repeatedly consume computational resources. Optimization of data encryption methods needs to be considered to improve encryption efficiency and reduce computational overhead.

[0005] In conclusion, from a practical application perspective, a searchable attribute-based encryption method that can meet users' diverse search needs in massive amounts of data in a cloud environment, support index revocation, and reduce encryption computation overhead when there is partial duplication in the encryption strategy has higher practical application value. Summary of the Invention

[0006] The purpose of this invention is to provide an efficient searchable attribute encryption method with data revocation functionality, which can meet users' diverse search needs in massive amounts of data in a cloud environment and support index revocation.

[0007] To achieve the above objectives, the technical solution adopted by this invention is: a highly efficient searchable attribute encryption method with data revocation function, comprising the following steps:

[0008] Step 1: The data owner generates a sub-policy that needs to be reused, extracts keywords from the plaintext data for mapping, encrypts the plaintext data, and sends it to the cloud server for storage. The cloud server generates the corresponding inverted index structure. Step 2: The data user maps the search keywords and sends them to the cloud server. The cloud server matches and searches the search token uploaded by the data user in the inverted index to obtain the intermediate ciphertext, which is then sent to the data user. The data user decrypts the ciphertext to obtain the plaintext.

[0009] Step 3: When the data owner needs to revoke the correspondence between the cloud index or certain keywords and its data, a revocation token is generated and sent to the cloud server; the cloud server verifies the signature of the revocation token in the request and the cloud encrypted data, and executes the corresponding revocation operation when the verification is successful.

[0010] Preferably, in step 1, while the cloud server encrypts and stores the plaintext data, the attribute authorization center generates a system public key, a user attribute key, and a decryption private key. The system public key is sent to the data owner, and the user attribute key and the decryption private key are sent to the data user.

[0011] Preferably, in step 2, after mapping the search keywords, the data user sends the user attribute key to the cloud server. When the user attribute key matches the access policy of the encrypted data embedded in the search results of the cloud server, the cloud server performs attribute outsourcing decryption on the encrypted data. The server sends the semi-decrypted intermediate ciphertext to the data user, and the data user uses the decryption private key to perform a small amount of calculation on the intermediate ciphertext to obtain the final plaintext.

[0012] Preferably, in step 2, when certain attribute conditions are the same in the data access structure of several data users, the duplicated strategy part is generated into a sub-access strategy, and the sub-access strategy is set as a shared sub-strategy.

[0013] Preferably, in step 2, when a data user issues a search request, the corresponding slots for the keywords contained in the search token are calculated using the same hash function. Then, the corresponding search algorithm is used in the skip list corresponding to each slot to find the set of document IDs containing the keyword. Finally, the corresponding intersection or union operation is performed on the set of document IDs for each keyword to obtain the query result.

[0014] Preferably, in step 3, when the data owner needs to revoke the retrieval index of one or more data, the system first extracts and calculates the mapping value of the set keywords in the integer field and the identity authentication component corresponding to its unique ID number to form a revocation token, which is then sent to the cloud server. The cloud server finds the corresponding file ID number based on the keyword set in the revocation token, extracts the relevant components from the corresponding ciphertext, and performs a BLS short signature-based calculation to verify whether the deletion request is legitimate. If the request is legitimate, the system modifies the corresponding pointer in the skip list to complete the deletion operation on the verified data and returns a successful deletion result to the data owner.

[0015] Preferably, the attribute authorization center is a completely trusted entity.

[0016] Preferably, the cloud server is a semi-trusted entity.

[0017] Preferably, the cloud server storage work in step 1 includes storing encrypted data and keywords uploaded by the data owner.

[0018] The beneficial effects of this invention are:

[0019] This solution addresses the issue by allowing data owners to partially reuse defined access policies. In scenarios where a particular policy is frequently used for data encryption, reusing that portion reduces computational complexity and increases encryption speed. Secondly, it considers user-defined searches based on multiple keywords of interest, catering to efficient and flexible retrieval needs. To achieve this, an inverted index structure built using hash tables and skip lists is employed, enabling Boolean retrieval of query keywords. Finally, considering the data owner's right to revoke cloud-based search indexes related to their data and control the relationship between data and keyword searches, BLS short signatures are used to verify the data owner's ability to revoke uploaded data or the correspondence between cloud data and keywords, enhancing the data owner's management and control over cloud data. Attached Figure Description

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

[0021] Figure 1 This is an overall structural diagram of the present invention.

[0022] Figure 2 This is a transformation access structure tree diagram for the present invention.

[0023] Figure 3 This is a diagram illustrating the construction determination of the Bloom filter of the present invention.

[0024] Figure 4 This is a segmentation keyword diagram for the present invention.

[0025] Figure 5 This is a diagram of the inverted index structure of the present invention.

[0026] Figure 6 This is a diagram illustrating the index cancellation operation of the present invention.

[0027] Figure 7 This is a sequence diagram of the algorithm implementation of the present invention. Detailed Implementation

[0028] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0029] The structures, proportions, sizes, etc., shown in the accompanying drawings of this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed in the specification, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0030] It should also be noted that, unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The term "plural" as used in the patent application specification and claims means two or more; the terms "upper," "lower," "left," "right," "front end," "rear end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Changes or adjustments to these relative relationships, without substantially altering the technical content, should also be considered within the scope of the invention's implementation.

[0031] The present invention will now be described in further detail with reference to the embodiments and the accompanying drawings.

[0032] Example 1:

[0033] This invention discloses a highly efficient searchable attribute encryption method with data revocation functionality. The overall structure is as follows: Figure 1 As shown. The entities involved in this encryption method include the attribute authorization center, data owner, data user, and cloud server. The searchable attribute encryption method includes the following steps:

[0034] Step 1: The data owner generates a sub-policy that needs to be reused, extracts keywords from the plaintext data for mapping processing, and encrypts the plaintext data before sending it to the cloud server for storage. The cloud server's storage work includes storing the encrypted data and keywords uploaded by the data owner, and generating a corresponding inverted index structure. At the same time, the attribute authorization center generates a system public key, a user attribute key, and a decryption private key. The system public key is sent to the data owner, and the user attribute key and decryption private key are sent to the data user. The attribute authorization center is a fully trusted entity, and the cloud server is a semi-trusted entity.

[0035] Step 2: After mapping the search keywords, the data user sends the user attribute key to the cloud server. The cloud server matches the search token uploaded by the data user in the inverted index. When the user attribute key matches the access policy of the encrypted data embedded in the cloud server's search results, the cloud server performs attribute outsourcing decryption on the encrypted data. The server sends the semi-decrypted intermediate ciphertext to the data user. The data user uses the decryption private key to perform a small amount of calculation on the intermediate ciphertext to obtain the final plaintext.

[0036] Step 3: When the data owner needs to revoke the correspondence between the cloud index or certain keywords and its data, a revocation token is generated and sent to the cloud server; the cloud server verifies the signature of the revocation token in the request and the cloud encrypted data, and executes the corresponding revocation operation when the verification is successful.

[0037] In step 2, when certain attribute conditions are the same in the data access structures of several data users, these repeated policy parts can be generated into a sub-access policy, which can be reused in the subsequent data encryption process, thereby saving the data owner's encryption computing resources and improving the efficiency of ciphertext generation. Assume there exists an access policy (a1∨(a2∧(a3∨a4(a5∧a6∧a7))))∨(b1∧b2∧b3)∨(c1∧c2), where a1, a2, ..., c2 are the attributes corresponding to the data users. The corresponding access structure tree for this policy is as follows: Figure 2 As shown in the left half, assume that the strategy corresponding to the subtree within the dashed box on the left might need to be reused when the data owner encrypts multiple other data. To simplify the encryption process and reduce the time cost of encryption, consider setting this part of the strategy as a shared sub-strategy. The specific construction method is as follows:

[0038] Step 1: Transform the access tree structure

[0039] The shared subtree is viewed as a leaf node in a complete access tree structure. A pseudo-attribute component is randomly selected from the public key of the system master key to replace this shared subtree. Starting from the root node of the access tree, a polynomial is constructed for each non-leaf node from top to bottom. The corresponding secret value is distributed to the leaf nodes, including those containing pseudo-attributes. The final transformed access tree structure is as follows: Figure 2 As shown in the right half.

[0040] Step 2: Construct a sub-policy decision Bloom filter

[0041] Disjunctive computation of the sub-policy yields four clauses where the conditions are true: C1 = (a5∧a6∧a7)∧a2, C2 = a3∧a2, C3 = a4∧a2, C4 = a1. For example... Figure 3As shown, a specific Bloom filter is constructed for each clause in the sub-policy, such that each Bloom filter corresponds to a minimal combination of attributes that satisfies the sub-policy. Specifically, four Bloom filters of length m with bit values ​​of {0,1} are initialized, and then a set of independent hash functions h are applied to each clause. ι The properties contained in the filter are mapped to ι different positions of the Bloom filter, and the values ​​of these positions are set from 0 to 1, i.e., h(τ)→L(τ)=1. The values ​​of the positions that are not mapped are still 0. When a position is set to 1 multiple times, its value is still 1.

[0042] Finally, the data owner calculates the attribute value component for each clause and selects any pseudo-attribute from the system public key to replace that sub-policy part in the complete access policy; then, the corresponding sub-policy identifier is calculated and stored locally; finally, the identifier is associated with the corresponding clause Bloom filter set and clause attribute value component set and uploaded to the cloud server.

[0043] Step 3: Sub-strategy determination process

[0044] Assuming the access policy includes sub-policies: In this case, the data owner encrypts the data using a simplified access structure tree without sub-policies, and uses the identifier corresponding to the sub-policy as an appended ciphertext component. Clause filters are stored as a set in the cloud, associated with the unique identifier of the sub-access policy. When it is necessary to determine the attributes of the data user and the relevant ciphertext contains the sub-policy identifier, the cloud server retrieves the set of clause filters corresponding to that sub-policy based on this identifier and performs the following determination:

[0045] ① Perform bit equality checks on the data user's attribute Bloom filter and clause Bloom filter. A bit with a value of 1 in the clause Bloom filter must also be 1 in the data user's attribute Bloom filter; otherwise, the check fails. The data user's attribute Bloom filter is generated by the attribute authorization center, which maps all attributes owned by the data user to a single Bloom filter, processes it, and then stores it in the data user's private key.

[0046] ②Since Bloom filters have a certain degree of false positives, we consider adding an additional equivalence verification step based on bilinear pairing of key components and clause attribute values ​​after Bloom filter verification to ensure the legitimacy of access.

[0047] When steps ① and ② are both successful, CSP returns the determination result FR. ν =0 for subsequent outsourced decryption.

[0048] A forward index is a mapping relationship between keywords extracted from each piece of plaintext data and documents containing those keywords, such as... Figure 4As shown in the left half. This retrieval indexing method is simple to construct and facilitates adding and deleting documents, but it requires a linear traversal of the entire document set to find keywords, resulting in very low retrieval efficiency. To improve retrieval efficiency, the document ID number of each keyword can be recorded, forming an inverted index structure from keyword to document ID number, such as... Figure 4 As shown in the right half.

[0049] A typical inverted index structure is difficult to modify after generation. Therefore, we consider constructing an inverted index retrieval structure that supports index revocation and multi-keyword retrieval using a hash table and skip lists. Specifically: A hash table is built. When a data owner uploads data, keywords are extracted from the plaintext data to obtain a keyword list. Each keyword is mapped to a large integer field, resulting in a unique (KW*) value. Then, a suitable hash function is used to hash this value into a slot in the hash table (H(KW*)). If the value already exists in the hash table, it is discarded to ensure that each keyword appears only once in the inverted index. Finally, a skip list is constructed at the end of the linked list corresponding to each non-empty slot to store the document ID number (F(*)) containing the keyword and the document's identification components, such as... Figure 5 The left half is shown.

[0050] When a data user issues a search request, the corresponding slot is calculated using the same hash function for the keywords contained in the search token. Then, a corresponding search algorithm is used in the skip list corresponding to each slot to find the set of document IDs containing that keyword. Finally, for each set of document IDs containing a keyword, the corresponding intersection or union operation is performed to obtain the query result, such as... Figure 5 As shown in the right half.

[0051] Revocation process: Consider implementing secure deletion of the inverted index by attaching a signature verification component to the ciphertext. This component is generated from the data owner's unique ID number, ensuring that only the legitimate data owner can complete the verification and deletion of the specified index. The specific steps are as follows:

[0052] When a data owner needs to revoke the retrieval index of one or more data items, they first extract and calculate the mapping values ​​of the set keywords on the integer field and the authentication component corresponding to their unique ID number to form a revocation token, which is then sent to the cloud server. The cloud server uses the keyword set in the revocation token to find the corresponding file ID number, extracts the relevant components from the corresponding ciphertext, and performs a BLS short signature calculation to verify the validity of the deletion request. If the request is valid, the corresponding pointer in the skip list is modified to complete the deletion operation on the verified data, and a successful deletion result is returned to the data owner. Figure 6 As shown.

[0053] This method allows data owners to fine-grainedly revoke retrieval indexes of encrypted data in the cloud to meet different needs. First, when the revocation token contains all keywords of the encrypted data, the encrypted data can be completely revoked in the inverted index. At this point, the data owner can selectively delete some data from the inverted index while retaining others, according to their needs. Second, when data users extract specific keywords from the data, they can revoke the association between some keywords and the encrypted data in the cloud, thereby achieving query control over the encrypted data.

[0054] The specific implementation of the searchable attribute encryption method is as follows: Figure 7 As shown, the main algorithm is explained below:

[0055] 1. Setup(1 λ ,U,V)→(MSK,MPK): The system initialization algorithm is executed by the attribute authorization center.

[0056] The algorithm takes a security parameter λ, a complete set of attributes U, and a set of pseudo-attributes V as input. It outputs the system master public key MPK and the system master private key MSK.

[0057] 2. KeyGen(Y,DU) id (MPK,MSK)→(UK) DU TK DU The key generation algorithm for data visitors is executed by the attribute authorization center.

[0058] The algorithm takes as input the set of attributes Y of the data visitor and the unique identifier DU. id The system master public key (MPK) and system master private key (MSK) are output. The attribute key (UK) of the data access user is also output. DU and decryption private key TK DU .

[0059] 3.STGen(Λ sub ,DO id ,MPK)→(T tag DO BF tag CSP The sub-access policy generation algorithm is executed by the data owner.

[0060] The algorithm inputs a sub-access strategy Λ sub The unique identifier of the data owner, DO id The system master public key MPK. Output the identifier T for the shared sub-policy. tag DO And the identifier set BF consisting of the Bloom filter and attribute component corresponding to the clause. tag CSP T tagDO Data is stored locally by the data owner, BF tag CSP Then it is uploaded to the cloud server.

[0061] 4. Encrypt(m,MPK,Λ,T) tag DO →CT m δ The ciphertext generation algorithm is executed by the data owner.

[0062] The algorithm takes plaintext data m as input, the system master public key MPK, the complete access policy Λ, and the identifier T corresponding to the shared sub-policy. tag DO Output encrypted CT m δ .

[0063] 5. GenInd(CT) m δ FileID → Index Invert The inverted index generation algorithm is executed by the cloud server.

[0064] After receiving the encrypted text uploaded by the data owner, the cloud server uses the mapping keyword set {KW} in the encrypted text to... k} k∈K Calculate its position in the hash table, and then put the corresponding ciphertext file ID (FileID) and the undo matching component (FileMatch) into the corresponding skip list to form the corresponding inverted index (Index). Invert structure.

[0065] 6. GenQ s (MPK, UK) DU ,{sw s} s∈S →Q s The trapdoor generation algorithm is executed by the data visitor. The data visitor inputs the system master public key MPK and the search keyword set {sw}. s} s∈S and attribute key UK DU Output the corresponding search trapdoor Q. s .

[0066] 7. Search(MPK, Q) s Index Invert →SR: The retrieval algorithm is executed by the data visitor and the cloud server.

[0067] Data access users input the system master public key MPK to retrieve the trapdoor Q. s Inverted index InvertReturns the search result SR.

[0068] 8. Decrypt1(CT) m δ UK DU BF tag CSP →CT m' The attribute outsourcing decryption algorithm is executed by the cloud server.

[0069] The cloud server inputs the relevant encrypted text CT from the search results SR. m δ The data visitor's attribute key (UK) DU Clause Bloom filters and their corresponding component sets, and their corresponding BF tag CSP The intermediate ciphertext CT obtained by outsourcing the output attributes for decryption. m' .

[0070] Decrypt2(CT m' TK DU →m: The intermediate ciphertext decryption algorithm is executed by the data accessor.

[0071] Data access users use their own decryption private key TK DU Decrypting the intermediate ciphertext CT m' Obtain plaintext data m.

[0072] 9. DeleteFiles(MPK,DK,CT) m δ Index Invert →DR: The revocation algorithm is executed by the data owner and the cloud server. The data owner inputs the system master public key (MPK), revocation token (DK), and ciphertext (CT). m δ Cloud server input inverted index Invert Output the cancellation result DR.

[0073] The data owner extracts some or all keywords from the file to obtain a revocation keyword set based on the revocation requirement. Then, they calculate the relevant authentication components to form a revocation token (DK) and send it to the cloud server. The cloud server first locates the file corresponding to the keyword set in the inverted index based on the revocation token. Then, it extracts the components from the corresponding encrypted file and performs signature verification with the revocation token. For files that pass verification, it performs a deletion operation in the search index and returns the deletion result to the data owner. The detailed algorithm design steps are shown below:

[0074] 1. Setup(1 λ(U,V)→(MSK,MPK): The initialization algorithm is executed by the attribute authorization center, with the input system security parameter λ, and the bilinear mapping e: G×G=G T , where G,G T Given a p-order multiplicative cyclic group, with generator g∈G. Select three collision-resistant hash functions. H2:{0,1} * →G, For each attribute u∈U in the attribute domain, we have: For each attribute v∈V in the pseudo-attribute domain, we have: Select Calculate the system master public key from the corresponding components:

[0075]

[0076] System Master Private Key: MSK = {b, c, α} u ,β v} u∈U,v∈V .

[0077] 2. KeyGen(Y,MPK,MSK)→(UK) DU TK DU The data access key is generated by the Attribute Authorization Center (CA), and the data access user (DU) enters their unique identifier (DU). id ∈{0,1} * Let the attribute of DU be y∈Y, and let the attribute authorization center CA generate a Bloom filter as the private key component BF based on the attribute existence information of DU. y Choose h∈ R G, Calculate C0 = H3(DU) id h) = z, C2 = g c / (b·z) C3 = g b·z′·z C4 = g z′·z C5 = BF y,y∈Y Obtain the attribute key: UK DU ={C1,C2,C3,C4,C5}, Decrypt private key: TK DU =C0, returned to the data accessor via a secure channel.

[0078] 3.STGen(Λ sub ,DO id ,MPK)→(T tag DO BF tag CSP The reuse sub-policy generation algorithm is executed by the data owner (DO). Depending on whether the access policy set by the DO needs to include a reuse sub-policy, this stage can be divided into three cases.

[0079] ① The system needs to include a reused sub-policy that has not been generated before. The data owner (DO) executes the STGen(·) algorithm to generate the reused sub-policy. First, the sub-policy is dissected to obtain several proper clauses that satisfy the sub-access policy, and the corresponding clause Bloom filters are constructed. Then, the algorithm is calculated... Where DO id This is a unique identifier for DO. Assuming there are i ∈ I attributes and j ∈ J true clauses in the sub-access strategy, for each clause l j calculate: The attributes are included in the clause. Then, the data owner selects any pseudo-attributes. Replace the sub-policy portion in the access tree structure corresponding to the access policy. Finally, the data owner calculates the sub-policy identifier. Stored locally, it is a collection of Bloom filters and attribute components corresponding to the identifier. tag CSP Send to the cloud server.

[0080] ② If the access policy needs to include a reused sub-policy, and this reused sub-policy has been generated previously, then the data owner can directly obtain the identifier of the sub-access policy from the local machine. And put it as a component into the ciphertext.

[0081] ③ If the access strategy does not require a sub-access strategy, then skip the algorithm and execute the encryption algorithm directly.

[0082] 4. Encrypt(m,MPK,Λ)→CT m δ The encryption algorithm for plaintext data m is executed by the data owner DO. DO first extracts the keyword set {kw} from m. k} k∈K ,calculate The access structure tree corresponding to the access policy Λ set by the data owner is T. com Let X be the set corresponding to the leaf node x in the access structure tree, and let the non-leaf nodes, including the root node, be the threshold nodes. Depending on whether the access strategy needs to include a reuse sub-strategy, the encryption process can be divided into two cases:

[0083] ① Does not include a reuse sub-policy: The data owner sets the secret value to q in the root node. Root(0) =r′, For accessing the structure tree T com For each non-leaf node d in the array, a random element of order O is selected. d polynomial Q d Order O d =Kd -1, K d Let be the node threshold. Then, the secret value r' of the root node is distributed from top to bottom through the access tree structure. ON(d) represents the order of node d in its parent node. Substituting this order into the polynomial as the independent variable yields the secret value q of node d. d(0) =q parent(d) ON(d) Select Input message m∈{0,1} * Calculate: E m =me(g,g) c·r·r' F2 = H2(DO) id → G FileMatch=g Hm E0 = g r E1 = g b·r E4 = g F1 ,right have: Obtain the ciphertext:

[0084] CT m δ ={T com E m FileMatch,E0,E1,E2,E3,E4,{KW k} k∈K}

[0085] ② Including the reuse sub-strategy: In this case, access the structure tree T com The subtree portion corresponding to the reused sub-strategy is randomly pseudo-attributed α. x The substitution, i.e., X = (XT)∪χ, is related to the ciphertext component. The remaining components are calculated using the same steps as above to obtain the ciphertext:

[0086] CT m δ ={T com ',E m FileMatch,E0,E1,E2',E3',E4,T tag ,{KW k} k∈K}

[0087] 5. GenInd(CT) m δ FileID → Index Invert The inverted index generation algorithm is executed by the cloud server CSP. After receiving the encrypted text uploaded by the data owner, the CSP generates the index based on the keyword set {kw} in the encrypted text. k} k∈KCalculate the position of each keyword in the hash table [L] k ] k∈K .

[0088] ①If [L k If the key is empty, it is inserted into the hash table. The cloud server generates a unique ID (FileID) for the encrypted file and extracts the components from the encrypted file. The cloud server then inserts <FileID, FileMatch> into the node of the skip list corresponding to the keyword, forming an ordered linked list structure Index. Invert .

[0089] ②If [L k If the value is not empty and the keyword stored here is equal to the keyword to be inserted into the table, then the corresponding FileID is added to the skip list in order, and the corresponding index is modified to form a multi-level ordered inverted index structure. Invert To reduce collisions, the keywords are hashed once and then moduloed multiple times to distribute them evenly across the hash table.

[0090] 6. GenQ s (MPK, UK) DU ,{sw s} s∈S →Q s The trapdoor generation algorithm is executed by the data visitor DU, which searches the set of keywords to be retrieved {sw}. s} s∈S Calculate SW s =H1(sw) s These search keywords can be connected by different logical operators, such as: S1 = {SW1&SW2&SW3}, S2 = {SW2||SW4}, etc. This ultimately forms the corresponding search trapdoor Q. s ={UK DU ,S r Send to the cloud server.

[0091] 7. Search(MPK, Q) s Index Invert →SR: The retrieval algorithm is executed by the cloud server CSP. The CSP first checks the retrieval trapdoor Q. s Each keyword in SW s Calculate the hash value and compare it with the keyword KW stored at the corresponding position in the hash table. k Compare the results; if they are equal, return the file ID corresponding to the keyword. s According to the search requirements, the set {FileID} s} s∈SThe file numbers in the search results are intersected or joined to obtain the final search result SR.

[0092] 8. Decrypt1(CT) m δ UK DU BF tag CSP →CT m' The outsourced decryption algorithm is executed by the cloud server CSP. This algorithm is used to decrypt several ciphertext CTs contained in the search result SR. m δ The cloud server does not send the data directly to the data access user. Instead, it performs outsourced decryption operations one by one based on the data access user's attribute key. The leaf nodes of the access tree structure are calculated in two ways, depending on whether the ciphertext contains a reuse access strategy:

[0093] ① The ciphertext does not contain sub-policy identifiers, meaning the access policy does not contain reuse sub-policies. The decryption algorithm for the leaf nodes of the corresponding access structure tree is Decrypt(CT). m δ The following (UK, x) results are as follows: Where x is a leaf node in the access tree structure. For the common attributes in the leaf nodes and data visitors, we have:

[0094] ② The ciphertext contains a sub-policy identifier, meaning the access policy contains a sub-policy. The decryption process for ordinary leaf nodes is the same as above. Leaf nodes obtained by reusing sub-policies for pseudo-attribute substitution include: The cloud server first determines the leaf node based on the sub-policy identifier T in the ciphertext component. tag Find the corresponding clause Bloom filter set and the corresponding clause attribute value component set, and determine whether the data visitor meets the sub-access policy. If the determination fails, return FR. ν =1, at this time Decrypt'(CT) algorithm m δ ,UK,χ) There are components that cannot be eliminated. The algorithm terminates when it cannot recursively calculate the secret value of the parent node. If successful, it returns FR. ν =0, at this time Decrypt'(CT) algorithm m δ ,UK,χ) calculated to For leaf nodes that meet the threshold condition, the secret value of their parent node is reconstructed using the Lagrange interpolation function.

[0095] Assume a non-leaf node x γ The set of child nodes is Sxγ Visiting non-leaf nodes in the tree structure can also be divided into two cases:

[0096] ①x γ child node γ c It does not contain pseudo-attribute nodes. It sets the non-leaf node x... γ child node γ c The order at point c is denoted as k = ON(γ). c ), Kγ c ={ON(γ c ),γ c ∈Sx γ}. Execute Decrypt(CT) m δ UK,x γ The algorithm is used, and the output is denoted as Dx. γ When set Sx γ When Dx does not exist γ =⊥, and vice versa:

[0097] When recursively calculating to the root node, there is

[0098] ②x γ child node γ c This includes pseudo-attribute nodes. When a data visitor satisfies the child access structure tree strategy corresponding to a pseudo-attribute node, the pseudo-attribute node can be treated as a regular leaf node, and the process of calculating the parent node's secret value is the same as the steps in ① above. When a data visitor does not satisfy the child access strategy corresponding to a pseudo-attribute node, the value corresponding to that pseudo-attribute node has a redundant part. It cannot be used to compute the secret value of its parent node, therefore it can be considered a secret-independent value. The component can be obtained by restoring the secret value of the root node. Finally, the intermediate ciphertext CT was processed. m ={E m The data is then sent to the data accessor, who executes the Decrypt2(CT) decryption algorithm locally. m TK DU →m, using your own decryption key TK to perform a small amount of computation to obtain the final plaintext.

[0099] If the data visitor does not meet the encrypted access policy, the root node secret value of the access tree structure cannot be recovered, the attribute outsourcing decryption fails, and the cloud server does not return any information to the data visitor regarding the file corresponding to the query keywords.

[0100] 9. DeleteFiles(MPK,DK,CT) m δ IndexInvert →DR: When a data owner wants to revoke the search index for one or more files on a cloud server, first extract the keyword set {kw} from the file to be revoked (m*). k*} k*∈K* The calculated KW k* =H1(kw k* Then, calculate the components related to the revocation token:

[0101] FileMatch * =g Hm* , Obtain the corresponding revocation token Send to the cloud server. The cloud server, based on the set {KW} k*} k*∈K* The hash value of each keyword in the keyword set is calculated, and then FileMatch is matched in the skip list corresponding to the keyword. * Perform an equivalent comparison with FileMatch, and denote the set of ciphertexts that successfully match as . For multiple E's of the revocation token DK m δ The components are added together to obtain Calculate the product of the corresponding encrypted components FileMatch: The product of ciphertext component E4 * =E4(m0)·E4(m1)...E4(m n Finally, a judgment is made: The undo operation is performed in the search index only if the results are equal.

[0102] It should be noted that the parts not described in detail in the above embodiments are all prior art.

[0103] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should be covered within the protection scope of the present invention.

Claims

1. An efficient searchable public key encryption method with data revocation function, characterized in that: The method comprises the following steps: Step 1, the data owner generates a sub-policy that needs to be reused, extracts keywords from the plaintext data for mapping processing, and encrypts the plaintext data and sends it to the cloud server for storage, and the cloud server generates a corresponding inverted index structure; Step 2, the data user sends the mapping operation of the search keyword to the cloud server, the cloud server matches and searches the search token uploaded by the data user in the inverted index to obtain intermediate ciphertext and sends it to the data user, and the data user decrypts to obtain plaintext; Step 3, when the data owner needs to revoke the index on the cloud or the corresponding relationship between some keywords and its data, a revocation token is generated and sent to the cloud server; the cloud server verifies the revocation token in the request and the encrypted data on the cloud, and performs the corresponding revocation operation when the verification is passed; In step 2, the data user sends the user attribute key to the cloud server after mapping operation of the search keyword; when the user attribute key meets the access policy embedded in the encrypted data in the cloud server search result, the cloud server performs attribute outsourcing decryption on the encrypted data; The cloud server sends the intermediate ciphertext obtained by semi-decryption to the data user, and the data user uses the decryption private key to perform a small amount of calculation on the intermediate ciphertext to obtain the final plaintext; in step 2, when some attribute conditions in the data access structure of several data users are the same, a sub-access policy is generated for the repeated policy part, and the sub-access policy is set as a shared sub-policy.

2. The high efficient searchable attribute-based encryption method with data revocation function according to claim 1, characterized in that: In step 1, the data owner encrypts the plaintext data and sends it to the cloud server for storage at the same time, the attribute authorization center generates a system public key, a user attribute key and a decryption private key, the system public key is sent to the data owner, and the user attribute key and the decryption private key are sent to the data user.

3. The efficient searchable attribute encryption method with data revocation function according to claim 1, characterized in that: In step 2, when the data user issues a search request, the keywords contained in the search token are calculated using the same hash function to obtain their corresponding slot positions, and then the corresponding search algorithm is used in the skip list corresponding to each slot position to find the set of document IDs containing the keywords, and finally the intersection or union operation is performed on each keyword document ID set to obtain the query result.

4. The efficient searchable attribute encryption method with data revocation function according to claim 1, characterized in that: In step 3, when the data owner needs to revoke the search index of a certain data or some data, first extract and calculate the mapping value of the set keyword on the integer domain and the identity authentication component corresponding to the unique ID number of the data to form a revocation token and send it to the cloud server; The cloud server finds the corresponding file ID number according to the keyword set in the revocation token, extracts the related components from the corresponding ciphertext, and performs BLS short signature-based calculation to verify whether the deletion request is legal; if the request is legal, the corresponding pointer of the skip list is modified, so that the deletion operation is completed on the verified data, and the successful deletion result is returned to the data owner.

5. The high efficient searchable attribute-based encryption method with data revocation function according to claim 2, characterized in that: The attribute authority center is a fully trusted entity.

6. The high efficient searchable attribute-based encryption method with data revocation function according to claim 1, characterized in that: The cloud server is a semi-trusted entity.

7. The high efficient searchable attribute-based encryption method with data revocation function according to claim 1, characterized in that: The cloud server storage work in step 1 includes storing the encrypted data and keywords uploaded by the data owner.

Images