A method for ciphertext range query with fine-grained authorization for multiple users

Abstract

This application relates to a method for multi-user fine-grained authorization of encrypted range queries. The method includes: a data owner inputting security parameters to generate public parameters and a system private key; the data owner using the system private key to encrypt plaintext data and its corresponding identity identifier, generating ciphertext bound to the identity identifier, and uploading the ciphertext to a cloud server; the data owner using the system private key to generate an authorization key for the target user's target identity identifier, and sending the authorization key to the target user; after receiving the authorization key, the target user generating a query trapdoor based on query conditions using the authorization key, and sending the query trapdoor to the cloud server; after receiving the query trapdoor, the cloud server performing a matching judgment on the stored ciphertext using the query trapdoor to obtain a set of target ciphertexts that meet the query conditions; and the cloud server returning the set of target ciphertexts to the target user. This method significantly improves the privacy protection level of encrypted databases in multi-query scenarios.

Description

Technical Field

[0001] This application relates to the fields of data security and cryptography, and in particular to a method for ciphertext range query with fine-grained authorization for multiple users. Background Technology

[0002] With the development of cloud computing and data outsourcing services, more and more enterprises and individuals are choosing to store data in the cloud to reduce local management costs and improve the flexibility of data access. In data outsourcing scenarios, to protect data privacy, data owners usually need to encrypt plaintext data before uploading. However, while traditional encryption technologies can guarantee data confidentiality, they severely limit the cloud's ability to compute and retrieve encrypted data. To solve this problem, Order-Revealing Encryption (ORE) technology was proposed. ORE allows direct numerical data size comparisons on ciphertext, becoming a fundamental cryptographic tool for range queries in encrypted databases. In a multi-user environment, the data owner distributes keys to authorized users to generate query trapdoors. Authorized users generate trapdoors and submit them to the cloud server. The cloud server executes a publicly available comparison algorithm and returns matching information based on the comparison result between the trapdoor and the ciphertext. Through this design, ORE enables cloud servers to perform range queries and sorting / filtering operations while maintaining a certain level of data privacy, thus finding wide application in cloud storage, privacy data analysis, and outsourced database management scenarios.

[0003] However, existing multi-user ORE solutions still have significant shortcomings in terms of authorization granularity, query trapdoor security, and information leakage suppression, making them unsuitable for deployment environments with stringent security requirements. Specifically, traditional authorization models cannot provide fine-grained access control based on user identity or data attributes, generally employing an "all or nothing" authorization approach. Once authorized, a user can query all cloud data belonging to that data owner, failing to achieve refined access control based on identity or data attributes. Secondly, the query trapdoor generation process lacks strong unforgeability guarantees for authorization keys. Authorized users may use their keys to derive new authorization keys and send them to other unauthorized users, causing an uncontrollable authorization chain and leading to key forgery or authorization transfer. Furthermore, cloud servers inevitably learn the relative size relationship between ciphertext and the trapdoor during comparison, posing an inherent risk of order leakage. After comparison, the cloud server can determine whether the underlying plaintext corresponding to a certain ciphertext is greater than, less than, or equal to the plaintext represented by the trapdoor. This information can be exploited in multiple rounds of queries or cross-set comparisons, forming inference attacks that allow the cloud server to reconstruct the plaintext distribution, estimate the plaintext value range, or infer the plaintext value interval. These shortcomings are amplified in real-world multi-user collaborative environments, making it difficult to meet the needs of sharing highly confidential data. Summary of the Invention

[0004] Therefore, it is necessary to address the aforementioned technical issues by providing a multi-user fine-grained authorized ciphertext range query method that can solve the key problems of existing multi-user range query schemes in terms of coarse-grained authorization, insufficient trapdoor security, and sequential privacy leakage, and significantly improve the privacy protection level of encrypted databases in multi-query scenarios.

[0005] A method for multi-user fine-grained authorization of encrypted range query, the method being applied to a system including a data owner, a cloud server, and a target user, comprising:

