Towards Privacy Preserving in 6G Networks: Verifiable Searchable Symmetric Encryption Based on Blockchain

Abstract

The blockchain-based searchable symmetric encryption (SSE) scheme allows the retrieval and verification of outsourced data on cloud servers in sixth generation (6G) networks while ensuring the privacy of data. However, existing schemes are challenging to comprehensively meet the requirements of 6G-based intelligent application systems for low latency, high security, and high reliability. To address these limitations, we present VSSE, a novel blockchain-based SSE scheme designed for 6G-based intelligent application systems. Our scheme constructs a state chain structure to resist file injection attacks, thereby ensuring forward privacy. Moreover, we execute the search and verification operations separately on the cloud server and blockchain, while introducing a bitmap index structure and message authentication code (MAC) technology to achieve efficient searching and dynamic verification. Notably, VSSE also includes access control functionality, permitting only authorized users to access relevant files. The combination of remarkable efficiency and strong security establishes our VSSE as an ideal solution suitable for implementation in G-based intelligent application systems.

1. Introduction

With the widespread adoption of fifth generation (5G) mobile communication technology, cloud computing-based intelligent applications, such as smart logistics, smart medical care, and smart homes, have greatly facilitated the quality of daily life and work. Massive data are collected by the physical device deployed in the intelligent applications, which also stores data in a cloud server and analyzes the data by cloud computing techniques. The breakthrough development of sixth generation (6G) mobile communication technology provides a more reliable and faster computing environment for the intelligent application systems [1]. However, the emergence of 6G communication technology has led to a significant increase in application data, and cloud servers may not always be trusted. Therefore, protecting the privacy of data becomes particularly critical. To protect data privacy in the 6G network, employing traditional encryption methods to encrypt the data helps maintain its privacy [2]. Nevertheless, encrypted data become non-retrievable, resulting in a substantial reduction in data accessibility. On the other hand, searchable encryption (SE) technology successfully achieves the capability of ciphertext retrieval.

Symmetric searchable encryption (SSE) is a ciphertext retrieval technique based on symmetric cryptographic primitives. In general, SSE operates as follows: the data owner encrypts files and constructs an encrypted index for each file, then uploads both to the server. When a data user wants to retrieve the files containing a specific keyword, they send search tokens related to this keyword to the server. Subsequently, the server executes a search algorithm using the search tokens and the encrypted index, and returns the corresponding results to the data user.

The initial SSE scheme was presented by Song et al. [3]. Afterward, searchable encryption rapidly became a prominent research topic of interest. Most of the subsequent work has been conducted under the ideal assumption that the cloud server is honest but curious. Goh et al. [4] established an inverted-index-based searchable encryption scheme using Bloom filters. This article formally discusses the security model that searchable encryption needs to satisfy for the first time. Curtmola et al. [5] were pioneers in defining several types of leaked information and identified issues in the existing security models. Additionally, they constructed the first inverted-index-based SSE scheme, which achieved sub-linear search efficiency. These schemes are all designed based on static databases and cannot meet the requirements of real-time data updates (addition or deletion) in intelligent application systems. Therefore, a practically valuable SSE scheme should possess dynamic updating capabilities. To enable SSE to support dynamic updates, Kamara et al. [6] proposed the first dynamic searchable encryption (DSSE) scheme. Subsequently, several DSSE schemes have been proposed in various studies [7,8]. However, these schemes overlook the threat of file injection attacks [9] on leaked information during the update. Such powerful attacks recover keywords by establishing a connection between previous search tokens and currently updated files, which seriously compromises data privacy. Therefore, the need to counteract file injection attacks becomes a crucial factor for consideration. Stefanov et al. [10] were the pioneers in introducing the concept of forward privacy as a defense mechanism against file injection attacks. Bost et al. [11] presented a groundbreaking public-key-based hash-link structure to construct a DSSE scheme with forward privacy. Song et al. [12] and Wei et al. [13] both implemented DSSE schemes with forward privacy by using symmetric cryptographic primitives based on the scheme in [11]. Zuo et al. [14] utilized homomorphic encryption with bitmap index to achieve forward privacy in their scheme. These schemes employed various methods to achieve forward privacy, making significant contributions to the security of SSE schemes and widely acknowledging the role of forward privacy. Subsequently, several works have revolved around the DSSE function [15,16,17], security [18,19,20], and efficiency [21,22,23], providing numerous excellent schemes. Additionally, certain files could contain a significant volume of sensitive messages, such as personal health records, which should not be accessed indiscriminately. Only specific authorized users should be able to access the corresponding files. Therefore, while investigating the functionality, efficiency, and security of DSSE, introducing access control functionality can effectively enhance the practicality of the schemes [24,25,26].

