DS-CKDSE: A Dual-Server Conjunctive Keyword Dynamic Searchable Encryption with Forward and Backward Security

TL;DR

This paper introduces a new encrypted search system that improves security and efficiency in cloud computing.

Contribution

A dual-server conjunctive keyword DSE scheme with forward and backward security is proposed.

Findings

The proposed DS-CKDSE scheme achieves adaptive security under a defined leakage function.

The system efficiently supports conjunctive keyword searches with high performance in updates and searches.

The dual-server architecture effectively mitigates KPRP leakage risks.

Abstract

Dynamic Searchable Encryption (DSE) is essential for enabling confidential search operations over encrypted data in cloud computing. However, all existing single-server DSE schemes are vulnerable to Keyword Pair Result Pattern (KPRP) leakage and fail to simultaneously achieve forward and backward security. To address these challenges, this paper proposes a conjunctive keyword DSE scheme based on a dual-server architecture (DS-CKDSE). By integrating a full binary tree with an Indistinguishable Bloom Filter (IBF), the proposed scheme adopts a secure index: The leaf nodes store the keywords and the associated file identifier, while the information of non-leaf nodes is encoded within the IBF. A random state update mechanism, a dual-state array for each keyword and the timestamp trapdoor designs jointly enable robust forward and backward security while supporting efficient conjunctive queries. The dual-server architecture mitigates KPRP leakage by separating secure index storage from trapdoor verification. The security analysis shows that the new scheme satisfies adaptive security under a defined leakage function. Finally, the performance of the proposed scheme is evaluated through experiments, and the results demonstrate that the new scheme enjoys high efficiency in both update and search operations.

Figures

Full text

1. Introduction

With the continuous development of cloud computing capabilities, both enterprises and individual users can offload local computational burdens and enjoy scalable, on-demand services provided by the cloud. However, while offering convenient and efficient storage, cloud service providers also raise serious data security concerns. When data is stored with cloud service providers that are not fully trustworthy, users risk losing authority and possession over their private data. Malicious cloud service providers may even attempt to steal or tamper with user data. To mitigate these risks, a growing number of users have opted to store their data in encrypted form, thereby enhancing confidentiality. However, the encryption process obscures the underlying data structure of the original plaintext, making efficient retrieval a major challenge.

In response to the aforementioned problem, Searchable Encryption (SE) emerged as a solution, enabling search functionality over encrypted data without revealing sensitive information. After Song [1] proposed the first SE scheme, a series of SE schemes were subsequently introduced. However, these schemes mainly focused on single keyword search, meaning that users could only use one keyword per search query. With the continuous growth in data volume and the increasing complexity of search requirements, single-keyword SE became inadequate for meeting complex query demands. To enable more precise data retrieval, the need for conjunctive keyword SE emerged.

Golle et al. [2] proposed the first SE scheme that supports conjunctive keyword search. However, the search complexity of this scheme increased linearly with the number of files, making it difficult to deploy in practical applications. Later, Cash et al. [3] proposed a sublinear SE scheme named Oblivious Cross-Tags (OXT). However, this scheme suffers from Keyword Pair Result Pattern (KPRP) leakage during the search phase. This means that for a conjunctive search query $[eqn]$ containing three keywords $[eqn]$ , the server can learn the encrypted file identifiers associated with each pair of query keywords $[eqn]$ , for which $[eqn]$ . To eliminate KPRP leakage, Lai et al. [4] subsequently proposed an efficient conjunctive keyword SE scheme based on OXT. However, all the aforementioned SE schemes lack support for dynamic updates, which are categorized as Static Searchable Encryption (SSE) for conjunctive keyword search.

In SSE schemes, if users need to add, delete, or modify data, they must reconstruct the entire index and ciphertext database. This imposes significant limitations on scalability and maintainability in real-world scenarios, rendering SSE unsuitable for practical situations that require frequent data updates. Due to the limitations of SSE in handling dynamic data updates, Dynamic Searchable Encryption (DSE) emerged. DSE supports dynamic operations, enabling it to adapt to scenarios with frequent data changes. Kamara et al. [5] introduced the first construction of a DSE scheme. This scheme allows data owners to encrypt and store their data, and subsequently perform searches and dynamic updates on the encrypted data. However, update operations introduce serious additional information leakage issues, and each update operation may decrease the system’s entropy, thereby leaking critical information to adversaries. For instance, a server might intentionally match previous search tokens with newly added file indexes to infer the keywords contained within the files or deduce query keywords from repeated search queries. To address these challenges, forward security [6] and backward security [7] were proposed as two core security properties to ensure data integrity and confidentiality: the former refers to the inability to link an updated file with previous search operations during an update, while the latter ensures that the results obtained during the user search phase do not include data that has already been deleted. Since then, a series of DSE schemes have emerged [8,9,10,11,12,13,14]. However, these schemes fail to simultaneously achieve forward security, backward security, and conjunctive keyword search. Currently, only the Oblivious Dynamic Cross-Tags (ODXT) scheme [15] supports conjunctive keyword search while guaranteeing both forward and backward privacy. Nevertheless, it remains vulnerable to KPRP leakage. Therefore, while ensuring forward and backward security, how to minimize information leakage during the search process—with the goal of eliminating KPRP leakage while still supporting efficient conjunctive keyword searches for data users—remains a significant topic for future research.

This paper proposes a dual-server scheme named DS-CKDSE, which supports conjunctive keyword search. The scheme is designed from an information-theoretic perspective to minimize information leakage, thereby achieving both forward and backward security and eliminating KPRP leakage. The main contributions of this work are as follows:

• A dual-server architecture is proposed, where one server is responsible for verifying the search trapdoor and the other for storing the encrypted secure index. This separation prevents the latter from accessing keyword states, thereby effectively preventing KPRP leakage.
• A privacy-preserving index is constructed based on a full binary tree, where the root node encompasses all keywords, non-leaf nodes store keyword sets, and leaf nodes hold individual keywords; this structure inherently supports efficient path-based retrieval. Each leaf node stores a single keyword and employs a multi-bitmap index to indicate which files contain it. During the conjunctive keyword search phase, the server can achieve efficient conjunctive keyword search without requiring file-by-file comparison or decryption. Non-leaf nodes use an Indistinguishable Bloom Filter (IBF) to store keyword data. By mapping keywords via hash functions, the IBF obscures their exact storage positions. This design effectively removes mutual information between the index’s structure and the actual keywords, thus preventing branch leakage as the tree is traversed.
• A dual-state array and a timestamp factor are introduced for each keyword to support secure update operations. The dual-state array records both the state and the update counters for each keyword during the processes of addition and deletion. The timestamp factor restricts the validity of the trapdoor. The combination of the dual-state array and the timestamp factor ensures both forward and backward security, thereby enhancing the overall security of dynamic data management.

