Efficient searchable attribute encryption method with data revocation function

Abstract

The invention provides an efficient searchable attribute encryption method with a data revocation function, and the method comprises the steps: a data owner generates a sub-strategy which needs to be reused, extracts a keyword from plaintext data, carries out the mapping processing, encrypts the plaintext data, and transmits the encrypted plaintext data to a cloud server for storage; the cloud server generates a corresponding inverted retrieval index structure; when the data owner needs to cancel the corresponding relationship between the cloud index or certain keywords and the data, generating a cancel token and sending the cancel token to the cloud server; and the cloud server performs signature verification on the revocation token in the request and the cloud encrypted data, and executes a corresponding revocation operation when the verification is passed. According to the method and the system, diversified search requirements of a user in massive data in a cloud environment can be met, and index revocation is supported.

Description

Technical Field

[0001] The present invention relates to the technical field of searchable encryption and attribute encryption, and in particular to an efficient searchable attribute encryption method with a data revocation function. Background Art

[0002] The rise and development of cloud computing has made outsourced data storage more and more common. In order to maintain the confidentiality of certain data, data owners often encrypt the data in a certain form before storing it on cloud servers. However, uploading the data after encryption makes the data unreadable and difficult to retrieve. In order to achieve effective retrieval and fine-grained access control of encrypted data, searchable attribute encryption technology was born. Among them, ciphertext-based attribute encryption technology allows data owners to define a series of attribute combination policies, set different access rules and restrictions on 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 cloud environments. Searchable encryption generates a search index for encrypted data by extracting keywords from the data when encrypting, and generates a search token for its private key and keywords when the user queries the ciphertext. The cloud server matches the search index and the search token and returns the result to the user.

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

[0004] In actual situations, although users can use the generated keywords to perform encrypted data retrieval operations in the cloud, they may not meet the data decryption permission requirements. After searching in the cloud server, if there is no decryption permission for the returned encrypted data, it will lead to a waste of communication resources and computing overhead. Secondly, the matching of retrieval indexes and retrieval tokens in the cloud is often based on bilinear pairing operations, which is computationally expensive, takes a long time to retrieve, is inflexible, and is difficult to revoke once the index is generated. In addition, when the data owner encrypts different data containing a certain type of user, there is a policy overlap. In most existing searchable attribute encryption methods, the encryption calculation overhead is proportional to the number of attributes in the access policy. Therefore, in this case, formulating access policies for each data separately will repeatedly consume computing resources. It is necessary to consider optimizing the form of data encryption to improve encryption efficiency and reduce computing overhead.

[0005] To sum up, from the perspective of practical application, a searchable attribute-based encryption method that can meet users' diversified search needs in massive data in a cloud environment, support index revocation, and reduce encryption calculation overhead when there is partial duplication of encryption strategies has higher practical application value. Summary of the invention

[0006] The purpose of the present invention is to provide an efficient searchable attribute encryption method with data revocation function, which can meet the user's diversified search needs in massive data in a cloud environment and support the revocation of indexes.

[0007] In order to achieve the above object, the technical solution adopted by the present invention is: an efficient searchable attribute encryption method with data revocation function, comprising the following steps: Step 1: The data owner generates a sub-strategy that he needs to reuse, 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 search index structure. Step 2: The data user maps the search keywords and sends them to the cloud server. The cloud server matches the search token uploaded by the data user in the inverted index, obtains the intermediate ciphertext and sends it to the data user. The data user decrypts it to obtain the plaintext. Step 3: When the data owner needs to revoke the cloud index or the correspondence between certain keywords and their data, a revocation token is generated and sent to the cloud server; the cloud server performs signature verification on the revocation token in the request and the cloud encrypted data, and executes the corresponding revocation operation when the verification passes.

[0008] Preferably, while the cloud server encrypts and stores the plaintext data in step 1, 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.