The SSE schemes mentioned above all assume that the server will honestly return the correct search results. However, in practical settings, the server should be semi-honest and curious, meaning it might return incorrect search results to save computational resources or gain service fees dishonestly. Therefore, incorporating verification functionality into DSSE schemes has become a challenge. Some verifiable searchable symmetric encryption schemes attempt to verify search results locally by users [27,28,29]. However, the verification techniques in these schemes rely on specific indexing structures, lacking generality and impeding the expandability of the scheme’s expressive capabilities. In addition, in cases where users are dishonest or maliciously repudiate, such methods still cannot guarantee a fair verification of search results. Blockchain is a distributed database with the property of immutability and decentralization. Compared to traditional networks, the information recorded on the blockchain is more reliable, addressing the issue of mutual distrust among different parties. Therefore, introducing blockchain as a trusted third party into searchable encryption schemes can effectively resolve the problem of fair verification between servers and users. Hu et al. [30] proposed a fair verifiable DSSE scheme by utilizing smart contracts to replace the server. Cai et al. [31] achieved ciphertext retrieval in distributed storage and utilized blockchain for verification. Yan et al. [32] and Li et al. [33] both achieved static verification of search results on the blockchain by using message authentication codes. However, static verification cannot meet the requirements for frequent data updates in the 6G network. These schemes can be combined with blockchain technology to achieve the verification of search results and mitigate the potential for dishonest or malicious denial by users. However, there are still some challenges and issues that need to be addressed. The existing blockchain-based verifiable DSSE schemes either lack consideration for forward privacy and access control, or trade frequent transactions for ciphertext retrieval and result verification. The reason for frequent transactions is that both retrieval and verification operations are executed on the blockchain, which reduces the efficiency of the scheme. Hence, the challenge of devising an efficient and comprehensive DSSE scheme for 6G-based intelligent application systems remains an unresolved issue.

In response to the requirements of low latency, high security, and high reliability in 6G-based intelligent application systems, we propose a novel blockchain-based DSSE scheme, referred to as VSSE. Firstly, VSSE possesses forward privacy to consist file-injection attacks, which greatly enhances the security of the scheme. We construct a state chain structure to achieve forward privacy. For each update, a new state is randomly generated for the keyword, and each state is linked by encrypted entries. The cloud server cannot deduce the most recent state of the keyword by relying on past search tokens. Building upon this foundation, to further enhance the efficiency of the scheme, our approach establishes the search operations on the server side, thereby reducing the frequency of interactions with the blockchain during the search and contributing to efficiency improvement. Next, in order to comprehensively meet the high reliability requirements of 6G systems, our scheme validates search results based on the tamper-resistant property of the blockchain. Once the search is completed, the results are sent from the server to the blockchain. After that, the blockchain performs verification based on verification information and returns the verification result and the search result to the data user. Meanwhile, we introduce a bitmap index structure to represent file identifiers and combine it with message authentication code (MAC) technology to attain dynamic verification of outcomes. Moreover, VSSE encompasses access control functionality, enabling users with distinct permissions to access relevant files. The aforementioned designs collectively fulfill the characteristics of 6G-based intelligent application systems. Ultimately, our scheme’s security analysis and experimental outcomes affirm its robust security and operational efficiency.

2. Problem Formulation

This section introduces the system model of our scheme, as well as the cryptographic background and notations used in the rest of paper.

2.1. System Model

Figure 1 shows the system model diagram of our scheme, VSSE. Within VSSE, four entities are involved: $DataOwner$, $CloudServer$, $DataUser$ and $BlockChain$.

$DataOwner$: These entities aim to store the collected extensive and critical data on a cloud server. Specifically, $DO$ encrypts each file and constructs secure indexes, which are then uploaded to $CS$. Furthermore, $DO$ is tasked with generating verification information and subsequently uploading it to the Blockchain $BC$.

$CloudServer$: $CS$ is tasked with executing the search protocol and returning the corresponding search results to the blockchain for verification. Specifically, upon receiving the search traps sent by $DU$, $CS$ uses secure index to execute search query. Then, $CS$ also has to determine which users have the authority to access which files. In addition, due to the potential of the server returning inaccurate search outcomes to $DU$, $CS$ is required to transmit the results to $BC$ for verification.

$DataUser$: These entities would like to obtain reliable search results. Specifically, $DU$ generates search trapdoor based on the keywords and transmits them to $CS$. Any legitimate $DU$ will receive search results and verification information, while unauthorized $DU$ will not be able to obtain any results.

$BlockChain$: The responsibility of verifying the outcomes to determine the reliability of search results obtained by $DU$ lies with $BC$. Specifically, upon receiving the search results, $BC$ utilizes a verification contract to validate the search results and returns it along with the verification identifier to $DU$.

2.2. Notations

Table 1. Common Notations.

Notations	Descriptions
$x\stackrel{\$}{\to }X$	x is uniformly and randomly sampled from the finite set X.
$\lambda$	The security parameter.
$poly\left(\lambda \right)$	The polynomial function.
$negl\left(\lambda \right)$	The negligible function.
$\mathbf{DB}$	The files database.
$\mathcal{W}$	The set of all keywords that appear in $\mathbf{DB}$.
$w\in \mathcal{W}$	The keyword in $\mathcal{W}$.
$\mathbf{DB}\left(w\right)$	The set of identifiers for all files that contain the keyword w.
$\left|\mathcal{W}\right|$	The number of distinct keywords.
$bs$	The file identifier
$s{t}_c$	The state of keyword.

presents the common notations in VSSE.

2.3. Dynamic Searchable Encryption

A dynamic searchable encryption scheme typically consists of the Setup, Update, and Search algorithms.

The role of the Setup algorithm is to generate keys and construct the encrypted database. Specifically, it takes the security parameter $\lambda$ and the database $\mathbf{DB}$ as inputs, and outputs the data owner’s key $sk$, state $\sigma$, and an encrypted database $\mathbf{EDB}$.

The Update algorithm is jointly executed by the data owner and the server, and its purpose is to insert or delete data from the database. Specifically, the data owner provides the key, state, keyword–document pairs, and update type as inputs, while the server provides the encrypted database $\mathbf{EDB}$ as input. This algorithm will return an updated state ${\sigma }^{\prime }$ and an updated encrypted database ${\mathbf{EDB}}^{\prime }$ to the data owner and the server, respectively.

