Method and apparatus for searchable encryption index with low frequency result inline and secondary bucket fallback

Abstract

The application provides a searchable encryption index method and device with low-frequency result interlinking and secondary bucket rollback, which comprises the following steps: obtaining keywords and a random record identifier of a record to be indexed; deriving an index internal tag, a counting bucket row key and a bucket encryption key material based on the keywords and a field-level search key; reading a corresponding counting bucket based on the counting bucket row key, and searching for a counting record matched with the index internal tag; adaptively writing the random record identifier into an interlinking identifier slot and an identifier set bucket in an identifier set bucket support table; and updating the counting record according to the writing result, and re-encrypting and writing back the updated counting bucket to the counting bucket support table. In the application, the defects of current low-frequency keywords needing additional access to a secondary identifier set table, increasing database round trips, the number of auxiliary table rows and writing cost are overcome.

Description

Technical Field

[0001] This invention relates to the field of database security and searchable encryption technology, and in particular to a searchable encrypted indexing method and apparatus with low-frequency result inlining and secondary bucket rollback. Background Technology

[0002] In encrypted database storage scenarios, business data is typically stored in encrypted form. To support keyword retrieval without exposing the plaintext of sensitive fields, the system needs to create secure indexes for the protected fields. Symmetric searchable encryption technology allows a trusted execution end to generate internal index tags and bucket row keys based on keywords, and then the database storage end performs retrieval assistance operations on the encrypted support table.

[0003] Traditional dynamic searchable encryption schemes typically store keyword count status and the corresponding record identifier set separately. For each keyword, the count structure records the insertion count or logical address, while the identifier set structure stores the identifier of the actual matching record. This structure is suitable for high-frequency keywords, but it has significant problems in database engineering implementation.

[0004] In actual business scenarios, there are generally two typical high-frequency keyword distribution scenarios: The first is a high-frequency scenario with massive data under a limited set of keywords, such as keywords based on the first three digits of a mobile phone number. The keyword itself has a fixed range of values ​​and a limited number, but the business data volume corresponding to each number segment can reach tens of billions. This is a typical high-frequency retrieval scenario with few keywords, high hit rate, and large data volume. The second is a skewed high-frequency scenario with uneven keyword distribution, such as keywords based on surnames. Due to the characteristics of business data distribution, a small number of common surnames occupy the vast majority of data samples, showing an extremely unbalanced distribution characteristic with a very small number of keywords hitting frequently and the vast majority of niche surnames hitting infrequently.

[0005] Many keywords are low-frequency keywords in actual business data, with very few matching records. If each low-frequency keyword still requires additional access to the secondary identifier set table, a single query will need to read at least two types of structures: the count support table and the identifier set support table, increasing database round trips, the number of auxiliary table rows, and write costs.

[0006] Therefore, a dynamic, searchable, and encrypted index structure is needed for databases, enabling low-frequency keywords to directly complete random record identification and query within the counting structure, and smoothly switching to a secondary identifier set structure after the number of results exceeds the inline capacity or policy threshold, thereby balancing the efficiency of low-frequency keywords, the scalability of high-frequency keywords, the database's supported table size, and the privacy boundary of encrypted indexes. Summary of the Invention

[0007] The main objective of this invention is to provide a searchable encrypted indexing method and apparatus for inlining low-frequency results and rolling back to the secondary bucket, aiming to overcome the shortcomings of current low-frequency keywords requiring additional access to the secondary identifier set table, which increases database round trips, auxiliary table rows, and write costs.

[0008] To achieve the above objectives, this invention provides a searchable encrypted indexing method with low-frequency result inlining and secondary bucket rollback, applied to a database searchable encrypted system including a trusted execution end and a database storage end. The database storage end stores a counting bucket support table and an identifier set bucket support table. The method includes: Retrieve the keywords and corresponding random record identifiers of the records to be indexed; The trusted execution unit derives internal index tags, counter bucket row keys, and bucket encryption key materials based on the keywords and field-level search keys. The corresponding counting bucket is read based on the counting bucket row key, the counting bucket is decrypted based on the bucket encryption key material, and the counting record that matches the internal tag of the index is found; wherein, the counting record includes a counting field for the secondary identifier set structure and at least one inline identifier slot; The random record identifier is adaptively written into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table; The counting record is updated based on the writing result, and the updated counting bucket is re-encrypted and written back to the counting bucket support table. If an updated identifier set bucket exists, the updated identifier set bucket is encrypted and written back to the identifier set bucket support table.

[0009] Furthermore, the counting record also includes a version field, a record status field, an option field, and a random field; The record status field is used to identify whether the count record is valid, and the random field is used to participate in encryption randomization, concurrent update detection, or replay detection. Each slot in the inline identifier slot has a valid state and an invalid state; When the slot is in an active state, the slot stores a random record identifier; when the slot is in an invalid state, the slot stores an invalid identifier, a random fill value, or a null value encoded in a preset format.

[0010] Furthermore, the counting field only assigns a secondary logical address to the random record identifier written to the identifier collection bucket; For random record identifiers written to the inline identifier slot, the trusted execution terminal uses a method of first classifying and allocating, first reserving and then backing up, or an equivalent batch adjustment method to ensure that the counting field does not occupy secondary logical address due to random record identifiers.

[0011] Further, adaptively writing the random record identifier into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table includes: Based on the availability status of the inline identifier slot and the preset inline strategy, the random record identifier is divided into an inline write set and a secondary write set; The random record identifier in the inline write set is written into the inline identifier slot, and the inline write set does not occupy the logical address of the secondary identifier set structure; Based on the count field, a secondary logical address is assigned to the random record identifier in the secondary write set, and the random record identifier in the secondary write set is written to the identifier set bucket in the identifier set bucket support table.

[0012] Furthermore, the preset inline strategy includes at least one of the following: The existence of an available slot in the inline identifier slot is used as the writing condition; The write condition is whether the size of the results corresponding to the keyword is less than a preset threshold. Write conditions are determined by the length of the count record, the cost of accessing the secondary bucket, or the concurrent write status.

[0013] Furthermore, writing the random record identifiers from the secondary write set to the identifier set bucket in the identifier set bucket support table includes: The secondary logical address is mapped to a secondary block number and a location within the block according to the preset block capacity; Based on the secondary block number, the index internal label, and the bucket row key derived from the bucket encryption key material; Read, create, or update the corresponding identifier collection bucket based on the row key of the identifier collection bucket; Write the random record identifier in the secondary write set into the identifier set record in the identifier set bucket that corresponds to the secondary block number and the position within the block.

[0014] Furthermore, both the counting bucket support table and the identifier set bucket support table adopt a database table structure of row key and value; wherein, the row key is the encoded bucket row key, and the value is the encrypted bucket value.

[0015] Furthermore, the counting record also includes a result total field representing the total number of currently valid random record identifiers, and the method further includes a keyword search process, which includes: Based on the search keywords and field-level search keys, derive the search internal tags, search count bucket row keys, and search bucket encryption key materials; Based on the search counter bucket row key and search bucket encryption key material, read and decrypt the corresponding counter bucket to obtain the count record that matches the search internal tag; Add the random record identifier stored in the inline identifier slot that is in a valid state from the count records of the internal tag matching of the search to the search results set; Based on the total number of results field, the count field, and the number of inline random record identifiers that have been added to the search results set, determine whether there is any secondary identifier set data to be read; When there is a set of secondary identifiers to be read, the corresponding identifier bucket is read and decrypted according to the secondary logical address range, and the valid random record identifiers are added to the search results set. Output the set of search results.

[0016] Furthermore, when the number of valid random record identifiers indicated by the total number of results field has already been provided by the inline identifier slot, the keyword search process does not access the identifier collection bucket support table.

[0017] Furthermore, the counting record also includes a result total field representing the total number of currently valid random record identifiers, and the method further includes a deletion process, which includes: Locate the corresponding count record based on the keyword to be deleted or the random record identifier to be deleted; Check the inline identifier slots in the located counting records. When the random record identifier in the slot meets the deletion condition, set the corresponding inline identifier slot to an invalid state. Check the identifier set bucket corresponding to the located count record. When the random record identifier in the bucket meets the deletion condition, set the position in the corresponding block to an invalid state. Update the total number of results field in the located count record according to the deletion result, and roll back, correct or maintain the count field according to the valid record status of the tail second-level block, concurrent update status or address continuity requirements. The updated counting bucket and the updated identifier set bucket are re-encrypted and written back to the database storage.

[0018] Furthermore, in the deletion process, the valid random record identifiers in the identifier collection bucket are sorted out, the valid random record identifiers are moved forward and invalid slots are cleared, and then the sorted identifier collection bucket is encrypted.

[0019] Furthermore, the updated counting bucket and identifier set bucket are encrypted as a whole using a new encrypted random quantity, an authentication random quantity, or an equivalent randomization state during write-back, so that the database storage end cannot determine the updated inline identifier slot or block position solely based on the difference between the old and new ciphertexts of the same bucket.

[0020] Furthermore, the method is executed within a database transaction; when a concurrent write conflict occurs in the counting bucket or the identifier set bucket, the bucket does not exist, the bucket is full, the write result is incomplete, or the secondary block capacity is insufficient, the corresponding bucket is reread and a retry is performed based on the latest counting record status.