[0009] Preferably, in step 2, the data user maps the search keywords and sends the user attribute key to the cloud server; when the user attribute key meets the access policy embedded in the encrypted data in the cloud server search results, the cloud server performs attribute outsourcing decryption on the encrypted data; the 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.

[0010] Preferably, in step 2, when some attribute conditions in the data access structures 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.

[0011] Preferably, in step 2, when the data user issues a search request, the same hash function is used to calculate the corresponding slot of the keyword contained in the search token, and then the corresponding search algorithm is used in the jump table corresponding to each slot to find the set of document IDs containing the keyword, and finally, the corresponding intersection or union operation is performed on the document ID set of each keyword to obtain the query result.

[0012] Preferably, in step 3, when the data owner needs to revoke the retrieval index of one or some data, the data is first extracted and the mapping value of the set keyword in the integer domain and the identity authentication component corresponding to the unique ID number are calculated to form a revocation token and then sent to the cloud server; the cloud server finds the corresponding file ID number according to the keyword set in the revocation token, extracts the relevant components from the corresponding ciphertext, and performs calculation based on the BLS short signature to verify whether the deletion request is legal; if the request is legal, the corresponding pointer of the jump table is modified to complete the deletion operation on the verified data, and return the result of successful deletion to the data owner.

[0013] Preferably, the attribute authority center is a completely trusted entity.

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

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

[0016] The beneficial effects of the present invention are:

[0017] This solution reuses part of the access policy formulated by the data owner. In the scenario where a part of the policy is often used to encrypt data, the part of the policy is reused to reduce the computational complexity of data encryption and improve the speed of encrypting data. Secondly, consider that users search in combination based on multiple keywords of interest to meet the needs of efficient and flexible retrieval. To achieve this goal, an inverted index structure constructed by hash tables and skip lists is adopted to realize Boolean retrieval of query keywords. Finally, considering that data owners should have the right to revoke cloud retrieval indexes related to their own data, as well as the ability to control the relationship between data and keyword retrieval, BLS short signatures are used to realize the verification of the data owner's revocation of the data uploaded to the cloud or the corresponding relationship between cloud data and keywords, thereby enhancing the data owner's management and control over cloud data. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0019] Figure 1 It is the overall structure diagram of the present invention.

[0020] Figure 2 A structure tree graph is accessed for the transformation of the present invention.

[0021] Figure 3 A Bloom filter graph is determined for the construction of the present invention.

[0022] Figure 4 This is the segmentation keyword graph of the present invention.

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

[0024] Figure 6 This is an index revocation operation diagram of the present invention.

[0025] Figure 7 This is a sequence diagram for realizing the algorithm of the present invention. DETAILED DESCRIPTION

[0026] The present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0027] The structures, proportions, sizes, etc. illustrated in the drawings of this specification are only used to match the contents disclosed in the specification so as to facilitate understanding and reading by persons familiar with the technology. They are not used to limit the conditions under which the present invention can be implemented, and therefore have no substantive technical significance. Any structural modification, change in proportion or adjustment of size shall still fall within the scope of the technical contents disclosed in the present invention without affecting the effects and purposes that can be achieved by the present invention.

[0028] At the same time, it should be noted that: unless otherwise defined, the technical terms or scientific terms used in this article should be the ordinary meaning understood by people with ordinary skills in the technical field to which the present invention belongs. The meaning of "multiple" used in the patent application specification and claims of the present invention is two or more; the orientation or position relationship indicated by the terms "upper", "lower", "left", "right", "front end", "rear end", etc. is based on the orientation or position relationship shown in the drawings, which is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. Changes or adjustments in their relative relationships should also be regarded as the scope of the implementation of the present invention without substantially changing the technical content.

[0029] The present invention is further described in detail below in conjunction with embodiments and with reference to the accompanying drawings.

[0030] Embodiment 1:

