A searchable encryption co-occurrence pattern hiding method and system supporting dynamic update

Abstract

This application discloses a searchable encrypted co-occurrence pattern hiding method and system that supports dynamic updates, relating to the technical field of search encryption. This application utilizes a differentiated replica allocation mechanism based on a comprehensive popularity index to divide queries into hot buckets, warm buckets, and cold buckets, creating different numbers of data replicas. Combined with a dynamic replica selection function, it enables the same query to access different replicas at different times. This application not only effectively hides the co-occurrence pattern of queries through differentiated replica allocation and dynamic replica rotation, but also achieves efficient dynamic update support through a two-layer storage structure and a periodic shuffling mechanism. Simultaneously, an adaptive hot bucket adjustment strategy ensures the rational utilization of storage resources and a dynamic balance between security protection strength.

Description

Technical Field

[0001] This application relates to the technical field of search encryption, and in particular to a method and system for hiding searchable encrypted co-occurrence patterns that supports dynamic updates. Background Technology

[0002] With the rapid development of cloud computing technology and the widespread application of data outsourcing storage models, more and more enterprises and individuals are choosing to store sensitive data on cloud servers to reduce local storage costs and improve data availability. However, data security issues in the cloud environment are becoming increasingly prominent, and how to achieve efficient data retrieval while ensuring data confidentiality has become a key technical problem that urgently needs to be solved.

[0003] Searchable encryption technology, as an important means to solve the above problems, allows users to perform keyword searches on encrypted data without decryption. Existing searchable encryption schemes typically use deterministic encryption or index structures to implement retrieval functions. By establishing a mapping relationship between keywords and encrypted documents, the server can locate matching encrypted data based on the user-submitted query traps and return the search results.

[0004] However, existing searchable encryption schemes commonly suffer from security vulnerabilities related to access pattern leakage and co-occurrence pattern leakage. Attackers can analyze the correlation and frequency distribution of different queries by observing the access patterns of query operations over a long period, thereby inferring sensitive query content. In addition, existing schemes often require rebuilding the entire index structure when supporting dynamic data updates, resulting in low update efficiency; at the same time, static replica allocation strategies cannot adapt to dynamic changes in query popularity, leading to wasted storage resources or insufficient security protection. Summary of the Invention

[0005] This application provides a method for hiding searchable encrypted co-occurrence patterns that supports dynamic updates, in order to solve the technical problems of high risk of co-occurrence pattern leakage, low efficiency of dynamic updates, and lack of adaptability of copy allocation strategies in existing searchable encryption technologies.

[0006] Firstly, this application provides a method for hiding a dynamically updated searchable encrypted co-occurrence pattern, the method comprising: A comprehensive popularity index is calculated based on the historical query frequency and sensitivity level of each query. Based on the comprehensive popularity index, each query is divided into different popularity buckets, and a different number of data replicas are created for the queries in different popularity buckets to obtain a multi-replica encrypted database. The different popularity buckets include hot buckets, warm buckets, and cold buckets. Based on the received data operation entries and operation types, the encrypted operation logs are stored in the corresponding partition of the buffer layer in the two-layer storage structure. The main layer is used to store the shuffled historical operation logs, and the buffer layer is used to store the new operation logs in the current period, resulting in the updated encrypted database. Based on the query request, determine the hot bucket to which the query belongs. Calculate the replica index to be accessed this time based on the replica selection function and query counter corresponding to the hot bucket. Perform the retrieval and merge the results in the main layer and buffer layer respectively according to the replica index to obtain the retrieval results. When the query counter reaches a preset threshold, the operation logs in the main layer and the buffer layer are shuffled according to the random permutation sequence to disrupt the storage order. The main layer is reconstructed based on the shuffle result and the buffer layer is cleared. The query is upgraded or downgraded according to the heat change in the current period to obtain the reconstructed encrypted database.

[0007] In the above embodiments, since existing searchable encryption schemes typically use fixed access paths when processing query requests, attackers can identify the co-occurrence relationships and access frequencies between different queries through long-term observation, thereby inferring sensitive query content. Simultaneously, existing schemes often require a full rebuild of the index structure when supporting dynamic updates, resulting in huge update overhead and an inability to adapt to real-time changes in query popularity. This application first calculates a comprehensive popularity index based on the historical query frequency and sensitivity level of each query, dividing queries into three different popularity levels: hot, warm, and cold. It then creates a differentiated number of data replicas for queries in different popularity buckets to construct a multi-replica encrypted database. Secondly, a two-layer storage structure is used to temporarily store newly generated operation logs in a buffer layer. In the corresponding partition, global rebuilds are avoided for every update. When executing a query, the replica index to be accessed is dynamically calculated based on the replica selection function and query counter corresponding to the hot bucket to which the query belongs, and the results are retrieved and merged in the main layer and buffer layer respectively. When the query counter reaches a preset threshold, the operation log is shuffled by a random permutation sequence to disrupt the storage order, and the query is upgraded or downgraded according to the change in popularity. This application not only effectively hides the co-occurrence pattern of queries through differentiated replica allocation and dynamic replica rotation, but also achieves efficient dynamic update support through a two-layer storage structure and periodic shuffling mechanism. At the same time, the adaptive hot bucket adjustment strategy ensures the rational utilization of storage resources and the dynamic balance of security protection strength.

