Updatable Multi-User Dynamic Searchable Encryption Scheme with Bidirectional Verification

Abstract

Among searchable encryption techniques, multi-user dynamic searchable encryption (MUDSE) schemes are an important research direction. After the data owner transfers data to the cloud, it may be necessary to authorize different users to access some or all of the data while allowing for dynamic updates. Enabling dynamic data sharing in cloud storage while preserving users’ ability to search the data is crucial for promoting data flow and maximizing its value. This approach is particularly significant in addressing the data silo problem. However, existing security mechanisms remain imperfect, and most current scenarios assume that cloud servers are merely “curious but honest”. In reality, cloud servers may exhibit malicious behavior, such as returning incorrect or incomplete search results. Similarly, malicious users might falsify search results—for example, to avoid payment—or collude with cloud servers to steal other users’ search privacy. To address these challenges, this paper proposes an updatable multi-user dynamic searchable encryption scheme with bidirectional verification. The scheme enables secure dynamic data sharing in multi-user scenarios by constructing an index structure using homomorphic message authentication codes and bitmaps. This ensures secure updates to encrypted data without revealing the relationship between files and keyword search keys while providing forward and backward security. Regarding privilege management, the scheme employs updatable keys, ensuring that users can only generate valid search commands if they possess the latest encryption key. Additionally, blockchain technology is introduced to assist in verifying user honesty. Through actual testing and security analysis, the proposed solution demonstrates improved search speed over traditional methods while maintaining security. It also exhibits high adaptability for handling frequently changing cloud data.

1. Introduction

With the rapid growth of data volume, locally stored and processed data face limitations due to the restricted storage capacity and parallel computing capabilities of terminal devices [1]. As a result, average users struggle to meet the storage demands of ultra-large-scale datasets [2]. Meanwhile, cloud storage services have emerged as a popular alternative, attracting a vast number of users to upload substantial amounts of private data. However, due to weak data protection awareness, technical vulnerabilities, malicious attacks, and profit-driven motives, issues such as data leaks, unauthorized access, illegal data trading, and privacy breaches have become prevalent [3].

To mitigate these risks, encrypting uploaded data has become essential to prevent privacy violations. This ensures that even if adversaries compromise the cloud server, they cannot extract meaningful information from the ciphertext [4]. For robust security, users retain exclusive control over encryption keys, restricting the cloud server to accessing only ciphertext and preventing it from performing additional operations. Among these operations, data retrieval is the most fundamental, as it enables extracting specific information from large datasets, facilitating subsequent data integration and sharing [5]. Traditional encryption methods require downloading all data locally for encryption and decryption, which imposes high demands on system memory and encryption algorithms. Efficiently utilizing ciphertext data remains a critical challenge in information security and a key research focus in both academia and industry.

The emergence of searchable encryption (SE) [6] provides an innovative solution to this problem. This framework allows users to construct verifiable index structures on encrypted data, implemented in three key phases: First, salient keywords are extracted from the original documents, followed by the synchronized upload of encrypted documents and their associated indexes. Next, when initiating a search request, the user generates a specific trapdoor function and submits it to the server. Finally, the cloud server employs pattern-matching algorithms to return the qualified result set.

In the context of big data, the explosive growth of private data has become the norm [7], and cloud-stored ciphertexts undergo continuous additions and deletions, exhibiting dynamic characteristics. Thus, achieving fast and accurate retrieval from vast, dynamically changing datasets remains a critical challenge. Traditional methods involve downloading indexes, performing local updates, and re-uploading modified indexes—a process that is inefficient and burdensome under frequent updates. To address this, dynamic symmetric searchable encryption (DSSE) has emerged [8,9], enabling users to dynamically modify ciphertexts and indexes while maintaining consistency. This ensures secure and efficient updates to searchable ciphertexts. While existing SE techniques have preliminarily addressed secure queries in dynamic environments, they still face numerous challenges in handling massive datasets, including scalability, efficiency, and security trade-offs.

1.1. Related Works

Searchable encryption (SE) technology, as a pivotal solution in the field of ciphertext retrieval, primarily aims to achieve controlled query functionality over encrypted data. Based on cryptographic architectures, SE can be classified into public-key encryption with keyword search (PEKS) [6] and symmetric searchable encryption (SSE) [10].

In the public-key paradigm, Boneh et al. [6] pioneered the PEKS mechanism in 2004. While PEKS demonstrates advantages in multi-user collaborative scenarios, its practical adoption is hindered by the high computational complexity stemming from bilinear pairing operations, resulting in significant efficiency challenges. In contrast, symmetric searchable encryption (SSE) offers superior computational efficiency, making it more suitable for single-user-dominated data storage and retrieval scenarios. The foundation of SSE research dates back to 2000, when Song et al. [10] proposed a two-layer encryption framework, enabling cloud servers to perform ciphertext scanning through a specialized cryptographic structure.

In the field of multi-user searchable encryption, Curtmola et al. [11] pioneered the integration of broadcast encryption mechanisms [12] into the multi-user symmetric searchable encryption (MSSE) framework. Building upon this foundation, Bao et al. [13] innovatively proposed a distributed user management model, significantly enhancing the system scalability of the encryption scheme. Regarding the extension of search functionality, Jarecki [14] and Sun et al. [15] independently adapted Cash’s single-user scheme [16] for multi-user scenarios, constructing conjunctive keyword search models. To address security threats from malicious users, Popa et al. [17] introduced the multi-key searchable encryption (MKSE) architecture, achieving fine-grained access control through an authorization conversion mechanism. In pursuit of optimal security-practicality trade-offs, Hamlin et al. [18] proposed two innovative approaches: the first employs a data replica isolation strategy that eliminates cross-user leakage at the cost of O(n) storage overhead, while the second [19] constructs a lightweight index based on indistinguishability obfuscation. Subsequent improvements by Patel et al. [20] introduced dynamic obfuscation factors to control keyword leakage probability under a single-copy storage architecture, though this approach remains vulnerable to semantic leakage when honest and malicious users access overlapping documents. Wang et al. [21,22] achieved a refined balance between performance and security through a triple-optimization strategy: reducing cross-user leakage to negligible levels, optimizing search time complexity, and effectively defending against historical data backtracking attacks. This comprehensive approach represents significant advancement in secure multi-user searchable encryption systems.

In the field of dynamic searchable encryption, Kamara et al. [8] pioneered the use of an inverted index architecture, achieving a breakthrough solution that supports dynamic updates. While this scheme overcomes the functional limitations of static systems, it introduces additional overhead in storage efficiency and computational complexity, along with potential keyword information leakage during document insertion. A significant milestone in DSSE (dynamic searchable symmetric encryption) technology was marked by Cash et al. [23] in 2016 with their index optimization scheme. By constructing a two-layer hash index structure, they reduced storage overhead from the traditional O(n²) to O(n) while limiting information leakage to the operation type and the number of matched documents. This breakthrough achieved, for the first time, a balance between storage efficiency and privacy protection, with its leakage model later termed the “Minimal Leakage Principle” in subsequent research. To address the inherent information leakage risks in DSSE systems, Stefanov et al. [24] established a dynamic operation security framework in 2017, systematically defining forward security and backward security mechanisms. Forward security employs a layered encryption strategy to isolate update operations from historical data correlations, ensuring that newly added documents do not reveal prior search patterns. Backward security, on the other hand, utilizes logical deletion chains to eliminate residual index traces after deletion operations, effectively defending against historical data backtracking attacks.

Most existing schemes predominantly assume that cloud servers are honest but curious. This means cloud servers comply with protocol requirements, neither actively disrupting system operations nor altering data, while attempting to extract additional information from processed data. However, in real-world scenarios, when cloud servers are compromised or misconfigured, they may return erroneous search results, thereby compromising the accuracy of user queries. In recent years, blockchain-based verification schemes for searchable encryption [25,26] have demonstrated significant improvements in system security. These approaches substantially reduce reliance on intermediate entities and effectively prevent data tampering and theft by malicious adversaries, thereby ensuring the correctness and integrity of user search results.