[0021] This invention also provides a searchable encrypted indexing device for low-frequency result inlining and secondary bucket rollback, applied to a database searchable encrypted system including a trusted execution end and a database storage end, wherein the database storage end stores a counting bucket support table and an identifier set bucket support table, and the device includes: The acquisition module is used to acquire the keywords of the records to be indexed and their corresponding random record identifiers; The derived module is used by the trusted execution end to derive index internal tags, counter bucket row keys, and bucket encryption key materials based on the keywords and field-level search keys; The reading module is used to read the corresponding counting bucket based on the counting bucket row key, decrypt the counting bucket based on the bucket encryption key material, and find the counting record that matches the internal tag of the index; wherein, the counting record includes a counting field for a secondary identifier set structure and at least one inline identifier slot; The writing module is used to adaptively write the random record identifier into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table; The update module is used to update the counting record according to the writing result, re-encrypt and write the updated counting bucket back to the counting bucket support table, and if there is an updated identifier set bucket, then encrypt and write the updated identifier set bucket back to the identifier set bucket support table.

[0022] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0023] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the methods described above.

[0024] This invention provides a searchable encrypted indexing method and apparatus for low-frequency result inlining and secondary bucket rollback, applicable to a database searchable encrypted system including a trusted execution end and a database storage end. The database storage end stores a counter bucket support table and an identifier set bucket support table, comprising: obtaining keywords and corresponding random record identifiers for records to be indexed; deriving index internal tags, counter bucket row keys, and bucket encryption key materials by the trusted execution end based on the keywords and field-level search keys; reading the corresponding counter bucket based on the counter bucket row key, decrypting the counter bucket based on the bucket encryption key materials, and searching for counter records matching the index internal tags; wherein, the counter record includes a counter field for a secondary identifier set structure and at least one inline identifier slot; adaptively writing the random record identifier into the inline identifier slot and the identifier set bucket in the identifier set bucket support table; updating the counter record according to the writing result; re-encrypting and writing the updated counter bucket back to the counter bucket support table; if an updated identifier set bucket exists, then encrypting and writing the updated identifier set bucket back to the identifier set bucket support table. In this invention, random record identifiers are adaptively written to the inline identifier slots and the identifier collection buckets in the identifier collection bucket support table; the count field and the inline identifier slots jointly maintain the keyword status, enabling insertion, searching, and deletion to be processed uniformly within the same structure; bucket-level overall encryption reduces the database storage end's ability to observe the modification position within the bucket. Furthermore, this overcomes the current shortcomings of low-frequency keywords requiring additional access to the secondary identifier collection table, increasing database round trips, auxiliary table rows, and write costs. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the steps of a searchable encrypted indexing method for low-frequency result inlining and secondary bucket rollback in one embodiment of the present invention; Figure 2 This is a structural block diagram of a searchable encrypted indexing device for low-frequency result inlining and secondary bucket rollback in one embodiment of the present invention; Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0026] The implementation, functional features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0028] Reference Figure 1One embodiment of the present invention provides a searchable encrypted indexing method with low-frequency result inlining and secondary bucket rollback, applied to a database searchable encrypted system including a trusted execution end and a database storage end. The database storage end stores a counting bucket support table and an identifier set bucket support table. The method includes: Step S1: Obtain the keywords and corresponding random record identifiers of the records to be indexed; Step S2: The trusted execution terminal derives the index internal tags, counter bucket row keys, and bucket encryption key materials based on the keywords and field-level search keys. Step S3: Read the corresponding counting bucket based on the counting bucket row key, decrypt the counting bucket based on the bucket encryption key material, and find the counting record that matches the internal tag of the index; wherein, the counting record includes a counting field for the secondary identifier set structure and at least one inline identifier slot; Step S4: Adaptively write the random record identifier into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table; Step S5: Update the counting record according to the writing result, re-encrypt and write the updated counting bucket back to the counting bucket support table. If there is an updated identifier set bucket, encrypt and write the updated identifier set bucket back to the identifier set bucket support table.

[0029] In this embodiment, as described in step S1 above, in a searchable encrypted business scenario oriented towards a database, the trusted execution terminal receives encrypted business records to be added to the database from the business side, and extracts plaintext keywords from the encrypted fields configured with retrieval permissions in the records. Simultaneously, the system pre-assigns a globally unique, random record identifier without business semantics to each business record to be indexed. This identifier serves as the de-identified index primary key for the business record in the encrypted scenario, establishing a mapping relationship between keywords and the original encrypted business records, thus completing the collection of the basic raw data required for index construction. In one embodiment, the aforementioned database is a relational database.

[0030] As described in step S2 above, the trusted execution terminal derives the index internal label, the counting bucket row key, and the bucket encryption key material based on the keyword and the field-level search key. The field-level search key is a symmetric key held exclusively by the trusted execution terminal and is used for secure derivation operations on all keyword indexes under the same database field. The trusted execution terminal uses the extracted keyword and the exclusive field-level search key as dual input parameters and can generate three types of cryptographic parameters in parallel using cryptographic hashing and key derivation algorithms: first, the index internal label, used to accurately locate the current keyword's exclusive counting record within a single counting bucket, achieving isolated storage of multiple keywords within the bucket; second, the counting bucket row key, serving as the row primary key of the database counting bucket support table, used to locate the ciphertext counting bucket carrying the index state of this keyword from the database storage end; and third, the bucket encryption key material, which includes cryptographic materials such as the symmetric encryption key and message authentication key, specifically used for the decryption of subsequent counting bucket and identifier set bucket ciphertexts and the overall encryption operation after updates, ensuring that all index data within the bucket is always stored in an unparseable ciphertext form at the database storage end.

[0031] As described in step S3 above, the trusted execution terminal sends the counter bucket row key to the database storage terminal, which then reads the corresponding ciphertext bucket data from the counter bucket support table based on the row key and sends it back. The trusted execution terminal calls the bucket encryption key material to perform decryption operations on the ciphertext counter bucket, simultaneously completing ciphertext integrity and anti-tampering verification to obtain the complete plaintext data of the counter bucket. In other embodiments, during the decryption operation, additional authentication operations can be performed, mainly for authenticating data integrity, authenticity, etc.

[0032] The trusted execution end traverses all storage units within the decrypted counting bucket, retrieving counting records carrying the internal tags of the current index; if no matching record exists, a new blank counting record is created. The counting record, as the index status management unit for a single keyword, contains three core fields: the counting field specifically serves the secondary identifier set bucket structure, recording the next secondary logical address to be allocated; the total result field provides real-time statistics on the total number of valid random record identifiers under the keyword, serving as the core statistical basis for distinguishing between low-frequency / high-frequency search scales and determining whether access to the secondary bucket is necessary; and the inline identifier slot is a local storage unit reserved within the counting record, used to directly store random record identifiers corresponding to small-scale result sets without occupying secondary storage resources.

[0033] As described in step S4 above, the system autonomously determines and adapts based on the built-in storage status and policy constraints. For random record identifiers of different data volumes and business scenarios, it dynamically selects the corresponding encrypted storage carrier and autonomously completes the adaptation writing to the inline identifier slot or identifier collection bucket. This achieves hierarchical adaptive storage of single-keyword index data without the need for manual intervention to fix the storage path. It is compatible with lightweight storage of low-frequency, small-volume data and large-scale extended storage of high-frequency, excessive data, constituting the core adaptive architecture of the hierarchical searchable encrypted index of this invention.

[0034] In one specific embodiment, adaptively writing the random record identifier into the inline identifier slot and the identifier set bucket in the identifier set bucket support table includes: dividing the random record identifier into an inline write set and a secondary write set according to the availability status of the inline identifier slot and a preset inline strategy; writing the random record identifier in the inline write set into the inline identifier slot, wherein the inline write set does not occupy the logical address of the secondary identifier set structure; allocating a secondary logical address for the random record identifier in the secondary write set based on the counting field, and writing the random record identifier in the secondary write set into the identifier set bucket in the identifier set bucket support table.

[0035] Specifically, the trusted execution end traverses all inline identifier slots of the current counting record, identifies the valid / invalid status of the slots, and calculates the available slot capacity. Simultaneously, it loads the system's pre-configured inline strategy, which comprehensively determines the storage path based on multiple constraints such as available slot capacity, keyword historical matching record size threshold, database I / O access cost, and system concurrent write load. Based on available storage capacity and strategy constraints, all random record identifiers to be written are binary-divided: identifiers that can be directly stored in available slots are grouped into the inline write set; remaining identifiers exceeding slot capacity or deemed unsuitable for local storage according to the strategy are grouped into the secondary write set, realizing a dynamic distribution logic of local storage for low-frequency results and sinking excess results to the secondary bucket.

[0036] The trusted execution end iterates through each random record identifier in the inline write set, sequentially filling the invalid, idle inline identifier slots in the count record, and then switching the corresponding slots to valid storage status. For this part of locally stored identifiers, the system uses cryptographic and count correction methods such as classification before address allocation and batch address reservation followed by rollback to avoid allocating secondary logical addresses to the count field. This ensures that inline writes to the set do not consume address resources of the secondary identifier set bucket, enabling low-frequency keywords to fully store matching identifiers relying solely on the count record, eliminating read and write operations on the identifier set bucket support table, and reducing database interaction overhead.