[0008] In some embodiments, the calculation of the comprehensive popularity index based on the historical query frequency and sensitivity level of each query specifically includes: The historical query frequency of each query is normalized to obtain the normalized frequency value; The sensitivity level is normalized to obtain a normalized sensitivity level. Based on the normalized frequency value and the normalized sensitivity level, a comprehensive heat index is calculated using a preset weighted summation formula. Based on the comparison results between the comprehensive popularity index and the preset threshold, the query is divided into a hot bucket, a warm bucket, or a cold bucket.

[0009] In the above embodiments, when directly using the original query frequency for popularity segmentation, frequency values ​​of different magnitudes may lead to distorted segmentation results, and a single frequency index cannot reflect the actual security requirements of the query. This application first normalizes the historical query frequency of each query to eliminate differences in dimensions, then calculates a comprehensive popularity index by merging the normalized frequency value and the sensitivity level through a weighted summation formula, and finally accurately segments the query into the corresponding popularity bucket based on the comparison result of this index with a preset threshold. The normalization process ensures fair comparison of queries in different frequency ranges, and the introduction of a sensitivity level factor enables popularity segmentation to simultaneously take into account both access frequency and security requirements.

[0010] In some embodiments, the replica index to be accessed this time is calculated based on the replica selection function and query counter corresponding to the hot bucket, specifically including: The client performs a hash operation based on the query identifier, the current query counter, and the client's secret factor to obtain the hash value; The replica index is obtained by taking the hash value modulo the number of replicas in the query's hot bucket and adding one.

[0011] In the above embodiments, since a fixed replica selection strategy will always lead to the same query accessing the same replica, attackers can identify query patterns based on this. This application uses the query identifier, the current query counter, and the client secret factor as inputs to the hash operation, making the replica selection result of each query pseudo-random. The final replica index is then determined by taking the modulo of the replica number and adding one. This not only ensures the deterministic verifiability of replica selection, but also achieves the effect of the same query accessing different replicas at different times by introducing a dynamically changing query counter, thus breaking the predictability of access patterns.

[0012] In some embodiments, before performing the retrieval and merging according to the replica index in the primary layer and the buffer layer respectively, the method further includes: Based on the query trapdoor, a hit check is performed in the cache. If a hit is found and the timeout is not exceeded, the cached result is returned directly and a virtual copy retrieval is performed to maintain operational consistency. If a miss is found, the copy index calculation continues.

[0013] In the above embodiments, frequent repeated queries will generate a large amount of redundant server interaction overhead, and directly skipping replica access will destroy the consistency of access patterns. Before performing replica retrieval, this application first performs a hit check in the local cache according to the query trapdoor. If a hit is found and the timeout is not exceeded, the cached result is returned directly to avoid repeated retrieval. At the same time, a virtual replica retrieval operation is performed to maintain the same access behavior characteristics as normal queries. The caching mechanism reduces the response latency and communication overhead of repeated queries, and the virtual retrieval operation ensures the indistinguishability of access patterns in cache hit scenarios.

[0014] In some embodiments, performing a shuffling operation on the operation logs in the main layer and the buffer layer according to a random permutation sequence specifically includes: The target location of each operation log is determined based on the random permutation sequence generated by the client. After re-encrypting each operation log according to the shuffling key, the log is written to the target location to obtain the shuffled operation log.

[0015] In the above embodiments, when performing the shuffling operation, this application first determines the target position of each operation log according to the random permutation sequence generated by the client, and then re-encrypts each operation log with the shuffling key before writing it to the target position; by randomly permuting, the physical storage order of the operation log is disrupted, and by re-encrypting, the ciphertext before and after the shuffling is completely different, thereby completely severing the correlation between the old and new ciphertext.

[0016] In some embodiments, the buffer layer includes an ADD partition and a DELETE partition, which are used to store data addition operation logs and data deletion operation logs, respectively.

[0017] In the above embodiments, this application divides the buffer layer into ADD partitions and DELETE partitions, which are used to store data addition operation logs and data deletion operation logs, respectively; this simplifies the management and retrieval process of different types of operation logs and provides a data organization structure for subsequent incremental merging and reshuffling reconstruction.

[0018] In some embodiments, storing the encrypted operation log to the corresponding partition of the buffer layer in the dual-layer storage structure specifically includes: For each newly added operation log, a replica log is generated synchronously based on the number of replicas in the hot bucket to which the query belongs; The client randomly assigns an independent physical location to each replica log in the buffer layer and establishes a mapping entry from the logical replica index to the physical location; The replica logs for add operations are written to the ADD partition, and the replica logs for delete operations are written to the DELETE partition; the physical location of replicas in the buffer layer is independent of the query counter.

[0019] In the above embodiments, since the buffer layer pre-fills all logical replica positions according to the number of hot bucket replicas when writing, and the physical location of each replica is randomly assigned by the client and isolated by mapping entries, the buffer layer and the main layer can hit the replica data corresponding to the same logical index under any query counter value, avoiding the problem of inconsistent access positions caused by counter drift between the two layers; at the same time, although the server can observe the writing and access behavior of the buffer layer, it cannot associate the physical location with the specific query keyword, further severing the potential association between the writing sequence and the access position, and improving the query pattern hiding capability in dynamic update scenarios.

[0020] In some embodiments, performing bucket upgrade or downgrade processing on the query based on changes in popularity within the current period specifically includes: When upgrading a bucket, the client derives the encrypted data of the new replica from the plaintext index or key held locally, generates a new replica log according to the number of replicas in the target bucket, randomly assigns the physical location of the new replica to the primary layer and establishes a mapping entry. When the bucket is downgraded, the client generates a deletion command containing the location identifier of the replica to be deleted. The server deletes the corresponding replica log according to the deletion command, and the client synchronously deletes the corresponding mapping entry.