[0031] The present invention discloses an efficient and searchable attribute encryption method with data revocation function. The overall structure is as follows Figure 1 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: Step 1: The data owner generates a sub-strategy that he needs to reuse, extracts keywords from the plaintext data for mapping, and encrypts the plaintext data before sending it to the cloud server for storage. The cloud server storage work includes storing the encrypted data and keywords uploaded by the data owner, and the cloud server generates the corresponding inverted search 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 the decryption private key are sent to the data user, wherein the attribute authorization center is a fully trusted entity, and the cloud server is a semi-trusted entity; Step 2: The data user maps the search keywords and 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 meets the access policy embedded in the encrypted data in the cloud server 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. Step 3: When the data owner needs to revoke the cloud index or the correspondence between certain keywords and their data, a revocation token is generated and sent to the cloud server; the cloud server performs signature verification on the revocation token in the request and the cloud encrypted data, and executes the corresponding revocation operation when the verification passes.

[0032] When some attribute conditions in the data access structure of several data users are the same in step 2, these repeated policy parts can be generated into a sub-access policy and reused in the subsequent data encryption process, thereby saving the encryption computing resources of the data owner and improving the efficiency of ciphertext generation. Assume that there is 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 of this policy is as follows Figure 2 As shown in the left half, assume that the policy corresponding to the subtree in the dotted box on the left may need to be reused when the data owner encrypts multiple other data in the future. In order to simplify the encryption process and reduce the time cost of encryption, consider setting this part of the policy as a shared sub-policy. The specific construction method is as follows:

[0033] Step 1: Convert the access structure tree

[0034] The entire shared subtree is regarded as a leaf node in the complete access structure tree. A pseudo-attribute component is randomly selected from the public key of the system master key to replace the 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 values ​​are distributed to the leaf nodes including the pseudo-attribute. The final converted access structure tree is as follows: Figure 2 Shown in the right half.

[0035] Step 2: Constructor strategy to determine Bloom filter

[0036] Perform disjunctive calculation on the sub-strategies and obtain four clauses whose conditions are true: C1 = (a5∧a6∧a7)∧a2, C2 = a3∧a2, C3 = a4∧a2, C4 = a1. Figure 3As shown in the figure, a specific Bloom filter is constructed for each clause in the sub-strategy, so that each Bloom filter corresponds to a simplest attribute combination that satisfies the sub-strategy. Specifically, four Bloom filters with length m and bit values ​​{0,1} are initialized, and then a set of independent hash functions h are used for each clause. ι Map the attributes it contains to ι different positions of the Bloom filter, and set the values ​​of these positions from 0 to 1, that is, h(τ)→L(τ)=1. The values ​​of the unmapped positions are still 0. When a position is set to 1 multiple times, its value is still 1.

[0037] Finally, the data owner calculates the attribute value component for each clause and selects an arbitrary pseudo-attribute in the system public key to replace the 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.

[0038] Step 3: Sub-strategy determination process

[0039] Assume that the access policy contains 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 the ciphertext component of the attachment. The clause filter is stored as a set in the cloud, associated with the unique identifier of the sub-access policy. When it is necessary to make attribute judgments on the data user and the relevant ciphertext contains the sub-policy identifier, the cloud server will retrieve the clause filter set corresponding to the sub-policy based on this identifier and make the following judgments: ① Perform equal bit determination on the attribute Bloom filter and clause Bloom filter of the data user. It is required that the bit with value 1 in the clause Bloom filter must also be 1 in the attribute Bloom filter of the data user, otherwise the determination fails. Among them, the attribute Bloom filter of the data user is generated by the attribute authorization center, which maps all the attributes owned by the data user to a Bloom filter and puts the private key of the data user into it after processing. ② Since Bloom filters have a certain degree of misjudgment, it is considered to add an additional equivalence judgment verification step based on bilinear pairing of key components and clause attribute values ​​after Bloom filter verification to ensure the legitimacy of access. When steps ① and ② are both judged to be successful, CSP returns the judgment result FR ν =0 for subsequent outsourcing decryption.