2. Related Work

SE has emerged as a crucial mechanism for ensuring data confidentiality in the cloud and has received extensive attention in recent years. The concept of SE was first introduced by Song et al. [1] and later formalized by Curtmola et al. [16]. Depending on their functional characteristics and security goals, existing studies mainly focus on the following directions.

2.1. SSE Scheme for Conjunctive Keyword Search

In 2000, Song et al. [1] first proposed the concept of SE and designed an SSE scheme. In this SSE scheme, a file is divided into multiple keywords, and each keyword is encrypted using a symmetric key and a pseudo-random function (PRF) to generate a unique encryption key. This scheme ensures that the server learns nothing about the search keyword during the search process. However, the search efficiency is relatively low, as the server must traverse all keywords in every file. The search time scales linearly with the file size. Later, Goh [17] pioneered an SSE scheme based on a secure index. This scheme uses pseudo-random functions and Bloom filters to build a secure index for each file, where each keyword is mapped to fixed positions on the BF. During the search process, the server quickly determines whether a corresponding keyword exists using the BF to achieve high search efficiency, with a constant-time search per file. However, due to the inherent false positive rate of the BF, the search results may include some irrelevant files, thereby reducing the accuracy of the results. In 2006, Curtmola et al. [16] proposed an efficient SSE scheme in which the search computation cost is constant and independent of the number of keywords in all files. This scheme also supports multi-user search.

The above SSE schemes only support single keyword search, which is quite limited for complex query requirements. For example, users may need to perform conjunctive searches based on multiple keywords to improve the accuracy of the query. If only single keyword search is supported, the server may return a large number of irrelevant files, leading to unnecessary data transmission and downloads. As a result, SSE schemes supporting conjunctive keyword search emerged. In 2004, Golle et al. [2] were the first to propose two schemes for conjunctive keyword search over indirectly linked keywords. However, the search complexity of both schemes grows linearly with the number of files and involves numerous modular exponentiations and bilinear pairing operations, which renders them impractical for real-world applications. In 2014, Cash et al. [3] proposed an SSE scheme called OXT (Oblivious Cross-Tags). The scheme introduces a technique known as Cross-Tags, which constructs a specialized index structure that enables the server to efficiently process complex Boolean queries such as AND, OR, and NOT. The search time of this scheme depends on the number of files. Its key advantages include significantly enhanced search flexibility and scalability. However, this scheme leaks certain access patterns and incurs substantial computational overhead during the initial index construction phase. In 2018, Lai et al. [4] proposed an SSE scheme that supports conjunctive keyword search based on the OXT framework [3]. The scheme utilizes hidden vector encryption and BF to construct an encrypted index structure, enabling the server to efficiently process conjunctive keyword search over encrypted indexes. It offers high search efficiency and strong scalability when handling large-scale datasets. However, the use of encrypted index structure and cryptographic primitives leads to higher setup overhead and increased implementation complexity. The SSE scheme proposed by Zhang et al. [18] based on hardness assumptions supports conjunctive keyword search with integrity verification, which prevents semi-honest servers from returning incomplete ciphertexts in an attempt to reduce computation costs.

2.2. DSE Scheme for Conjunctive Keyword Search

Distinct from SSE, DSE not only enables ciphertext retrieval but also supports dynamic updates to the encrypted database.

Stefanov et al. [6] proposed a practical DSE scheme and were the first to formally define the concept of forward security. The scheme employs Oblivious RAM (ORAM) technology [19] and a specialized data structure called blind storage to construct a secure index. Through the ORAM mechanism, it effectively mitigates information leakage during search and update operations, ensuring that the server cannot obtain additional information beyond the search results. However, reliance on ORAM brings substantial computational and communication overhead, especially under frequent dynamic updates, thereby limiting its practicality in real-world applications. Later, Bost et al. [20] proposed a scheme that employs a PRF and an encrypted linked list structure to construct an encrypted index that supports efficient updates and satisfies forward security. This scheme also provided the first rigorous formal definition of forward security. By introducing trapdoor permutation functions as a foundation, the scheme redesigns the encryption process in the search phase, successfully optimizing the search time complexity to sublinear. However, the scheme cannot avoid the computational overhead caused by cryptographic primitives, and the maintenance cost of the index increases with the growth of the database. In 2017, Bost et al. [7] formally defined the notion of backward security and presented several efficient DSE schemes, one of which was called Janus. In Janus, the data index is encrypted using puncturable encryption, which allows the server to retrieve only the matching index entries that have not been deleted. However, puncturable encryption brings significant communication and computation overhead.

Later, Zuo et al. [21] proposed a DSE scheme designed to achieve both forward and backward security. This scheme leverages pseudo-random functions and homomorphic addition to construct the index, thereby achieving a stronger level of privacy. However, due to the use of homomorphic addition, the complexity of index updates is increased. Wu et al. [22] designed a tree-based data structure called VBTree, enabling a DSE scheme that supports conjunctive keyword search. By organizing index elements into a virtual binary tree, VBTree enables efficient conjunctive keyword search over encrypted data while mitigating privacy leakage risks associated with exposing traditional tree structures to the cloud. The core innovation of the scheme lies in its ability to support dynamic data updates in sublinear time without reconstructing the entire tree, thereby improving update efficiency. Subsequently, VBTree has been adopted as an effective data structure in many DSE schemes. However, VBTree only guarantees forward security and still leaks file access patterns, potentially exposing to the server the files that match a specific keyword. To address this, Wang et al. [23] optimized the VBTree structure based on the OXT framework, further reducing information leakage and improving the efficiency of conjunctive keyword search. Nevertheless, due to the use of public-key cryptographic primitives, the scheme still incurs relatively high computational overhead.