[0021] In the above embodiments, since the encrypted data of the newly added replicas during bucket upgrade is directly derived by the client from the local plaintext index or key, there is no need to request decryption from the server, thus avoiding the leakage of plaintext information to the server during the replica expansion process; since the target replica log is precisely deleted and the mapping entries are cleaned up synchronously through the deletion command containing the location identifier during bucket downgrade, the problem of replica data residue and floating mapping entries that may be caused by random deletion is avoided, ensuring the storage consistency and access correctness when the replica configuration is dynamically adjusted according to the query popularity, and realizing adaptive optimization of the number of replicas.

[0022] In some embodiments, the method further includes: at the end of each retrieval period, calculating the inter-bucket discrimination index based on the access frequency of each hot bucket, and when the index exceeds a preset safety threshold, generating a noisy query by the client and submitting it to the server by the replica selection function.

[0023] In the above embodiments, because the method of calculating the inter-bucket discrimination index based on information entropy and the adaptive noise query injection mechanism are adopted, even if the server statistically analyzes the access frequency distribution of each replica location for a long time, it is impossible to infer the hot bucket to which the query belongs through frequency analysis. Therefore, it is impossible to use the hot bucket attribution information to narrow the inference range of query co-occurrence relationship, effectively resisting side-channel attacks based on access frequency statistics and further enhancing the security of query co-occurrence pattern hiding.

[0024] Secondly, embodiments of this application provide a searchable encrypted co-occurrence pattern hiding system that supports dynamic updates, comprising: one or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, and the one or more processors invoking the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation thereof. One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By using a differentiated replica allocation mechanism based on comprehensive popularity indicators, queries are divided into hot buckets, warm buckets, and cold buckets, and different numbers of data replicas are created. Combined with a dynamic replica selection function, the same query accesses different replicas at different times, which effectively breaks the fixed pattern of query access. This makes it impossible for attackers to identify the co-occurrence relationship between queries through long-term observation, and fundamentally solves the security risk of co-occurrence pattern leakage in searchable encryption schemes. 2. By using a dual-layer storage structure to temporarily store new operation logs in the buffer layer, and with a periodic shuffling and reconstruction mechanism, the problem of triggering global index reconstruction with each data update is avoided. At the same time, a re-encryption strategy is used during the shuffling process to completely sever the correlation between the old and new ciphertexts, thus maintaining forward and backward security while ensuring the efficiency of dynamic updates. 3. By adopting an adaptive hot bucket adjustment strategy, the system performs bucket upgrade or downgrade processing on queries based on changes in query popularity within the current period. This allows replica allocation to dynamically adapt to the evolution of actual access patterns, ensuring that high-frequency sensitive queries receive sufficient security protection while avoiding low-frequency queries from consuming too many storage resources, thus achieving a dynamic balance between security and storage efficiency. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a searchable encrypted co-occurrence pattern hiding method that supports dynamic updates, as described in an embodiment of this application. Figure 2 This is a schematic diagram of a physical device structure of a searchable encrypted co-occurrence pattern hiding system that supports dynamic updates, as described in an embodiment of this application. Detailed Implementation

[0026] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0028] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0029] In the field of information security technology, with the rapid development of cloud computing and data outsourcing services, more and more users are choosing to encrypt sensitive data and store it on cloud servers in order to reduce local storage costs and improve data access efficiency.

[0030] In related technologies, although searchable encryption technology allows users to perform keyword searches without decrypting data, during multiple queries, the server can infer the co-occurrence relationship between multiple queries by observing the data access locations of the queries, thereby revealing the query co-occurrence pattern and significantly weakening the privacy protection capability. In addition, most existing solutions are designed for static scenarios, have insufficient support for dynamic data update operations, and have large copy management overhead.

[0031] This application is primarily applied to cloud storage encrypted retrieval scenarios, including outsourced medical data storage and cloud-hosted financial data. In these scenarios, users need to achieve efficient retrieval while ensuring data confidentiality and preventing servers from inferring sensitive information through query pattern analysis. To address these technical problems, this application provides a dynamically updated, searchable, encrypted co-occurrence pattern hiding method. An embodiment is described below, combined with… Figure 1 This application describes a method for hiding a searchable encrypted co-occurrence pattern that supports dynamic updates.

[0032] The following describes the process of the method provided in this implementation. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating a searchable encrypted co-occurrence pattern hiding method that supports dynamic updates, as described in an embodiment of this application.

[0033] S101. Calculate the comprehensive popularity index based on the historical query frequency and sensitivity level of each query. Divide each query into different popularity buckets based on the comprehensive popularity index, and create a differentiated number of data replicas for the queries in different popularity buckets to obtain a multi-replica encrypted database.

[0034] Among them, the comprehensive popularity index refers to the quantitative score value obtained by comprehensively considering the query frequency and sensitivity; the popularity bucket refers to the query classification container divided according to the comprehensive popularity index, including hot bucket, warm bucket and cold bucket; data copy refers to multiple encrypted copies of the data corresponding to the same query stored on the server.

[0035] Specifically, the system first obtains the historical query frequency of each query and normalizes it to obtain a normalized frequency value. Then, it determines the sensitivity level of each query according to preset sensitivity level evaluation rules. Next, it calculates the comprehensive popularity index of each query based on the normalized frequency value and sensitivity level, and classifies the queries into hot buckets, warm buckets, or cold buckets according to preset thresholds. Finally, it creates a first number of replicas for hot bucket queries, a second number of replicas for warm bucket queries, and a third number of replicas for cold bucket queries, generating a multi-replica encrypted database. For example, in a specific embodiment, hot bucket queries create 3 replicas, warm bucket queries create 2 replicas, and cold bucket queries create 1 replica.