[0040] Forward index is a mapping relationship between the keywords extracted from each plaintext data and the documents containing the keywords, such as Figure 4The left half is shown. This retrieval index method is simple in structure and convenient for adding and deleting documents, but it requires linear traversal of all document collections to search for keywords, and the retrieval efficiency is very low. In order to improve the retrieval efficiency, the document ID number where each keyword appears can be recorded to form an inverted index structure from keyword to document ID number, such as Figure 4 Shown in the right half.

[0041] It is difficult to modify the general inverted index structure after it is generated, so consider using hash tables and skip lists to construct an inverted index retrieval structure that supports index revocation and multi-keyword retrieval. Specifically: establish a hash table. When the data owner wants to upload data, extract keywords from the plaintext data to obtain a keyword list, map the keywords to a large integer field, and obtain a unique (KW*) value. Then use a suitable hash function to hash the value to the slot in the hash table (H(KW*)). If the value exists in the hash table, it will be discarded to ensure that each keyword only appears 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 identification component of the document, such as Figure 5 Shown in the left half.

[0042] When a data user issues a search request, the same hash function is used to calculate the corresponding slot for the keyword contained in the search token. 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 document ID set of each keyword to obtain the query result, such as Figure 5 Shown in the right half.

[0043] Revocation process: Consider implementing secure deletion of inverted indexes by attaching a signature component to the ciphertext. The relevant component is generated by the unique ID number of the data owner, thus ensuring that only the legitimate data owner can complete the operation of deleting the specified index after verification. The specific steps are as follows: When the data owner needs to revoke the retrieval index of one or more data, first extract the data and calculate the mapping value of the set keyword in the integer domain and the identity authentication component corresponding to the unique ID number, form a revocation token and send it 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 calculations based on the BLS short signature to verify whether the deletion request is legal. If the request is legal, the corresponding pointer of the jump table is modified to complete the deletion operation on the verified data, and the result of successful deletion is returned to the data owner, such as Figure 6 shown.

[0044] This method allows data owners to revoke the retrieval index of encrypted data on the cloud in a fine-grained manner to meet different needs. First, when the revocation token contains all the keywords of the encrypted data, the encrypted data can be completely revoked in the inverted index. At this time, the data owner can selectively delete some data in the inverted index and retain other data according to his or her needs. Secondly, when the data user customizes the extraction of several keywords from the data, the association between some keywords and the encrypted data on the cloud can be revoked, thereby achieving query control over the encrypted data on the cloud.

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

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

[0047] The algorithm inputs security parameter λ, the complete set of attributes U, and the pseudo attribute set V. It outputs the system master public key MPK and the system master private key MSK.

[0048] 2.KeyGen(Y,DU id ,MPK,MSK)→(UK DU ,TK DU ): The key generation algorithm for data accessors is performed by the attribute authority.

[0049] The algorithm inputs the attribute set Y of the data accessor and the unique identification number DU id , system master public key MPK, system master private key MSK. Output the attribute key UK of the data accessor DU and the decryption private key TK DU .

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

[0051] The algorithm inputs the sub-access policy Λ sub , the unique identification number of the data owner DO id , system master public key MPK. Output the identifier of the shared sub-strategy T tag DO and the identifier set BF consisting of the Bloom filter and attribute components corresponding to the clause tag CSP , where T tagDO Stored locally by the data owner, BF tag CSP Then upload to the cloud server.

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

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

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

[0055] After receiving the ciphertext uploaded by the data owner, the cloud server will k} k∈K Calculate its position in the hash table, and then put the corresponding ciphertext file ID FileID and the revocation matching component FileMatch into the corresponding skip list to form the corresponding inverted index Index Invert structure.

[0056] 6. GenQ s (MPK,UK DU ,{sw s} s∈S ) → Q s : The retrieval trap generation algorithm is executed by the data accessor. The data accessor inputs the system master public key MPK, the retrieval keyword set {sw s} s∈S and property key UK DU Output the corresponding retrieval trap Q s .

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