[0037] The trusted execution terminal reads the current value of the count field in the count record and uses this value as the starting address to assign independent and continuous secondary logical addresses to the identifiers of each random record in the secondary write set. Then, according to the system's preset secondary block capacity threshold, it maps each secondary logical address to a secondary block number and an offset position within the block. Based on the secondary block number, the index internal label, and the bucket encryption key material, a unique identifier set bucket row key is derived. The trusted execution terminal sends the key to the database storage end, reads the corresponding encrypted identifier set bucket, and automatically creates a blank identifier set bucket if no matching bucket is found. After decrypting the identifier set bucket, the random record identifiers in the secondary write set are written to the storage unit within the bucket corresponding to the secondary block number and the offset position within the block, completing the secondary extended storage of excess identifiers.

[0038] As in step S5 above, the trusted execution end counts the successful write results of the inline identifier slot and the identifier bucket in the identifier bucket support table and updates the count record to ensure that the total number of records that effectively match the keyword is accurate in real time. Further, in one embodiment, based on all the secondary logical addresses that have been allocated this time, the count field value is updated to the next logical address of all allocated addresses, which serves as the address allocation benchmark for the next batch of secondary write identifiers, maintaining the continuity and order of the secondary identifier bucket address allocation.

[0039] After updating the count records and the data within the identifier buckets, the trusted execution end uses the bucket encryption key to perform a comprehensive encryption operation on the modified plaintext of the complete count bucket, generating a new ciphertext bucket with tamper-proof verification information. This ciphertext is then written back to the count bucket support table in the database storage via the count bucket row key. If a new or modified identifier bucket exists during this write operation, the same set of bucket encryption keys is used to encrypt the updated identifier bucket as a whole, generating new ciphertext, which is then written to the identifier bucket support table via the corresponding identifier bucket row key. All bucket data is persisted in ciphertext form in the database storage. The storage end can only observe the bucket row key and the ciphertext bytes, and cannot parse all plaintext sensitive index data such as keywords, random record identifiers, and count fields within the bucket, thus ensuring index privacy and security. In other embodiments, additional authentication operations can be performed during the encryption operation, primarily for verifying data integrity and authenticity.

[0040] In this embodiment, random record identifiers for low-frequency keywords or small-scale result sets are directly stored within the counting record. During a search, the results are returned simply by reading the counting bucket. When the number of results exceeds the inline capacity or policy threshold, it automatically falls back to the secondary identifier set bucket, maintaining the scalability of high-frequency keywords. The counting field, the total number of results field, and the inline identifier slot jointly maintain the keyword status, enabling insertion, searching, and deletion to be processed uniformly within the same structure. Bucket-level overall encryption reduces the database storage's ability to observe modification locations within the bucket. This overcomes the current shortcomings of requiring additional access to the secondary identifier set table for low-frequency keywords, increasing database round trips, auxiliary table rows, and write costs.

[0041] In one embodiment, the counting record further includes a version field, a record status field, an option field, and a random field; The record status field is used to identify whether the count record is valid, and the random field is used to participate in encryption randomization, concurrent update detection, or replay detection. In this embodiment, the version field is an auto-incrementing counter record used for concurrent conflict verification, index version tracking, and fault recovery. The record status field marks the entire counter record as valid or invalid, filtering out obsolete keyword indexes and isolating invalid data during retrieval. The options field stores single-keyword-specific indexing strategy parameters, which are read by the write, retrieval, and deletion processes to achieve differentiated inlining and secondary bucket management.

[0042] The random field is a high-entropy random value with three uses: participating in bucket encryption randomization, assisting in concurrent update verification, and intercepting operation replay attacks, thereby improving index privacy and security.

[0043] In one embodiment, each slot in the inline identifier slot has a valid state and an invalid state; When the slot is in an active state, the slot stores a random record identifier; when the slot is in an invalid state, the slot stores an invalid identifier, a random fill value, or a null value encoded in a preset format.

[0044] In this embodiment, the inline identifier slot is an independent storage unit inside the counting record used to directly cache the random record identifier. Each slot is uniformly defined with two mutually exclusive operating states: valid state and invalid state. The data content and business semantics carried by the two states are clearly distinguished, and they participate in the logical judgment and data reading and writing of the entire process of index writing, retrieval, and deletion.

[0045] When a slot is marked as valid, the storage unit contains a complete and valid random record identifier, indicating that there is a valid matching business record for the current keyword. During the index insertion phase, the trusted execution end first traverses all slots, selects invalid slots as the writing carrier, writes the random record identifier to be stored, and then synchronously switches the slot to a valid state. During the keyword retrieval phase, the system only extracts the random record identifiers stored in all valid slots and merges them into the result set. The data in the valid slots directly constitutes all the retrieval results for low-frequency keywords. During the index deletion phase, if the target random record identifier stored in a slot is matched, the slot will be changed from a valid state to an invalid state, and the storage space will be released for subsequent writing of new identifiers.

[0046] When a slot is marked as invalid, the unit no longer carries a valid random record identifier. To avoid the database storage end from distinguishing whether data has been deleted or identifying the location of business changes through the plaintext content of the slot, the slot will not be empty. Instead, it will be uniformly filled with one of three types of standardized placeholder data: a dedicated invalid identifier, a high-entropy random filling value, or a null value generated by a preset encoding rule.

[0047] Fill with a dedicated invalid identifier: Use a fixed code agreed upon by the system as a placeholder. The program can quickly identify that the slot is empty, which is suitable for business scenarios that require high read verification efficiency. Fill with random padding values: Use cryptographic high-entropy random data to fill the slots, so that there is no fixed distinguishing feature between the stored bytes in valid slots and invalid slots, eliminating the risk of ciphertext differential leakage and improving index privacy and security; Fill in pre-formatted encoded null values: Generate standardized empty placeholder data through unified encoding rules, which facilitates batch parsing and batch resetting of slot status, and is suitable for large-scale index maintenance scenarios.

[0048] In one embodiment, the counting field only assigns a secondary logical address to the random record identifier written to the identifier collection bucket; For random record identifiers written to the inline identifier slot, the trusted execution terminal uses a method of first classifying and allocating, first reserving and then backing up, or an equivalent batch adjustment method to ensure that the counting field does not occupy secondary logical address due to random record identifiers.

[0049] In this embodiment, the core function of the counting field is to maintain the allocation benchmark of logical addresses within the secondary identifier set bucket. Its address allocation logic has clear boundary constraints: this field only allocates dedicated secondary logical addresses for random record identifiers that are stored in the identifier set bucket. It will not occupy or consume any secondary logical address resources for random record identifiers stored in the inline identifier slot. The address resource isolation between the two types of identifiers is achieved through the batch numerical control mechanism of the trusted execution end.

[0050] When processing secondary write sets, the trusted execution unit uses the current value stored in the counter field as the first address to be allocated. It then sequentially and orderly allocates independent secondary logical addresses to each random record identifier within the set. After each identifier's address allocation is completed, the address reference is advanced. Once all secondary identifiers have been allocated, the counter field is updated to the next bit of the last allocated address, serving as the starting point for the next batch of secondary identifier allocations. This entire address allocation process only applies to data on the secondary bucket side and is a fundamental function inherently designed into the counter field.

[0051] For random record identifiers stored in the inline identifier slot, the trusted execution end isolates address consumption through any of the following equivalent batch adjustment methods to ensure that the inline identifier does not drive the increment of the counter field value or occupy the secondary address space: The classification-then-allocation method: After the trusted execution end completes the traffic division, it distinguishes between the inline write set and the secondary write set in advance; only the address allocation operation is performed on the secondary write set, and the inline write set does not enter the address allocation process at all. The value of the count field only changes with the secondary identifier write behavior and is not affected by the inline identifier write operation.

[0052] The reservation-then-rollback approach: The trusted execution end adopts a batch unified processing logic: First, it is assumed that all random record identifiers are written to the secondary bucket, and a continuous secondary logical address is temporarily reserved based on the total number of records; then, the number of identifiers belonging to the inline write set is identified, and the corresponding number of address segments are rolled back from the reserved address as a whole to offset them. Finally, only the valid address range corresponding to the secondary write set is retained, and the count field is updated only according to the actual consumed address after the offset, thus offsetting the invalid address occupation caused by the inline identifiers.

[0053] Equivalent batch adjustment method: As a general alternative to the first two methods, the trusted execution end performs batch numerical correction calculations to deduct the virtual address increment corresponding to the inline identifier before updating the count field. Finally, the count field written to the count record only reflects the actual address length consumed by the secondary identifier, thereby decoupling the inline identifier from the secondary address resources at the metadata level.

[0054] The aforementioned address isolation rules thoroughly distinguish the resource systems of inline storage and secondary bucket storage at the underlying metadata level. On the one hand, this avoids unnecessary occupation of secondary logical addresses by a small number of low-frequency identifiers, reduces the generation of empty blocks and fragmented data in secondary buckets, and reduces the waste of database storage resources. On the other hand, it ensures that the count field accurately reflects only the storage scale of the secondary bucket. In the retrieval process, the number of secondary identifiers can be quickly calculated by relying on the count field and the total number of results field, accurately determining whether it is necessary to access the identifier set bucket, and stably achieving the core technical effect of completing the retrieval of low-frequency keywords by reading only the count bucket.