[0036] It should be noted that the comprehensive popularity index is calculated using a weighted summation method. Let the historical query frequency of query q be freq(q), and the sensitivity level be level(q). Then, the formula for calculating the comprehensive popularity index heat_score(q) is: heat_score(q) = α·norm(freq(q)) + β·level_norm(q), where level_norm(q) = level(q) / L_max, L_max is the highest value of the sensitivity level (L_max = 3 in this embodiment), norm(freq(q)) is the normalized value of the query frequency, with a value range of [0,1]; level(q) is the sensitivity level, with a value of 1, 2, or 3, representing low sensitivity, medium sensitivity, and high sensitivity, respectively; α is the frequency weight coefficient; β is the sensitivity level weight coefficient, and the sum of α and β is 1.

[0037] The bucketing rules are as follows: when heat_score(q) is greater than or equal to the first threshold, query q is assigned to the hot bucket; when heat_score(q) is greater than or equal to the second threshold but less than the first threshold, query q is assigned to the warm bucket; and when heat_score(q) is less than the second threshold, query q is assigned to the cold bucket. Through this bucketing mechanism, the system can adaptively adjust the number of replicas based on the actual access characteristics of the query, avoiding storage waste caused by creating the same number of replicas for all queries.

[0038] For example, in a simulation scenario, as a specific numerical example, suppose a medical data system has a query q1 with a historical query frequency of 50 times per day and a maximum query frequency of 100 times per day. Then, the normalized frequency value norm(freq(q1)) = 50 / 100 = 0.5. This query involves patient diagnosis information, with a sensitivity level level(q1) = 3. Normalizing the sensitivity level to the highest level of 3 yields a normalized sensitivity level level_norm(q1) = 3 / 3 = 1.0. Let the frequency weighting coefficient α = 0.6, the sensitivity level weighting coefficient β = 0.4 (α + β = 1), the first threshold be 0.7, and the second threshold be 0.3. The comprehensive heat score (q1) = α·norm(freq(q1)) + β·level_norm(q1) = 0.6 × 0.5 + 0.4 × 1.0 = 0.3 + 0.4 = 0.7, which reaches the first threshold. Therefore, query q1 is assigned to the hot bucket, and the system creates 3 data replicas for it.

[0039] Furthermore, during the initial construction phase of the multi-replica encrypted database, the client randomly assigns a primary physical location to each replica of each query and initializes the mapping relationship between logical indexes and physical locations in PosMap.

[0040] S102. Based on the received data operation entries and operation types, the encrypted operation logs are stored in the corresponding partition of the buffer layer in the two-layer storage structure. The main layer is used to store the shuffled historical operation logs, and the buffer layer is used to store the new operation logs in the current period, thus obtaining the updated encrypted database.

[0041] Among them, the two-layer storage structure refers to a hierarchical data storage architecture that includes a main layer and a buffer layer; the operation log refers to an encrypted record that records the data operation type, operation object, and operation content; the ADD partition and the DELETE partition refer to independent storage areas in the buffer layer used to store data addition operations and data deletion operations, respectively.

[0042] Specifically, the system first parses the received data operation entries to identify whether the operation type is an add or delete operation; then it encrypts the operation entries using an encryption key to generate an encrypted operation log; next, it determines the target partition based on the operation type: if it is an add operation, it points to the ADD partition, and if it is a delete operation, it points to the DELETE partition; finally, it writes the encrypted operation log to the corresponding partition of the buffer layer to complete the data update.

[0043] For each new entry in the buffer layer, the system synchronously generates k replica logs based on the number of replicas k in the hot bucket of the query to which the entry belongs, corresponding to logical replica indices 1 to k respectively. The client allocates an independent physical location for each replica log in the buffer layer and establishes a mapping entry in PosMap from the logical replica index to the physical location in the buffer layer. During query execution, the client calculates the logical replica index for this query using f(q, counter), then obtains the physical location of this logical index in both the main layer and the buffer layer using PosMap, and submits both along with the trapdoor to the server for retrieval and merging. Specifically, the k replica logs generated for ADD operation entries are all written to the ADD partition in the buffer layer; the k replica logs generated for DELETE operation entries are all written to the DELETE partition in the buffer layer; the buffer layer physical location entries in PosMap are recorded separately according to their respective partitions.

[0044] It should be noted that since the buffer layer fills all k logical replica positions during writing, the physical location of the replicas in the buffer layer is determined only by the random allocation at the time of writing, and is independent of the query counter. This avoids the problem of inconsistent access positions between the main layer and the buffer layer due to counter drift, and ensures that both layers can hit the replica data corresponding to the same logical index under any value of f(q, counter).

[0045] It should be noted that generating k replica logs for each new entry in the buffer layer will result in k times the buffer layer storage overhead. However, since the buffer layer only carries new operation logs within a single retrieval cycle (which are shuffled and merged into the main layer at the end of the cycle and then cleared), and the preset threshold is usually controlled within the range of [1000, 10000], the steady-state size of the buffer layer is much smaller than that of the main layer. At the same time, this design makes the main layer and the buffer layer completely consistent in their replica access patterns, so the server cannot infer the query identity by comparing the differences in access behavior between the two layers. The security benefits significantly outweigh the storage overhead costs.

[0046] S103. Determine the hot bucket to which the query belongs based on the query request. Calculate the replica index to be accessed this time based on the replica selection function and query counter corresponding to the hot bucket. Perform the retrieval and merge the results in the main layer and the buffer layer respectively, based on the replica index, to obtain the retrieval results.