[0058] The data accessor enters the system master public key MPK and retrieves the trapdoor Q s , Inverted search index Invert. Return the search result SR.

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

[0060] The cloud server inputs the relevant ciphertext CT in the retrieval result SR m δ , data accessor's property key UK DU , clause Bloom filter and corresponding component set corresponding to BF tag CSP. Output attribute outsourcing decryption to obtain the intermediate ciphertext CT m' .

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

[0062] The data accessor uses his own decryption private key TK DU Decrypt the intermediate ciphertext CT m' Get the plaintext data m.

[0063] 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, the revocation token DK, and the ciphertext CT m δ . Cloud server inputs inverted search index Index Invert , output the revocation result DR.

[0064] The data owner extracts several or all keywords from the file according to the revocation needs and maps them to obtain a revocation keyword set, and then calculates the relevant identity authentication components to form a revocation token DK and sends it to the cloud server. The cloud server first finds the file corresponding to the keyword set in the inverted index based on the revocation token, and then extracts the components from the corresponding ciphertext and performs signature verification with the revocation token. The index of the verified files in the search index is deleted, and the deletion result is returned to the data owner. The detailed algorithm design steps are as follows:

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

[0066] 2.KeyGen(Y,MPK,MSK)→(UK DU ,TK DU ): The data accessor's key is generated by the attribute authorization center CA, and the data accessor DU enters his unique identification number DU id ∈{0,1} * , let the attribute of DU be y∈Y, the attribute authority CA generates a Bloom filter as the private key component BF for 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 , get the attribute key: UK DU ={C1,C2,C3,C4,C5}, decryption private key: TK DU =C0, returned to the data accessor through a secure channel.

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

[0068] ① If a reused sub-strategy is required and the reused sub-strategy has not been generated, the data owner DO executes the algorithm STGen(·) to generate the reused sub-strategy. First, extract the sub-strategies to obtain several true clauses that satisfy the sub-access strategy, and construct the corresponding clause Bloom filter. Then calculate Where DO id is the unique identification number of DO. Assume that there are i∈I attributes and j∈J true clauses in the sub-access strategy. For each clause l j calculate: gαi ,j Next, the data owner selects any pseudo-attribute Replace the sub-policy part in the access tree structure corresponding to the access policy. Finally, the data owner calculates the sub-policy identifier Stored locally, the set BF consisting of the clause Bloom filter and attribute components corresponding to the identifier tag CSP Send to the cloud server.

[0069] ② The access policy needs to contain a reused sub-policy, and the reused sub-policy has been generated before. The data owner can directly obtain the identifier of the sub-access policy locally. And put it as a component in the ciphertext.

[0070] ③If the access policy does not need to include a sub-access policy, skip the algorithm and execute the encryption algorithm directly.

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

[0072] ① Does not contain reused sub-strategy: The data owner sets the secret value q at the root node Root(0) = r′, To access the structure tree T com Each non-leaf node d in the d The polynomial Q d , order O d =K d -1, K dis the node threshold. Then the secret value r' of the root node is distributed to the access structure tree from top to bottom. ON(d) is the order of node d in its parent node. Substituting this order into the polynomial as an independent variable, the secret value q of node d is obtained. d(0) =q parent(d) ON(d) . Select Input message m∈{0,1} * ,calculate: F2=H2(DO id )→G, E0=g r , E1=g b·r , right have: Get the ciphertext: CT m δ ={T com ,E m ,FileMatch,E0,E1,E2,E3,E4,{KW k} k∈K}.