Lu et al. [24] proposed a verifiable DSE scheme that supports conjunctive keyword search and achieves both forward and backward security. The scheme constructs a forward index using a t-puncturable PRF and designs verification tags. During the search process, the scheme first narrows the search scope using an inverted index, then determines the final search result through the forward index, while verifying the correctness and completeness of the result using the verification tags. However, its drawback lies in the additional computational resources required to construct and maintain the encrypted index, resulting in high initial setup and update costs. In 2024, Jin et al. [25] proposed an improved bloom filter named Authenticator Bloom Filter (ABF) and applied it to a DSE scheme. The scheme supports forward and backward security, multi-user environments and dynamic updates. However, the ABF used in the scheme requires maintaining both a bit array and a counter, which brings additional storage and computation overhead. Later, the SDSSE-CQ scheme proposed by Zuo et al. [26] achieves forward and backward security in DSE by combining the OXT framework with aura technology. It is particularly well-suited for scenarios requiring efficient conjunctive queries. However, this scheme requires maintaining two instances of aura (“TSet” and “XSet”), which results in relatively high storage overhead.

3. Preliminaries

3.1. Notations

The main notations used in this paper are presented in Table 1.

3.2. Full Binary Tree

To support efficient tree traversal and secure search, this scheme adopts a full binary tree. In a binary tree of height $[eqn]$ , every non-leaf node has exactly two child nodes. The tree contains a total of $[eqn]$ nodes, among which $[eqn]$ are leaf nodes. In this scheme, the full binary tree serves solely as a logical structure, with node elements stored as key-value pairs in a hash table. The example of a full binary tree in this scheme is shown in Figure 1. As shown in Figure 1, the root node contains four keywords $[eqn]$ , non-leaf nodes store sets of keywords. Leaf nodes store a single keyword and its corresponding files, and paths are defined by binary encoding, for example, the path from the root node to keyword $[eqn]$ is ‘01’, the leaf node storing $[eqn]$ also stores the file $[eqn]$ containing the keyword $[eqn]$ . In this scheme, $[eqn]$ denotes a string concatenated with all tree branches beginning from the root node to the current node $[eqn]$ . $[eqn]$ refers to the node with $[eqn]$ . The full binary tree structure employs binary path encoding: The left branch is labeled ‘0’ and the right branch ‘1’. This encoding ensures that the path from the root to any node $[eqn]$ is uniquely represented as a binary string. The binary string $[eqn]$ can be computed from $[eqn]$ by tracing back to the root and recording the sequence of left/right moves.

3.3. Multi-Bitmap Index

To enhance the efficiency of conjunctive keyword search over encrypted database, this scheme adopts an extended bitmap index structure, called the multi-bitmap index. Unlike the traditional bitmap index [27], where each keyword is mapped to a simple binary vector, the multi-bitmap index utilizes a fixed-length bit group (e.g., $[eqn]$ bits) to represent the presence of files, which means each keyword corresponds to an $[eqn]$ -bit string that indicates which files contain the keyword. Assume that the system supports a maximum of $[eqn]$ files. Then each keyword is represented by a bit string of total length $[eqn]$ . If a file $[eqn]$ (where $[eqn]$ ) contains a particular keyword, the bit at position $[eqn]$ is set to 1, and the following $[eqn]$ bits, from position $[eqn]$ to $[eqn]$ , are set to 0. When users initiate a conjunctive keyword search, the server retrieves the multi-bitmap index for each queried keyword. After obtaining the relevant bit strings, the server performs a modular addition operation (mod $[eqn]$ ) across these bit strings and returns the resulting bit vector to the user. If the bits from position $[eqn]$ to $[eqn]$ in the resulting bit vector represent the binary representation of the total number of query keywords, it indicates that the file $[eqn]$ contains all the queried keywords; otherwise, the file is excluded from the final result set. If a user intends to add a file containing a specific keyword to the system, the modular addition operation (mod $[eqn]$ ) is performed on the multi-bitmap index of that keyword; similarly, if the user wishes to delete the file, the modular subtraction operation (mod $[eqn]$ ) is executed. An example is shown in Figure 2.

For instance, consider a database containing three files $[eqn]$ , $[eqn]$ , $[eqn]$ (i.e., $[eqn]$ ), where each file is represented using a 3-bit group (i.e., $[eqn]$ ). Each keyword will then be represented by a bit string with a total length of $[eqn]$ , i.e., 3·3 = 9. The corresponding file bits are mapped as follows: the positions {0, 1, 2} corresponds to file $[eqn]$ , {3, 4, 5} corresponds to $[eqn]$ , and {6, 7, 8} corresponds to $[eqn]$ . As shown in Figure 2a, for the keyword $[eqn]$ (contained in $[eqn]$ and $[eqn]$ ), if the file contain $[eqn]$ , its corresponding 3-bit segment is set to 001; otherwise it is set to 000. Consequently, the bit string corresponding to $[eqn]$ is 001000001. Similarly, the bit string corresponding to $[eqn]$ (contained in $[eqn]$ and $[eqn]$ ) is set to 001001000, whereas $[eqn]$ (contained in $[eqn]$ ) is set to 001000000. Figure 2b illustrates the execution of a conjunctive keyword query $[eqn]$ . The server first retrieves the multi-bitmap index 001000001, 001001000 and 001000000 corresponding to these keywords $[eqn]$ , $[eqn]$ , and $[eqn]$ , respectively. Then the server performs a modular addition operation (i.e., (001000001 + 001001000 + 001000000) mod $[eqn]$ = 011001001) and returns the result 011001001 to the user. Upon receiving the result vector 011001001, the user obtains the bits from position $[eqn]$ to $[eqn]$ is exactly 011 (the binary representation of the total number 3 of queried keywords), thus confirming that the file $[eqn]$ satisfies the query conditions. Figure 2c demonstrates the addition of file $[eqn]$ (containing $[eqn]$ , with bits 000001000) to the system (not containing $[eqn]$ , with bits 001000001), the required update bits can be obtained through modular addition operations (i.e., (000001000 + 001000001) mod $[eqn]$ = 001001001). Figure 2d illustrates the deletion of file $[eqn]$ (containing $[eqn]$ with bits 000001000) from the system (containing $[eqn]$ , with bits 001001001), the required update bits can be obtained through modular subtraction operations (i.e., (001001001 − 000001000) mod $[eqn]$ = 001000001).

3.4. Indistinguishable Bloom Filter