[0055] In one embodiment, the preset inline strategy includes at least one of the following: The existence of an available slot in the inline identifier slot is used as the writing condition; The write condition is whether the size of the results corresponding to the keyword is less than a preset threshold. Write conditions are determined by the length of the count record, the cost of accessing the secondary bucket, or the concurrent write status.

[0056] In this embodiment, the preset inline strategy is a set of judgment rules followed by the trusted execution end when performing random record identifier distribution. Any judgment condition can be enabled individually, or multiple conditions can be superimposed for compound judgment. Its core function is to distinguish whether the random record identifier to be written should be stored in the inline identifier slot of the counting record or allocated to the secondary logical address and written to the identifier collection bucket.

[0057] The existence of available inline identifier slots is used as the write decision condition. This condition is a basic constraint on hardware storage capacity, and the decision is based on the parsed status of all inline identifier slots. The trusted execution end counts the number of slots currently in an invalid free state. If there are available free slots, the precondition for inline writing is met, and the corresponding number of random record identifiers can be added to the inline write set. If all slots are in a valid occupied state and there is no remaining storage space, inline writing will not be performed, and all identifiers to be written will be added to the secondary write set.

[0058] This decision logic is executed first in the identifier distribution process and is the basic prerequisite for all inline storage behavior. The slot write operation is only performed when this condition is met. If there are no free slots, the inline write process is skipped and all identifiers enter the secondary address allocation and secondary bucket write process.

[0059] The write decision is based on whether the size of the results corresponding to the keyword is less than a preset threshold. This condition is used to control the applicability of inline storage from the perspective of business data volume. The system pre-configures a threshold for the number of records that can be stored inline. The trusted execution end combines the total number of results in the count record with the number of newly added identifiers to be written, and calculates the total size of the overall matching records for the keyword after the write is completed. If the calculated total size is less than the preset threshold, it is determined that inline storage is suitable, and the identifiers are stored in the slots as much as possible. If the total size exceeds the threshold, it means that the keyword is no longer a low-frequency keyword. In order to avoid excessive expansion of the count record and slow down the search efficiency, the identifiers exceeding the capacity are uniformly assigned to the secondary write set.

[0060] This determination is performed in conjunction with the availability of slots during the flow division. Even if there are still a few empty slots, if the total result size exceeds the threshold after writing, the remaining identifiers will no longer occupy inline slots and will be directly sinked to the secondary identifier collection bucket.

[0061] Using record count length, secondary bucket access cost, and concurrent write status as write judgment conditions, this type of condition belongs to the comprehensive optimization judgment at the system performance and load level. The three types of indicators can participate in the rule judgment individually or in combination: Based on the length of the counting record: continuous filling of the inline identifier slot will increase the length of the plaintext data in the counting bucket, and increase the transmission and encryption / decryption time of the counting bucket; when the current length of the counting record is close to the system's set length limit, even if there are still available slots, the addition of new identifiers for inline storage will be restricted, and the data will be diverted to the secondary bucket in advance to control the data volume of a single counting record. Based on the secondary bucket access cost determination: the system quantifies the database IO round-trip overhead caused by reading and writing to the identifier collection bucket. If the latency and resource consumption of the current link accessing the secondary bucket are extremely high, then the system will prioritize using inline slots to store more identifiers and reduce the access frequency to the identifier collection bucket support table; if the secondary bucket access cost is low, then the system will appropriately reduce the amount of inline storage to balance the load on the counting bucket. Based on concurrent write status determination: When the system detects that there are multiple concurrent write conflicts in the count record corresponding to the current keyword and the overall concurrency pressure of the database is too high, it will reduce the inline write capacity, divert most of the identifiers to the secondary bucket, reduce the probability of transaction retry caused by high frequency updates of the count bucket, and improve the overall index write concurrency stability.

[0062] This comprehensive judgment serves as a flexible control rule, correcting the results of the first two basic judgments during the diversion process. It takes into account both storage capacity and data volume, as well as system operating load, and dynamically adjusts the boundary between the inline write set and the secondary write set.

[0063] In one embodiment, writing the random record identifier in the secondary write set to the identifier set bucket in the identifier set bucket support table includes: The secondary logical address is mapped to a secondary block number and a location within the block according to the preset block capacity; Based on the secondary block number, the index internal label, and the bucket row key derived from the bucket encryption key material; Read, create, or update the corresponding identifier collection bucket based on the row key of the identifier collection bucket; Write the random record identifier in the secondary write set into the identifier set record in the identifier set bucket that corresponds to the secondary block number and the position within the block.

[0064] In this embodiment, a fixed number of identifiers that a single block can hold is pre-defined, i.e., the preset block capacity, which serves as the block partitioning standard for the secondary identifier collection bucket. After the trusted execution terminal obtains the allocated single secondary logical address, it performs integer division and modulo operations on the address using the preset block capacity as the divisor. The quotient obtained from the integer division serves as the secondary block number, used to distinguish different independent storage blocks under the same keyword; the remainder obtained from the modulo operation serves as the position within the block, representing the storage offset sequence number of the current random record identifier within the corresponding secondary block. Through this mapping rule, the one-dimensional continuous secondary logical address is decomposed into two-dimensional positioning coordinates of "block number + offset within the block," dividing the massive discrete identifier data into data blocks of fixed size, reducing the data volume of a single bucket, narrowing the data range of a single encryption / decryption and transmission, reducing the single IO overhead of the database, and facilitating subsequent invalid identifier cleanup and address rollback maintenance operations within the block.

[0065] Internal index labels isolate index data for different keywords, second-level block numbers distinguish different data blocks under the same keyword, and bucket encryption key materials provide basic cryptographic derivation parameters. The trusted execution end takes these three types of data as joint input and generates a globally unique identifier set bucket row key through hash derivation operations. This row key is the primary key of the database identifier set bucket support table, which can accurately locate the ciphertext bucket carrying the current second-level block data. By using a multi-parameter joint derivation of the row key, data from different keywords and different second-level blocks is stored in row-isolated manner in the data table, avoiding mutual interference between second-level identifier data of different business keywords. At the same time, relying on the key material to participate in the derivation, it prevents external entities from reverse-engineering the plaintext information related to keywords and identifiers through the row key.

[0066] The trusted execution end sends the derived identifier set bucket row key to the database storage end to perform a query operation: if the identifier set bucket supports the existence of the ciphertext bucket data corresponding to the row key in the table, the storage end reads the ciphertext bucket and sends it back to the trusted execution end; if there is no matching row key in the data table, the trusted execution end initializes a blank plaintext identifier set bucket; for the existing ciphertext buckets that have been read, the trusted execution end uses the bucket encryption key material to complete the decryption and obtain the complete plaintext structure inside the bucket. At this point, the carrier loading of the target secondary storage block is completed, providing an operable plaintext container for writing random record identifiers.

[0067] Based on the mapped secondary block number and intra-block location, the trusted execution end locates the unique corresponding identifier set record storage unit within the decrypted identifier set bucket plaintext. It then fills this storage unit with the identifier of a single random record from the secondary write set and marks it as valid storage. In batch processing scenarios, it iterates through all identifiers in the secondary write set, completing address mapping, bucket location, and data filling one by one. After all random record identifiers to be stored are written to the corresponding coordinate storage units, the data within the identifier set bucket is synchronously updated, fully accommodating keyword matching record identifiers exceeding the inline slot capacity.

[0068] In one embodiment, both the counting bucket support table and the identifier set bucket support table adopt a database table structure of row key and value; wherein, the row key is the encoded bucket row key, and the value is the encrypted bucket value.

[0069] In this embodiment, the counting bucket support table and the identifier set bucket support table are two independent data tables deployed on the database storage side, which respectively carry the encrypted data of the counting bucket and the encrypted data of the identifier set bucket. Both adopt the database's native row key-value storage model to build the table structure. Each row in the table contains only two core fields: row key and bucket encrypted value. The underlying storage rules are completely consistent, and only the data types of the stored bucket business are different.

[0070] Both supporting tables use a storage granularity of "one row corresponds to one complete bucket": a single row record consists of two parts. The first part is the unique index primary key of that row, i.e., the encoded bucket row key; the second part is the payload data stored in that row, i.e., the complete encrypted ciphertext of the bucket (bucket value). The database builds a unique index based on the row key, enabling single-point reading and overwrite of bucket data based on a specified bucket row key. This adapts to the trusted execution end's read / write operation mode based on buckets, eliminating the need for a full table scan and reducing index access I / O overhead.

[0071] The counting bucket row key and the identifier set bucket row key, derived from the trusted execution end, belong to the original logical row key. The original row key contains original cryptographic information such as index internal tags, block numbers, and key derivation parameters. In order to adapt to the database primary key storage specification, the system will perform a unified encoding conversion on the original bucket row key to obtain the encoded bucket row key that can be stored and indexed by the data table, which serves as the primary key of the data table row.