1.2. Our Motivation and Contributions

Most existing searchable encryption schemes remain confined to the single-data-owner paradigm, where only the data uploader can perform search operations using specific trapdoors. However, as application scenarios continue to expand in both data scale and user base, multi-user data sharing and collaborative access have become essential requirements. Traditional single-user architectures can no longer adequately meet the functional demands of modern distributed systems. Against this backdrop, searchable encryption techniques supporting multi-user collaborative retrieval have emerged as a crucial research direction in cryptography. Although some of the research on searchable encryption technology has realized the data sharing function to a certain extent, it faces multidimensional security challenges in the dynamic data environment. First, with the real-time update of data resources and the complexity of application scenarios, the traditional static encryption model has found it difficult to cope with the security hazards arising from the dynamic updating process; specifically, the problem of forward privacy and backward privacy during the iteration of data versions needs to be solved urgently. Secondly, the dynamic management mechanism of access rights under multi-user collaboration scenarios has not yet been perfected, and there are systematic defects in key updating and access control policy adjustment in the process of rights change, which constitutes a key constraint in breaking the phenomenon of data silos and promoting the efficient circulation of data.

The first issue faced in this scenario is the management of user access rights, which refers to how the data owner controls which data users can access the data and which cannot. It is also necessary to consider changes in the access rights of data users, such as how to revoke the access rights of users when the rights of use purchased by them expire. To solve this problem, existing work combines a searchable encryption scheme with a broadcast encryption scheme to send a secret message to users with access rights using broadcast encryption. When a user is revoked, the secret message has to be regenerated and sent to all data users with access rights at the moment; however, this method does not support the data owner to update the data. Although the existing work can make use of the proxy server to manage the access rights of users, ensuring that only users in the legitimate access list can obtain the valid secret information returned by the proxy server when searching for data and complete the search for data. In most existing schemes, only forward security can be achieved, and backward security cannot be guaranteed when deleting data. This chapter further explores how to design a more efficient and secure solution that achieves both forward and backward security while also managing user access rights without the involvement of a proxy server.

It is worth noting that this technology also needs to deal with the credible challenges in the cloud service environment:driven by economic interests or system failures and other factors, the cloud service provider may return incomplete or biased search result sets, while private users may refuse to pay and thus return “dishonest” results, which will seriously threaten data availability and system reliability. Therefore, it is necessary to study multi-user dynamic searchable encryption that supports authentication.

To achieve secure multi-user dynamic ciphertext sharing with bidirectional verification, the core concept involves constructing a security-controlled sharing platform. This platform employs a bidirectional verification mechanism to ensure data update integrity while realizing dynamic access management through key update strategies. For the one-to-many sharing model of dynamic data, we utilize homomorphic message authentication codes (HMACs), binary bitmaps, and pseudo-random functions (PRFs) to construct a dynamic index structure. Each keyword corresponds to a bitmap matching the file count, where 1/0 markers indicate keyword–file associations. PRFs randomize bitmap position mapping, while HMACs combined with keyword-specific keys complete bitmap encryption.

During data updates, leveraging the homomorphic property, updated HMACs can be generated through linear combination of original authentication codes and differential authentication codes, thereby achieving synchronous key updates. For fine-grained access control, a key fragmentation mechanism enables dynamic permission granting and revocation. When a data owner authorizes access to a user, only the target keyword’s key and current-state differential HMACs are distributed. For permission revocation, the owner simply restricts the user’s access to subsequent differential HMACs without requiring a reconstruction of private key information.

Finally, leveraging blockchain’s tamper-proof characteristics, bidirectional verification is implemented: cloud server results undergo blockchain auditing, while user behavior authenticity is verified through HMAC. Formal security proofs and experimental evaluations demonstrate that our solution satisfies both forward security and backward security, while significantly reducing computational and communication overhead in multi-user scenarios.

To sum up, the main contributions are as follows:

• The scheme achieves dynamic search key updates, thereby enabling real-time adjustment of user data access privileges. It enables dynamic security maintenance of encrypted information during user searches, where updated ciphertexts become inaccessible to search operations using pre-update keys. This mechanism provides effective defense against file injection attacks during data addition operations while preventing sensitive information leakage during deletion processes.
• Capture forward security and backward security. When authorizing a user to access specific keywords, the data owner distributes the corresponding keyword-specific key and current differential HMACs to the target user. For permission revocation, the data owner neither needs to modify the master key nor reconstruct the cryptographic material; instead, it suffices to restrict the target user’s access to subsequent differential HMAC updates.
• The immutability property of blockchain is leveraged to verify the integrity of cloud-returned results, while user behavior authenticity is validated through HMAC-based authentication.

A comparison of our scheme with the existing schemes is given in

Table 1. A comparison of our scheme with the existing schemes.

Scheme	Forward Security	Backward Security	Key Updating	Bidirectional Verification	Multi-User
Mitra [27]	yes	yes	no	no	no
BASE [28]	yes	yes	no	no	no
CLOSE [29]	yes	no	no	no	no
ROSE [30]	yes	yes	yes	no	no
Ours	yes	yes	yes	yes	yes

.

1.3. Organization

Section 2 reviews some of the basic primitives used in this paper. Section 3 presents the security model and the specific structure of our proposed scheme. In Section 4, the security of this scheme is analyzed and proved. In Section 5, we compare and analyze the efficiency and feasibility of our scheme through simulation experiments. Finally, in Section 6, we conclude and look forward to future work.

2. Preliminaries

2.1. Notations

The notations are shown in

Table 2. Notation description.

Notations	Descriptions
$H_1,H_2,H_3$	Keyed hash functions
$H_4,\left\{P\right\},\left\{Q\right\}$	Family of hash functions
$\omega$	Keywords
n	File capacity within the index
t	Moment t
$W^t$	The set of keywords at moment t
$D^t$	Collection of documents at time t
p	Serial number of the column
EDB	Encrypted database
$A^t$	Explicit index at moment t
$B^t$	Ciphertext index at time t
$d_p^t$	The plaintext of the file in column p
$\Delta D$	Updating document collections
$\Delta W$	Updating keyword collections
$v^t$	The set of authentication labels
${\beta }_{\omega }^t$	Ciphertext index of the keyword
$R_{\omega }^t$	The retrieved set of keywords

.

2.2. Basic Primitives

2.2.1. Negligible Function

Assuming that an adversary is able to decipher an encryption scheme within polynomial time complexity poly(n), the encryption scheme is determined to be computationally insecure. Conversely, an encryption scheme is considered computationally secure when the probability of success of an adversary in deciphering the scheme within polynomial time complexity is less than ${\displaystyle \frac{1}{poly\left(n\right)}}$. This probability threshold ${\displaystyle \frac{1}{poly\left(n\right)}}$ is defined as negligible probability. Its mathematical formalization is described as follows:

Definition 1

(Negligible Function). For any function $negl:N\to R$, if for any polynomial function poly(n), $x\in \mathbb{N}$, there exists a natural number $\lambda \in N$ such that for any $x>\lambda$, the following is satisfied:

$$negl\left(x\right)<{\displaystyle \frac{1}{poly\left(n\right)}}$$

Then, the function negl(x) is treated as negligible.

2.2.2. Pseudo-Random Function