[0047] The replica selection function is a mapping function that determines which replica should be accessed in this query based on the query identifier and the query counter; the query counter is a counter variable that records the number of times the query is executed in the current period; and the replica index is the sequence number that identifies the position of a specific replica in the multi-replica set.

[0048] Specifically, the system first generates a query trapdoor based on the query request and determines the hot bucket to which the query belongs; then it obtains the replica selection function and the current query counter value corresponding to the hot bucket; next, it calculates the replica index to be accessed based on the replica selection function; finally, it retrieves the corresponding replica data in the primary layer based on the replica index, and at the same time retrieves matching entries in the ADD and DELETE partitions of the buffer layer, merges the results of the primary layer and the results of the buffer layer, and returns them to the client.

[0049] In some embodiments, the system employs a hash-based replica index calculation method. Specifically, the system performs a hash operation based on the query identifier, the current query counter, and the client's secret factor to obtain a hash value. The replica index is then calculated by taking the hash value modulo the replica count of the bucket to which the query belongs and incrementing it by one. The replica index is calculated by the client based on `secret_seed`, converted into a physical location in the main and buffer layers via `PosMap`, and then submitted to the server along with the query trapdoor. Since both `secret_seed` and `PosMap` are invisible to the server, the server cannot predict the replica index for subsequent queries, nor can it deduce the query identity from the physical location.

[0050] Hash operation refers to a cryptographic one-way function operation that maps an input of arbitrary length to an output of fixed length.

[0051] Specifically, the system first concatenates the query identifier q, the current query counter counter, and the client secret factor secret_seed to form a concatenation string; then it performs a cryptographic hash function operation on the concatenation string to obtain a hash value of fixed length; next, it converts the hash value into an integer and performs a modulo operation on the number of replicas k; finally, it increments the modulo result by one to obtain the replica index, which has a value range of [1, k].

[0052] It should be noted that the technical advantages of using hash functions to calculate replica indexes are as follows: the one-way nature of hash functions ensures that the server cannot deduce the query counter or secret factor from the replica index; the uniform distribution characteristic of hash functions ensures that the probability of each replica being accessed tends to be equal; and the introduction of query counters ensures that multiple consecutive executions of the same query will be mapped to different replicas, thereby breaking the regularity of access locations.

[0053] It's important to note that the replica selection function is the core mechanism for hiding query co-occurrence patterns. Let the query be q, the current query counter be counter, the client secret factor be secret_seed, and the number of replicas in the bucket to which the query belongs be k. Then, the formula for calculating the replica index is: f(q, counter) = (H(q || counter || secret_seed)mod k) + 1. Here, H is the cryptographic hash function; || represents the string concatenation operation; mod represents the modulo operation; and k is the number of replicas corresponding to the hot bucket to which the query belongs. This function has the following characteristics: determinism, meaning that the same input parameters produce the same replica index, ensuring consistency between the client and server calculations; uniformity, meaning that in the long run, the number of times each replica is accessed tends to be balanced; and unpredictability, meaning that the server cannot predict which replica the next query will access without knowing secret_seed. Through this mechanism, even if the server observes multiple queries for the same keyword, because the replica locations accessed each time are different, the server cannot establish a relationship between the queries, thus achieving the hiding of query co-occurrence patterns.

[0054] For example, in a simulation scenario, as a specific numerical example, assume query q belongs to the hot bucket, the number of replicas k=3, the current query counter counter=5, and the client secret factor secret_seed="abc123". The system calculates the connection string as "q||5||abc123", performs a SHA-256 hash operation on this string to obtain the hash value. Assuming the hash value is converted to an integer 1234567890, then the replica index f(q,5)=(1234567890 mod 3)+1=(0)+1=1, so this query accesses the first replica. When counter increments to 6, the hash value changes. Assuming the new hash value corresponds to the integer 1234567891, then f(q,6)=(1234567891 mod 3)+1=(1)+1=2, so this query accesses the second replica. In this way, multiple consecutive executions of the same query will rotate and access different replicas.

[0055] In some embodiments, the system employs an adaptive noise injection mechanism based on information entropy to defend against frequency analysis attacks. Specifically, the system calculates the inter-bucket discrimination index based on the actual access frequency distribution of each hot bucket in the current period. When the inter-bucket discrimination index exceeds a preset security threshold, a noise query sequence is generated based on the frequency difference and injected into the replica position corresponding to the low-frequency bucket, so that the access frequency distribution of each hot bucket tends to be balanced.

[0056] Among them, the inter-bucket discrimination index refers to the statistical measure of the degree of difference in access frequency distribution between buckets with different popularity; noisy query refers to the virtual query operation generated by the client that does not carry an actual search intent but accesses the real copy location; frequency difference refers to the difference in access frequency between the target bucket and the benchmark bucket.

[0057] Specifically, the system first counts the cumulative number of visits to each hot bucket at the end of each retrieval cycle and calculates the access frequency ratio of each bucket. Then, it calculates the inter-bucket discrimination index based on the access frequency ratio of each bucket. Next, it compares the inter-bucket discrimination index with a preset safety threshold. If the threshold is exceeded, a noise injection process is triggered. Finally, based on the frequency difference between hot buckets and warm buckets, and between warm buckets and cold buckets, the client generates a corresponding number of noise queries. The replica index of the noise queries is calculated according to the replica selection function. The server executes the replica access operation corresponding to the noise query but does not return actual data. It can be understood that when the client generates noise queries, it also converts the logical replica index into a physical location through PosMap and submits it to the server, so that the access behavior of the noise queries is completely consistent with the real query from the server's perspective.