This paper utilizes an Indistinguishable Bloom Filter (IBF) [28] to store index elements. Unlike traditional BF, IBF introduces a twin-cell structure and additional hash functions to achieve indistinguishability. An IBF consists of an array $[eqn]$ of $[eqn]$ twins, each twin contains two 1-bit cells with opposite values (i.e., one bit is 0, the other is 1). It also includes $[eqn]$ hash functions $[eqn]$ , and a hash function $[eqn]$ . The functions $[eqn]$ are defined as $[eqn]$ , $[eqn]$ is defined as $[eqn]$ . To insert a keyword $[eqn]$ , the first $[eqn]$ hash functions $[eqn]$ map $[eqn]$ to $[eqn]$ twin positions in the IBF. Then, for each position, a randomized value is computed as $[eqn]$ , where $[eqn]$ . The hash function $[eqn]$ is then applied to this value to probabilistically select one of the two 1-bit cells in each twin through $[eqn]$ . The selected cell is set to 1, and the unselected cell is set to 0, ensuring that the cell selection process is probabilistic and indistinguishable. To verify whether a keyword exists in the IBF, the same hash computations are performed, and the bits at the selected positions $[eqn]$ are examined. The element is considered to be present in the IBF with high probability only if all corresponding bits are 1. Otherwise, if any bit is 0, the element is definitively absent.

Therefore, through its inherent randomized design, the IBF mechanism systematically eliminates the mutual information between the index structure and specific keywords. Figure 3 illustrates the structure of the IBF, where the deep blue cells represent the selected cells.

4. Problem Formulation

4.1. System Model

The DS-CKDSE system consists of four main entities as shown in Figure 4: a data owner (DO), a data user (DU), a verification server (VS) and a storage server (SS).

DO: Before uploading the files to SS, DO first extracts keywords from the files and initializes an empty dual-state array $[eqn]$ . These keywords are then encrypted to generate a secure index $[eqn]$ , and the files are encrypted to form a ciphertext. Finally, both the secure index $[eqn]$ and the ciphertext are uploaded to SS and the dual-state array $[eqn]$ is sent to VS.DU: An authorized DU aims to retrieve the collection of files that contain the queried keywords, without revealing them. To perform a conjunctive keyword search, DU constructs a search trapdoor $[eqn]$ for the queried keyword $[eqn]$ , and then submits the search trapdoor $[eqn]$ to VS for query processing.VS: After receiving the search trapdoor $[eqn]$ from DU, VS uses a pre-stored dual-state array $[eqn]$ to verify the validity of the trapdoor $[eqn]$ . If the trapdoor $[eqn]$ is invalid, VS returns ‘reject’ to DU. Otherwise, after confirming the validity of the trapdoor $[eqn]$ , VS sends it to SS.SS: SS is responsible for storing the encrypted database and the secure index $[eqn]$ , as well as for processing the valid trapdoors $[eqn]$ received from VS. Upon receiving a valid trapdoor $[eqn]$ , SS traverses the path-encoded binary tree structure to retrieve the matching encrypted file identifiers. These results are then returned to DU, who decrypts them to obtain the target file identifiers.

4.2. Algorithm Definition

• $[eqn]$ : This algorithm is executed by DO. Given a secure parameter $[eqn]$ and an initial database $[eqn]$ , it outputs the key set $[eqn]$ , the dual-state array $[eqn]$ , the secure index $[eqn]$ , the state index $[eqn]$ , and an encrypted database $[eqn]$ .
• $[eqn]$ : This is an interactive algorithm between DO and two servers, VS and SS. DO inputs a keyword $[eqn]$ , the dual-state array $[eqn]$ , a file identifier $[eqn]$ , along with the operation type $[eqn]$ (where “ $[eqn]$ ” denotes inserting a file into the system, “ $[eqn]$ ” denotes removing a file from the system), the secure index $[eqn]$ and the state index $[eqn]$ . After executing the algorithm, VS outputs the updated dual-state array $[eqn]$ and the updated state index $[eqn]$ , and SS outputs the updated secure index $[eqn]$ .
• $[eqn]$ : This is an interactive algorithm between DU and two servers, VS and SS. DU inputs a keyword $[eqn]$ , a timestamp $[eqn]$ , the current dual-state array $[eqn]$ and the encrypted database $[eqn]$ , then generates a search trapdoor $[eqn]$ , and transmits it to VS. Upon successful verification, VS sends the valid trapdoor to SS. SS then executes a query over the secure index $[eqn]$ and returns the corresponding encrypted results $[eqn]$ , which DU decrypts to obtain the identifiers of the matching files.

4.3. Security Definition

The security of a DSE scheme is defined by the ability of an adversary $[eqn]$ to distinguish between the real world $[eqn]$ and the ideal world $[eqn]$ . The real world corresponds to the original DSE scheme, where the adversary $[eqn]$ interacts with a challenger. The ideal world is a simulated environment that only includes the leakage information of the original scheme, where the adversary $[eqn]$ interacts with a simulator $[eqn]$ . The leakage function is defined as $[eqn]$ , where $[eqn]$ denotes the leakage permitted to the adversary during the setup phase, $[eqn]$ denotes the leakage permitted to the adversary during the update phase, and $[eqn]$ denotes the leakage permitted to the adversary during the search phase. The goal of the adversary $[eqn]$ is to determine whether it interacts with the real or the ideal world. Eventually, the adversary $[eqn]$ outputs a bit $[eqn]$ , where $[eqn]$ denotes that it interacts with the real world or $[eqn]$ denotes that it interacts with the ideal world.

$[eqn]$ :The adversary $[eqn]$ selects a database $[eqn]$ and submits it to the challenger. The challenger executes $[eqn]$ and returns the encrypted database $[eqn]$ and the key set $[eqn]$ to the adversary $[eqn]$ . Then the adversary $[eqn]$ adaptively issues a polynomial number of update and search queries. The challenger responds to each query by executing the real algorithms and returns the corresponding results to $[eqn]$ . At the end of the experiment, the adversary $[eqn]$ outputs a bit $[eqn]$ . $[eqn]$ :The adversary $[eqn]$ selects a database $[eqn]$ and sends it to the simulator $[eqn]$ . Given only the leakage function $[eqn]$ , the simulator $[eqn]$ generates a simulated encrypted database $[eqn]$ and sends it to the adversary $[eqn]$ . For each subsequent adaptive query issued by the adversary $[eqn]$ , the simulator $[eqn]$ responds using only the corresponding leakage function $[eqn]$ or $[eqn]$ , without access to the plaintext. Finally, the adversary $[eqn]$ outputs a bit $[eqn]$ .