The Search algorithm is executed collaboratively by the data user and the server, aiming to search for files related to keyword w. Specifically, the data user provides the key $sk$ and the keyword w as input, while the server provides the encrypted database $\mathbf{EDB}$ as input. The algorithm returns a collection of files $\mathbf{DB}\left(w\right)$ related to w to the data user.

The above content follows the general definition of searchable encryption as outlined in reference [34,35,36]. Additionally, our scheme includes the Verify algorithm, which will be elaborated in detail later in this paper.

2.4. Forward Privacy

Forward privacy focuses on preserving the confidentiality of keywords during file addition operations, ensuring that an addition query does not disclose any information about the keywords [37,38]. An SSE scheme lacking forward privacy may unintentionally leak information when inserting a new file. Exploiting this vulnerability, $CS$ tests the previously submitted search token during a new update, checking whether the old search token matches the new update. A file injection attack takes advantage of this behavior to extract information about the keyword. First, $CS$ can trick the $DO$ into injecting some files containing certain specific keywords. After $DO$ uploads the injected files, $CS$ employs the search token provided by $DO$ to search within the injected files, recovering the corresponding keyword based on the search result. As forward privacy guarantees that the past search token cannot be linked to a newly added file, this type of attack can be thwarted.

2.5. Bitmap Index

VSSE verifies the accuracy of search results through blockchain, a system that only allows for the appending of information, i.e., data can only be added and not deleted. However, updating (adding or deleting) data is a common operation in real-world DSSE applications. In order to update the data while completing the search result validation, we incorporate a bitmap index to uniquely identify and manage file identifiers. Specifically, assuming that the database can hold at most m files, it can be represented as m bits by using the bitmap index. From right to left, the i-th bit of the bitmap index represents the i-th file $f_i$. A bit value of 1 indicates that the file has been added, while a value of 0 signifies that the file has been deleted or does not exist.

Figure 2 shows a sample bitmap index for $m=6$. Figure 2a shows the state of the bitmap index when files $f_1$ and $f_3$ are present. Figure 2b depicts the addition of file $f_0$ based on the original state. We first need to generate the bit string 00001 for $f_0$ and then perform an XOR operation with the original bit string. The final state of the bitmap index is 001011. Figure 2c depicts the deletion of file $f_3$ based on the previous operations. Similar to the addition operation, we generate the bit string 001000 for $f_3$ and perform an XOR operation with the original bit string 001011. The resulting state of the bitmap index is 000011.

3. Construction of Our Work

In this section, we present VSSE in detail, a verifiable dynamic searchable symmetric encryption scheme based on blockchain.

3.1. Detailed Construction

VSSE defines four protocols: Setup, Update, Search, and Verify. We first describe the symbols and functions that may be involved in each protocol. $\lambda$ is a security parameter to generate secret keys. The value of m represents the maximum capacity of the database and also indicates the maximum length of the bitmap index, and $H_1$, $H_2$ are both hash function used to generate keyword state locations and encrypted entries, respectively. Algorithms 1–4 summarize Setup, Update, Search, and Verify protocols of VSSE, respectively. Specifically, the structure of state chains is shown in Figure 3, while Setup, Update, and Search protocols are detailed below.

Algorithm 1 VSSE.Setup.

$\mathbf{Input}$: The security parameter $\lambda$.

$\mathbf{Output}$: The security key $k_s,k_u$ and empty maps $\mathbf{W},\mathbf{T},\mathbf{A}$, Σ and $\mathbf{Tag}$.

$DataOwner:$

1: $k_s,k_u\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

2: $\mathbf{W}\leftarrow \mathrm{empty}\mathrm{map}$

$CloudServer:$

3: $\mathbf{T},\mathbf{A}\leftarrow \mathrm{empty}\mathrm{map}$

$\mathit{Block}$ $\mathit{Chain}$:

4: Σ, Tag $\leftarrow \mathrm{empty}\mathrm{map}$

Setup. In the this protocol, $DO$ generates the secret key $k_s$, $k_u$ and an empty maps, $\mathbf{W}$. The key $k_s$ and $k_u$ are secreted by a $\lambda$-bits random string that are used to encrypt keywords and users. The map $\mathbf{W}$ is employed to maintain the most recent state of each keyword, organized as a dynamic list with two columns. Keywords and their latest states are sequentially arranged in the two columns of $\mathbf{W}$. $CS$ maintains two empty map $\mathbf{T}$ and $\mathbf{A}$. $\mathbf{T}$ is a dynamic list with two columns to construct secure index, where the first column is used to store the location of update and the second column corresponds to the updated file identifiers. $\mathbf{A}$ is used to map the information about the user. It consist of two columns: the user’s identifier and user’s file access authority are located in the two columns of $\mathbf{A}$ in order. $BC$ also maintains two empty maps, Σ and $\mathbf{Tag}$. Σ is employed to store the user’s identifier and the corresponding file identifier for a specific keyword. $\mathbf{Tag}$ is a dynamic list to store verification tag in the form of two columns. The user’s identifiers and keywords are located in the first column of $\mathbf{Tag}$, and the MAC values corresponding to search results are in the second column.