[0058] It should be noted that the inter-bucket discrimination index is calculated using an information entropy-based measurement method. Let the number of visits to the hot bucket, warm bucket, and cold bucket in the current period be N_hot, N_warm, and N_cold, respectively, and the total number of visits be N_total = N_hot + N_warm + N_cold. Then, the access frequency proportions of each bucket are p_hot = N_hot / N_total, p_warm = N_warm / N_total, and p_cold = N_cold / N_total, respectively. Ideally, if an attacker cannot distinguish between buckets, the access frequency of each bucket should tend to be evenly distributed, i.e., p_ideal = 1 / 3. The formula for calculating the inter-bucket discrimination index D_bucket is: D_bucket = Σ_{i∈{hot,warm,cold}} |p_i - p_ideal| / p_ideal. Where |·| represents the absolute value operation. When D_bucket=0, it means that the access frequency of each bucket is completely uniform, and attackers cannot distinguish the bucket affiliation through frequency analysis; when the value of D_bucket is larger, it means that the access frequency of each bucket is more significantly different, and attackers can more easily infer the popularity of the bucket through statistical analysis.

[0059] It should be noted that the calculation of the number of noise queries follows the frequency balance principle. Let the preset safety threshold be D_threshold. When D_bucket > D_threshold, the system needs to inject noise queries into the low-frequency bucket to reduce the distinguishability between buckets. Let the bucket with the highest access frequency in the current period be the reference bucket, and its access count be N_base. Then, for the bucket with an access count of N_i, the calculation formula for the number of noise queries noise_i to be injected is: noise_i = max(0, ⌈γ·(N_base - N_i)⌉). Here, γ is the noise injection coefficient, and its value range is (0, 1], which is used to control the aggressiveness of noise injection; ⌈·⌉ represents the ceiling operation. The larger the value of γ, the more noise queries are injected, the faster the distinguishability between buckets decreases, but the communication overhead also increases accordingly.

[0060] Exemplarily, in a simulation scenario, as a specific numerical example, assume that in a certain retrieval period, the cumulative access count of the hot bucket N_hot = 600, the cumulative access count of the warm bucket N_warm = 300, and the cumulative access count of the cold bucket N_cold = 100. Then the total access count N_total = 1000. The access frequency ratios of each bucket are p_hot = 0.6, p_warm = 0.3, p_cold = 0.1, and the ideal uniform distribution p_ideal = 1 / 3 ≈ 0.333. The bucket distinguishability index D_bucket = |0.6 - 0.333| / 0.333 + |0.3 - 0.333| / 0.333 + |0.1 - 0.333| / 0.333 = 0.801 + 0.099 + 0.700 = 1.600. Let the preset safety threshold D_threshold = 0.5 and the noise injection coefficient γ = 0.3. Since D_bucket = 1.600 > D_threshold = 0.5, the noise injection process is triggered. Taking the hot bucket as the reference bucket, N_base = 600. Then the number of noise queries to be injected into the warm bucket noise_warm = ⌈0.3×(600 - 300)⌉ = ⌈90⌉ = 90, and the number of noise queries to be injected into the cold bucket noise_cold = ⌈0.3×(600 - 100)⌉ = ⌈150⌉ = 150. After injection, the equivalent access count of the warm bucket becomes 390, and the equivalent access count of the cold bucket becomes 250. The frequency distribution differences between each bucket are significantly reduced, and the bucket distinguishability index is reduced to D_bucket' = 0.487 < D_threshold, meeting the safety requirements.

[0061] Because it employs an information entropy-based method for calculating the inter-bucket discrimination index and an adaptive noise query injection mechanism, even if the server statistically analyzes the access frequency distribution of each replica location over a long period, it cannot infer the hot bucket to which the query belongs through frequency analysis. Consequently, it cannot use the hot bucket attribution information to narrow down the inference range of query co-occurrence relationships. This effectively resists side-channel attacks based on access frequency statistics and further enhances the security of query co-occurrence pattern hiding.

[0062] S104. When the query counter reaches the preset threshold, the operation logs in the main layer and the buffer layer are shuffled according to the random permutation sequence to disrupt the storage order. The main layer is rebuilt and the buffer layer is cleared based on the shuffling result. The query is upgraded or downgraded according to the heat change in the current period to obtain the rebuilt encrypted database.

[0063] Among these, random permutation sequence refers to a random arrangement generated by the client to determine the target position of data rearrangement; shuffling operation refers to the operation of rearranging data storage locations to hide position mapping relationships while maintaining data confidentiality; bucket promotion and bucket demotion refer to the operation of adjusting a query from the current bucket to a higher or lower popularity bucket based on changes in query popularity. It is understandable that... The system executes this step after the query counter accumulates to a preset threshold. This step is used to sever the data location association before and after reconstruction and to achieve replica reuse. The preset threshold can be determined based on a combination of security requirements and performance overhead, for example, a value range of [1000, 10000].

[0064] Specifically, the system first checks if the query counter has reached a preset threshold; if so, it triggers a reconstruction process. Then, the client generates a random permutation sequence, and the server merges the ADD and DELETE partitions in the main layer and the buffer layer, respectively. Next, the client and server collaborate to shuffle the merged operation logs according to the random permutation sequence and the shuffling key, re-encrypting each operation log and writing it to a new target location. Finally, the main layer is reconstructed based on the shuffled data, the buffer layer is cleared, the query counter is set to zero, and the popularity index is recalculated based on the actual access frequency of each query in the current period. Queries with increasing popularity are promoted to higher buckets, and queries with decreasing popularity are demoted to lower buckets.