[0072] The encoding operation serves two purposes: first, it converts the original row key, which is composed of multiple fields and is in binary format, into a string or fixed-length binary primary key format supported by the database, making it compatible with mainstream relational database index types; second, it hides the keyword association information carried in the original row key by adding salt and hashing encoding. The database storage end can only observe the encoded semantically non-semantic primary key and cannot deduce sensitive business information such as plaintext keywords and internal index tags from the row key.

[0073] Before each read / write operation of the bucket, the trusted execution end first derives the original bucket row key and then performs the encoding operation, accurately locating the corresponding row record in the support table based on the encoding result.

[0074] The bucket value corresponds to the entire plaintext of a single counting bucket or a single identifier set bucket, including counting records, inline identifier slots, secondary block identifier records, various metadata fields, status flags, and all other index-sensitive data. Due to privacy and security constraints of searchable encryption, plaintext bucket data is not directly stored in the database. The trusted execution end will use the bucket encryption key material to perform encryption operations with message authentication codes on the complete bucket plaintext to generate ciphertext data with both confidentiality and integrity verification capabilities. This ciphertext is the bucket value stored in the data table.

[0075] This storage method has two layers of security constraints: Confidentiality: The database storage does not contain the bucket encryption key material, making it impossible to decrypt the bucket value and read all sensitive plaintext such as random record identifiers, count fields, and keyword-related metadata within the bucket; Anti-tampering integrity: Encryption and synchronous generation of verification digest. When the trusted execution end reads the bucket value for decryption, it will verify the digest. If the bucket value is tampered with during storage or transmission, the verification will fail and the bucket data will be directly discarded to intercept illegal tampering attacks.

[0076] In this embodiment, a unified row key-value data table structure is adapted to the underlying database capabilities, and index data is stored in isolation at the bucket level. The encoded row key hides the index association features, and the encrypted bucket value ensures the privacy and integrity of all index plaintext. While adapting to the implementation of general database projects, it fully meets the security constraints of searchable and encrypted scenarios.

[0077] In one embodiment, the counting record further includes a result total field for representing the total number of currently valid random record identifiers, and the method further includes a keyword search process, the keyword search process including: Based on the search keywords and field-level search keys, derive the search internal tags, search count bucket row keys, and search bucket encryption key materials; Based on the search counter bucket row key and search bucket encryption key material, read and decrypt the corresponding counter bucket to obtain the count record that matches the search internal tag; Add the random record identifier stored in the inline identifier slot that is in a valid state from the count records of the internal tag matching of the search to the search results set; Based on the total number of results field, the count field, and the number of inline random record identifiers that have been added to the search results set, determine whether there is any secondary identifier set data to be read; When there is a set of secondary identifiers to be read, the corresponding identifier bucket is read and decrypted according to the secondary logical address range, and the valid random record identifiers are added to the search results set. Output the set of search results.

[0078] In this embodiment, the search process relies on a two-layer encrypted index structure of counting buckets and identifier set buckets built during the writing phase. The retrieval is completed without disclosing the plaintext of keywords to the database storage end and randomly recording the plaintext of identifiers. The entire process is executed by a trusted execution end.

[0079] After a search is initiated, the trusted execution terminal receives the keyword to be searched from the user and retrieves the field-level search key specific to the corresponding database field as the cryptographic input parameter. It reuses the key derivation algorithm consistent with the index writing phase to generate three types of search-specific cryptographic parameters in parallel. The search internal tag is used to locate the keyword-specific count record within the counting bucket, and its generation rules are completely consistent with those of the index internal tag during the writing phase. The search counting bucket row key serves as the query primary key for the counting bucket support table, used to locate the ciphertext counting bucket storing the keyword's index status. The search bucket encryption key material includes a symmetric encryption key and a message authentication factor, specifically used for decryption operations on the ciphertext of the counting bucket and identifier set bucket during this search process. This ensures that the encryption / decryption operations are consistent with the cryptographic system of the index writing process. Furthermore, the entire derivation operation is completed only within the trusted execution terminal; the keyword plaintext is not sent to the database storage.

[0080] The trusted execution unit sends the encoded search counter bucket row key to the database storage. The storage unit reads the corresponding encrypted bucket value from the counter bucket support table based on the row key and sends it back to the trusted execution unit. The trusted execution unit uses the search bucket encryption key material to decrypt the encrypted bucket and simultaneously performs an encrypted integrity check. If the check fails, it is determined that the bucket data has been tampered with, and the current search is terminated. After obtaining the complete plaintext of the counter bucket, the trusted execution unit traverses all counter records in the bucket, filters out a single target counter record carrying the current search's internal tag, and obtains all index metadata, inline identifier slots, and secondary bucket address allocation bases for that keyword. If no matching counter record is found, it means that there is no business record corresponding to that keyword in the database, and an empty search result set can be output directly, skipping all subsequent search steps.

[0081] The trusted execution end iterates through all inline identifier slots in the target count record, verifying the status marker of each slot. It only reads the data from slots with a valid status and storing real random record identifiers, filling them into the temporary search results set. Slots marked as invalid and filled with placeholder data are skipped and not included in the search results. This step prioritizes extracting locally stored identifier data, eliminating the need for database access to the identifier collection bucket's support table. For low-frequency keywords, all matching record identifiers can be directly retrieved, significantly reducing the number of database I / O interactions during the search process and lowering query latency.

[0082] The trusted execution unit reads two core metadata entries from the counting record: the total number of results field records the total number of valid random record identifiers for the keyword, and the count field records the upper limit of the allocated logical addresses for the secondary identifier set. It then calculates the difference between the total number of valid identifiers in the total results field and the number of identifiers currently retrieved from the inline slots. If the difference is zero, it means all matching identifiers are stored in the inline slots, and there is no secondary bucket data. If the difference is greater than zero, it means some random record identifiers are still stored in the identifier set bucket, and it is necessary to continue reading data from the secondary storage structure. This judgment logic relies solely on the local metadata of the counting record, eliminating the need to pre-read the secondary buckets and achieving overhead-free secondary data pre-judgment.

[0083] If secondary identifier data is determined to exist, the trusted execution unit combines the count field to determine the complete secondary logical address range, reuses the address block mapping rules from the write phase, and breaks down the continuous address range into corresponding secondary block numbers. Based on the secondary block number, internal search tags, and search bucket encryption key material, the row key of the identifier set bucket corresponding to each secondary block is derived. The trusted execution unit sequentially reads the corresponding ciphertext bucket from the identifier set bucket support table through the row key, completes decryption using the search bucket encryption key material, traverses all secondary block storage units within the bucket, extracts random record identifiers marked as valid, and appends them all to the existing search result set. The entire secondary bucket reading and parsing logic is bidirectionally matched with the storage rules during index writing, ensuring that matching record identifiers exceeding the inline slot capacity can be completely obtained.

[0084] After all inline slot identifiers and secondary bucket valid identifiers are collected, the trusted execution end performs regularization processing on the random record identifiers in the search results set, removes duplicate identifiers, and completes the result sorting; the organized identifier set is output as the search result, and the business system can use the random record identifiers to locate the corresponding encrypted business records in the database and complete the entire keyword search process.

[0085] In one embodiment, when the number of valid random record identifiers indicated by the total number of results field has already been provided by the inline identifier slot, the keyword search process does not access the identifier collection bucket support table.

[0086] In this embodiment, the total result field records the total number of valid random record identifiers corresponding to the current keyword. The inline identifier slots only store identifier data that has not been pushed down to the secondary storage. After the keyword retrieval process completes the traversal of the inline slots and extracts all valid random record identifiers, the trusted execution terminal compares and verifies the total number of identifiers read from the slots with the total number of globally valid identifiers recorded in the total result field.

[0087] If the two values ​​are exactly equal, it means that all random record identifiers corresponding to the matching business records for the keyword have been stored in the inline identifier slots within the counting record. There is no secondary identifier data written to the identifier collection bucket support table, and no additional retrieval content to be read. Under this premise, the retrieval process directly terminates the secondary data reading branch, no longer derives the identifier collection bucket row key, and no longer initiates queries or decryption operations on the identifier collection bucket support table to the database storage side. It directly aggregates the identifiers extracted from the inline slots to generate search results and outputs them.

[0088] In this embodiment, the following beneficial effects are achieved: By reducing database interaction overhead, the number of matching records for low-frequency keywords is small, and all tags can be stored in inline slots. During retrieval, the complete results can be obtained by reading the counting bucket support table in a single operation, saving network I / O and database query operations that require multiple rounds of reading the tag collection bucket, thus significantly reducing retrieval latency.

[0089] Reduce cryptographic computation costs by eliminating the need to perform ciphertext reading and decryption operations on any identifier set bucket, saving computational overhead for encryption / decryption and integrity verification at the trusted execution end, and improving the system's concurrent retrieval capacity.

[0090] The core design goal of adapting to hierarchical indexes is to optimize the retrieval performance of low-frequency keywords by setting inline identifier slots. This decision branch achieves on-demand skipping of secondary storage access through rapid metadata verification, giving full play to the lightweight retrieval advantages of the local storage structure of counting records, distinguishing the retrieval paths of low-frequency small-scale results and high-frequency large-scale results, and realizing adaptive optimization of retrieval performance.