[0006] The data owner and the cloud server initialize the system, with the data owner inputting security parameters to generate public parameters and the system private key; The data owner uses the system's private key to encrypt plaintext data and its corresponding identity identifier, generating ciphertext bound to the identity identifier, and then uploads the ciphertext to the cloud server. The data owner uses the system's private key to generate an authorization key for the target user's target identity and then sends the authorization key to the target user; After receiving the authorization key, the target user generates a query trap using the authorization key based on the query conditions and sends the query trap to the cloud server. After receiving the query trap, the cloud server uses the query trap to perform a matching judgment on the stored ciphertext to obtain the target ciphertext set that meets the query conditions; The cloud server returns the target encrypted set to the target user.

[0007] The aforementioned method for multi-user fine-grained authorization of encrypted range query, by introducing an identity matching mechanism, ensures that the cloud server can only legally determine the relationship between the encrypted data and the trapdoor size when performing comparison operations, provided that the user identities match. This enables fine-grained access control at the encrypted level, ensuring that different users can only query the data range they are authorized to access. It solves the all-or-nothing authorization problem commonly found in existing multi-user sequential visibility encryption schemes, effectively improving access control precision in multi-user cloud environments. Simultaneously, the use of a proxyable equivalent-preserving hash function during the authorization key generation process ensures that the query trapdoor is strictly bound to a specific user identity and authorization range. Other users cannot forge, concatenate, or migrate trapdoors, guaranteeing the secure distribution and use of query capabilities and resolving the security risks of trapdoor forgery and authorization diffusion in existing schemes. Furthermore, by introducing a special encoding layer into the ciphertext structure, the cloud server can only determine whether a match is found and whether the comparison conditions are met when executing the comparison algorithm. It cannot infer the relative size and order between the ciphertext and the trapdoor, effectively suppressing the inherent relative order leakage of traditional order-visible encryption. The cloud server cannot obtain additional order information from the ciphertext-trapdoor pair, and therefore cannot infer the data distribution through multiple queries, significantly improving the privacy protection level of the encrypted database in multi-query scenarios. In summary, this application, through the comprehensive design of identity matching, an unforgeable trapdoor generation mechanism, and order leakage suppression technology, solves the key problems of existing multi-user query schemes in terms of coarse-grained authorization, insufficient trapdoor security, and order privacy leakage, achieving a more secure, flexible, and efficient encrypted data comparison capability in a multi-user cloud environment. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating a multi-user fine-grained authorization ciphertext range query method in one embodiment; Figure 2 This is a schematic diagram of the system in one embodiment; Figure 3 This is a schematic diagram illustrating the encryption time overhead in one embodiment; Figure 4 This is a schematic diagram of the ciphertext length in another embodiment; Figure 5 This is a schematic diagram illustrating the time overhead of the trapdoor generation algorithm in one embodiment; Figure 6 This is a schematic diagram of the trapdoor length overhead in one embodiment; Figure 7 This is a schematic diagram illustrating the time overhead of a comparison algorithm in one embodiment. Detailed Implementation

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

[0010] In one embodiment, such as Figure 1 As shown, a method for multi-user fine-grained authorization ciphertext range query is provided, which is applied to, for example... Figure 2 As shown, the system includes a data owner, a cloud server, and a target user. The data owner is responsible for generating a master key (for data encryption) and a query key (for authorization). After encrypting the database with the master key, the ciphertext is outsourced to the cloud server, and fine-grained access control to the data is achieved by generating keys through a management trapdoor.

[0011] Data User: A user authorized by the data owner uses a trapdoor generation key to generate a query trapdoor and initiates a search request to the cloud server. This chapter assumes that a malicious data user will not collude with the cloud server, but may collude with other users or attempt to transfer authorization or decrypt other users' query trapdoor privacy information independently.

[0012] Cloud server: Responsible for storing encrypted databases belonging to multiple data owners and responding to query traps submitted by data users. The server employs a semi-honest model, meaning that while faithfully executing protocol operations, it may attempt to obtain additional information through statistical analysis of ciphertext and query records.

[0013] In this application, the data owner first encrypts the data to be outsourced locally, generating corresponding ciphertext, and uploads this ciphertext to a cloud server for long-term storage. Subsequently, the data owner generates an authorization key bound to the target user's identity according to access control policies and sends this key to the user for subsequent query operations. When an authorized user needs to perform a query, they generate a corresponding query trap using the authorization key and their query conditions, and send the trap to the cloud server. Upon receiving the query trap, the cloud server matches and compares all stored ciphertext data, filters out ciphertext that meets the query conditions based on the comparison results, and finally returns the matching query results to the user, thus completing a cross-user data query process.