A pseudo-random function (PRF) [31] is a cryptographic tool that simulates real random behavior through deterministic algorithms and has a wide range of applications in various cryptosystems. The method has a certain degree of randomness, but its essence is a family of mathematical functions built on the basis of deterministic algorithms. For any input pseudo-random function, the output is a random variable. Given a key (seed) and input, it is able to output seemingly random values but can reproduce the result with the same seed. The algorithm produces a fixed sequence based on the seed, and the same input must yield the same output. Under computational complexity theory, polynomial time algorithms cannot distinguish between the PRF outputs and the true random sequences. The security of the seed directly determines the unpredictability of the function’s outputs, and a leakage of the seed will lead to the exposure of the full sequence. The following is a formal definition of a pseudo-random function.

Definition 2

(Pseudo-random function). If a function $F:K\times X\to Y$ is considered as a safe pseudo-random function, its dominance is defined for any polynomial time adversary A as follows: $Ad{v}_{A,F}^{PRF}\left(x\right)=|Pr[A^{F(k,·)}\left(x\right)=1]-Pr[A^{f(·)}\left(x\right)=1]|\le negl\left(x\right)$ where negl(x) is a negligible function, $k\leftarrow K$, and f is a true random function mapping from X to Y.

2.2.3. Homomorphic Message Authentication Code

A homomorphic message authentication code (HMAC) is a new cryptographic tool that integrates homomorphic encryption and a message authentication mechanism. Its core function is to support the computational verification of ciphertext data, i.e., to verify the integrity and authenticity of remote computation results without decrypting the ciphertext. The technique has the synergy of pseudo-random functions and homomorphic encryption algorithms, allowing third parties to perform specific operations (e.g., addition, multiplication) on encrypted data, and the resulting computation results can still be verified.

In this paper, the role of homomorphic message authentication codes is mainly to verify whether the data have been tampered with or not. Since cloud servers are not always honest and trustworthy, users have to perform a lot of computational work on the data stored in cloud servers. In addition to key techniques, such as verifiable computation and storage proxies, homomorphic authentication-based methods have received much attention for authenticating the results of computation. Here, a more efficient homomorphic message authentication code proposed by Catalano and Fiore [32] is introduced, whose security relies solely on the existence of pseudo-random functions. The following is its formal definition.

Definition 3

(Homomorphic Message Authentication Code). A secure homomorphic message authentication code scheme contains the following four-stage polynomial time algorithm:

• Key generation: $HMAC.KeyGen:1^{\lambda } to (sk,ek)$. This key generation algorithm inputs a security parameter λ and outputs a user private key sk and a user computation key ek.
• Authentication: $HMAC.Auth:(sk,v,m)\to \omega$. This authentication algorithm inputs a user private key sk, any message m in the message space M and its corresponding input label v, and it outputs the authentication label ω for this message m.
• Verification: $HMAC.Ver:(sk,m,Pr,\omega )\to 1 or 0$. This authentication algorithm inputs a user private key sk, any message m in the message space M, a program $Pr=(F,v_1,v_2,\dots ,v_n)$ and an authentication label ω for m. The output is either 1 or 0, where 1 means that the authentication has passed and 0 means that the authentication has failed.
• Evaluation: $HMAC.Eval:(ek,F,\overrightarrow{\omega })\to \omega$. This evaluation algorithm takes as input a computational key ek, a computational function F, and a vector $\overrightarrow{\omega }$ with respect to the authentication tags, and it outputs a new authentication tag ω.

Note that this scheme is combinatorial; the authentication tags output by the computational algorithm can be used again as input to this computational algorithm. For example, the computational algorithm outputs ${\omega }_1,{\omega }_2,\dots ,{\omega }_n$, a total of n authentication labels corresponding to different authentication information $m_1,m_2,\dots ,m_n$, if the computational algorithm is fed again with ${\omega }_1,{\omega }_2,\dots ,{\omega }_n$ and a program P to obtain a new authentication tag $\omega$. The output obtained by the program P and $m_1,m_2,\dots ,m_n$ outputs the obtained new message m. Then, due to the combinatorial nature of the program, it is made that $\omega$ is the authentication label of message m.

2.3. Symmetric Searchable Encryption

Symmetric searchable encryption (SSE) is constructed based on a symmetric encryption system and cryptographic primitives to support the retrieval operation of ciphertext data in non-trusted environments, aiming to ensure data privacy and security during the retrieval operation.

Definition 4

(Symmetric Searchable Encryption). A symmetric searchable encryption algorithm includes the following three specific algorithms:

• Initialization: $Setup(DB,\lambda )\to (\alpha ,k,EDB)$: This algorithm takes the original database DB and the security parameter λ as inputs to generate the encrypted database EDB. The client transmits the generated EDB to the third-party cloud storage provider, while the key k and the system state α are securely stored locally.
• Search: $Search(k,\omega ,\alpha ,EDB,t)\to ({\alpha }^{\prime },t,r,ED{B}^{\prime })$: This protocol runs as an interactive process between the client and the cloud server. The client calls the locally securely stored encryption key, combines the keywords to be checked ω to generate the search token t, and updates the system state to ${\alpha }^{\prime }$. After receiving the token t, the cloud service provider executes the search operation based on the EDB, and finally returns the matching result r to the client. At the same time, it completes the update iteration of the encrypted database EDB.
• Update: $Update(k,\alpha ,EDB,DB)\to ({\alpha }^{\prime },EDB,ED{B}^{\prime })$: This protocol is implemented as a two-way communication mechanism between the client and the cloud server. The client performs symmetric encryption of the original database DB using key k, generates a new encrypted database EDB and updates the system state to ${\alpha }^{\prime }$. The newly encrypted data are transmitted over a secure channel to the cloud server for storage, and the cloud server thus completes the update iteration of the EDB.

3. Security Models and Construction of Our Proposed Scheme

In this section, we now introduce the security definition, the system framework and the scheme description.

3.1. Security Models

3.1.1. Adaptive Security

In the field of searchable encryption, most of the existing schemes allow a specific degree of privacy leakage in order to improve the retrieval efficiency as compared to high-cost techniques such as multi-party computation with full homomorphic encryption. The information leakage of dynamic searchable encryption (DSSE) schemes can be formally described as follows [24]: $\left(L_{Setup},L_{Search},L_{Update}\right)$.

The model allows an attacker A to obtain system information by performing initialization, retrieval, and data update processes. The security of DSSE is formally verified through a framework of real-world and ideal-world experiments. This study has definitions for two games: $Rea{l}_{Game}$ denotes a game that simulates the operation of a real system, and $Idea{l}_{Game}$ denotes a game that operates in an ideal experimental environment. If the attacker is unable to distinguish between the two types of experiments, the scheme is judged to satisfy the security requirements.

In the real world, the system strictly follows the protocol specification: Firstly, the encrypted database EDB is generated by $Setup(DB,\lambda )$ and transmitted to the attacker, who can select the keyword $\omega$ to initiate the $Search(k,\omega ,\alpha ,EDB,t)$ query and can select the set of documents EDB to receive $Update(k,\alpha ,EDB,DB)$ response. Then, the encrypted database outputs the adjudication bit $\mathit{b}\in$ 0,1.

In the ideal experiment, the simulator S reconstructs the system response based on the leakage function: the simulated EDB is generated using $S\left(L_{Setup}\left(\lambda \right)\right)$ and transmitted to the attacker, who performs the retrieval and update operations based on the leakage functions $S\left(L_{Search}\left(\omega \right)\right)$ and $S\left(L_{Update}(EDB,op)\right)$ and ultimately outputs the judgment bit $\mathit{b}\in$ 0,1 in the simulated environment. In this case, op is an ‘add’ or ‘delete’ operation that dynamically updates data.

Definition 5

(Adaptive Security). A DSSE scheme satisfies the adaptive security requirement if and only if there exists a probabilistic polynomial time simulator S, such that for any probabilistic polynomial time attacker A both satisfy the following:

$$|Pr[Idea{l}_{Game}\left(\lambda \right)=1]-Pr[{\mathrm{Real}}_{Game}\left(\lambda \right)=1]|\le negl\left(\lambda \right).$$