[0091] In terms of privacy, the entire retrieval process only operates on the counting bucket support table and does not send any row key query instructions related to the collection bucket to the database storage. The storage cannot observe whether there are large-scale matching results for the keyword through the retrieval behavior, further hiding the characteristics of the business data volume and strengthening the index privacy protection capabilities.

[0092] In one embodiment, the counting record further includes a result total field for representing the total number of currently valid random record identifiers, and the method further includes a deletion process, the deletion process including: Locate the corresponding count record based on the keyword to be deleted or the random record identifier to be deleted; Check the inline identifier slots in the located counting records. When the random record identifier in the slot meets the deletion condition, set the corresponding inline identifier slot to an invalid state. Check the identifier set bucket corresponding to the located count record. When the random record identifier in the bucket meets the deletion condition, set the position in the corresponding block to an invalid state. Update the total number of results field in the located count record according to the deletion result, and roll back, correct or maintain the count field according to the valid record status of the tail second-level block, concurrent update status or address continuity requirements. The updated counting bucket and the updated identifier set bucket are re-encrypted and written back to the database storage.

[0093] In this embodiment, the deletion process is used to clear the index mapping relationship corresponding to the invalid business records. It supports two triggering methods: batch deletion based on keywords and precise single-point deletion based on random record identifiers. The entire process is completed by the trusted execution terminal under the encrypted index architecture to change the metadata and storage unit status.

[0094] The deletion operation has two types of input triggers. The trusted execution end executes differentiated positioning logic based on the input type: If the input is a keyword to be deleted, the trusted execution end reuses the field-level search key to derive the search internal tags and counting bucket row keys, reads and decrypts the corresponding counting bucket, matches the index internal tags to lock the target counting record, and realizes batch deletion of all index data under the keyword; if the input is a random record identifier to be deleted, the system pre-establishes an association mapping between the identifier and the keyword index, reversely derives the keyword, index internal tags, and counting bucket row keys to which the identifier belongs, and similarly reads and decrypts the counting bucket to locate the uniquely corresponding counting record, completing the precise deletion of a single identifier. The counting record is the core carrier for managing all inline identifiers, secondary bucket address bases, and statistical totals for a single keyword. This step completes the locking of the top-level index carrier of the deleted object, and all subsequent failure marking and metadata correction operations revolve around this counting record.

[0095] The trusted execution end traverses all inline identifier slots in the target counting record, reads the random record identifier and slot status flag stored in each slot one by one, and verifies whether the preset deletion conditions are met: in the batch deletion scenario, any identifier in the slot meets the deletion conditions; in the single-point deletion scenario, only the slot that stores data that completely matches the random record identifier to be deleted meets the deletion conditions.

[0096] For target slots that meet the deletion criteria, the system switches their status from valid to invalid and fills them with invalid identifiers, high-entropy random values, or preset coded null values ​​according to specifications, overwriting the original random record identifiers. After the slot position becomes invalid, it restores its free and reusable attribute, allowing subsequent additions of random record identifiers to be written inline, thus realizing the recycling of inline storage resources. This step only modifies the local storage unit of the count record and does not involve data access to the identifier collection bucket support table.

[0097] If the deletion scope covers the random record identifiers stored in the secondary storage, the trusted execution end determines all allocated secondary logical address ranges based on the count field of the count record, splits the address mapping rules to obtain the secondary block number, derives the row key of the corresponding identifier set bucket, and reads and decrypts each associated identifier set bucket in sequence.

[0098] The trusted execution unit traverses the storage locations corresponding to each secondary block within the bucket, comparing the random record identifiers stored within the block to see if they match the deletion conditions. For storage units that match the deletion conditions, only the location within that block is marked as invalid; the data is not directly erased, but rather its validity is distinguished solely by the status identifier. This marking method simplifies the overhead of a single deletion operation, eliminating the need for immediate reordering of data within the block, allowing the deletion process to quickly complete basic invalidation marking. Block defragmentation is an optional post-optimization step that does not block the main deletion process.

[0099] After invalidating the inline slots and secondary bucket storage units, the trusted execution terminal counts the total number of successfully invalidated random record identifiers, subtracts this number from the original value of the total result field, and updates the result field to ensure that the total result field always accurately reflects the true total number of all valid identifiers under the current keyword, providing accurate statistical basis for the secondary bucket access determination in the subsequent retrieval process.

[0100] Based on this, the system performs differential adjustments on the count field by combining three types of constraints: First, based on the valid record status of the tail level two block: if all storage units inside the tail level two block at the end of the address allocation have been marked as invalid, it means that the block has no valid identifier to carry. The count field value can be rolled back to the address start position of the previous valid block, and the idle level two logical address can be reclaimed. Second, based on the concurrent update status: if there are multiple concurrent read and write conflicts in the current count record, in order to avoid frequent address rollbacks causing metadata inconsistencies, we choose to keep the original value of the count field and suspend the address reclamation operation. Third, based on the address continuity requirement: if the deletion operation only clears the segment address and the tail block still has a valid identifier, and the address range cannot be continuously reclaimed, then only the count field is slightly modified or the original value is kept unchanged.

[0101] Dynamic management of the counting field is achieved through multiple condition constraints, balancing the recycling rate of address resources with the consistency of index metadata in concurrent scenarios.

[0102] The slot status, total result field, and count field within the counting record have all been modified, and the corresponding plaintext data of the counting bucket has been updated. The plaintext of the identifier set bucket, which has an invalidation marker or has undergone compaction operations, has also been modified. The trusted execution end uses the bucket encryption key material to perform independent overall encryption operations on the modified counting bucket and identifier set bucket, respectively. The encryption process generates entirely new encrypted random variables and authentication verification factors, preventing the database storage end from locating the deleted or modified slot or block position through the difference between the old and new ciphertext bytes. After generating the new ciphertext bucket value, it is written to the counting bucket support table and the identifier set bucket support table, respectively, using the original encoded bucket row key as the primary key. This completes the persistent storage of all data changes from the deletion operation. The database storage end only stores the ciphertext and cannot parse any plaintext change details.

[0103] In one embodiment, during the deletion process, the valid random record identifiers in the identifier collection bucket are sorted out, the valid random record identifiers are moved forward and invalid slots are cleared, and then the sorted identifier collection bucket is encrypted.

[0104] In this embodiment, during the index deletion process, when the identifier of the random record to be deleted is stored inside the identifier set bucket, marking the corresponding position in the block as invalid will cause a large number of invalid empty spaces to be discretely distributed in the bucket, forming storage fragments; the continuous accumulation of fragments will increase the data volume of a single read and decryption, prolong the retrieval time, and waste secondary logical address resources.

[0105] The trusted execution unit maps the target secondary block number based on the secondary logical address corresponding to the random record identifier to be deleted, derives the identifier set bucket row key, reads and decrypts the corresponding ciphertext identifier set bucket, obtains all the plaintext data of the secondary blocks within the bucket, and identifies the secondary blocks to be processed that have invalid slots. The trusted execution unit traverses all storage locations within the target secondary block, filters all random record identifiers marked as valid, and uniformly shifts and fills the selected valid identifiers to the beginning of the block in their original order. After the shift is completed, all remaining free slots at the end of the block are uniformly set to invalid and filled with invalid identifiers, random obfuscation values, or standardized coded null values, thoroughly clearing the scattered invalid empty slots within the block and eliminating storage fragmentation.

[0106] After sorting, all valid random record identifiers within a single block are stored consecutively and centrally, while all invalid storage units are concentrated at the end of the block, eliminating the situation where valid identifiers and invalid empty spaces are interspersed.

[0107] After the identifier compaction and forward shift are completed, the trusted execution end, in conjunction with the latest number of valid identifiers within the block and the idle status of the tail-end secondary blocks and address continuity constraints, performs a rollback correction on the count field in the count record, reclaiming redundant secondary logical addresses that no longer carry valid identifiers, and preventing empty addresses from continuously occupying the address allocation baseline. Simultaneously, the total result field is updated synchronously, deducting the number of valid identifiers deleted in this instance, ensuring that the metadata statistics match the actual total number of valid identifiers within the bucket.

[0108] After completing the compact organization of the identifiers within the block and the correction of the metadata, the trusted execution end uses the bucket encryption key material to perform a comprehensive encryption operation on the plaintext of the completely updated identifier set bucket, generating new ciphertext bucket data. The encryption process introduces a new encryption random factor to avoid the database storage end identifying the modified position within the block by the difference between the old and new ciphertext bytes. After encryption, the new ciphertext bucket is overwritten and written to the identifier set bucket support table for persistent storage using the original identifier set bucket row key.

[0109] In one embodiment, the updated counting bucket and identifier set bucket are encrypted as a whole using a new encrypted random quantity, an authentication random quantity, or an equivalent randomization state during write-back, so that the database storage end cannot determine the updated inline identifier slot or block position based solely on the difference between the old and new ciphertexts of the same bucket.

[0110] In this embodiment, after the write and delete processes have completed the plaintext data modification within the counting bucket and the identifier set bucket, and before writing back the ciphertext bucket to the database storage end, the trusted execution end enables a new set of randomized parameters to perform overall encryption, preventing the storage end from inferring the location of changes within the bucket through the differences in ciphertext before and after the update of the same bucket.