Update. When updating (adds or deletes) a file with identifier $bs$ that contains keyword w, $DO$ initiates the process by initially retrieving the previous state $s{t}_c$ associated with the keyword w from $\mathbf{W}$. Subsequently, a new state $s{t}_{c+1}$ is generated at random. $\mathbf{W}\left[w\right]$ is also updated accordingly. Next, $DO$ computes ${\mathbf{H}}_1(k_w\left|\right|s{t}_{c+1})$ and ${\mathbf{H}}_2(k_w\left|\right|s{t}_{c+1})$ separately. ${\mathbf{H}}_1(k_w\left|\right|s{t}_{c+1})$ represents the location of encrypted index entry e on the server, and ${\mathbf{H}}_2(k_w\left|\right|s{t}_{c+1})$ is used to compute the encrypted index entry e. As the state is generated randomly, each observed state by the server during an update appears as if it has been drawn randomly. Consequently, the server remains incapable of deducing the subsequent state based on the current search token. This imparts a guarantee of forward privacy. $DO$ also needs to encrypt the authorized user’s identifiers $u_j$ to facilitate the storage of corresponding information on the server and the blockchain. Finally, $DO$ sends $(v_{c+1},e_{c+1},L,bs)$ to the server, which then stores the encrypted entries and associated file identifiers. Meanwhile, $DO$ sends $(bs,k_w,L)$ to the blockchain to complete the result verification process, and the blockchain updates and stores the accessible files for the user along with their corresponding message authentication codes.

Algorithm 2 VSSE.Update.

$\mathbf{Input}$: The security key $k_s,k_u$, the file identifier $bs$, the keyword w and user $u_j$.

$\mathbf{Output}$: The latest state $s{t}_{c+1}$, the index location $v_{c+1}$, the index information $e_{c+1}$.

$DataOwner$:

1: $k_w\leftarrow F(k_s,w)$

2: $s{t}_c\leftarrow \mathbf{W}\left[w\right]$

3: $\mathbf{if}s{t}_c=\perp \mathbf{then}$

4: ${st}_0\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

5: $\mathbf{end}\mathbf{if}$

6: ${st}_{c+1}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

7: $\mathbf{W}\left[w\right]\leftarrow s{t}_{c+1}$

8: $v_{c+1}\stackrel{}{\leftarrow }{H}_1(k_w\left|\right|s{t}_{c+1})$

9: $e_{c+1}\stackrel{}{\leftarrow }\left(bs\right||s{t}_c)\oplus H_2(k_w\left|\right|s{t}_{c+1})$

10: $\mathbf{for}\mathrm{all}\mathrm{user}{u}_j\mathrm{can}\mathrm{access}bs\mathbf{do}$

11: $l_j\stackrel{}{\leftarrow }F(k_u,u_j),L\stackrel{}{\leftarrow }L\cup l_j$

12: $\mathbf{end}\mathbf{for}$

13: $\mathrm{Send}(v_{c+1},e_{c+1},L,bs)\mathrm{to}\mathrm{cloud}\mathrm{server}$

14: $\mathrm{Send}(bs,k_w,L)\mathrm{to}\mathrm{block}\mathrm{chain}$

$CloudServer:$

15: $\mathbf{T}\left[u_{c+1}\right]=e_{c+1}$

16: $\mathbf{for}{l}_j\in L\mathbf{do}$

17: $\mathbf{A}\left[l_j\right]\leftarrow \mathbf{A}\left[l_j\right]\oplus bs$

18: $\mathbf{end}\mathbf{for}$

$BlockChain$:

19: $\mathbf{for}{l}_j\in L\mathbf{do}$

20: $\Sigma [k_w\left|\right|l_j]\stackrel{}{\leftarrow }\Sigma [k_w\left|\right|l_j]\oplus bs$

21: $\mathbf{Tag}[k_w\left|\right|l_j]\stackrel{}{\leftarrow }MAC(\Sigma [k_w\left|\right|l_j\left]\right)$

22: $\mathbf{end}\mathbf{for}$

Search. When searching for the files containing keyword w, $DU$ encrypts keyword w by using $k_s$ and a pseudorandom function F, and retrieves the current state from $\mathbf{W}\left[w\right]$. Then, $DU$ sends $(k_w,l_j,s{t}_c)$ to $CS$. $CS$ uses the $(k_w,l_j,s{t}_c)$ to obtain the location of current state $s{t}_c$ and retrieves the corresponding encrypted entry $e_c$ from $\mathbf{T}$. By decrypting the encrypted entry, $CS$ obtains the file identifier $bs$ associated with the current state $s{t}_c$ and the previous state $s{t}_{c-1}$. Finally, after c iterations, $CS$ XORs each bitmap $bs$ to obtain the final result $Bs$, which includes all the results involving the keyword w. For different $DU$, the server retrieves the files that the current $DU$ is authorized to access from $\mathbf{A}$ by the user’s identifier. After completing the search for files containing w, $CS$ must determine whether the user has permission to access these files, i.e., it performs an AND operation between $Bs$ and $\mathbf{A}\left[l_j\right]$. The final result $Res$ is not directly returned to the $DU$ but is sent by the server to the blockchain for further verification.

Algorithm 3 VSSE.Search.

$\mathbf{Input}$: The security key $k_s,k_u$, the keyword w and user $u_j$.

$\mathbf{Output}$: The search result $Res$.

$DataUser$:

1: $k_w\stackrel{}{\leftarrow }F(k_s,w),l_j\stackrel{}{\leftarrow }F(k_u,u_j)$

2: $s{t}_c\stackrel{}{\leftarrow }\mathbf{W}\left[w\right]$

3: $\mathbf{if}s{t}_c=\perp \mathbf{then}$

4:    $\mathbf{return}Ø$

5: $\mathbf{end}\mathbf{for}$

6: $\mathrm{Send}(k_w,l_j,s{t}_c)\mathrm{to}\mathrm{cloud}\mathrm{server}$

$CloudServer:$

7: $Bs\stackrel{}{\leftarrow }0,Res\stackrel{}{\leftarrow }Ø$

8: $\mathbf{for}i=c\mathbf{to}1\mathbf{do}$