[0073] ②Contains multiplexing sub-strategy: At this time, access the structure tree T com The subtree corresponding to the reused sub-strategy is replaced by the random pseudo-attribute α x Substitution, that is, X = (XT) ∪ χ, the relevant ciphertext components are Calculate the remaining components in the same way as above to get the ciphertext: CT m δ ={T com ',E m ,FileMatch,E0,E1,E2',E3',E4,T tag ,{KW k} k∈K}.

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

[0075] ①If [L k] is empty, the keyword is inserted into the hash table. The cloud server generates a unique ID number FileID for the ciphertext file and extracts the component in the ciphertext The cloud server then inserts <FileID, FileMatch> into the node of the jump list corresponding to the keyword to form an ordered linked list structure Index Invert .

[0076] ②If [L k ] 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 Index Invert In order to reduce conflicts, the keywords are hashed once and modulo multiple times to evenly distribute the keywords in the hash table.

[0077] 6. GenQ s (MPK,UK DU ,{sw s} s∈S ) → Q s :The retrieval trap generation algorithm is executed by the data accessor DU, which generates a 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. Finally, the corresponding search trap Q is formed. s ={UK DU ,S r}Sent to the cloud server.

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

[0079] 8.Decrypt1(CT m δ ,UK DU,BF tag CSP )→CT m' :The outsourced decryption algorithm is executed by the cloud server CSP. For the several ciphertexts CT contained in the above search result SR m δ , the cloud server does not send it directly to the data accessor, but outsources the decryption operation one by one based on the attribute key of the data accessor. The leaf nodes of the access structure tree are calculated in two cases according to whether the ciphertext contains a reuse access policy:

[0080] ① The ciphertext does not contain a sub-policy identifier, that is, the access policy does not contain a reused sub-policy. The decryption algorithm Decrypt(CT m δ ,UK,x) are as follows: Where x is the leaf node in the access structure tree. For the same attributes in the leaf node and the data accessor,

[0081] ② The ciphertext contains a sub-policy identifier, that is, the access policy contains a sub-policy. The calculation and decryption process for ordinary leaf nodes is the same as above. The leaf nodes obtained by replacing the pseudo-attribute with the reused sub-policy are: The cloud server first calculates 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 accessor satisfies the sub-access strategy. If the determination fails, return FR ν =1, at this time By the decryption algorithm Decrypt′(CT m δ ,UK,χ) There are components that cannot be eliminated The algorithm terminates if the secret value of the parent node cannot be recursively calculated. If the judgment is successful, FR is returned. ν =0, at this time By the decryption algorithm Decrypt′(CT m δ ,UK,χ) is calculated For leaf nodes that meet the threshold condition, the Lagrange interpolation function is used to reconstruct the secret value of its parent node.

[0082] Assume that non-leaf node x γ The child node set is Sx γ , accessing non-leaf nodes in the structure tree can also be divided into two cases:

[0083] ①x γ Child nodes of γ c Does not include pseudo-attribute nodes.γ Child nodes of γ c The order at c is denoted as k=ON(γ c ), Kγ c ={ON(γ c ),γ c ∈Sx γ}. Execute Decrypt(CT m δ ,UK,x γ ) algorithm, and record the output result as Dx γ When the set Sx γ When Dx is absent γ =⊥, and vice versa: When recursively calculating to the root node, there is

[0084] ②x γ Child nodes of γ c The pseudo-attribute node is included. When the data accessor satisfies the sub-access structure tree policy corresponding to the pseudo-attribute node, the pseudo-attribute node can be treated as a normal leaf node, and the process of calculating the parent node secret value is the same as step ① above. When the data accessor does not satisfy the sub-access policy corresponding to the pseudo-attribute node, the value corresponding to the pseudo-attribute node has redundant parts. It cannot be used to calculate the secret value of its parent node, so it can be regarded as a secret-independent value. When restoring the secret value of the root node, the component Finally, the intermediate ciphertext CT m ={E m ,Dr} and sends it to the data accessor. The data accessor executes the decryption algorithm Decrypt2 (CT m ,TK DU )→m, and use its own decryption key TK to perform a small amount of calculation to obtain the final plaintext

[0085] If the data accessor does not meet the access policy of the ciphertext, the root node secret value of the access structure tree cannot be recovered, the attribute outsourcing decryption fails, and the cloud server does not return any information about the file corresponding to the query keyword to the data accessor.

[0086] 9.DeleteFiles(MPK,DK,CT m δ ,Index Invert )→DR: When the data owner wants to cancel the retrieval index of one or some files on the cloud server, first extract the keyword set {kw k*} k*∈K* , calculate KW k* =H1(kw k*), and then calculate the revocation token related components: FileMatch * =g Hm* , Get the corresponding revocation token DK = {{KW k*} k*∈K* ,FileMatch * ,E m δ} is sent to the cloud server. The cloud server k*} k*∈K* The keyword set in the table calculates the hash value of each keyword, and then searches for FileMatch in the jump table corresponding to the keyword. * Perform an equivalent comparison with FileMatch, and the set of successfully matched ciphertexts is recorded as Multiple E for revoking token DK m δ Add the components together to get Calculate the product of the corresponding ciphertext components FileMatch: The product E4 of the ciphertext components E4 * =E4(m0)·E4(m1)...E4(m n ). Finally, make a judgment: If and only if the determination results are equal, an undo operation is performed in the search index.

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