Definition 1.  We say that a DSE scheme  $[eqn]$  with a leakage function  $[eqn]$  is an  $[eqn]$ -adaptively secure conjunctive keyword DSE scheme if for any probabilistic polynomial time (PPT) adversary  $[eqn]$ , there exists a PPT simulator  $[eqn]$  such that:

$$[eqn]$$

where  $[eqn]$ is a negligible function in  $[eqn]$ .

Informally, a dynamic DSE scheme is $[eqn]$ -adaptively secure with respect to a leakage function $[eqn]$ if the adversarial server provably learns no more information about $[eqn]$ other than that encapsulated by $[eqn]$ . The less information the leakage function $[eqn]$ reveals, the higher the residual entropy of the sensitive information from the adversary’s perspective, and thus the stronger the security guarantee.

4.4. Threat Model

In this scheme, DO and DU are assumed to be honest, meaning they do not leak secret keys or trapdoor information to unauthorized parties. An authorized DU is assumed to be non-malicious during the search phase. The system architecture includes two non-colluding servers: VS and SS, both modeled as honest-but-curious entities. Although VS and SS execute operations correctly, they may passively observe access patterns in an attempt to infer sensitive keyword information. Under the non-collusion assumption, VS and SS do not share their respective stored data.

4.5. Design Goals

The main design goals are as follows:

• Dynamic update support: The scheme should support frequent update operations, including file additions and deletions, while ensuring that each update maintains the security of the index structure.
• Forward security: After DO performs an addition operation, the scheme ensures that previously generated search trapdoors cannot be used to retrieve the newly added file.
• Backward security: After DO performs a deletion operation, the scheme guarantees that the deleted files cannot be retrieved by future search trapdoors.
• Search efficiency: While supporting conjunctive keyword search, this scheme aims to achieve sublinear search time complexity with respect to the total number of keywords.
• KPRP: The scheme must ensure that the server cannot infer whether any two keywords co-occur in the same file by observing trapdoors and query results.

5. Our Construction

In this section, we present the detailed construction of the DS-CKDSE scheme, which is defined as $[eqn]$ The scheme employs four hash functions $[eqn]$ , $[eqn]$ , $[eqn]$ , and $[eqn]$ , along with two pseudo-random functions $[eqn]$ and $[eqn]$ . The meanings of $[eqn]$ are shown in Table 1.

5.1. Setup Phase

In the setup phase, DO is responsible for generating the key set $[eqn]$ and building the secure index $[eqn]$ .

KeyGen: DO inputs the secure parameter $[eqn]$ and runs Algorithm 1 to generate a dual-state array $[eqn]$ , an empty IBF, a key set $[eqn]$ , where $[eqn]$ is used to encrypt keyword states, $[eqn]$ is used to encrypt keywords and $[eqn]$ is used to encrypt files. The dual-state array $[eqn]$ is maintained by DO, DU and VS, while SS is strictly prohibited from accessing keyword states and update counters, thereby enhancing security.

Algorithm 1: KeyGenInput: The secure parameter $[eqn]$ Output: The dual-state array $[eqn]$ , the $[eqn]$ , and the Key set $[eqn]$ 1. Initialize an empty map $[eqn]$ an IBF with element 0;2. $[eqn]$ which is used to encrypt keyword states; 3. $[eqn]$ which is used to encrypt keywords; 4. $[eqn]$ which is used to encrypt files; 5. return $[eqn]$ $[eqn]$ $[eqn]$

Generate Trapdoor: DU inputs the keyword $[eqn]$ , the key set $[eqn]$ , and the dual-state array $[eqn]$ , then executes Algorithm 2 to generate a trapdoor $[eqn]$ .

Algorithm 2: Generate TrapdoorInput: The keyword $[eqn]$ , the Key set $[eqn]$ , the dual-state array $[eqn]$ Output: The trapdoor $[eqn]$ 1. Choose a PRF $[eqn]$ ;2. Choose a PRF $[eqn]$ ;3. Select $[eqn]$ ;4. Compute $[eqn]$ ;5. Get the current time $[eqn]$ ;6. Compute $[eqn]$ ;7. return $[eqn]$

Build Secure Index: DO preprocesses the files by extracting keywords and forming keyword–file identifier pairs $[eqn]$ , where $[eqn]$ denotes the total number of keywords in the database, DO then inputs an IBF and keyword–file identifier pairs $[eqn]$ , and runs Algorithm 3 to generate a secure index $[eqn]$ . For each non-leaf node $[eqn]$ , the keywords in $[eqn]$ are mapped into the IBF using a total of $[eqn]$ hash functions: $[eqn]$ and $[eqn]$ . Each leaf node stores a keyword and the file identifiers that contain that keyword. During query execution, if the IBF does not contain the search keywords, the corresponding subtree can be skipped, thereby improving search efficiency. Each leaf node $[eqn]$ represents a keyword and stores the associated file identifiers in the form of multi-bitmap index.

Algorithm 3: Build Secure IndexInput: The $[eqn]$ , the keyword–file pairs $[eqn]$ , the dual-state array $[eqn]$ Output: The secure index $[eqn]$ 1. Initialize empty binary tree $[eqn]$ ;2. Initialize empty set $[eqn]$ ;3. Choose a PRF $[eqn]$ ;4. Choose a PRF $[eqn]$ ;5. Choose hash functions $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ ;6. for  $[eqn]$  do7.    for  $[eqn]$  do8.     $[eqn]$ ;9.    while  $[eqn]$  do10.     Compute $[eqn]$ ;11.     Select $[eqn]$ ;12.     Get the current time $[eqn]$ ;13.     Compute search trapdoor $[eqn]$ ;14.     Let $[eqn]$ . Then compute $[eqn]$ ;15.      $[eqn]$ ;16.      $[eqn]$ ;17.      $[eqn]$ ;18.      $[eqn]$ ;19.    end while20.     $[eqn]$ ;21.    end for22. end for23. for  $[eqn]$  do24.       $[eqn]$ ;25.       $[eqn]$ ;26. end for27. $[eqn]$

Figure 5 shows an example of a secure index. All keywords $[eqn]$ stored in the root node are encrypted using the IBF. Through a binary tree structure, the keyword sets in non-leaf nodes are progressively subdivided: $[eqn]$ and $[eqn]$ , ultimately reaching leaf nodes where they are refined into individual keywords. Leaf nodes store keywords and their corresponding files, with files represented using multi-bitmap index. For example, the keyword $[eqn]$ with path ‘01’ is stored as “001000001” for file $[eqn]$ and $[eqn]$ containing $[eqn]$ .