9: $v_i\stackrel{}{\leftarrow }{H}_1(k_w\left|\right|s{t}_i),e_i\stackrel{}{\leftarrow }\mathbf{T}\left[v_i\right]$

10: $(s{t}_{i-1},bs)\stackrel{}{\leftarrow }{e}_i\oplus H_2(k_w\left|\right|s{t}_i)$

11: $Bs\stackrel{}{\leftarrow }Bs\oplus bs$

12: $\mathbf{end}\mathbf{for}$

13: $Res\stackrel{}{\leftarrow }Bs\wedge \mathbf{A}\left[l_j\right]$

14: $\mathrm{Send}(k_w,l_j,Res)\mathrm{to}\mathrm{block}\mathrm{chain}$

Algorithm 4 VSSE.Verify.

$\mathbf{Input}$: The encrypted keyword $k_w$, the encrypted user $l_j$ and search result $Res$.

$\mathbf{Output}$: The search result $Res$ and the verify information $proof$.

$BlockChain$:

1: $Ta{g}^{*}\stackrel{}{\leftarrow }\mathbf{Tag}[k_w\left|\right|l_j]$

2: $Tag\stackrel{}{\leftarrow }MAC\left(Res\right)$

3: $\mathbf{if}Ta{g}^{*}=Tag\mathbf{then}$

4:    $proof=1$

5: $\mathbf{else}$

6:    $proof=0$

7: $\mathbf{end}\mathbf{if}$

8: $\mathrm{Return}(Res,proof)$

Verify. In this protocol, the blockchain utilizes a verification contract to validate the correctness of search results. The verification contract constructs a key-value pair list $\mathbf{Tag}$ in the form of (addr, val), where the first column contains user and keyword information used to locate a specific entry, and the second column stores the MAC for the corresponding result. Upon receiving encrypted keywords $k_w$, encrypted user identifiers $l_j$, and search results $Res$ from the server, the verification contract retrieves the MAC value $Ta{g}^{*}$ for the corresponding result by using $k_w$ and $l_j$ as indices in the $\mathbf{Tag}$. Then, the verification contract computes the corresponding MAC value $Tag$ based on the search result $Res$ and compares $Tag$ with $Ta{g}^{*}$. If they match, the verification token $proof$ is set to 1, indicating that the search result is correct; otherwise, the verification token is set to 0. Finally, the blockchain sends the verification token along with the search result $Res$ to $DU$, which employs $proof$ to ascertain the correctness of the search outcome.

To illustrate the verification process of the scheme on the blockchain more intuitively, we provide an explanation using a simple example. Figure 4 depicts the verification process when the cloud server sends the keyword $w_1$, user identifier information $l_1$, and the corresponding search result $Res=\left(0101\right)$ to the blockchain. Upon receiving the aforementioned information, the blockchain employs the verification contract to extract the correct MAC value stored in the $\mathbf{Tag}$ list for the combination of $\left(w_1\right|\left|l_1\right)$, i.e. $MAC\left(0101\right)$. Subsequently, the verification contract computes the MAC value $MAC\left(Res\right)$ for the result $Res=\left(0101\right)$ sent by the cloud server and compares it with the extracted $MAC\left(0101\right)$ from the $\mathbf{Tag}$. Since $MAC\left(Res\right)$ is equal to $MAC\left(0101\right)$, the verification token $proof$ is set to 1. Finally, the blockchain returns the verification token $proof$ along with the search result $Res$ to the user.

3.2. Security Analysis

Forward privacy is a crucial security attribute that a DSSE scheme should possess, as it involves the update and search operations common to all DSSE schemes. Therefore, our security analysis primarily focuses on threats associated with the update and search operations. VSSE satisfies definition of forward security. Specifically, in VSSE, each state of the keyword is randomly generated, the value of each state is indistinguishable from a random value in the server’s view, and the server is incapable of deducing the forthcoming state using the present state of the keyword. As a result, the forward privacy of VSSE remains ensured.

The theorem regarding the security of VSSE is as follows.

Theorem 1.

Assume that F is a secure pseudorandom function, and $H_1$ and $H_2$ are hash functions in random oracle model. The leakage functions are denoted as ${\mathcal{L}}^{Updt}(i,b{s}_i,w)=(i,b{s}_i)$ and ${\mathcal{L}}^{Srch}\left(w\right)=(\mathbf{sp}\left(w\right),\mathbf{ap}\left(w\right))$, where ${\mathcal{L}}^{Updt}$ and ${\mathcal{L}}^{Srch}$ are used to capture the leakage during the update and search, $\mathbf{ap}\left(w\right)$ is the access pattern, and $\mathbf{sp}\left(w\right)$ is the search pattern. Then VSSE is an $\mathcal{L}$-adaptively secure SSE scheme with forward privacy.

Proof of Theorem 1.

The security of VSSE is proven through a sequence of games involving the real game $R_{EAL}$ and the ideal game $I_{DEAL}$. By demonstrating the indistinguishability between two adjacent games, we establish the equivalence between the real and ideal games.

Game $G_0$: $G_0$ is $R_{EAL}$ game.

$$Pr\left({\mathrm{R}}_{\mathrm{EAL}}\left(\lambda \right)=1\right)=Pr(G_0=1).$$

(1)

Game $G_1$: In $G_1$, instead of using a pseudo-random function F to generate $k_w$, we randomly select $k_w$ and store it in the mapping $\mathbf{Key}$. For the subsequent query on w, we can directly retrieve the corresponding $k_w$ from $\mathbf{Key}$. Since we cannot distinguish between a F and a true random function, $G_1$ and $G_0$ are indistinguishable.