[0088] The above description is only a preferred embodiment of the present invention and does not constitute any form of limitation to the present invention. Although the present invention has been disclosed as a preferred embodiment as above, it is not intended to limit the present invention. Any technician familiar with the profession can make some changes or modifications to equivalent embodiments of equivalent changes using the technical contents disclosed above without departing from the scope of the technical solution of the present invention. However, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention should be covered within the protection scope of the present invention.

Claims

1. An efficient searchable attribute encryption method with data revocation function, characterized by: The following steps are involved: Step 1: The data owner generates the sub-strategy that he needs to reuse, extracts keywords from the plaintext data for mapping, encrypts the plaintext data and sends them to the cloud server for storage. The cloud server generates the corresponding inverted search index structure. Step 2: The data user maps the search keywords and sends them to the cloud server. The cloud server matches the search token uploaded by the data user in the inverted index, obtains the intermediate ciphertext and sends it to the data user. The data user decrypts it to obtain the plaintext. Step 3: When the data owner needs to revoke the cloud index or the correspondence between certain keywords and their data, a revocation token is generated to be sent to the cloud server; The cloud server performs signature verification on the revocation token in the request and the cloud encrypted data, and performs the corresponding revocation operation if the verification passes.

2. According to claim 1, a highly efficient searchable attribute encryption method with data revocation function is characterized by: 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 decryption private key are sent to the data user.

3. The efficient searchable attribute encryption method with data revocation function according to claim 2, characterized in that: In step 2, the data user maps the search keywords and sends the user attribute key to the cloud server; when the user attribute key meets the access policy embedded in the encrypted data 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.

4. The efficient searchable attribute encryption method with data revocation function according to claim 3, characterized in that: In step 2, when some attribute conditions in the data access structures of several data users are the same, a sub-access policy is generated from the repeated policy part, and the sub-access policy is set as a shared sub-policy.

5. The efficient searchable attribute encryption method with data revocation function according to claim 3, characterized in that: In step 2, when the data user issues a search request, the same hash function is used to calculate the corresponding slot of the keyword contained in the search token, and then the corresponding search algorithm is used in the jump table 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 document ID set of each keyword to obtain the query result.

6. The efficient searchable attribute encryption method with data revocation function according to claim 3, characterized in that: In step 3, when the data owner needs to revoke the retrieval index of one or some data, first extract the data and calculate the mapping value of the set keyword in the integer domain and the identity authentication component corresponding to the unique ID number, and then generate a revocation token and send it 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 calculations based on the BLS short signature to verify whether the deletion request is legal; if the request is legal, the corresponding pointer of the jump table is modified to complete the deletion operation on the verified data, and return the result of successful deletion to the data owner.

7. The efficient searchable attribute encryption method with data revocation function according to claim 3, characterized in that: The attribute authority is a completely trusted entity.

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

9. The efficient searchable attribute 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