[0111] After the trusted execution end completes operations such as changing the status of inline identifier slots, marking positions within secondary buckets, and correcting various metadata fields, it first distinguishes which buckets have had their plaintext content modified. Counting buckets and identifier set buckets where only the plaintext has been updated need to be re-encrypted; buckets that have not undergone any changes do not need to be re-encrypted and can directly use the original ciphertext, thereby controlling the overhead of cryptographic operations. For all updated bucket plaintext to be persisted, the system prepares to initiate a new round of complete encryption.

[0112] The trusted execution end cryptographic module independently generates high-entropy random data as the randomization material used in this round of encryption. This set of random parameters is only used for the current bucket encryption and will not reuse the random values ​​used in the previous round of encryption for the same bucket. The encryption random quantity participates in the plaintext encryption transformation process, and the authentication random quantity is used for the generation of the message authentication code. If the system adopts different cryptographic schemes, a cryptographically equivalent randomized state vector can also be used as a substitute. The key constraint is that this set of random parameters must be replaced with each update and write-back of the same bucket. The random materials used in the new and old rounds of encryption are independent of each other and have no fixed correlation.

[0113] The trusted execution end uses the bucket encryption key material, combined with the newly generated encryption random quantity and authentication random quantity, to perform an integrated encryption operation on the entire plaintext of the bucket, rather than encrypting only the modified local area within the bucket. The bucket plaintext contains all the content of all inline identifier slots, second-level block storage records, version fields, record status fields, count fields, and total result fields.

[0114] Even if only one inline slot or one position within a secondary block is modified within the bucket, the entire bucket is still treated as a single encryption unit. The newly introduced random parameter applies to all ciphertext bits, making the ciphertext generation highly dependent on the fresh random number generated.

[0115] Because each encryption uses different fresh random parameters, even if the plaintext of the bucket is only slightly modified, or in extreme scenarios the plaintext of the bucket remains unchanged and only routine re-encryption is performed, there will be a wide range of irregular differences between the ciphertext output in this round and the old ciphertext stored in the previous round.

[0116] The database storage can only obtain two complete sets of ciphertext before and after the update. It cannot distinguish whether the difference in ciphertext comes from the modification of a certain identifier in the bucket, the change of metadata, or simply the change of encryption random parameters. The storage cannot locate the specific inline identifier slot, second-level block number, or corresponding block position that was modified by comparing the difference between the old and new ciphertexts, thus preventing attack paths based on ciphertext comparison for index behavior analysis.

[0117] After encryption, a new ciphertext bucket value is obtained. The trusted execution end uses the original encoded bucket row key as the primary key of the data table and replaces the old ciphertext stored in the table with the new ciphertext. The database storage end only perceives that the ciphertext of that row record has been updated as a whole, and cannot distinguish the differences between the plaintext modification area and the noise differences caused by random parameters. The details of the modification inside the index remain confidential.

[0118] In one embodiment, the method is executed within a database transaction; when a concurrent write conflict occurs in the counting bucket or the identifier set bucket, the bucket does not exist, the bucket is full, the write result is incomplete, or the secondary block capacity is insufficient, the corresponding bucket is reread and a retry is performed based on the latest counting record status.

[0119] In this embodiment, the index writing, updating, and deleting processes are all executed in a closed loop using the database transaction mechanism, ensuring that data updates to the counting bucket and the identifier set bucket possess atomicity, consistency, and isolation. During transaction execution, if abnormal conditions such as concurrent write conflicts, missing target buckets, full bucket storage space, incomplete written data, or insufficient secondary block capacity are detected, the system will not directly report an error and terminate the transaction. Instead, it will trigger a standardized retry mechanism: reload the latest bucket encrypted data and decrypt it to obtain the real-time counting record status. Based on the latest index metadata, it will re-execute the identifier distribution, address allocation, data writing, and metadata update logic, ultimately completing a legitimate steady-state update and fully adapting to database operation scenarios with high concurrency, dynamic expansion, and transaction contention.

[0120] All index change operations are encapsulated within an independent database transaction and executed within a single transaction. Each transaction fully covers the entire process of bucket reading, decryption, data modification, metadata update, re-encryption, and data write-back. All data changes during transaction execution are temporary states within the transaction and are only committed to disk after the entire process has been legally completed. If an abnormal condition is detected midway, the current temporary result of the transaction is abandoned, and retry logic is initiated to reload the latest data from the data source, avoiding dirty data, address errors, or index anomalies based on expired snapshots.

[0121] Concurrent write conflicts in counting buckets or identifier collection buckets occur when multiple threads and requests concurrently update the same keyword index. Multiple transactions may simultaneously read the same counting bucket or identifier collection bucket and perform data modification operations in parallel. The system uses a dual-checking mechanism based on the version field and random field of the counting record to identify concurrent conflicts: if the bucket version number and random check parameter read by the current transaction are inconsistent with the latest persisted version parameter in the database, it is determined that the bucket has been modified by other concurrent transactions. The current transaction's logic for splitting, writing, and address updating based on expired data then fails, triggering a transaction retry. This mechanism effectively avoids index consistency problems such as metadata overwriting, identifier loss, and address corruption caused by concurrent updates from multiple transactions.

[0122] If the target bucket does not exist, during transaction execution, if the corresponding encrypted bucket data is not found when reading the counting bucket support table or the identifier set bucket support table based on the derived row key, the bucket is determined to be non-existent. This situation typically occurs when a new keyword is first written to the index, historical index data is cleaned up and deleted, or the initialization sequence of cross-transaction buckets is misaligned. The system will not directly terminate the process, but will re-execute the bucket creation logic through a retry mechanism, initializing the blank bucket structure based on the latest keyword parameters and key materials, ensuring the normal closed loop of the index creation process.

[0123] The bucket storage space is full. All valid storage units in the counting bucket or the corresponding secondary identifier collection bucket are occupied, and there are no remaining free slots or in-block storage space, so the current identifier write operation cannot continue. This state is determined by the system after reading the latest bucket structure and counting the number of free inline slots and the remaining capacity of the secondary block. If the write is performed based on an expired snapshot, it will result in write failure or data overflow. Therefore, a retry mechanism is triggered, and the traffic distribution strategy is adjusted again based on the latest full state, so that the newly added identifier is completely distributed to the secondary expansion area or a new secondary block is created.

[0124] Incomplete write results occur when, after a transaction executes a write operation, the system verifies the number of successfully written random record identifiers. If this number does not match the target number to be written, the write result is deemed incomplete. This anomaly is often caused by momentary I / O fluctuations, temporary database blocking, or concurrent resource contention leading to the failure of some identifier writes. To avoid incomplete index data and distorted total result statistics, the system discards the incomplete write result, triggers a transaction retry, and re-completes the batch write based on the latest bucket state, ensuring the integrity of data written in a single transaction.

[0125] If the second-level block capacity is insufficient, during the execution of second-level write set address mapping and data writing, the remaining storage space of the current target second-level block cannot accommodate all the random record identifiers to be written, and the second-level block capacity is exhausted. If a forced write occurs, it will result in address out-of-bounds error, data overwriting, or write failure. After recognizing this insufficient capacity condition, the system terminates the current transaction logic, triggers a retry, and re-executes the logic of second-level block expansion, new block creation, and address segmentation allocation.

[0126] When any of the above-mentioned abnormal conditions are triggered, the system immediately rolls back the currently failed transaction, clears all temporary modified data within this transaction, and enters a unified retry process. First, it rereads the latest encrypted data of the counter bucket and identifier set bucket from the database storage using a valid row key. Decryption is then performed using the latest bucket encryption key to obtain the latest and most accurate metadata of the counter records, slot status, secondary block capacity, and address allocation status, completely avoiding data deviations caused by expired snapshots. Subsequently, based on the refreshed latest index status, the complete inline and secondary identifier routing judgment, slot writing, secondary address allocation, identifier bucket writing, and update logic for the total result field and counter field are re-executed to adapt to the latest index storage status and system load status. After all data modifications and metadata corrections are completed, the overall bucket encryption and transaction commit write-back operations are re-executed to ensure that the final index data written to disk is completely accurate, consistent, and valid.

[0127] The aforementioned retry fault-tolerance mechanism enables the entire searchable encrypted indexing method to possess high concurrency adaptability and anomaly self-healing capabilities. By refreshing bucket data in real time and retrying updates based on the latest state, it completely resolves issues such as concurrent write conflicts, insufficient storage space, incomplete data writes, and bucket timing anomalies, ensuring metadata consistency, storage integrity, and address continuity between the counting bucket and the identifier set bucket. Without sacrificing the privacy and security of the encrypted index, it significantly improves the stability of the index insertion, deletion, and modification processes and the system's concurrency handling capacity, adapting to large-scale, high-concurrency encrypted database business retrieval scenarios.