Game $G_2$: $G_2$ no longer calls $H_1$ to generate location in the update protocol, but uses random numbers instead. Specifically, it involves using $v\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ instead of $v\stackrel{}{\leftarrow }{H}_1(k_w,s{t}_{c+1})$ and performing $\mathbf{L}[k_w\left|\right|s{t}_{c+1}]\stackrel{}{\leftarrow }v$, where $\mathbf{L}$ is a mapping held by $G_2$. Then, ${\mathbf{H}}_{\mathbf{1}}[k_w\left|\right|s{t}_{c+1}]\stackrel{}{\leftarrow }\mathbf{L}[k_w\left|\right|s{t}_{c+1}]$ is executed in the search protocol, where ${\mathbf{H}}_1$ is the table of $H_1$. It can be seen that ${\mathbf{H}}_1$ is not updated in real time, so when the adversary accesses ${\mathbf{H}}_1[k_w\left|\right|s{t}_{c+1}]$ before the search query is issued, ${\mathbf{H}}_1[k_w\left|\right|s{t}_{c+1}]$ will randomly generate a value $v^{*}$ that is different from v. When the adversary accesses ${\mathbf{H}}_1[k_w\left|\right|s{t}_{c+1}]$ once more following the subsequent search, it will obtain the value v that has been updated into ${\mathbf{H}}_1$. By comparing the differences between the two access results, the adversary will know that it is in $G_2$. However, the probability of such case occurring is negligible.

Based on the above, this case only happens when the adversary accesses ${\mathbf{H}}_1$ using $k_w\left|\right|s{t}_{c+1}$. Given that $s{t}_{c+1}$ is randomly generated, the likelihood of the adversary selecting $s{t}_{c+1}$ is $\frac{1}{2^{\lambda }}+negl\left(\lambda \right)$. Assuming a PPT adversary makes up to $p=poly\left(\lambda \right)$ guesses, the probability of this occurrence is $\frac{p}{2^{\lambda }}+p·negl\left(\lambda \right)$, which can be negligible. Therefore, $G_2$ and $G_1$ are indistinguishable.

$$Pr(G_1=1)-Pr(G_2=1)\le \frac{p}{2^{\lambda }}+p·negl\left(\lambda \right).$$

(2)

Game $G_3$: In the update protocol of $G_3$, $H_2$ is processed in the same way as $H_1$ in $G_2$. Since the likelihood of the adversary guessing $s{t}_{c+1}$ is $\frac{1}{2^{\lambda }}+negl\left(\lambda \right)$, and the probability after $p=poly\left(\lambda \right)$ polynomial queries by the adversary is $\frac{p}{2^{\lambda }}+p·negl\left(\lambda \right)$, it follows that $G_3$ and $G_2$ are indistinguishable.

$$Pr(G_2=1)-Pr(G_3=1)\le \frac{p}{2^{\lambda }}+p·negl\left(\lambda \right).$$

(3)

Game $G_4$: In $G_4$, the value of $st$ is generated instantaneously during the search. Algorithm 5 shows the algorithmic changes on the $DO$. $G_4$ utilizes $\mathbf{Updates}$ to record the update query that occurred after the last search, and extracts the number of updates and $\mathbf{DB}\left(w\right)$. $G_4$ randomly selects the query result of a random oracle without the information about $st$. Subsequently, $st$ is generated and used to update the random oracle during the execution of the search operation. From the adversary’s perspective, since $G_4$ and $G_3$ output two random strings during the update phase and both output $(k_w,s{t}_c)$ during the search, $G_4$ and $G_3$ are completely indistinguishable.

Simulator: In the ideal game $I_{DEAL}$, the simulator $\mathcal{S}$ constructs a view by utilizing the leakage function. Algorithm 6 details $\mathcal{S}$, which maintains two mappings and an update counter. The values of each mapping are also randomly generated during the update. Unlike $G_4$, $\mathcal{S}$ uses $\underline{w}\stackrel{}{\leftarrow }min\mathbf{sp}\left(w\right)$ to represent the first time to search keywords w and uses the update history $\mathbf{uh}\left[w\right]=\left((i,b{s}_i)\right|q_i=(i,b{s}_i,w))$ as input to parse the number of keyword updates and update requests, rather than computing based on $\mathbf{Updates}$. Afterwards, $\mathcal{S}$ randomly generates $s{t}_i$ and updates the random oracle with the information above. The simulator and $G_4$ are entirely equivalent.

$$\mathrm{Pr}[I_{DEAL}\left(\lambda \right)=1]=\mathrm{Pr}[G_4=1]$$

(4)

Algorithm 5 Game $G_4$

Setup(λ)

$DataOwner:$

1: $\mathbf{L},\mathbf{E}\stackrel{}{\leftarrow }\mathrm{empty}\mathrm{map}$

2: $t\stackrel{}{\leftarrow }0$

Update(ks,W,w, bs; T)

$DatOwner$:

3: $\mathrm{Add}(t,bs)\mathrm{to}\mathbf{Updates}\left[w\right]$