[0065] In some embodiments, the system adopts a specific shuffling implementation method, that is, the system determines the target position of each operation log according to the random permutation sequence generated by the client; after re-encrypting each operation log according to the shuffling key, it writes it to the target position to obtain the shuffled operation log.

[0066] Re-encryption refers to the operation of encrypting the data a second time using new encryption parameters to update the ciphertext form.

[0067] Specifically, the system first generates a random permutation sequence covering all operation log positions by the client; then it iterates through each operation log and obtains its corresponding target storage position from the permutation sequence; next, it uses the shuffling key to re-encrypt the operation log to generate a new ciphertext form; finally, it writes the re-encrypted operation log to the target position to complete the position rearrangement.

[0068] It should be noted that the security of the shuffling operation relies on the following mechanisms: the random permutation sequence is generated locally by the client, and the server cannot know the specific permutation rules; the re-encryption operation updates the ciphertext form, making it impossible for the server to identify the correspondence of the same data before and after the shuffling through ciphertext comparison; the shuffling key is secretly held by the client, and the server cannot decrypt the operation log content. Through the combination of the above mechanisms, even if the server records all data positions before and after the shuffling, it cannot establish a position mapping relationship, thereby effectively severing the association of access patterns across cycles.

[0069] It should be noted that the specific implementation process of the shuffling operation is as follows: Let the set of operation logs to be shuffled be LogEntries, the random permutation sequence be PermSeq, and the shuffling key be ShuffleKey. The system iterates through each operation log in LogEntries. For the i-th log, it first obtains its target position target_idx = PermSeq[i] from PermSeq; then, it re-encrypts the log using ShuffleKey to generate new ciphertext; finally, it writes the re-encrypted log to the target position target_idx. Since the server does not know the generation rules of PermSeq and the specific value of ShuffleKey, it cannot infer the position before shuffling from the data position after shuffling, thus severing the positional correlation before and after reconstruction.

[0070] To support replica location after shuffling, the client maintains a local location mapping table, PosMap, recording the current physical location of each replica in the primary layer for each query q. After each shuffle, the client synchronously updates PosMap based on the current random permutation sequence, PermSeq. During query execution, the client first calculates the logical replica index using f(q,counter), then converts it to a primary layer physical location using PosMap, and submits it to the server via a trapdoor. PosMap is held only by the client; the server has no way of knowing the correspondence between physical locations and queries. After shuffling, the client clears all buffer layer physical location entries in PosMap and rewrites all primary layer physical location entries based on the current random permutation sequence, PermSeq; then, it sets the query counter to zero and starts a new retrieval cycle.

[0071] Since the physical location of the buffer layer is randomly assigned by the client during writing and isolated by PosMap, although the server can observe the writing and access times of the buffer layer, it cannot associate the physical location of the buffer layer with specific query keywords. Combined with the periodic shuffling mechanism of the main layer, all physical locations of the buffer layer are re-allocated when it is merged into the main layer, further severing the potential association between the writing sequence and the access location.

[0072] The rules for bucket upgrades and downgrades are as follows: The system recalculates the overall popularity index based on the actual number of queries within the current period. If the updated popularity index exceeds the upper threshold of the current bucket, the query is upgraded to a higher popularity bucket and its replica count is increased; if the updated popularity index is lower than the lower threshold of the current bucket, the query is downgraded to a lower popularity bucket and its replica count is reduced. Through this adaptive adjustment mechanism, the system can optimize replica configuration based on dynamic changes in query access patterns. During a bucket upgrade, the client derives encrypted data for the new replica from its locally held plaintext index / key (without requesting decryption from the server), generates a new replica log based on the target bucket's replica count, randomly assigns a primary physical location to each new replica, writes the replica log to the corresponding physical location, and establishes a mapping entry from the new logical replica index to the physical location in PosMap. During a bucket downgrade, the client generates a replica deletion command containing the location identifier of the replica to be deleted. The server deletes the replica log at the corresponding location according to the command, and the client synchronously deletes the corresponding logical-physical mapping entry for the replica in PosMap.

[0073] In some embodiments, the system performs a cache check before performing a replica retrieval. That is, the system performs a hit check in the cache based on the query trapdoor. If a hit occurs and the timeout does not occur, the cached result is returned directly and a virtual replica retrieval is performed to maintain operational consistency. If a hit does not occur, the replica index calculation continues.

[0074] Among them, cache hit check refers to the operation of checking whether there are valid historical query results in the cache; virtual copy retrieval refers to the simulated retrieval operation performed when the cache is hit, without obtaining the actual data but maintaining the same access mode.

[0075] Specifically, the system first searches for a matching entry in the server cache table based on the query trap; then it checks whether the difference between the timestamp of the matching entry and the current time exceeds the preset lifespan; if a match is found and the timeout has not occurred, the system directly retrieves the query result from the cache and performs a virtual copy retrieval operation to maintain consistent behavior; finally, if a match is not found or the timeout has occurred, the expired cache entry is deleted and the normal copy index calculation and retrieval process continues.