5.2. Update Phase

In the update phase, DO intends to add or delete a file associated with a keyword $[eqn]$ , while preserving forward and backward security.

As shown in Algorithm 4, during the update phase, DO inputs the keyword $[eqn]$ , the dual-state array $[eqn]$ and the file identifier $[eqn]$ . Depending on the type of operation $[eqn]$ , a new random $[eqn]$ -bit string $[eqn]$ is generated as the current keyword state, while the previous state is denoted as $[eqn]$ . Specifically, in the case of an addition operation “ $[eqn]$ ”, DO generates a new state $[eqn]$ , increments the addition counter $[eqn]$ and updates the dual-state array $[eqn]$ to $[eqn]$ , in the case of a deletion operation “ $[eqn]$ ”, DO generates a new state $[eqn]$ , increments the deletion counter $[eqn]$ and updates the dual-state array $[eqn]$ to $[eqn]$ This randomization mechanism ensures that the updated and historical search trapdoors are independent, effectively preventing information leakage, and ensuring both forward and backward security during updates.

Then, the keyword token $[eqn]$ is generated via $[eqn]$ . This token is used to compute the update trapdoor $[eqn]$ by $[eqn]$ . Based on the update trapdoor $[eqn]$ , the values $[eqn]$ and $[eqn]$ are further computed. Next, $[eqn]$ and $[eqn]$ are sent to VS, while $[eqn]$ and $[eqn]$ are sent to SS. SS updates the encrypted file identifier $[eqn]$ in the corresponding position $[eqn]$ of the secure index, VS updates the encrypted state information $[eqn]$ in the position $[eqn]$ of the state index. Finally returns the updated dual-state array $[eqn]$ , the updated state index $[eqn]$ and the updated secure index $[eqn]$ . Algorithm 4: UpdateInput: The keyword $[eqn]$ , dual-state array $[eqn]$ , file identifier $[eqn]$ , operation $[eqn]$ , $[eqn]$ , secure index $[eqn]$ , state index $[eqn]$ Output: Updated dual-state array $[eqn]$ , updated state index $[eqn]$ , updated secure index $[eqn]$ 1. $[eqn]$ ;2. $[eqn]$ ; 3. $[eqn]$ $[eqn]$ $[eqn]$ $[eqn]$ $[eqn]$ $[eqn]$ ; 4. $[eqn]$ ; 5. $[eqn]$ “ $[eqn]$ ” then6.   $[eqn]$ ;7.   $[eqn]$ ;8.   $[eqn]$ ;9.   $[eqn]$ ;10. end if11. $[eqn]$ “ $[eqn]$ ” then12.    $[eqn]$ ;13.    $[eqn]$ ;14.    $[eqn]$ ;15.    $[eqn]$ ;16. end if17. Compute encrypted keyword and token $[eqn]$ ;18. $[eqn]$ ;19. Computer update trapdoor $[eqn]$ ;20. $[eqn]$ ;21. $[eqn]$ ;22. $[eqn]$ ;23. $[eqn]$ ;24. $[eqn]$ do25.    $[eqn]$ do26.     $[eqn]$ do27.      $[eqn]$ ;28.      $[eqn]$ ;29.      $[eqn]$ ;30.     end for31.    end for32. end for33. $[eqn]$ ;34. $[eqn]$ ;35. $[eqn]$ $[eqn]$ $[eqn]$

5.3. Search Phase

The search phase relies on a dual-server architecture. Let $[eqn]$ be a conjunctive search query issued by DU. The search phase is described by Algorithm 5.

DU: When DU initiates a conjunctive keyword search over the encrypted database, Algorithm 2 is used to generate a time-restricted search trapdoor $[eqn]$ for each queried keyword. Then these trapdoors are aggregated into a set $[eqn]$ , which is sent to VS for verification.

VS: Upon receiving the trapdoors, VS checks the state of each keyword using the stored dual-state array $[eqn]$ and verifies whether the associated timestamp $[eqn]$ falls within the valid time window $[eqn]$ . If verification is successful, VS forwards the validated trapdoors to SS, which is responsible for index traversal.

SS: SS then traverses a full binary tree index, where each non-leaf node is equipped with an IBF that helps determine whether its subtree contains all queried keywords. The function $[eqn]$ ’ is used to check whether each keyword is present in a node. When the length of the path is $[eqn]$ , which means that the search has reached a leaf node, SS retrieves the encrypted file identifiers that match the conjunctive search. The set of encrypted file identifiers $[eqn]$ is then returned to DU.

DU: DU decrypts the file identifiers using the secret key to obtain the desired files. Algorithm 5: SearchInput:  $[eqn]$ $[eqn]$ $[eqn]$ $[eqn]$ , the path, the time window $[eqn]$ Output: The set of file identifiers $[eqn]$ 1. DU: $[eqn]$ ;2. $[eqn]$ do 3.     $[eqn]$ ; 4.     Compute encrypted keyword and token $[eqn]$ ; 5.     $[eqn]$   $[eqn]$ ;6.     $[eqn]$ ;7.     $[eqn]$ ;8.     $[eqn]$ 9. end for10. $[eqn]$ to VS11. VS: $[eqn]$ do12.     $[eqn]$ ;13.     $[eqn]$ $[eqn]$ ;14.     $[eqn]$   $[eqn]$ $[eqn]$ 15.     $[eqn]$ then16.    $[eqn]$ 17.     end if18.     $[eqn]$ to SS;19. end for20. SS: $[eqn]$ 21. for  $[eqn]$ do22.     $[eqn]$ then23.    Return ‘not found’;24.     end if25.     $[eqn]$ then26.    $[eqn]$ ;27.    $[eqn]$ ; 28.     else29.    $[eqn]$ ;30.     end if31. end for32. $[eqn]$ to DU;33. DU: $[eqn]$ do34.     $[eqn]$ ;35. end for36. $[eqn]$

6. Security Analysis

6.1. L-Adaptive Security

Theorem 1.  We use the leakage function  $[eqn]$  to represent the leakage information of the scheme. If  $[eqn]$   and  $[eqn]$   are secure pseudo-random functions, then our DS-CKDSE scheme is  $[eqn]$ -adaptively secure against the leakage function  $[eqn]$   defined as follows:

$$[eqn]$$