[0128] Reference Figure 2 In another embodiment of the present invention, a searchable encrypted indexing device with low-frequency result inlining and secondary bucket rollback is provided, applied to a database searchable encrypted system including a trusted execution end and a database storage end, wherein the database storage end stores a counting bucket support table and an identifier set bucket support table, and the device includes: The acquisition module is used to acquire the keywords of the records to be indexed and their corresponding random record identifiers; The derived module is used by the trusted execution end to derive index internal tags, counter bucket row keys, and bucket encryption key materials based on the keywords and field-level search keys; The reading module is used to read the corresponding counting bucket based on the counting bucket row key, decrypt the counting bucket based on the bucket encryption key material, and find the counting record that matches the internal tag of the index; wherein, the counting record includes a counting field for a secondary identifier set structure and at least one inline identifier slot; The writing module is used to adaptively write the random record identifier into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table; The update module is used to update the counting record according to the writing result, re-encrypt and write the updated counting bucket back to the counting bucket support table, and if there is an updated identifier set bucket, then encrypt and write the updated identifier set bucket back to the identifier set bucket support table.

[0129] In this embodiment, the specific implementation of each module in the above device embodiment is described in the above method embodiment, and will not be repeated here.

[0130] Reference Figure 3 This invention also provides a computer device, which can be a server, and its internal structure can be as follows: Figure 3As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0131] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0132] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0133] In summary, the searchable encrypted indexing method and apparatus for low-frequency result inlining and secondary bucket rollback provided in this embodiment of the invention are applied to a database searchable encrypted system including a trusted execution end and a database storage end. The database storage end stores a counting bucket support table and an identifier set bucket support table, including: obtaining the keywords of the record to be indexed and the corresponding random record identifiers; the trusted execution end derives the index internal label, the counting bucket row key, and the bucket encryption key material based on the keywords and the field-level search key; reads the corresponding counting bucket based on the counting bucket row key, decrypts the counting bucket based on the bucket encryption key material, and searches for the counting record that matches the index internal label; wherein, the counting record includes a counting field for the secondary identifier set structure, a result total field for representing the total number of currently valid random record identifiers, and at least one inlining identifier. Slots; Based on the availability status of the inline identifier slots and the preset inline strategy, the random record identifiers are divided into an inline write set and a secondary write set; the random record identifiers in the inline write set are written into the inline identifier slots, and the inline write set does not occupy the logical address of the secondary identifier set structure; a secondary logical address is allocated to the random record identifiers in the secondary write set based on the count field, and the random record identifiers in the secondary write set are written into the identifier set bucket in the identifier set bucket support table; the total number of results field of the count record is updated according to the write result, and the count field is updated to the next allocatable secondary logical address; the updated count bucket is re-encrypted and written back to the count bucket support table, and if an updated identifier set bucket exists, the updated identifier set bucket is encrypted and written back to the identifier set bucket support table. In this invention, random record identifiers for low-frequency keywords or small-scale result sets are directly stored within the counting record. During a search, the results are returned simply by reading the counting bucket. When the number of results exceeds the inline capacity or policy threshold, it automatically falls back to the secondary identifier set bucket, maintaining the scalability of high-frequency keywords. The counting field, the total number of results field, and the inline identifier slot jointly maintain the keyword status, enabling insertion, searching, and deletion to be processed uniformly within the same structure. Bucket-level overall encryption reduces the database storage's ability to observe modification locations within the bucket. Furthermore, this overcomes the current shortcomings of requiring additional access to the secondary identifier set table for low-frequency keywords, increasing database round trips, auxiliary table rows, and write costs.

[0134] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0135] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0136] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A searchable encrypted indexing method with low-frequency result inlining and secondary bucket rollback, applied to a database searchable encrypted system including a trusted execution end and a database storage end, wherein the database storage end stores a counting bucket support table and an identifier set bucket support table, characterized in that, The method includes: Retrieve the keywords and corresponding random record identifiers of the records to be indexed; The trusted execution unit derives internal index tags, counter bucket row keys, and bucket encryption key materials based on the keywords and field-level search keys. The corresponding counting bucket is read based on the counting bucket row key, the counting bucket is decrypted based on the bucket encryption key material, and the counting record that matches the internal tag of the index is found; wherein, the counting record includes a counting field for the secondary identifier set structure and at least one inline identifier slot; The random record identifier is adaptively written into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table; The counting record is updated based on the writing result, and the updated counting bucket is re-encrypted and written back to the counting bucket support table. If an updated identifier set bucket exists, the updated identifier set bucket is encrypted and written back to the identifier set bucket support table.

2. The method according to claim 1, characterized in that, The counting record also includes a version field, a record status field, an option field, and a random field; The record status field is used to identify whether the count record is valid, and the random field is used to participate in encryption randomization, concurrent update detection, or replay detection. Each slot in the inline identifier slot has a valid state and an invalid state; When the slot is in an active state, the slot stores a random record identifier; when the slot is in an invalid state, the slot stores an invalid identifier, a random fill value, or a null value encoded in a preset format.

3. The method according to claim 1, characterized in that, The counting field only assigns a secondary logical address to the random record identifier written to the identifier collection bucket; For random record identifiers written to the inline identifier slot, the trusted execution terminal uses a method of first classifying and allocating, first reserving and then backing up, or an equivalent batch adjustment method to ensure that the counting field does not occupy secondary logical address due to random record identifiers.

4. The method according to claim 1, characterized in that, Adaptively writing the random record identifier into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table includes: Based on the availability status of the inline identifier slot and the preset inline strategy, the random record identifier is divided into an inline write set and a secondary write set; The random record identifier in the inline write set is written into the inline identifier slot, and the inline write set does not occupy the logical address of the secondary identifier set structure; Based on the count field, a secondary logical address is assigned to the random record identifier in the secondary write set, and the random record identifier in the secondary write set is written to the identifier set bucket in the identifier set bucket support table.

5. The method according to claim 4, characterized in that, The preset inline strategy includes at least one of the following: The existence of an available slot in the inline identifier slot is used as the writing condition; The write condition is whether the size of the results corresponding to the keyword is less than a preset threshold. Write conditions are determined by the length of the count record, the cost of accessing the secondary bucket, or the concurrent write status.

6. The method according to claim 4, characterized in that, Writing the random record identifiers from the secondary write set to the identifier set bucket in the identifier set bucket support table includes: The secondary logical address is mapped to a secondary block number and a location within the block according to the preset block capacity; Based on the secondary block number, the index internal label, and the bucket row key derived from the bucket encryption key material; Read, create, or update the corresponding identifier collection bucket based on the row key of the identifier collection bucket; Write the random record identifier in the secondary write set into the identifier set record in the identifier set bucket that corresponds to the secondary block number and the position within the block.

7. The method according to claim 1, characterized in that, The counting record also includes a result total field representing the total number of currently valid random record identifiers. The method also includes a keyword search process, which includes: Based on the search keywords and field-level search keys, derive the search internal tags, search count bucket row keys, and search bucket encryption key materials; Based on the search counter bucket row key and search bucket encryption key material, read and decrypt the corresponding counter bucket to obtain the count record that matches the search internal tag; Add the random record identifier stored in the inline identifier slot that is in a valid state from the count records of the internal tag matching of the search to the search results set; Based on the total number of results field, the count field, and the number of inline random record identifiers that have been added to the search results set, determine whether there is any secondary identifier set data to be read; When there is a set of secondary identifiers to be read, the corresponding identifier bucket is read and decrypted according to the secondary logical address range, and the valid random record identifiers are added to the search results set. Output the set of search results.

8. The method according to claim 1, characterized in that, The counting record also includes a result total field representing the total number of currently valid random record identifiers; the method further includes a deletion process, which includes: Locate the corresponding count record based on the keyword to be deleted or the random record identifier to be deleted; Check the inline identifier slots in the located counting records. When the random record identifier in the slot meets the deletion condition, set the corresponding inline identifier slot to an invalid state. Check the identifier set bucket corresponding to the located count record. When the random record identifier in the bucket meets the deletion condition, set the position in the corresponding block to an invalid state. Update the total number of results field in the located count record according to the deletion result, and roll back, correct or maintain the count field according to the valid record status of the tail second-level block, concurrent update status or address continuity requirements. The updated counting bucket and the updated identifier set bucket are re-encrypted and written back to the database storage.

9. The method according to claim 1, characterized in that, The updated counting bucket and identifier set bucket are encrypted as a whole using new encrypted random quantity, authentication random quantity, or equivalent randomization state during write-back, so that the database storage end cannot determine the updated inline identifier slot or block position based solely on the difference between the old and new ciphertexts of the same bucket.

10. A searchable encrypted indexing device with low-frequency result inlining and secondary bucket rollback, applied to a database searchable encrypted system including a trusted execution end and a database storage end, wherein the database storage end stores a counting bucket support table and an identifier set bucket support table, characterized in that, The device includes: The acquisition module is used to acquire the keywords of the records to be indexed and their corresponding random record identifiers; The derived module is used by the trusted execution end to derive index internal tags, counter bucket row keys, and bucket encryption key materials based on the keywords and field-level search keys; The reading module is used to read the corresponding counting bucket based on the counting bucket row key, decrypt the counting bucket based on the bucket encryption key material, and find the counting record that matches the internal tag of the index; wherein, the counting record includes a counting field for a secondary identifier set structure and at least one inline identifier slot; The writing module is used to adaptively write the random record identifier into the inline identifier slot and the identifier collection bucket in the identifier collection bucket support table; The update module is used to update the counting record according to the writing result, re-encrypt and write the updated counting bucket back to the counting bucket support table, and if there is an updated identifier set bucket, then encrypt and write the updated identifier set bucket back to the identifier set bucket support table.

Images