3.1.2. Forward and Backward Security

As the key indexes for evaluating the security of dynamic searchable encryption schemes, forward security and backward security [24,33] provide protection mechanisms for different operations, respectively. Forward security aims to ensure the security of the op=add operation of adding documents in dynamic searchable encryption, and schemes with forward security features can effectively prevent document injection attacks. Backward security, as a security standard for document deletion operations, is categorized into three levels of security strength based on the difference in the degree of information leakage. The next step is to define the formalization of forward and backward security.

Forward security means that the add document operation must not expose the correlation between the historical search keywords and the added document. The formalization for forward security is defined as follows:

Definition 6

(Forward Security). When a dynamic searchable encryption scheme can satisfy the definition of forward security, then its corresponding update leakage function $L_{Update}$ needs to satisfy the following mathematical constraints:

$$S\left(L_{Update}(EDB,op)\right)=S\left(L_{Update}^{\prime }\left(\right\{i{d}_x,|W_{i{d}_x}\left|\right\},op)\right).$$

The above definition indicates that if a dynamic searchable encryption scheme is forward secure, there is no way for the scheme to synchronize the exposure of the corresponding operator op, the document identifier id, and the number of keywords involved in the document update.

Backward security [24] requires dynamic searchable encryption schemes to prohibit the disclosure of any information related to an entry during the execution of a delete operation. However, such schemes may lead to a significant decrease in search efficiency. For this reason, Bost et al. proposed three gradations of backward security (BP-I, BP-II, and BP-III) based on the differences in the degree of information leakage to balance security and search efficiency. These three levels correspond to different tiers of leakage: BP-I has the lowest amount of information leakage, while BP-III has the highest. In order to systematically characterize these three leakage levels, partial functions need to be predefined.

Let the function Q denote the set of operations associated with each entry. In the entry retrieval process, define t as the timestamp and $\omega$ as the keyword to be queried.

The first function that is defined is the Time function, whose function is to return the keyword (t, id) associated with all the added operations, which is formally defined as follows:

$$\mathrm{Time}=\left\{(t,id)\right|(t,add,(\omega ,id))\in Q\wedge \forall t^{\prime },(t^{\prime },del,(\omega ,id))\notin Q\}.$$

The second function Update is used to extract the timestamp of the database update operation, which is formally defined as follows:

$$Update=\left\{t|\left(t,add,(\omega ,id)\right)\in Qor\left(t^{\prime },del,(\omega ,id)\right)\in Q\right\}.$$

The third function, Delete, is used to return the set of timestamps corresponding to the delete operation, which is formally defined as follows:

$$Delete\left(\omega \right)=\left\{(t^{add},t^{del})|\exists id:\left(t^{add},add,(\omega ,id)\right)\in Q\wedge \left(t^{del},del,(\omega ,id)\right)\in Q\right\}.$$

Based on the above three functions, backward security can be formally defined as follows:

Definition 7

(Backward Security). If an adaptive dynamic searchable encryption scheme needs to satisfy backward security, it must fulfill the following conditions:

• BP-I level backward security (Backward Privacy type-I):

  $$L_{Update}(op,\omega ,id)=L^{\prime }\left(op\right)and{L}_{Search}\left(\omega \right)=L^{″}(Time\left(\omega \right),k)$$
• BP-II level backward security (Backward Privacy type-II):

  $$L_{Update}(op,\omega ,id)=L^{\prime }(op,\omega )and{L}_{Search}\left(\omega \right)=L^{″}\left(Time\left(\omega \right),Update\left(\omega \right)\right)$$
• BP-III backward security (Backward Privacy type-III):

  $$L_{Update}(op,\omega ,id)=L^{\prime }(op,\omega )and{L}_{Search}\left(\omega \right)=L^{″}\left(Time\left(\omega \right),Delete\left(\omega \right)\right)$$

Note that the functions L′ and L″ are both defined as stateless functions in such models.

3.2. System Framework

There are four core entities in this scheme: A data owner responsible for data encryption and authority management. A data user performing retrieval requests and decryption operations. A cloud server undertaking ciphertext storage and computation tasks. A blockchain supported by distributed ledger technology realizing operation auditing and key verification. These four core entities together constitute the system model of the program, which will be introduced in detail below. The scheme model architecture is shown in Figure 1.

• Data Owner:

As the controlling body of data resources, the core responsibility of a data owner includes encrypting the original data, extracting the feature keywords and generating the index structure from the original dataset, and then completing the index encryption operation, and finally transmitting the encrypted data collection to the cloud storage node securely. In the dynamic data change scenario, including the addition or removal of data items, the subject needs to synchronize the maintenance of the corresponding encrypted database and the update of the necessary parameters involving the key system to the authorized users to ensure that the retrieval operation is always performed based on the latest version of the data collection. The subject of this operation is preset to be fully trusted, and its behavioral pattern strictly follows the protocol specification of the scheme.

• Data User:

As the subject of authorized data access, data users are granted retrieval permission by the data owner and obtain key system related parameters for data query operations. When the subject initiates a retrieval request, the key parameters are utilized to transform the retrieval keyword into an encryption key, which is transmitted to the cloud server through a secure channel. The cloud server performs the retrieval operation and returns the corresponding dataset to the requesting party. When there is doubt about the returned dataset, the result can be verified through the data owner. The operation endpoint is preconfigured as a technical execution unit with limited trust attributes, and its behavioral pattern, while following established protocols, presents a potential risk of incomplete reliability.

• Cloud Server:

As a core component of the distributed computing architecture, the cloud server possesses superior computing performance and ample storage resources. Its core functions include securely storing encrypted databases submitted by data owners and providing retrieval services to authorized users. The entity keeps the encrypted dataset intact for both the initial submission and subsequent updates by the data owner. Upon receiving the query command from the data user, the system performs the retrieval operation by invoking the stored encrypted database and the search key, and it finally returns the processing result to the requesting party. This computing node is set to be semi-honest, and it may run the complete algorithmic protocol with incomplete or biased feedback information due to computational errors; at the same time, driven by interests, it may try to parse the sensitive information in the ciphertext database while following the protocol specifications, which happens from time to time in real scenarios.

• Blockchain:

A blockchain based on distributed ledger technology is naturally equipped with tamper-proof features and distributed fault-tolerant mechanisms. These core mechanisms provide infrastructure support for trusted data interactions. The network adopts a federated chain architecture, and its node access mechanism is limited to data controllers and authenticated member nodes. After completing a data sharing or version update operation, the data owner needs to synchronize the relevant auxiliary parameters to the blockchain. The architecture maintains an encrypted index library and returns the corresponding ciphertext dataset to the data requestor based on the authorization token. When receiving the update credentials from the data owner, the system performs the key rotation operation based on the update credentials. When an authorized user initiates a keyword search, they need to obtain the authentication-related parameters from the distributed ledger to perform the search and authentication process.

3.3. Scheme Description

For ease of presentation, we name the proposed updatable multi-user dynamic searchable encryption scheme with bidirectional authentication support BVUMU-DSSE, which contains six core algorithms, namely the initialization algorithm, the data update algorithm, the ciphertext search algorithm, the user authorization algorithm, the decryption algorithm, and the result verification algorithm. A flow chart of the scheme is shown in Figure 2. The initialization algorithm generates the system public parameters and the master private key based on the input security parameters, the update protocol regulates the data owner to perform the generation and maintenance of the ciphertext database, the ciphertext search algorithm contains the data user to generate the search key, and the cloud service provider performs the ciphertext retrieval process based on the key. The user authorization algorithm distributes the corresponding key to the authorized user, the decryption algorithm and the authentication algorithm are used to decrypt the retrieval results and verify the integrity of the results; at the same time, they are used verify the honesty of the user.

• Setup: $1^{\lambda }\to (PP,SK)$.