where the search pattern  $[eqn]$   indicates that the keyword  $[eqn]$   was searched in the  $[eqn]$ -th query, and  $[eqn]$   is the path from the root node to the updated node.

Proof of Theorem 1. We prove Theorem 1 via a sequence of games that transition from the real game $[eqn]$ to the ideal game $[eqn]$ . By constructing a sequence of games, we finally demonstrate that real game and ideal game are computationally indistinguishable, thus completing the proof of Theorem 1. Game $[eqn]$ ( $[eqn]$ ): This game is equivalent to the real game $[eqn]$ .Game $[eqn]$ : In $[eqn]$ , instead of pseudo-random functions $[eqn]$ and $[eqn]$ , we use truly random functions. In $[eqn]$ , the PRF $[eqn]$ is used to generate the encrypted keyword $[eqn]$ and the token $[eqn]$ . Compared to $[eqn]$ , $[eqn]$ uses a mapping table $[eqn]$ to store the encrypted keyword $[eqn]$ and the token $[eqn]$ . For each keyword $[eqn]$ , if the adversary queries a repeated keyword $[eqn]$ , $[eqn]$ returns the same random value recorded in $[eqn]$ ; Otherwise, it generates a new random bit string and records it.In $[eqn]$ , the PRF $[eqn]$ is used to generate $[eqn]$ as the update trapdoor. $[eqn]$ uses a mapping table $[eqn]$ to store the trapdoor value $[eqn]$ . When the search algorithm needs to generate $[eqn]$ , $[eqn]$ already exists in the mapping table $[eqn]$ . If it exists, return the corresponding value from $[eqn]$ ; Otherwise, generate a random bit string and record it.Since the PRF and a truly random function are computationally indistinguishable, the difference is negligible. Therefore, we have:

$$[eqn]$$

Game $[eqn]$ : Compared to $[eqn]$ , we replace the hash functions $[eqn]$ , $[eqn]$ , $[eqn]$ and $[eqn]$ with random oracles in $[eqn]$ . Some tables are established to record the random values generated. If the adversary queries the random oracle with an input undefined in the update or search operations, the oracle returns a uniformly random string and records this mapping in the corresponding table. Conversely, if the input already exists in the table, the random oracle directly returns the pre-recorded corresponding output. If the adversary successfully guesses the correct input value that has not yet been defined in an update or search query while querying the random oracle, a “Bad” event occurs.We now analyze the probability of the “Bad” event occurring. In the ideal random oracle model, since the output length of each hash function is $[eqn]$ bits, the probability of an adversary successfully guessing a specific valid input in a single random attempt is $[eqn]$ . Furthermore, the adversary does not know $[eqn]$ and $[eqn]$ , which may introduce a negligible advantage, denoted as $[eqn]$ . Assume that a PPT adversary $[eqn]$ makes at most $[eqn]$ queries to the random oracle, the probability of the “Bad” event happening is then bounded by: $[eqn]$ . Since both $[eqn]$ and $[eqn]$ are negligible functions in $[eqn]$ , the probability $[eqn]$ itself is also negligible.The adversary can only observe a discrepancy between the random oracle responses in $[eqn]$ and the real hash function behavior in $[eqn]$ if the “Bad” event occurs. Since that $[eqn]$ is negligible, the difference in the output distributions of the two games from the adversary’s perspective is negligible. Hence:

$$[eqn]$$

Game $[eqn]$ : The difference between $[eqn]$ and $[eqn]$ is the randomization of the IBF bit positions. For each keyword, the bit positions in the IBF are generated randomly, each cell is mapped by $[eqn]$ hash functions. Under the random oracle model, the encoded values of these cells are computationally indistinguishable from uniformly random strings, making it infeasible for the adversary to distinguish between real encoded bits and random bits. Thus, based on the indistinguishability between the IBF random strings and the random oracle simulation, we have:

$$[eqn]$$

Game $[eqn]$ : In this game, real trapdoors and state values are replaced with simulated values. Specifically, all instances of $[eqn]$ , $[eqn]$ , and $[eqn]$ are substituted with independent random strings. The timestamp verification logic in this game relies solely on the leakage function’s parameter $[eqn]$ . The simulator can directly determine the validity of a trapdoor based on the valid time window $[eqn]$ included in the leakage $[eqn]$ , without revealing any actual timestamp information. Therefore, we have:

$$[eqn]$$

Game $[eqn]$ : In this game, instead of using real file identifiers $[eqn]$ , the simulator generates random file identifiers $[eqn]$ for each file. The encrypted form is then set as: $[eqn]$ . Since the original $[eqn]$ is fully masked by the PRF and the resulting $[eqn]$ is computationally indistinguishable from a uniform random string, the adversary cannot distinguish this change. Therefore, we have the following:

$$[eqn]$$

Game $[eqn]$ ( $[eqn]$ ): In this game, the entire system output has been replaced with simulated data. All search trapdoors $[eqn]$ , dual-state array $[eqn]$ , and encrypted file identifiers $[eqn]$ are substituted with random strings generated by the simulator, which responds solely based on the leakage function $[eqn]$ . Since all values (keywords, states, and timestamps) are simulated consistently with the defined leakage, the adversary’s view is computationally indistinguishable from that in Game $[eqn]$ . Thus:

$$[eqn]$$

Summing the indistinguishability bounds over all game transitions, we obtain the overall security guarantee:

$$[eqn]$$

□

6.2. Forward and Backward Security

Theorem 2.  Let  $[eqn]$  be the leakage function defined in Theorem 1. An  $[eqn]$ -adaptively secure DSSE scheme is forward security, if leakage function  $[eqn]$   can be written in the following form:

$$[eqn]$$

Proof of Theorem 2. Forward security guarantees that previously generated trapdoors cannot be used to search over newly added files. Each keyword $[eqn]$ is associated with a dual-state array $[eqn]$ . For the file addition operation, DO generates a random string as the new state $[eqn]$ to replace the previous state. The updated trapdoor is computed as $[eqn]$ . The new state is independent of previous states, ensuring complete randomness and confidentiality, it is computationally infeasible for an adversary to link the new state to the old one. Therefore, the search trapdoors generated before the state update cannot match the newly added files, which ensures forward security. □

Theorem 3.  An  $[eqn]$ -adaptively secure DSSE scheme is backward security, if leakage functions  $[eqn]$   and  $[eqn]$   can be written in the following form:

$$[eqn]$$ $$[eqn]$$