[0014] The method specifically includes the following steps: Step 102: The data owner and the cloud server initialize the system. The data owner inputs security parameters to generate public parameters and the system private key.

[0015] The method proposed in this application is based on a proxyable equivalence-preserving hash mechanism and an identity-matching order-visible encryption mechanism. By embedding identity identifiers into the data and authorizing based on identity control, the data owner can encrypt outsourced data and upload it to a cloud server. Simultaneously, authorized users are allowed to generate corresponding query trapdoors based on authorization keys, thereby performing range queries on the encrypted data in the cloud and returning results that meet the conditions. The data owner calls the DEPH.Setup algorithm, taking security parameters as input, to generate public parameters. and system private key Public parameters The algorithm includes the group parameters and bilinear mapping parameters required for system operation. Specifically, after the client inputs the security parameter λ, the algorithm constructs a prime number p-order group system, including the group... , and And establish a bilinear mapping Subsequently, a generator is randomly selected. and calculate The algorithm continues to randomly generate private key parameters x and y (both belonging to...). ), and a key of length λ bits ( The algorithm ultimately outputs public parameters. and private key =( , , The public parameter `pp` is implicitly invoked at various stages of this application, while the private key `sk` is used for subsequent ciphertext hash generation and identity proxy key generation. The data owner initializes the local storage structure based on the public parameters for storing... Plain text data This includes subsequently generated ciphertext, authorization keys, and other content. The cloud server initializes its own ciphertext storage structure based on publicly available parameters for subsequent unstructured storage of the ciphertext (ct).

[0016] Step 104: The data owner uses the system private key to perform encryption operations on the plaintext data and the corresponding identity identifier, generating ciphertext bound to the identity identifier, and then uploads the ciphertext to the cloud server.

[0017] The data owner first checks each plaintext Perform block processing and select an identifier for each plaintext message. Specifically, the data owner inputs... Plain text and identity First of all Decomposed into Each block: Each block has b bits. Then, for each block... and all Constructing intermediate structures for comparison:

[0018] The data owner calls DEPH's hash algorithm to... Generate bound identity Hash entries:

[0019] all After random permutation The following is combined into ciphertext:

[0020] The final generated It includes both structured content that supports range comparisons and identity information. The access control labels displayed. All encrypted data. After being generated, it is sent to the cloud server for storage and management.

[0021] Step 106: The data owner uses the system private key to generate an authorization key for the target user's target identity and sends the authorization key to the target user.

[0022] Data owner reads private key With the target identity Call DEPH's key generation process Generate proxy key and will As an authorization key Output, i.e.: = Specifically, the client enters the system private key. =( , , and identity Then, the algorithm randomly selects elements. The core component of the proxy key is calculated according to the following expression:

[0023] The algorithm ultimately outputs the proxy key. =(K, , The proxy key will also carry the identity. The access characteristics make subsequent use The generated trapdoor Only with the same identity The encrypted data is compared to the encrypted data, thereby enabling fine-grained access control.

[0024] Authorization Key The 'id' is internally bound, and subsequent authorized users can only access users with the same 'id'. ciphertext This creates a query trap, preventing access to data belonging to other individuals. The data owner will... Send to target users for subsequent generation use.

[0025] Step 108: After receiving the authorization key, the target user generates a query trap using the authorization key based on the query conditions and sends the query trap to the cloud server.

[0026] Authorized users can read locally saved data. And select the benchmark value based on the query conditions. Simultaneously set indicator bits ( =1 indicates a query for "less than" " =0 indicates that the query is greater than 0. The user decomposes m' into... Each block: Each block has b bits.

[0027] Then, an intermediate description is constructed for each block:

[0028] The user invoked DEPH's trapdoor generation algorithm and obtained:

[0029] all After random permutation The final combination forms the trapdoor:

[0030] It also includes the query direction. and Bound identity Users will Submitted to the cloud server for subsequent matching.

[0031] Step 110: After receiving the query trapdoor, the cloud server uses the query trapdoor to perform a matching judgment on the stored ciphertext to obtain the target ciphertext set that meets the query conditions.

[0032] The cloud server will receive Parsed as and each ciphertext They are respectively analyzed as The server processes each pair Calling the underlying DEPH matching test: The matching condition for the DEPH.Test algorithm is: the input is a hash. With the trapdoor The server verifies based on the following matching conditions: if... If the result is 1, the output is 1; otherwise, the output is 0. Here, e is a bilinear mapping. If the test result is 1, it means that the corresponding message satisfies the identity matching and the message... and Same; upon the imORE call, the matching pattern is further expanded to "comparison holds". If any ( i , j If b=1, then determine the... and Matching means that the corresponding plaintext meets the user's query range (e.g., "greater than"). "or less than" The server will send all successfully matched data. Collected and used as query results.

[0033] Step 112: The cloud server returns the target ciphertext set to the target user.

[0034] The cloud server will return the final query results to the user, completing a query based on the authorization key. The process of range querying. The cloud server will filter the results. The system returns the corresponding identifier to the user without exposing any additional information. The entire process ensures that the user can only query the information specified in the query. Authorized identity The corresponding data.

[0035] The aforementioned method for multi-user fine-grained authorization of encrypted range query, by introducing an identity matching mechanism, ensures that the cloud server can only legally determine the relationship between the encrypted data and the trapdoor size when performing comparison operations, provided that the user identities match. This enables fine-grained access control at the encrypted level, ensuring that different users can only query the data range they are authorized to access. It solves the all-or-nothing authorization problem commonly found in existing multi-user sequential visibility encryption schemes, effectively improving access control precision in multi-user cloud environments. Simultaneously, the use of a proxyable equivalent-preserving hash function during the authorization key generation process ensures that the query trapdoor is strictly bound to a specific user identity and authorization range. Other users cannot forge, concatenate, or migrate trapdoors, guaranteeing the secure distribution and use of query capabilities and resolving the security risks of trapdoor forgery and authorization diffusion in existing schemes. Furthermore, by introducing a special encoding layer into the ciphertext structure, the cloud server can only determine whether a match is found and whether the comparison conditions are met when executing the comparison algorithm. It cannot infer the relative size and order between the ciphertext and the trapdoor, effectively suppressing the inherent relative order leakage of traditional order-visible encryption. The cloud server cannot obtain additional order information from the ciphertext-trapdoor pair, and therefore cannot infer the data distribution through multiple queries, significantly improving the privacy protection level of the encrypted database in multi-query scenarios. In summary, this application, through the comprehensive design of identity matching, an unforgeable trapdoor generation mechanism, and order leakage suppression technology, solves the key problems of existing multi-user query schemes in terms of coarse-grained authorization, insufficient trapdoor security, and order privacy leakage, achieving a more secure, flexible, and efficient encrypted data comparison capability in a multi-user cloud environment.

[0036] In one embodiment, the process by which the data owner inputs security parameters to generate public parameters and a system private key includes: the data owner calling the DEPH.Setup algorithm to generate public parameters PP and a system private key SK. The public parameters PP contain the group parameters and bilinear mapping parameters required for system operation, and the system private key SK is used for subsequent ciphertext generation and authorization key generation.

[0037] Specifically, the system parameters are initialized. The data owner inputs the security parameter λ, and through the initialization process of the underlying Proxyable Equivalent Preserved Hash (DEPH), public parameters and the system private key are generated. This process includes calling the DEPH Setup sub-algorithm. The process yields (pp, sk), with pp used as the public parameter in this application and sk as the system private key. The public parameters include the fundamental group parameters, bilinear mapping, and other parameters required for system operation; the private key is used to subsequently encrypt plaintext m and generate an authorization key. The data owner initializes the local storage area based on pp, and the cloud server initializes the ciphertext storage structure based on pp to store subsequently uploaded ciphertext. Through this initialization process, a secure cryptographic foundation is established for the entire system, ensuring the security of subsequent encryption, authorization, and comparison operations.

[0038] In one embodiment, generating ciphertext bound to an identity identifier includes: The plaintext data is decomposed into multiple blocks; an intermediate value is constructed for each block; the DEPH.Hash algorithm is called based on the system private key to generate a hash value bound to the identity identifier for the intermediate value; and the multiple hash values ​​are combined into ciphertext after random permutation.

[0039] Specifically, this is achieved by constructing intermediate values ​​for each block and generating bound identities. The hash value ensures that the final ciphertext contains both structured content that supports range comparisons and identity information. The access control labels are displayed. Random permutation further enhances the indistinguishability of the ciphertext, making it impossible for the cloud server to infer the block order information from the ciphertext structure.

[0040] In one embodiment, the intermediate value is constructed as follows: in, The first part represents the plaintext data. i Each block, Indicates the first i The possible values ​​for each block are: Represents a hash function. Indicates when Greater than The value is 1 if the condition is met, and 0 otherwise.

[0041] Specifically, this intermediate value construction method cleverly encodes the block position, prefix information, possible values ​​of the current block, and size comparison relationships into the hash input. By introducing... The indicator bits enable the subsequently generated hash values ​​to implicitly support range query comparison logic, providing a basis for cloud servers to only perform equality tests and not obtain order information.

[0042] In one embodiment, the hash value for generating the bound identity identifier from the intermediate value is: in, For the system private key, The median value. For identification purposes.

[0043] Specifically, the hash value calculation process takes the system private key, intermediate value, and identity identifier as input to generate a triplet structure bound to the identity. The DEPH.Hash algorithm first randomly selects... The output is

[0044] The triplet also carries a message. Encoded information and identity The binding information forms the foundation for subsequent matching tests. In this way, the ciphertext hash value and the identity identifier are securely bound, ensuring that only users holding the corresponding authorization key can generate a valid query trapdoor.

[0045] In one embodiment, generating the authorization key includes: Based on the system private key and the target identity, the DEPH.KGen algorithm is called to calculate the proxy key, and the proxy key is output as the authorization key. The proxy key is calculated as follows: in, For generators, It is a pseudo-random function. , , It is a component of the system's private key. For target identity identification, This is a randomly selected integer.

[0046] Specifically, the authorization key generation process randomly selects elements. And calculate the proxy key based on the target identity. Authorization key Internally bound to identity identifier This makes subsequent use The generated trapdoor Only with the same identity The encrypted data is compared. The core component of the proxy key uses a fractional exponential form, combined with random numbers. and private key parameters , This ensures that the authorization key is unforgeable and non-transferable, preventing users who have not obtained the authorization key from constructing effective query traps.

[0047] In one embodiment, generating a query trapdoor includes: The query value is decomposed into multiple blocks; a matching segment is constructed based on the query direction bit; the DEPH.TGen algorithm is called using the authorization key to calculate the trapdoor component for each matching segment; multiple trapdoor components are combined into a query trapdoor after random permutation; The matching fragment is constructed as follows: in, Indicates the first value of the query value Each block, Indicates the query direction bit. This represents a hash function.

[0048] Specifically, this matching fragment construction method corresponds to the intermediate value construction method in the encryption phase, by using the query direction bits. The hash input is encoded so that the generated trapdoor can be matched with the hash value in the ciphertext. =1 indicates a query for "less than" " =0 indicates that the query is greater than 0. The data. Through this design, users can adjust... It allows for flexible expression of different range query conditions.

[0049] In one embodiment, the trapdoor component is: in, For authorization key, For matching segments.

[0050] Specifically, the DEPH.TGen algorithm inputs the proxy key. =(K,r,k) and the query message provided by the user The algorithm is based on the message. Calculate the output trapdoor .in The random values ​​generated during the authorization phase must remain consistent throughout. The first part is the crucial component that allows for matching tests with hashes under the same identity. This trapdoor component inherits the identity binding information from the authorization key, ensuring that only users with the correct identity authorization key can generate a valid trapdoor.

[0051] In one embodiment, performing a matching determination includes: The components of the ciphertext are compared with the components of the query trapdoor using an equivalence test. The DEPH.Test algorithm is then called to determine if they match. If at least one set of test results is true, the ciphertext is deemed to meet the query conditions. The matching condition for the DEPH.Test algorithm is: the input is a hash. With the trapdoor ,like If the expression matches, the output will show a match; otherwise, the output will show a mismatch. The hash component in the ciphertext. To query the trapdoor component in a trapdoor, e is a bilinear mapping.

[0052] Specifically, the cloud server verifies the equivalence between the ciphertext hash and the trapdoor using a bilinear mapping operation. This matching condition implements an equality test at the underlying level without exposing any size or order information. The bilinear mapping equation holds when identities match and messages are identical; otherwise, it does not. The cloud server can only obtain a Boolean result of a match or non-match, and cannot know the relative size and order between the ciphertext and the trapdoor, nor can it obtain any order information when identities do not match. This design fundamentally eliminates the inherent risk of order leakage in traditional order-visible encryption.

[0053] In one embodiment, the authorization key is bound to the target identity identifier, and only valid query trapdoors are allowed to be generated for ciphertexts with the same identity identifier; the query trapdoor is unforgeable, and users who have not obtained the authorization key cannot construct valid query trapdoors; when the cloud server performs the matching judgment, it only obtains a Boolean result of matching or not matching, and cannot know the relative size order between the ciphertext and the query trapdoor.

[0054] Specifically, by binding the authorization key to the identity identifier, fine-grained access control at the ciphertext level is achieved. Only users holding the corresponding authorization key can generate valid query trapdoors, thus solving the "all-or-nothing" authorization problem commonly found in existing multi-user sequential visibility encryption schemes. The unforgeability of the query trapdoor stems from the cryptographic construction used in the authorization key generation process. Users without the authorization key cannot forge, concatenate, or migrate the trapdoor, effectively preventing unauthorized access and authorization diffusion. The cloud server can only obtain matching or non-matching Boolean results and cannot infer the relative size and order between the ciphertext and the trapdoor, nor can it infer the data distribution through multiple queries, thus significantly improving the privacy protection level of the encrypted database in multi-query scenarios.

[0055] In a specific embodiment, the multi-user sequential visibility encryption scheme supporting identity matching proposed in this application was fully simulated and implemented using the C language. To evaluate the performance and security of this scheme, several ORE schemes were selected as benchmarks, specifically the m-ORE multi-user ORE scheme, the DORE proxy-enabled ORE scheme, the PH-ORE parameter-hidden ORE scheme, and the en-ORE enhanced ORE scheme. Systematic comparative tests were conducted under the same experimental environment. All experiments were developed using the C language, with the pseudo-random function (PRF) instantiated using SHA-256. The experimental platform was a desktop computer equipped with an Intel i9-11900K processor, 128 GB of main memory, and running Ubuntu 20.04.6 LTS. The implementation of bilinear mapping relied on the PBC library to ensure the correctness and efficiency of group operations and bilinear operations. The experimental configuration and environment were unified to ensure the comparability of performance evaluations between different schemes. The above environment provided a stable operating foundation for the core algorithms in this application, such as encryption, trapdoor generation, and comparison, and effectively reflected the execution overhead and scalability of the scheme in a real-world deployment environment. For comparison, a 2-bit block size was selected as the baseline. The message length range was set to 8 to 64 bits.

[0056] Regarding the overhead of encryption algorithms, such as Figure 3 As shown, this application maintains millisecond-level encryption latency for the vast majority of message sizes, outperforming PH-ORE and DORE overall. Furthermore, it provides stronger security and richer functionality than m-ORE and en-ORE while introducing only slightly higher encryption overhead. Specifically, for 64-bit messages, the encryption time is approximately 70ms. Regarding ciphertext length, as... Figure 4 As shown, although the ciphertext size of the scheme is relatively large, the optimized design significantly reduces the ciphertext overhead, with an overall reduction of approximately 40%. In contrast, the ciphertext storage of m-ORE and en-ORE is also at the KB level.

[0057] Regarding the overhead of trapdoor generation, such as Figure 5 and Figure 6 Experimental results show that the trapdoor generation time and trapdoor size of this application are significantly better than m-ORE, with time overhead reduced to about 25% and trapdoor size reduced to less than 30%. Although en-ORE has advantages in trapdoor generation efficiency and trapdoor length, its functionality is limited, and the trapdoor is a deterministic form, which brings additional information leakage risks.

[0058] In terms of performance comparison, such as Figure 7As shown, the time overhead of the comparison algorithm is roughly equivalent to PH-ORE. After structural optimization, the comparison time is further reduced to approximately 1 / 139 of the original, making it one of the current optimal asymmetric comparison schemes. This efficiency improvement is mainly due to the simplified bilinear pairing computation structure, which requires a maximum of only n bilinear pairing operations (where n is the bit length of the message). In contrast, other schemes may require 3n, 8n, or even up to 4n² bilinear pairing operations in the worst case.

[0059] This application achieves significant efficiency improvements while maintaining the same security guarantees as the original design. It should be noted that the embodiments of this application can be implemented using hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of this application can be implemented using hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., or can be implemented using software executed by various types of processors, or can be implemented using a combination of the above-described hardware circuits and software, such as firmware.

[0060] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0061] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0062] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for multi-user fine-grained authorization ciphertext range query, characterized in that, The method is applied to a system that includes a data owner, a cloud server, and a target user, including: The data owner and the cloud server initialize the system, with the data owner inputting security parameters to generate public parameters and a system private key; The data owner uses the system private key to perform encryption operations on the plaintext data and the corresponding identity identifier, generates ciphertext bound to the identity identifier, and uploads the ciphertext to the cloud server; The data owner uses the system private key to generate an authorization key for the target user's target identity identifier, and sends the authorization key to the target user; After receiving the authorization key, the target user generates a query trap using the authorization key based on the query conditions, and sends the query trap to the cloud server. After receiving the query trap, the cloud server uses the query trap to perform a matching judgment on the stored ciphertext to obtain a set of target ciphertexts that meet the query conditions. The cloud server returns the target ciphertext set to the target user.

2. The method according to claim 1, characterized in that, The process by which the data owner inputs security parameters to generate public parameters and a system private key includes: the data owner calling the DEPH.Setup algorithm to generate public parameters and a system private key, wherein the public parameters include the group parameters and bilinear mapping parameters required for system operation, and the system private key is used for subsequent ciphertext generation and authorization key generation.

3. The method according to claim 1, characterized in that, The generation of ciphertext bound to the identity identifier includes: The plaintext data is decomposed into multiple blocks; an intermediate value is constructed for each block; the DEPH.Hash algorithm is called based on the system private key to generate a hash value that is bound to the identity identifier for the intermediate value; and the multiple hash values ​​are combined into the ciphertext after random permutation.

4. The method according to claim 3, characterized in that, The intermediate value is constructed as follows: in, The first part represents the plaintext data. i Each block, Indicates the first i The possible values ​​for each block are: Represents a hash function. Indicates when Greater than The value is 1 if the condition is met, and 0 otherwise.

5. The method according to claim 3, characterized in that, Generate a hash value for the intermediate value that is bound to the identity identifier: in, The system's private key. The intermediate value, This refers to the identity identifier.

6. The method according to claim 1, characterized in that, The generation of the authorization key includes: Based on the system private key and the target identity identifier, the DEPH.KGen algorithm is invoked to calculate the proxy key, and the proxy key is output as the authorization key. The proxy key is calculated as follows: in, For generators, It is a pseudo-random function. , , It is a component of the system's private key. The target identity identifier, This is a randomly selected integer.

7. The method according to claim 1, characterized in that, The generated query trapdoor includes: The query value is decomposed into multiple blocks; a matching segment is constructed based on the query direction bit; the DEPH.TGen algorithm is called using the authorization key to calculate the trapdoor component for each matching segment; and multiple trapdoor components are combined into the query trapdoor after random permutation. The matching fragment is constructed as follows: in, Indicates the first value of the query value Each block, Indicates the query direction bit. This represents a hash function.

8. The method according to claim 7, characterized in that, The trapdoor component is: in, The authorization key, The matched segment.

9. The method according to claim 1, characterized in that, The execution of the matching judgment includes: An equivalence test is performed on each component of the ciphertext and each component of the query trapdoor, and the DEPH.Test algorithm is called to determine whether they match; if at least one set of test results is true, the ciphertext is determined to meet the query conditions. The matching condition for the DEPH.Test algorithm is: the input is a hash. With the trapdoor ,like If the expression matches, the output will show a match; otherwise, the output will show a mismatch. The hash component in the ciphertext. To query the trapdoor component in a trapdoor, e is a bilinear mapping.

10. The method according to claim 1, characterized in that, The authorization key is bound to the target identity identifier, and only allows the generation of valid query trapdoors for ciphertexts with the same identity identifier; the query trapdoor is unforgeable, and users who do not obtain the authorization key cannot construct valid query trapdoors; when the cloud server performs the matching judgment, it only obtains a Boolean result of matching or not matching, and cannot know the relative size order between the ciphertext and the query trapdoor.

Images