The data owner inputs the security parameters. Execute the initialization algorithm to generate the keys and hash functions that are required by the system according to the security parameters. In the specific implementation, the data owner will randomly select three keyed hash functions $H_1,H_2,H_3$ according to the security parameter $\lambda$, randomly select the hash function $H_4$ as well as two families of hash functions P and Q (used for the index generation and encryption operations), and generate the master key $K_W$, $E{K}_W$ and the file encryption key $K_D$.

Finally, the output of this initialization algorithm outputs the public parameters $PP=\{H_1,H_2,H_3,H_4\}$ and saves the private key $SK=(K_W,E{K}_W,K_D,\left\{P\right\},\left\{Q\right\})$.

• Update: $(PP,SK,ED{B}^t,\Delta D,\Delta W)\to (ED{B}^{t+1},\Delta v^t)$.

The data owner generates or updates the ciphertext data with index $ED{B}^t$ at different time nodes t through a dynamic maintenance mechanism as follows. The update algorithm pseudo-code is shown in

Table 3. The update algorithm pseudo-code.

Protocol 2: Update
$Input:PP,Sk,D,W,ED{B}^t$
$Output:\Delta u^t,ED{B}^{t+1}$
1$:\mathrm{if}\mathrm{t}=0\mathrm{then}$	51:         $p\leftarrow P^{t+1}\left(d\right)$
2$:\mathrm{for}1\le \mathrm{p}\le \mathrm{n}$	52:         $C_p^{t+1}\leftarrow En{c}_{k_p}\left(d\right)$
3$:{\mathrm{k}}_{\mathrm{p}}\leftarrow {\mathrm{H}}_3({\mathrm{K}}_{\mathrm{D}},\mathrm{p})$	53:         $C_D^{t+1}\leftarrow C_D^{t+1}\cup C_p^{t+1}$
4:      end for	54:      end for
5:      $\mathrm{for}d\in D$	55:      if p does not match files then
6:         $p\leftarrow P^t\left(d\right)$	56:         ${\rho }_p\leftarrow {\{0,1\}}^{*}$
7:         $C_p^t\leftarrow En{c}_{k_p}\left(d\right)$	57:         $C_D^{t+1}\leftarrow C_D^{t+1}\cup C_p^{t+1}$
8:         $C_D^t\leftarrow C_D^t\cup C_p^t$	58:      end if
9:      end for	59:      $\mathrm{for}\omega \in W^{t+1}$
10:      if p does not match files then	60:         ${\alpha }_{\omega }^{t+1}\leftarrow (a_1,\dots ,a_n)$
11:         ${\rho }_p\leftarrow {\{0,1\}}^{*}$	61:         ${\sigma }_{\omega }^{t+1}\leftarrow H.Auth(k_{\omega },\rho ,{\alpha }_{\omega }^{t+1})$
12:         $C_D^t\leftarrow C_D^t\cup C_p^t$	62:         ${\beta }_{\omega }^t\leftarrow En{c}_{{\sigma }_{\omega }^t}\left({\alpha }_{\omega }^t\right)$
13:      end if	63:         $\Delta {\alpha }_{\omega }^t\leftarrow {\alpha }_{\omega }^{t+1}-{\alpha }_{\omega }^t$
14:      $\mathrm{extract}W=\left\{\omega \right\}\mathrm{from}\mathrm{D}$	64:         $\Delta {\alpha }_{\omega }^t\leftarrow {\alpha }_{\omega }^{t+1}-{\alpha }_{\omega }^t$
15:      $\mathrm{for}\omega \in W$	65:         $\Delta {\sigma }_{\omega }^t\leftarrow H.Auth(k_{\omega },\rho ,{\alpha }_{\omega }^{t+1})$
16:         $k_{\omega }\leftarrow H_1(K_W,H_4\left(\omega \right))$	66:         $\Delta v^t\leftarrow \Delta v^t\cup \left\{(\omega ,\Delta {\sigma }_{\omega }^t)\right\}$
17:         $e{k}_{\omega }\leftarrow H_2\left(E{K}_W,H_4\left(\omega \right)\right)$	67:      end for
18:         ${\alpha }_{\omega }^t\leftarrow (a_1,\dots ,a_n)$	68:      $Q^{t+1}\leftarrow (\left\{Q\right\},t+1)$
19:         $a_i=1\mathrm{when}\mathrm{the}\mathrm{file}\mathrm{contains}\omega$	69:      $\mathrm{for}\mathrm{all}\omega$
20:         ${\sigma }_{\omega }^t\leftarrow HMAC.Auth(k_{\omega },\rho ,{\alpha }_{\omega }^t)$	70:         $i^{t+1}\leftarrow Q^{t+1}\left({\sigma }_{\omega }^{t+1}\right)$
21:         $i\leftarrow Q^t\left({\sigma }_{\omega }^t\right)$	71:      end for
22:         $v^t\leftarrow v^t\cup \left\{(\omega ,{\sigma }_{\omega }^t)\right\}$	72:      $A^{t+1}\leftarrow ({\alpha }_1^{t+1},{\alpha }_2^{t+1},\dots ,{\alpha }_n^{t+1})$
23:         ${\beta }_{\omega }^t\leftarrow En{c}_{{\sigma }_{\omega }^t}\left({\alpha }_{\omega }^t\right)$	73:      $B^{t+1}\leftarrow ({\beta }_1^{t+1},{\beta }_2^{t+1},\dots ,{\beta }_n^{t+1})$
24:      end for	74:      $\mathrm{send}ED{B}^{t+1}$ to cloud server
25:      $A^t\leftarrow ({\alpha }_1^t,{\alpha }_2^t,\dots ,{\alpha }_n^t)$	75:      send $t+1,Q^{t+1},B^{t+1}$ to blockchain
26:      $B^t\leftarrow ({\beta }_1^t,{\beta }_2^t,\dots ,{\beta }_n^t)$	76:      send $\Delta {\upsilon }^t$ to data users
27:      $\mathrm{send}ED{B}^t=(t,Q^t,B^t,C_D^t)$	77:   end
28:   else
29:      $\mathrm{generate}\Delta D,\Delta W$
30:      $D^{t+1}\leftarrow D^t$
31:      $W^{t+1}\leftarrow W^t$
32:      $\mathrm{for}\mathrm{all}d\in \Delta D$
33:      $Output:\Delta u^t,ED{B}^{t+1}$
34:         $\mathrm{if}op\left(d\right)$=“add” then
35:            $D^{t+1}\leftarrow D^t\cup \left\{d\right\}$
36:         else
37:            $D^{t+1}\leftarrow D^t-\left\{d\right\}$
38:         end if
39:      end for
40:      $\mathrm{for}\omega \in \Delta W$
41:         $\mathrm{if}op\left(\omega \right)$= =“add” then
42:            $W^{t+1}\leftarrow W^{t+1}\cup \left\{\omega \right\}$
43:            $k_{\omega }\leftarrow H_1(K_W,H_4\left(\omega \right))$
44:            $e{k}_{\omega }\leftarrow H_2(E{K}_W,H_4\left(\omega \right))$
45:         else
46:            $e{k}_{\omega }\leftarrow H_2(E{K}_W,H_4\left(\omega \right))$
47:         end if
48:      end for
49:      $P^{t+1}\leftarrow (\left\{P\right\},t+1)$
50:      $\mathrm{for}d\in D^{t+1}$

.