[0076] In the above embodiments, due to the adoption of a query bucketing mechanism based on comprehensive popularity indicators, a differentiated replica creation strategy, and a replica rotation selection mechanism based on hash functions, the replica location accessed in each query is unpredictable and evenly distributed. This effectively solves the privacy leakage problem in searchable encryption where the server infers the query co-occurrence pattern by observing the query access location. At the same time, due to the adoption of a two-layer storage structure including a main layer and a buffer layer, as well as a shuffling-based periodic reconstruction mechanism, the system can support dynamic data updates while severing the positional association before and after reconstruction. This achieves a searchable encryption co-occurrence pattern hiding scheme that balances security, practicality, and storage efficiency.

[0077] like Figure 2 As shown in the illustration, this application also provides a searchable encrypted co-occurrence pattern hiding system that supports dynamic updates, including a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements steps S101 to S104 in the above method embodiments. The system further includes an input interface for receiving query requests and data operation entries, an output interface for returning retrieval results, a storage portion for storing a multi-copy encrypted database and operation logs, and a network interface for communicating with clients.

[0078] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the system described in the above embodiments; or it may exist independently and not assembled into the system. The storage medium carries one or more computer programs that, when executed by a processor of the system, cause the system to implement the methods provided in the above embodiments.

[0079] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0080] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

Claims

1. A method for hiding a dynamically updated, searchable, encrypted co-occurrence pattern, characterized in that, The method includes: A comprehensive popularity index is calculated based on the historical query frequency and sensitivity level of each query. Based on the comprehensive popularity index, each query is divided into different popularity buckets, and a different number of data replicas are created for the queries in different popularity buckets to obtain a multi-replica encrypted database. The different popularity buckets include hot buckets, warm buckets, and cold buckets. Based on the received data operation entries and operation types, the encrypted operation logs are stored in the corresponding partition of the buffer layer in the two-layer storage structure. The main layer is used to store the shuffled historical operation logs, and the buffer layer is used to store the new operation logs in the current period, resulting in the updated encrypted database. Based on the query request, determine the hot bucket to which the query belongs. Calculate the replica index to be accessed this time based on the replica selection function and query counter corresponding to the hot bucket. Perform the retrieval and merge the results in the main layer and buffer layer respectively according to the replica index to obtain the retrieval results. When the query counter reaches a preset threshold, the operation logs in the main layer and the buffer layer are shuffled according to the random permutation sequence to disrupt the storage order. The main layer is reconstructed based on the shuffle result and the buffer layer is cleared. The query is upgraded or downgraded according to the heat change in the current period to obtain the reconstructed encrypted database.

2. The method according to claim 1, characterized in that, The calculation of the comprehensive popularity index based on the historical query frequency and sensitivity level of each query specifically includes: The historical query frequency of each query is normalized to obtain the normalized frequency value; The sensitivity level is normalized to obtain a normalized sensitivity level. Based on the normalized frequency value and the normalized sensitivity level, a comprehensive heat index is calculated using a preset weighted summation formula. Based on the comparison results between the comprehensive popularity index and the preset threshold, the query is divided into a hot bucket, a warm bucket, or a cold bucket.

3. The method according to claim 1, characterized in that, The replica index to be accessed this time is calculated based on the replica selection function and query counter corresponding to the hot bucket, specifically including: The client performs a hash operation based on the query identifier, the current query counter, and the client's secret factor to obtain the hash value; The replica index is obtained by taking the hash value modulo the number of replicas in the query's hot bucket and adding one.

4. The method according to claim 1, characterized in that, Before performing the retrieval and merging in the main layer and buffer layer respectively according to the replica index, the method further includes: Based on the query trapdoor, a hit check is performed in the cache. If a hit is found and the timeout is not exceeded, the cached result is returned directly and a virtual copy retrieval is performed to maintain operational consistency. If a miss is found, the copy index calculation continues.

5. The method according to claim 1, characterized in that, The step of shuffling the operation logs in the main layer and the buffer layer according to the random permutation sequence specifically includes: The target location of each operation log is determined based on the random permutation sequence generated by the client. After re-encrypting each operation log according to the shuffling key, the log is written to the target location to obtain the shuffled operation log.

6. The method according to claim 1, characterized in that, The buffer layer includes an ADD partition and a DELETE partition, which are used to store data addition operation logs and data deletion operation logs, respectively.

7. The method according to claim 1, characterized in that, The step of storing the encrypted operation log to the corresponding partition of the buffer layer in the dual-layer storage structure specifically includes: For each newly added operation log, a replica log is generated synchronously based on the number of replicas in the hot bucket to which the query belongs; The client randomly assigns an independent physical location to each replica log in the buffer layer and establishes a mapping entry from the logical replica index to the physical location; The replica logs for add operations are written to the ADD partition, and the replica logs for delete operations are written to the DELETE partition; the physical location of replicas in the buffer layer is independent of the query counter.

8. The method according to claim 1, characterized in that, The process of adjusting the bucket size based on changes in popularity within the current period specifically includes: When upgrading a bucket, the client derives the encrypted data of the new replica from the plaintext index or key held locally, generates a new replica log according to the number of replicas in the target bucket, randomly assigns the physical location of the new replica to the primary layer and establishes a mapping entry. When the bucket is downgraded, the client generates a deletion command containing the location identifier of the replica to be deleted. The server deletes the corresponding replica log according to the deletion command, and the client synchronously deletes the corresponding mapping entry.

9. The method according to claim 1, characterized in that, The method also includes: at the end of each retrieval period, calculating the inter-bucket discrimination index based on the access frequency of each hot bucket, and when it exceeds a preset safety threshold, generating a noisy query by the client and submitting it to the server by the replica selection function.

10. A searchable encrypted co-occurrence pattern hiding system that supports dynamic updates, characterized in that, include: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the system to perform the method as described in any one of claims 1-9.

Images