4: $\mathbf{L}\left[t\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

5: $\mathbf{E}\left[t\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{l+\lambda }$

6: $t\stackrel{}{\leftarrow }t+1$

7: $\mathrm{Send}(\mathbf{L},\mathbf{E})\mathrm{to}\mathrm{server}$

Search(ks,W,w; T)

$DataOwner$:

8: $\mathbf{if}\mathbf{Key}\left[w\right]=\perp \mathbf{then}$

9: $\mathbf{Key}\left[w\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

10: $\mathbf{end}\mathbf{if}$

11: $k_w\stackrel{}{\leftarrow }\mathbf{Key}\left[w\right]$

12: $\mathbf{if}\mathbf{W}\left[w\right]=\perp \mathbf{then}$

13: $\mathbf{W}\left[w\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

14: $\mathbf{end}\mathbf{if}$

15: $((v_0,b{s}_0)\cdots ,(v_c,b{s}_c))\stackrel{}{\leftarrow }\mathbf{Updates}\left[w\right]$

16: $s{t}_0\stackrel{}{\leftarrow }\mathbf{W}\left[w\right]$

17: $c\stackrel{}{\leftarrow }\left|\mathbf{Updates}\left[w\right]\right|$

18: $\mathbf{for}i=1\mathbf{to}c\mathbf{do}$

19: $s{t}_i\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

20:${\mathbf{H}}_1[k_w\left|\right|s{t}_i]\stackrel{}{\leftarrow }\mathbf{L}\left[v_i\right]$

21:${\mathbf{H}}_2[k_w\left|\right|s{t}_i]\stackrel{}{\leftarrow }\mathbf{E}\left[v_i\right]\oplus (s{t}_{i-1}\left|\right|b{s}_i)$

22: $\mathbf{end}\mathbf{for}$

23: $\mathrm{Send}(k_w,s{t}_c)\mathrm{to}\mathrm{server}$

Algorithm 6 Simulator

Setup()

$DataOwner$:

1: $\mathbf{L},\mathbf{E}\stackrel{}{\leftarrow }\mathrm{empty}\mathrm{map}$

2: $t\stackrel{}{\leftarrow }0$

Update()

$DataOwner:$

3: $\mathbf{L}\left[t\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

4: $\mathbf{E}\left[t\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{l+\lambda }$

5: $t\stackrel{}{\leftarrow }t+1$

6: $\mathrm{Send}(\mathbf{L},\mathbf{E})\mathrm{to}\mathrm{server}$

Search(sp(w), uh(w))

$DataOwner$:

7: $\underline{w}\stackrel{}{\leftarrow }min\mathbf{sp}\left(w\right)$

8: $\mathbf{if}\mathbf{Key}\left[w\right]=\perp \mathbf{then}$

9: $\mathbf{Key}\left[w\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

10: $\mathbf{end}\mathbf{if}$

11: $k_w\stackrel{}{\leftarrow }\mathbf{Key}\left[\underline{w}\right]$

12: $\mathbf{if}\mathbf{W}\left[\underline{w}\right]=\perp \mathbf{then}$

13: $\mathbf{W}\left[\underline{w}\right]\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

14: $\mathbf{end}\mathbf{if}$

15: $((v_0,b{s}_0)\cdots ,(v_c,b{s}_c))\stackrel{}{\leftarrow }\mathbf{uh}\left[w\right]$

16: $s{t}_0\stackrel{}{\leftarrow }\mathbf{W}\left[\underline{w}\right]$,$c\stackrel{}{\leftarrow }\left|\mathbf{uh}\left[w\right]\right|$

17: $\mathbf{for}i=1\mathbf{to}c\mathbf{do}$

18: $s{t}_i\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

19:${\mathbf{H}}_1[k_w\left|\right|s{t}_i]\stackrel{}{\leftarrow }\mathbf{L}\left[v_i\right]$

20:${\mathbf{H}}_2[k_w\left|\right|s{t}_i]\stackrel{}{\leftarrow }\mathbf{E}\left[v_i\right]\oplus (s{t}_{i-1}\left|\right|b{s}_i)$

21: $\mathbf{end}\mathbf{for}$

22: $\mathrm{Send}(k_w,s{t}_c)\mathrm{to}\mathrm{server}$

□

4. Experimental Evaluation

This section presents a comparative analysis between VSSE and other existing schemes, considering both functionality and performance aspects.

4.1. Function Comparison

Table 2. Function comparison of various scheme.

Properties	Forward Security	Access Control	Verification	Dynamic Verification	Multi User
Scheme [11]	√	×	×	×	×
Scheme [24]	√	√	×	×	√
Scheme [25]	×	√	×	×	√
Scheme [31]	×	×	√	√	×
Scheme [33]	×	×	√	×	×
Our Scheme	√	√	√	√	√

offers a functional comparison between our scheme and other existing schemes. The schemes in refs. [11,24,25] did not consider the possibility of incorrect search results and do not possess the capability for result verification. The schemes in [31,33] and our scheme all take into account the scenario where the server maliciously returns incorrect search results, and they all rely on blockchain technology to accomplish the verification of search results. However, the schemes in refs. [31,33] lack consideration for forward security during the update, and they are only applicable to single-user scenarios. The scheme in refs. [33] also fails to achieve dynamic verification of search results.

Our scheme ensures forward security during the data update by a state chain structure and achieves dynamic verification of search results using blockchain and bitmap index. Additionally, we employ access control operations to enable the scheme to achieve secure search functionality in multi-user scenarios.

4.2. Performance Analysis

Implementation and settings. In order to provide a more realistic evaluation of the scheme’s performance in practical applications, we conducted tests using the Enron email dataset, which reflects real-world scenarios. This dataset contains email information from approximately 150 users across different folders. We selected 30,109 files from the Enron email dataset to form the file collection. Then, we utilized the method described in refs. [39,40] to extract 77,000 keywords from these files. We implemented VSSE in Python. Specifically, we used AES-256 and SHA-256 to implement the pseudo-random function and hash function, respectively. For the verification module, we used Solidity to build Ethereum smart contracts and utilize Ganache to evaluate the smart contracts. We have conducted a comparative analysis between VSSE and the existing schemes presented in refs. [26,32] to demonstrate the advantages of our proposed scheme. In particular, the scheme in refs. [32] is a blockchain-based solution and is also the primary comparison object in our study.

Index Generation Performance. Constructing a secure index is the foundation for performing effective search operations. Figure 5 illustrates the correlation between the index generations time and the amount of keywords. Illustrated in Figure 5, r index generation time across all schemes exhibits a proportional relationship with the number of keywords. Specifically, to balance search efficiency, the scheme in ref. [26] constructs a dual-index structure, which requires more time. On the other hand, in scheme [32], the index is constructed with less time cost by using key-value pairs, but lacks consideration for forward security. Compared to the schemes in refs. [26,32], VSSE outperforms [32] and takes more time than [26]. However, the index generated by VSSE fully considers the forward privacy and contributes to the search efficiency. Subsequent experiments will demonstrate this.

Search Performance.Figure 6 illustrates the correlation between search time and factors such as the quantity of keywords, the number of users, and the count of matching files. In Figure 6a, we demonstrate the influence of the quantity of keywords and the count of matching files on the search time. In Figure 6a, distinct colors of bars are employed to indicate varying quantities of matching files. It is evident that the search time exhibits a direct proportionality with the number of matching files and remains unaffected by the number of keywords. This observation is attributed to the construction of the inverted index. Moreover, Figure 6b illustrates the search efficiency of each scheme under different numbers of matching documents. VSSE outperforms the scheme in refs. [26,32]. The scheme in ref. [32] is worse than [26] and VSSE, which is because this scheme requires additional interaction with the blockchain during search operations. The search performance of [26] matches VSSE, but it lacks a verification feature. VSSE does not require additional interaction with the blockchain during the search and achieves search result verification functionality. Figure 6c depicts the impact of varying numbers of users and matching documents on search time. It can be observed that, with a fixed number of matching files, search time increases with the quantity of users grows. Similarly, with a constant number of users, search time also increases with the scale of files. The increase in search time due to the growth in the number of users is foreseeable. Figure 6d further illustrates the influence of varying numbers of users on the search time for each scheme. It is evident from the graph that the search time for all schemes is directly proportional to the number of users. However, compared to [32], both the scheme in ref. [26] and VSSE exhibit greater advantages.

Verification Performance. In this section, since the scheme in ref. [26] lacks the verification capability, we only compare the scheme in ref. [32] with VSSE. Figure 7 illustrates the correlations between the quantity of matching files and the storage capacity of the blockchain. As depicted in Figure 7, the storage requirement of the scheme proposed in ref. [32] escalates as the number of matching files increases. When the number of matching files rises from 1000 to 5000, the storage space usage also increases from 76.3 KB to 380.4 KB. This is because the scheme in ref. [32] requires storing the verification information for each file sequentially on the blockchain, and as the number of files increases, so does the required storage space. For VSSE, we only need to store a fixed bitmap index on the blockchain, which contains information about all the relevant files. Therefore, the storage cost of VSSE is hardly affected by the number of files, and our storage cost is much lower than that of the scheme in ref. [32] (e.g., for the number of matching files is 5000, VSSE incurs a storage cost of 13.8KB, while the scheme in ref. [32] takes 380.4 KB). Moreover, we compare the verification efficiency of the two schemes. Figure 8 illustrates the correlation between verification time and factors such as the length of bitmap index and the count of matching files. In Figure 8a, the verification time of the scheme in ref. [32] is proportional to the number of matching files, and the verification time of VSSE remains nearly constant and is faster than the scheme in ref. [32] in most scenarios (e.g., for the number of matching files is 5000, the verification time of VSSE is 2.5 s, while the scheme in ref. [32] takes 5.4 s). This is because the scheme in ref. [32] requires the computation of verification information for each file during the verification phase, and the number of files directly affects the verification time. In contrast, VSSE only needs to compute verification information for the bitmap index, and the verification time is solely related to the length of the bitmap index, unaffected by the number of matching files. Figure 8b further illustrates the impact of the bitmap index length on the verification time of VSSE. Distinct colors of bars indicate varying numbers of matching files. With the bitmap length increasing from 1000 to 5000, the verification time also increases from 0.53 s to 2.53 s. However, when the bitmap index length is fixed, the verification time remains almost the same.

5. Conclusions and Future Work

In this work, we present VSSE, a verifiable DSSE scheme based on blockchain for 6G-based intelligent application systems. This scheme ensures forward privacy of data in the 6G network through a state chain structure. VSSE leverages the immutable nature of blockchain to perform verification operations on the blockchain. Meanwhile, it combines bitmap index and MAC technology to achieve dynamic verification of search results. Our scheme also possesses effective access control functionality. Finally, the evaluation of the scheme’s functionality and performance demonstrates that VSSE aligns with the requirements of 6G-based intelligent application systems.

Regarding future work, in this paper, we conducted a security analysis focusing solely on threats related to update and search operations. However, potential threats still exist in the verification process between the cloud server and the blockchain, as well as in the access control mechanism for users with different privileges. Therefore, a more comprehensive security analysis of VSSE is needed, including the consideration of various attack scenarios, such as collusion attacks, and the proposal of corresponding security measures. Furthermore, although the scheme presented in this paper exhibits high search efficiency for single keyword, the search cost increases linearly with the number of keywords when users perform conjunctive searches involving multiple keywords. This is not favorable for a truly practical DSSE scheme. Therefore, our future research direction will focus on extending our scheme from single-keyword searches to multi-keyword searches while maximizing search efficiency. When our scheme achieves both rich expressive capability and efficient search performance, along with dynamic verification functionality, it will represent a more ideal DSSE solution in the context of 6G networks.