When t = 0, which corresponds to the initialization phase, this means the first instance of ciphertext database construction: The data owner assigns a column file encryption key to each column of the data and then assigns a unique column ordinal number p to each file through the hash function P. Then, it encrypts the file using the column file encryption key corresponding to this column identifier. For the files without assigned column identifiers, a file-equivalent random number is generated and encrypted as the padding ciphertext of this column file, which finally forms the file ciphertext collection $C_D^t$. When constructing the index, the data owner extracts the file keyword collection and constructs an n bit-length bitmap ${\alpha }_{\omega }^t$ for each keyword, and the bitmap is displayed as 1 only if the keyword exists in the column file to which it belongs; otherwise, it is displayed as 0. The plaintext is displayed as 1 only if the keyword exists in the column file to which it belongs. Otherwise, it is displayed as 0. After the plaintext index is constructed, the algorithm $HMAC.Auth:(k_{\omega },\rho ,{\alpha }_{\omega }^t)\to {\sigma }_{\omega }^t$ is called to generate a row encryption key, and ${\alpha }_{\omega }^t$ is encrypted by using this key ${\sigma }_{\omega }^t$ to obtain ${\beta }_{\omega }^t$. Subsequently, a set of encrypted indexes ${\left(B^t\right)}^T={\left({\beta }_1^t,{\beta }_2^t,\dots ,{\beta }_i^t,\dots ,{\beta }_{\left|W\right|}^t\right)}^T$ is constructed by the hash function $i\leftarrow Q^t\left({\sigma }_{\omega }^t\right)$. Finally, the encrypted database $ED{B}^t=(t,B^t,C_D^t,Q^t)$ generated at moment t is sent to the cloud server, and the auxiliary information such as $(t,B^t,Q^t)$ is sent to the blockchain.

When $\mathbf{t}\ne 0$, which is the database update phase, the data owner dynamically updates certain files, performs file addition and deletion operations, and selects a new hash function P from the function family P based on the temporal state. Moreover, it assigns new column keys and column identifiers to the files within the same operation as when the database was first constructed and performs encryption operations on the files. After that, the data owner will adjust the keyword set (add or delete keywords), generate keys for the new keywords according to the initialization rules, and then select a new function Q from the function family Q, reconstruct a new bitmap for each keyword and construct an encrypted index. At the same time, in order for users to search the ciphertext database normally to obtain the desired results, the data owner will proceed to calculate the difference corresponding to the same keyword and construct the difference label HMAC through $HMAC.Auth:(k_{\omega },\rho ,{\alpha }_{\omega }^{t+1}-{\alpha }_{\omega }^t)\to \Delta {\sigma }_{\omega }^t$. Eventually, the updated ciphertext database is sent to the cloud server, auxiliary information is sent to the blockchain, and the set of differential labels $\Delta {\upsilon }^t=\left\{(\omega ,\Delta {\sigma }_{\omega }^t)\right\}$ is distributed to authorized users.

• Search: $\left(t,\omega ,UL,ED{B}^t\right)\to \left({\beta }_{\omega }^t\right)$.

The ciphertext search algorithm requires data users and blockchain nodes to collaborate to complete the operation process. The specific process is outlined below. The search algorithm pseudo-code is shown in

Table 4. The search algorithm pseudo-code.

Protocol 3: Search
$Input:UL,t,\omega ,ED{B}^t$
$Output:{\beta }_{\omega }^t$
1:   $\mathbf{data}\mathbf{users}:$	11:   $\mathbf{blockchain}:$
2:   $\mathrm{if}\mathrm{no}\mathrm{update}\mathrm{occurs}\mathrm{then}$	12:   if u ∉ UL then
3:      ${\sigma }_{\omega }^t\leftarrow (\omega ,t,v^t)$	13:      output ⊥
4:      $T_u\left(\omega \right)\leftarrow Enc\left({\sigma }_{\omega }^t\right)$	14:   else
5:   else	15:      ${\sigma }_{\omega }^t\leftarrow Enc\left(T_u\left(\omega \right)\right)$
6:      $e{k}_{\omega }\leftarrow H_2\left(E{K}_W,H_4\left(\omega \right)\right)$	16:      $i\leftarrow Q^t\left({\sigma }_{\omega }^t\right)$
7:      ${\sigma }_{\omega }^t\leftarrow H.Eval\left(e{k}_{\omega },{\sigma }_{\omega }^{t-1},\Delta {\sigma }_{\omega }^{t-1}\right)$	17:      $\left({\beta }_{\omega }^t\right)\leftarrow i$
8:      $T_u\left(\omega \right)\leftarrow Enc\left({\sigma }_{\omega }^t\right)$	18:      return ${\beta }_{\omega }^t$ to data users
9:   end if	19:   end
10:   send $T_u\left(\omega \right)$ to blockchain

.

For the data user, there are two states: the initial state and the update state. In the initial state, i.e., when t = 0, the initial tag set received by the legitimate user contains the search key parameter ${\sigma }_{\omega }^t$; in the update state, i.e., when $\mathbf{t}\ne 0$, the ciphertext database will be changed at this time, and the user will need to perform the calculation algorithm of the HMAC (homomorphic message authentication code) to regenerate the updated search key, $HMAC.Eval:(e{k}_{\omega },{\sigma }_{\omega }^t,\Delta {\sigma }_{\omega }^t)\to {\sigma }_{\omega }^{t+1}$. The updated key is eventually submitted to the blockchain network over a secure channel.

For the blockchain, after receiving the dataset containing the search request and the key, it is necessary to complete the verification of the membership in the authorization list. This search process should be terminated if it is verified that the user is not in this user list; if it is verified that the user is in this list, it is necessary to parse the set of ciphertext indexes corresponding to the keywords searched by the user by $Q^t$ and then return the ciphertext index set ${\beta }_{\omega }^t$ to the data user who initiated the search.

• Authorization: $(UL,u,Sk)\to (S{k}_u,UL)$.

The user authorization algorithm requires the data owner to perform a user authorization operation, add user u to the user authorization list, and then distribute the user private key $S{k}_u$ to user u, which consists of $H_2,H_4,E{K}_W,K_D$ and $v^t=\left\{(\omega ,{\sigma }_{\omega }^t)\right\}$. Eventually, the data owner synchronizes the updated authorization list UL to the blockchain node with the cloud server to complete the update of the user list status.

• Verification: $(\omega ,{\sigma }_{\omega }^t,{\alpha }_{\omega }^t,{\beta }_{\omega }^t)\to accept\mathrm{or}reject$

This result verification algorithm is divided into two phases.

The first phase is the cloud server honesty verification phase, where the the data user submits the search key ${\sigma }_{\omega }^t$ to the cloud server. After the cloud server receives the dataset containing the search request and the key, it needs to complete the verification of the membership in the authorization list first and terminate this search process if it is verified that the user is not in this user list. If the user is found to be in this list, it is necessary to use $Q^t$ to reverse parse out the identifier of the ciphertext index corresponding to the keyword searched by the user to obtain ${\beta }_{\omega }^t$’ and carry out decryption. Then, it is necessary to increase all the files corresponding to component 1 to the final set of retrieval results $R_{\omega }^t$. Ultimately, the collection of retrieval results $R_{\omega }^t$ should be sent to the user who initiated the search, and the collection of ciphertext indexes corresponding to the collection of retrieval results ${\beta }_{\omega }^t$′ should be sentto the blockchain. The blockchain compares ${\beta }_{\omega }^t$′ with its own calculated ${\beta }_{\omega }^t$. If the comparison is consistent, the verification passes, indicating that the set of search results returned to the data user by the cloud server is correct; if the comparison is inconsistent, the verification fails, indicating that the cloud server returns an incorrect result.

The second stage is the user honesty verification stage. The data user decrypts the ciphertext index data ${\beta }_{\omega }^t$ returned by the blockchain to obtain ${\alpha }_{\omega }^t$′, and then transmits $(\omega ,{\sigma }_{\omega }^t,{\alpha }_{\omega }^t)$ to the data owner, who executes the verification algorithm in the homomorphic message authentication code. If the result of the algorithm is 1, this means that the result provided by the user is valid; otherwise, the user is deemed untrustworthy.