Proof of Theorem 3. Backward security ensures that after a document containing a keyword $[eqn]$ is deleted, it cannot be retrieved by future searches, even if the adversary retains prior search trapdoors. This scheme ensures backward security through the following two mechanisms:

• Timestamp Constraint in Trapdoor Validation: Each search trapdoor $[eqn]$ incorporates a timestamp $[eqn]$ to limit its validity. During verification, VS checks the timestamp as: $[eqn]$ . This constraint ensures that a trapdoor is only valid within a limited time window $[eqn]$ , preventing old trapdoors from being reused to retrieve deleted files.
• Incorporation of Deletion States: The DS-CKDSE scheme utilizes a dual-state array $[eqn]$ explicitly tracks both addition and deletion states for each keyword. When a document containing $[eqn]$ is deleted, the data owner generates a new random deletion state $[eqn]$ , and increments the counter $[eqn]$ . Future trapdoors are constructed using only the active addition state $[eqn]$ , which is unaffected by the deleted state. This separation prevents the server from inferring the original contents of deleted files, ensuring that adversaries cannot recover deleted files through future queries. Therefore, the DS-CKDSE scheme guarantees forward and backward security. □

6.3. KPRP Privacy

To demonstrate that our proposed scheme effectively prevents KPRP leakage, we compare it with the ODXT scheme [15]. KPRP leakage refers to the ability of a semi-honest server to learn partial intersection results of individual keyword pairs during a conjunctive query, which may allow an adversary to infer the underlying query structure through repeated observation. In this scheme, VS only stores the dual-state array $[eqn]$ for each keyword and cannot access the secure index $[eqn]$ or encrypted database $[eqn]$ . SS only stores the secure index $[eqn]$ and the encrypted database $[eqn]$ , performing index-based retrieval but unable to obtain the dual-state array $[eqn]$ for each keyword. Even if one server is compromised, due to the separation between both servers, an attacker still cannot simultaneously acquire both keyword state information and index data. Consequently, the matching results of keyword pairs cannot be reconstructed, thereby effectively preventing KPRP leakage. We present a concrete example to demonstrate the privacy improvement. Consider a database that stores five encrypted files with associated keywords, as presented in Table 2.

Suppose the user issues a conjunctive query $[eqn]$ and the corresponding document set is $[eqn]$ , which $[eqn]$ represents the set of files containing the keyword $[eqn]$ within the database $[eqn]$ . The server then checks whether these files also contain $[eqn]$ and $[eqn]$ .

In ODXT, the server can learn partial intersections such as:

$$[eqn]$$

Thus, although the final intersection result is $[eqn]$ , the server gains additional information about intermediate keyword relations, leading to KPRP leakage.

In our scheme, the trapdoor structure incorporates randomized states and timestamp factor, which prevent the server from obtaining any intermediate keyword pair matches. The server learns only the final conjunctive query $[eqn]$ result $[eqn]$ without observing the result of $[eqn]$ or $[eqn]$ . Therefore, our DS-CKDSE scheme eliminates KPRP leakage.

7. Performance Analysis

In this section, we evaluate the performance of the DS-CKDSE scheme by comparing it with existing representative DSE schemes. As shown in Table 3, we have compared our scheme with existing ones in multiple aspects. The comparison includes dynamic update efficiency, search efficiency, forward and backward security, and KPRP privacy. As seen in Table 3, our scheme and ESP-CKS [29] are the only two that meet all security requirements; however, our scheme has the advantage of superior update and search efficiency. Specially, in terms of update efficiency, our scheme achieves logarithmic growth ( $[eqn]$ ) while ESP-CKS [29] only achieves linear growth ( $[eqn]$ ). In terms of search efficiency, our scheme achieves linearithmic growth ( $[eqn]$ ), while ESP-CKS [29] only achieves quadratic growth ( $[eqn]$ ). Compared to ODXT [15], although it exhibits better update efficiency, it fails to achieve KPRP privacy. Compared to VBTree [22], although it exhibits better search efficiency, it achieves this at the cost of backward security. The experiments were implemented in Java. The experimental platform was configured with an Intel^®^ CoreTM i5-13600kf processor (Manufacturer: Intel Corporation; Assembly Location: Wuhan, China), 16 GB of RAM, and the Windows 11 operating system. The Enron email dataset [30] was used as experimental data for testing.

Update efficiency: In terms of update efficiency, we compare our proposed scheme with other conjunctive keyword search schemes such as ESP-CKS [29] and VBtree [22]. Figure 6a illustrates how update time changes with an increasing number of files. The results demonstrate that the update time of DS-CKDSE increases relatively smoothly with the number of files, without significant growth. This is attributed to the multi-bitmap index, which supports batch processing of multiple files, thereby reducing redundant operations on individual files. As a result, DS-CKDSE achieves better update efficiency and more stable performance when handling a large volume of files. Figure 6b illustrates how the update time changes with an increasing number of search keywords. Experimental results indicate that the update time exhibits a linear relationship with the number of keywords. This is due to the height of the binary tree $[eqn]$ increases with the number of keywords. Therefore, to maintain high update performance, it is essential to reasonably control the number of keywords.

Search efficiency: In terms of search efficiency, the experimental results show that the search time of DS-CKDSE is independent of the number of files, as illustrated in Figure 6c. This is due to the fact that DS-CKDSE constructs the secure index $[eqn]$ based on a full binary tree, where the search process only depends on the keyword’s path and the search process does not require traversing all files. The search time increases linearly with the number of queried keywords, as shown in Figure 6d. The height of the secure index depends solely on the number of keywords. Compared with the VBTree scheme [22], DS-CKDSE achieves more consistent search performance when handling large file sets. This is due to the fact that the tree height is only affected by the number of keywords, rather than the total number of files.

8. Conclusions

The proposed DS-CKDSE scheme simultaneously achieves forward and backward security under a dual-server architecture. By integrating a full binary tree structure, an IBF, and a multi-bitmap index, DS-CKDSE enables privacy-preserving conjunctive keyword search. The dual-server architecture separates trapdoor verification from index storage, thereby preventing KPRP leakage. Additionally, the dual-state array and timestamp mechanism jointly ensure that the scheme achieves forward and backward security. This design effectively mitigates the leakage of information entropy during the system’s search and update processes. Through a sequence of games, we prove that the scheme is $[eqn]$ -adaptively secure under the defined leakage function $[eqn]$ . The experimental results show that the scheme maintains high efficiency in both update and search operations.