• Decryption: $(H_3,K_D,{\beta }_{\omega }^t,R_{\omega }^t)\to D_{\omega }$

After obtaining the search results, the data user deduces the encryption key $k_p$ of the corresponding column based on the position of 1 in the index ${\beta }_{\omega }^t$ and then decrypts the ciphertext $R_{\omega }^t$ returned by the cloud server by applying the key of this column, so as to recover the original plaintext file $d_p^t$.

3.4. Correctness

When a user needs to retrieve a file containing a specific keyword at time t, they need to perform the operations in lines 1 to 9 of the ciphertext search algorithm to generate a search token for the keyword and transmit it to the cloud server. Since the ciphertext indexes of the cloud server are all constructed by the same pseudo-random function, this mechanism guarantees the accuracy of keyword retrieval. However, since the cloud server acts as a semi-honest participant in the index construction stage, the query results returned by it are not necessarily correct, so we compare and verify the ciphertext index collection in the search results through the blockchain, so as to confirm that the documents returned in the cloud server correspond to the ciphertext index collection, i.e., whether the returned documents are related to the search keywords.

3.5. Complexity Analysis

This subsection provides an analytical comparison between the BVUMU-DSSE scheme and some of the existing schemes in terms of complexity, as shown in

Table 5. A complexity comparison of our scheme with the existing schemes.

Scheme	Communication Complexity	Storage Complexity	Computational Complexity
	(Update)	(Owner)	(Cloud)	(Update)
MONETA [34]	$O\left(lo{g}^{3}N\right)$	$O\left(1\right)$	$O(a_{\omega }logN+lo{g}^{3}N)$	$O\left(lo{g}^{2}N\right)$
khons [35]	$O\left(1\right)$	$O(mlog|D|+|D|logW)$	$O\left(\right|D\left(W\right)\left|\right)$	$O\left(1\right)$
FBDSSE [36]	$O\left(\right|W\left|\right)$	$O\left(\right|W|log|D\left|\right)$	$O\left(a_{\omega }\right)$	$O\left(1\right)$
MFS [37]	$O\left(1\right)$	$O\left(1\right)$	$O\left(\right|D\left(W\right)\left|\right)$	$O\left(1\right) or O\left(\right|D\left(W\right)\left|\right)$
Ours	$O\left(\right|W\left|\right)$	$O\left(1\right)$	$O\left(1\right)$	$O\left(\right|W|+|D\left|\right)$

, where the owner represents the data owner entity, |D| denotes the total number of documents in the document collection, N denotes the number of combinations between keywords and document identifiers, $a_{\omega }$ denotes the frequency of keyword addition operations, W is defined as the keyword collection, |W| denotes the number of keyword collections, m denotes the number of keywords, and $D\left(\omega \right)$ denotes the collection of documents that contain a particular keyword $\omega$.

4. Security Analysis

We need to prove the following theorem.

Theorem 1.

If the pseudo-random functions $H_1,H_2,H_3,\left\{P\right\},\left\{Q\right\}$ satisfy the security conditions and the symmetric encryption scheme ${\prod }_A=(Setup,Enc,Dec)$ complies with the IND-CPA security standard while the homomorphic message authentication code ${\prod }_B$ has security, the BVUMU-DSSE scheme is said to be able to achieve forward and backward security.

Proof

Provenance: According to the threat model, the cloud server acts as a semi-honest attacker that steals sensitive information that should be kept confidential, despite performing operations according to the protocol specification. Assume that in a real scenario, challenger C responds to attacker A’s query with real data and algorithmic outputs; in the simulation scenario, simulator S generates an answer based on the information provided by leakage function L only. In the following, we will demonstrate, through a series of games, that the attacker is unable to differentiate between the environments in which it operates with non-negligible probability.

Game ${\mathbf{G}}_{\mathbf{0}}$: This game is identical to the real world, i.e., we can treat it as if it were the real world, so we define $Pr[{\mathrm{Real}}_A^{BVUMU-DSSE}\left(\lambda \right)=1]=Pr[G_0=1]$.

Game ${\mathbf{G}}_{\mathbf{1}}$: In this game, we assume that the system generates the keys for the columns by no longer calling the pseudo-random function H realistically, but by randomly selecting the values and depositing them in the key table. If column p has been interrogated, the simulator S reads the corresponding key from the key table directly; otherwise, it generates a new random value and updates the key table. Since the pseudo-random function is secure, it follows that the attacker A is unable to distinguish the two games $G_0$ and $G_1$ with non-negligible probability, or else it would be able to construct some other attacker $B_1$, which would be able to invoke A to attack this pseudo-random function H. Therefore, we get $|Pr[G_1=1]-Pr[G_0=1]|\le neg{l}_{B_1}\left(\lambda \right)$).

Game ${\mathbf{G}}_{\mathbf{2}}$: The same operation as H is applied to the pseudo-random function P. As in the first game, if the attacker can distinguish the real pseudo-random function from P with indistinguishable probability, they can design a polynomial time algorithm $B_2$ to break its security assumption, so $|Pr[G_2=1]-Pr[G_1=1]|\le neg{l}_{B_2}\left(\lambda \right)$. With the same principle, we construct the game $G_3$ for the pseudo-random function $H_1$ and the game $G_4$ for the pseudo-random function $H_2$. Then, we obtain $|Pr[G_3=1]-Pr[G_2=1]|\le neg{l}_{B_3}\left(\lambda \right)$ and $|Pr[G_4=1]-Pr[G_3=1]|\le neg{l}_{B_4}\left(\lambda \right)$.

Game ${\mathbf{G}}_{\mathbf{5}}$: This game is a modified update algorithm based on $G_4$. Instead of performing the operations of the original update algorithm, the simulator S dynamically sets the corresponding keyword bitmap based on the leakage timestamp t, search result $r\left(\omega \right)$, search pattern $sp\left(\omega \right)$ and update operation. The bitmap of the queried keywords is generated according to the search result $r\left(\omega \right)$ and the file position at the current moment, while the bitmap of the unqueried keywords is populated by random binary sequences, thus obtaining a ciphertext database EDB. When the ciphertext database EDB is updated, the simulator S adjusts the keyword update based on $r\left(\omega \right)$ in the leakage function in the current state. Some keywords are not subject to the update operation. Adjust the bitmap based on the updated file order, thus ensuring the correct response to attacker A’s query both before and after the state update. In the following, we will prove four aspects that the attacker is unable to extract valid information from the encrypted database EDB and therefore cannot distinguish whether their interaction is still with the simulator S or with the challenger C.

1.

The attacker is unable to extract any valid information from the encrypted file. Even if the columns in which the file is located are not displaced and the content of the file itself is not updated, the mechanism still guarantees the data confidentiality, which would otherwise break the IND-CPA security of the symmetric encryption scheme.

2.

The probability of using the key for keyword $\omega$ to decrypt other keywords is negligible, because the decryption key is bound to a specific keyword and the corresponding bitmap state, which makes it difficult for an attacker to decrypt keyword $r\left(\omega \right)$′ using the key for keyword $\omega$. If such an attack succeeds, it will violate the authentication of the homomorphic message authentication code and the IND-CPA security of the symmetric encryption scheme at the same time.

3.

Before and after the system update, the attacker cannot extract any data related to the keyword from the encrypted index; otherwise, it will violate the IND-CPA security property of the symmetric encryption scheme. If the attacker launches multiple queries for the same keyword, it is assumed that the two search keys are ${\sigma }_{\omega }^t$ and ${\sigma }_{\omega }^{t+1}$, respectively. However, due to the synchronization change of the bitmap caused by the file sorting update, the attacker who does not hold the latest key cannot retrieve the updated data, and the key generated at the previous moment is invalid for the new version of data retrieval; otherwise, the authentication of the homomorphic message authentication code will be violated.

4.

If the attacker A has the computational key $e{k}_{\omega }$, due to the difference label $\Delta {\sigma }_{\omega }^t$ being transmitted through the public key encryption mechanism, this results in the attacker’s access being revoked and not able to obtain this updated difference label, thus losing the ability to generate the latest key with the ability to retrieve the updated data; otherwise, it will threaten the security of the public key encryption system.

Therefore, the attacker is unable to recognize the difference between the two games ($G_4$, $G_5$) with non-negligible probability, thus satisfying $|Pr[G_5=1]-Pr[G_4=1]|\le neg{l}_B\left(\lambda \right)$. Since $G_5$ corresponds exactly to the environment generated by the simulator S through the leakage function, it can be obtained that $Pr[G_5=1]=Pr[Idea{l}_{A,S}^{BVUMU-DSSE}=1]$.

Combining the above analyses, it finally follows that $Pr[Idea{l}_{A,S}^{BVUMU-DSSE}=1]-Pr[{\mathrm{Real}}_A^{BVUMU-DSSE}\left(\lambda \right)=1]\le negl\left(\lambda \right)$, where $negl\left(\lambda \right)$ is a negligible function. It can be proved that the BVUMU-DSSE scheme has security in the L-adaptive security model. In addition, since the amount of information in the leakage function is strictly limited to the forward and backward security framework, it can be further inferred that the BVUMU-DSSE scheme satisfies the forward and backward security requirements.

The proof is complete. □

5. Scheme Simulation Experiment

This section focuses on analyzing and comparing the efficiency of the BVUMU-DSSE scheme with other existing schemes through simulation experiments, so as to prove that its performance is feasible in practical applications. Since the MFS [37] scheme is highly compatible with the proposed architecture in this study in terms of functionality and considering that its efficiency is significantly better than most of the existing schemes, the next simulation experiments of the BVUMU-DSSE scheme will choose the MFS [37] scheme as the benchmark comparison object.

5.1. Experimental Environment

In this subsection, the experimental equipment is configured as follows. We use a Linux system with a 2.4 GHz Intel Core i7 processor (Intel, Guangzhou, China), with 16 GB of RAM, running the Windows 10 operating system. This hardware environment provides standardized test benchmarks for scheme performance evaluation. In terms of algorithm implementation, the hash operation in the scheme is implemented using the HMAC module, the symmetric encryption and decryption is implemented using the AES algorithm, the public key encryption scheme is based on the RSA protocol, the bilinear pair operation is implemented using the 80-bit security parameter, and the length of the ciphertext is fixed at 512 bits. The above parameter settings ensure that the experimental results are reproducible and horizontally comparable.

5.2. Comparison of Performance Evaluation

In this subsection, we compare the performance of the BVUMU-DSSE scheme with the MFS [37] scheme.

The computational complexity of the index construction phase is positively correlated with the amount of keyword–document identifier association data, and the processing efficiency of the MFS scheme is directly affected by this parameter. The experiments set the initial data size as 500,000 sets of keyword–document identifier mapping relationships (k = ${10}^3$), the BVUMU-DSSE scheme adopts a test environment with a fixed document base of ${10}^4$, and the average number of keyword associations in a single document is 50. Comparison and analysis of the index construction under the keyword sizes from 1 × ${10}^3$ to 1 × ${10}^4$ show the difference in time overhead. The results, displayed in Figure 3, show that the index construction efficiency of BVUMU-DSSE is significantly higher than that of the MFS scheme, mainly due to the fact that the latter needs to perform bilinear pair operations. Both schemes use the AES algorithm to realize document encryption, and the test document base maintains experimental consistency. The index construction time and keyword size show a linear growth relationship.

In terms of trapdoor generation efficiency, the trapdoor generation process of the MFS scheme relies on the cooperative computing resources of the proxy server. In order to accurately evaluate the total system time consumed, the computation of the cloud server is also included in the test scope. Tests for 1k to 10k trapdoor generation operations show that the trapdoor generation mode of BVUMU-DSSE is categorized into two computation paths according to the update status: a single public key encryption operation is required when there is no update, and homomorphic message authentication code computation is required to be superimposed when there is an update. The results are shown in Figure 4: the trapdoor generation efficiency of BVUMU-DSSE without trapdoor update operation is superior to the MFS scheme.

In terms of ciphertext retrieval efficiency, this study continuously examines two scenarios of the FBM-DSSE scheme in the presence or absence of updates. The horizontal axis of the MFS scheme characterizes the total number of documents returned for a query keyword, which is expressed as the retrieval of a single keyword, w, covering 100–1000 (keyword–document ID) combinations. The BVUMU-DSSE scheme corresponds to retrieving 100–1000 independent keywords, a feature that originates from the design principle that its bitmap indexing structure can obtain all the matching results through a single search. The experimental results are shown in Figure 5, which indicate that the BVUMU-DSSE scheme has better retrieval performance, and its execution efficiency is significantly better than the MFS scheme under the same data size.

In terms of index updating, a comparison of the time overheads of the two schemes when implementing an extension equivalent to the existing index capacity is shown in Figure 6. The BVUMU-DSSE scheme needs to extend 1k to 10k keywords, and the overall time consumed exceeds the initial index generation phase due to the need to re-construct the keyword global mapping relationships. In contrast, the MFS scheme continuously appends 500k sets of (keyword–document ID) pairings, and the range of the corresponding keyword numbers is kept at 1k to 10k sets, which results in the time consumption being basically the same as that of the index creation cycle, since the updating mechanism of the scheme is little affected by the existing indexes. However, the experimental data show that the BVUMU-DSSE scheme still outperforms the MFS scheme.

Comprehensive performance analysis shows that compared with the existing verifiable multi-user dynamic searchable schemes, this scheme achieves significant optimization in terms of computational resource consumption, transmission load, and storage requirements, which makes it more practical and efficient in multi-user application scenarios.

6. Conclusions

Facing the demand of dynamic encrypted data sharing, this study builds a security control system for dynamic multi-user scenarios, covering user rights’ management, ciphertext retrieval and dynamic update functions. In order to realize the verifiable dynamic update of encrypted data (which needs to satisfy the dual constraints of forward security and backward security), we need to simultaneously solve the security access control and privilege recovery mechanism of the authorized users on the incremental data under the security constraints. This study builds an index architecture with a state tracking capability by means of bitmap structure and homomorphic message authentication code technology, adopts key dynamic updating mechanism to synchronize forward and backward security and fine-grained privilege control, and utilizes blockchain technology to assist in completing the bidirectional authentication between the cloud server and the users.

However, some technical bottlenecks are found in the research process that still need to be explored in depth:

1.

This study is currently limited to a single keyword search mode. In order to improve the applicability of practical scenarios, it is necessary to explore the expansion of search function sets in a multi-user collaborative environment, such as the support of Boolean logic composite queries, numerical range searches, and fuzzy matching based on edit distance and other core functions. Such extensions are of key value for medical data analysis, financial transaction auditing, and other scenarios, and new indexing structures need to be designed under the premise of ensuring forward security, such as combining Bloom filters and range trees to realize efficient range queries.

2.

This study focuses on the dynamic data sharing problem under the one-to-many authorization paradigm. In the future, it is necessary to further explore the data sharing technology of many-to-many collaboration scenarios. At the permission management level, we need to construct a fine-grained permission control mechanism based on attribute encryption and optimize the security and performance of the scheme to promote the practical application of the scheme in distributed cloud environments. In addition, we are committed to exploring an integrated searchable encryption scheme that supports multimodal retrieval, data aggregation, and secure sharing. For example, in medical data sharing scenarios, we need to design encrypted retrieval protocols that support fuzzy matching and statistical analysis of gene sequences. This kind of research will advance searchable encryption technology from theoretical models to practical engineering applications.