Privacy-Preserving Hierarchical Top-k Nearest Keyword Search on Graphs

Abstract

Graph search techniques are increasingly vital for applications involving labeled or textual content on network vertices. A key task is the top-k nearest keyword (kNK) search on undirected graphs where a query vertex and keywords identify k closest vertices containing the keywords. With cloud storage widely used for outsourcing graph services, ensuring data privacy and security is critical. Existing solutions employ encrypted indexes for privacy-preserving keyword searches but lack fine-grained access control, limiting their ability to accommodate diverse user needs. To address this, we propose privacy-preserving hierarchical top-k nearest keyword search on graphs (PH-kNK), a novel scheme enhancing privacy-preserving top-k keyword searches by integrating hierarchical access control. PH-kNK introduces hierarchical query entry indexes that regulate access at multiple security levels, significantly improving privacy, security and adaptability. The granular query entry indexes established by our approach enables users with higher security levels to query the graph structure and access corresponding vertices while maintaining transparency for lower-level users. The scheme leverages pseudo-random mapping, order-preserving encryption and re-encryption of search indexes to ensure robust data security. Experimental results on real-world datasets demonstrate the scheme’s high efficiency and validate its security.

1. Introduction

1.1. Background

Keyword search techniques on graphs have gained significant popularity in recent years for various real-life applications in networks that contain labeled or textual content on their vertices. In these scenarios, a top-k nearest keyword (kNK) search [1,2,3] is one of the most commonly used search types where a query request consists of a query vertex and a set of query keywords. The objective is to identify k vertices in the graph that contain the query keywords and are closest to the query vertex.

Cloud storage has become an increasingly popular solution for data owners seeking to outsource graph services, driven by the need for cost efficiency, enhanced scheme responsiveness and performance optimization. The simultaneous evolution of cloud services and big data represents a pivotal trend in the current digital economy. However, this rapid growth comes with significant risks. For instance, in 2017, a misconfiguration in Amazon AWS S3 buckets led to the exposure of sensitive information belonging to millions of users, affecting numerous prominent companies and organizations by leaking personal identity and financial data. Similarly, in 2019, security experts discovered a vulnerability within a service on Aliyun that could allow attackers to access user RAM permissions and subsequently obtain all authorized privileges. During the same year, researchers identified that some user API keys on Tencent Cloud were stored unprotected in publicly accessible code repositories, which could have been exploited by attackers to access sensitive user data and cloud resources. Tencent Cloud responded promptly by enhancing its security measures.

Recently, advancements in cloud services have included the continuous maturation of technologies such as artificial intelligence, blockchain and big data computing services. These developments underscore the growing universality, versatility and standardization of cloud-based solutions. Throughout the service lifecycle, both the data owned by service providers and the personal data of users are highly sensitive and must be protected diligently. Ensuring data privacy is a critical concern. To secure outsourced data, encrypted indexes are frequently employed. Specifically, to maintain the confidentiality of graph data, original keyword searches can only be conducted on encrypted versions.

As data owners increasingly rely on cloud storage for outsourcing graph services [4], the need for efficient algorithms becomes even more critical. One of the most commonly utilized searches within graph structures is the shortest path search, which is pivotal in applications like transportation networks where it calculates the shortest route between two points for navigation purposes. The shortest path problem has been extensively studied across various contexts. Numerous algorithms have been proposed to efficiently identify the shortest path between two vertices in a graph, such as transforming the graph into a directed graph and constructing a variant of a DT tree to discover time-limited shortest paths [5]. Alternatively, some approaches discussed searchable encryption [6,7,8,9], some are based on the shortest path community expansion algorithm, which leverages the dense connections within communities and sparse connections between them. This method uses the shortest path technique for expansion, developing index data structures and algorithms for path queries on general graphs, thereby optimizing performance for both serial and parallel graphs and solving multi-graph problems in polynomial time [10]. Additionally, researchers have explored the use of graph mining schemes to effectively represent specific unstructured data as graph data [11,12].

In practical network applications that involve vertex labels or textual content, keyword search technology within graph structures has gained increasing significance. A crucial operation in this context is the “top-k Nearest Keyword” (kNK) search on undirected graphs [13] where query requests typically involve a query vertex and a set of query keywords. The primary goal is to identify vertices in the graph that not only contain the query keywords but are also closest to the query vertex. The kNK search problem has garnered significant attention from the database and data mining communities. Lei Zou introduced the Top-k Correlated Subgraph Search (top-cgSearch) problem [14], developed the pattern growth algorithm (PG-Search) and conducted searches using graph indexing methods, significantly improving the efficiency of each independent local search involved. Similar problems were also studied [15].

Looking towards the future, considering factors like storage costs, service responsiveness and performance optimization, the trend is expected to favor the widespread adoption of cloud storage for outsourcing graph services. Throughout the service lifecycle, data belonging to both data owners and users is highly sensitive and requires meticulous protection. Data privacy remains a paramount concern. Encrypted indexes play a significant role in ensuring the security of outsourced data. To preserve the confidentiality of graph data, original keyword searches are confined to encrypted versions.

Existing solutions, such as the PPkNK scheme [16], excel at performing privacy-protected searches for the top-k nearest keywords in a graph. These methods involve constructing two-level indexes, utilizing encryption techniques and intersecting privacy-protected sets to ensure both privacy and operational efficiency during searches. Furthermore, a hierarchical searchable encryption scheme based on blockchain indexing, known as HSE-BI [17], has been introduced. This innovative solution provides robust fine-grained access control and maintains the reliability of search results through the consistency and immutability of blockchain-based indexing. However, these schemes are not specifically designed for graph structure searches. Existing kNK schemes fall short of addressing the needs of users who require access to information from vertices with varying secrecy levels for the same keyword.

To address this, the scheme has fine-grained access control for performing kNK searches over encrypted graphs. Each vertex possesses a security level, allowing users with higher security levels to query the graph structure and access corresponding vertices. In contrast, vertices remain hidden during the query process for users with lower security levels. This approach effectively caters to scenarios where users require access to data with varying sensitivities, enabling flexible and secure querying.

Imagine a collaboration between multiple research institutes across different countries working on a global health initiative. These institutes need to share and analyze large datasets, such as patient records, clinical trial results and genetic data, to develop treatments for a particular disease. However, due to varying privacy regulations and the sensitivity of the data, not all researchers can access the same level of information. Researchers in different countries need access to this data to collaborate effectively, but they must comply with their respective national regulations. This means that access to certain data must be restricted based on the user’s location, role and security clearance. Each piece of data, represented as a vertex in the graph, is assigned a security level based on its sensitivity. For example, basic research data might be accessible to all researchers, while patient records are only accessible to researchers with the highest security clearance. Our scheme allows international researchers to collaborate effectively by providing them with the information they need while complying with local data privacy regulations. High-level researchers can access detailed data for their analysis, while others only see the information they are permitted to view. The privacy-preserving methods ensure that sensitive data remains secure throughout the process.

1.2. Our Contribution

• We propose a hierarchical privacy-preserving top-k keyword search scheme (PH-kNK) on graphs which achieves hierarchical access control and privacy preserving.
• The scheme has fine-grained access control allowing users with certain security level can only access vertices with lower level.
• We analysis the proposed scheme and conduct experiments with real-world datasets. The result of the experiment shows the proposed scheme has higher efficiency compared to other existing solutions.

2. Related Works

The concept of searchable encryption technology was first introduced by Song et al. in 2000 [18]. Since then, research has extensively expanded, focusing on improving search efficiency and security across diverse applications.

In tackling the challenges of secure, efficient querying over complex, structured data, Chase and Kamara made a groundbreaking leap with their concept of structured encryption [19]. Moving beyond the realm of symmetric searchable encryption (SSE), they formulated structured encryption to handle data as intricate as web graphs or social networks, pushing the boundaries of private data access. Their work brought forth the Chosen-Query Attack (CQA) security model, which reshaped security standards for structured data, along with a suite of encryption schemes: for example, matrix-structured encryption to enable rapid lookups, keyword-searchable labeled data encryption and multiple graph-based encryption schemes.

Recent literature on searchable encryption over graph-structured data has explored various aspects of security, accuracy and efficiency. As shown in Table 1, MVSSE [20] can achieve hierarchical privacy protection on non-structured data. k-NK [13], PPkNK [16], Aton [21] and other frameworks have made strides in handling large-scale knowledge graphs, but fail to fully address privacy-preserving searches in hierarchical graph structures. Our work uniquely integrates these dimensions, providing a comprehensive solution for top-k keyword searches in hierarchical privacy-preserving graph structures.

Table 1. Comparison of privacy protection and graph types across different methods.

	k-NK	MVSSE	PPkNK	Aton	PH-kNK
Privacy protection		✓	✓	✓	✓
labeled graphs	✓		✓	✓	✓
accurate search	✓			✓	✓
hierarchical search		✓			✓

As shown in Figure 1, research on searchable encryption covers aspects related to data security, searchability, user authentication and access control. Some schemes have been conducted on keywords search on graphs [22,23]. Our scheme takes all of the above into account and addresses the limitation of existing kNK schemes by offering fine-grained access control, improves query efficiency with a novel hierarchical index structure and enhances data security through advanced encryption techniques.

Figure 1. Research on searchable encryption.

Another research focus aspect is keyword search within encrypted graph structures. Graph encryption schemes, such as those proposed by Teng et al., support privacy-preserving Top-k nearest keyword searches on encrypted graphs, using secure indexing and encryption techniques to balance security and efficiency [16,24]. Moreover, distance-based keyword search methods have gained attention, such as the keyLabel-Indexing algorithm, which efficiently handles shortest path queries on encrypted graph data [25]. More recently, semantic search engines leveraging graph data have been introduced to improve the accuracy of keyword searches. Cozza and Sellami proposed frameworks integrating semantic knowledge from linked web data, enhancing search engines’ ability to process complex queries [26,27]. Figure 2 illustrates the development overview of graph structure encryption and hierarchical encryption. Our solution is a combination of solutions to problems in aspects hierarchical searchable encryption and keyword search on encrypted graph.

Figure 2. Overview of Graph Structure Encryption and Hierarchical Encryption.

3. Preliminaries

3.1. Pruned 2-Hop Labeling

The pruned landmark labeling technique [28], which builds upon the 2-hop cover framework, is a method designed for querying shortest path distances efficiently in large-scale networks. It involves creating distance labels (also known as distance-aware 2-hop covers) for each vertex, allowing for rapid computation of shortest paths between vertices. This is done by applying breadth-first search (BFS) to precompute distance labels and utilizing pruning during the search.

In this method, for each vertex v, a label, denoted $L\left(v\right)$, is generated. The label comprises pairs of the form $(u,{\delta }_{uv})$, where u denotes a vertex and ${\delta }_{uv}$ is the shortest distance between vertices u and v. The collection of these labels, ${L\left(v\right)}_{v\in V}$, forms the index used for queries. To answer a distance query between two vertices s and t, the query function is defined as follows:

$$\mathrm{Query}(s,t,L)=min\{{\delta }_{vs}+{\delta }_{vt}|(v,{\delta }_{vs})\in L\left(s\right),(v,{\delta }_{vt})\in L\left(t\right)\}.$$

If $L\left(s\right)$ and $L\left(t\right)$ do not share any common vertex, the query result is ∞, signifying the absence of a path between s and t based on the labels. A label set L is termed a 2-hop cover if, for any vertices s and t, $\mathrm{Query}(s,t,L)$ accurately equals $d_G(s,t)$, the shortest path distance in the graph G.

For optimization, each vertex’s label $L\left(v\right)$ is pre-sorted by vertex indices, enabling an efficient merge-join algorithm for querying. This reduces the computational complexity of each query to $O\left(\right|L\left(s\right)|+|L\left(t\right)\left|\right)$, ensuring fast retrieval of shortest paths.

The method guarantees the construction of a valid 2-hop cover, ensuring that for any vertex pair $(s,t)$, $\mathrm{Query}(s,t,L)$ returns the exact shortest path, $d_G(s,t)$.

3.2. Order-Preserving Encryption

The Order-Preserving Encryption (OPE) scheme, as outlined by Boldyreva et al. [29], retains the relative order of plaintext values in their corresponding ciphertexts, resembling the behavior of pseudorandom functions (PRFs). OPE takes advantage of the mathematical properties of order-preserving functions and relies on the hypergeometric distribution for efficient sampling in encryption processes.

In formal terms, consider two subsets A and B of the natural numbers $\mathbb{N}$, with $\left|A\right|\le \left|B\right|$. A function $f:A\to B$ is labeled order-preserving (or strictly-increasing) if for any $i,j\in A$, $f\left(i\right)>f\left(j\right)$ implies $i>j$.

An encryption scheme $SE=(K,enc,\mathrm{Dec})$ is defined as order-preserving when, for all secret keys K generated by the key generation algorithm, the encryption function $enc(K,·)$ ensures that the relative order of plaintexts is maintained in the ciphertext domain. Specifically, this is achieved by defining $enc(K,·)$ as an order-preserving function between the plaintext space D and ciphertext space R where both spaces consist of natural numbers encoded as strings. Typically, the plaintext space is denoted as $\left[M\right]$ and the ciphertext space as $\left[N\right]$, where $N\ge M$.

3.3. Proxy Re-Encryption

Proxy Re-encryption (PRE) is a cryptographic mechanism designed to securely transform ciphertext from one key to another. Introduced by Blaze et al. at Eurocrypt in 1998, PRE allows a ciphertext encrypted under the delegator’s public key to be transformed, enabling a delegate to decrypt it using their own private key, without revealing the plaintext to the proxy performing the transformation. This transformation is achieved using a re-encryption key, which the delegator provides to the proxy. The key enables the semi-trusted proxy to convert the original ciphertext for the delegate without accessing the underlying data. Umbral Encryption [30] employs a Key Encapsulation Mechanism (KEM) to delegate decryption capabilities from Alice to Bob. For example, if data is encrypted using Alice’s public key, $c_A=\mathrm{encrypt}(p{k}_A,m)$, Bob can be authorized to decrypt the data by re-encrypting the ciphertext with a transformation key, $r{k}_{A\to B}$. Bob can then decrypt the re-encrypted ciphertext using his private key: $c_B=\mathrm{reencrypt}(r{k}_{A\to B},c_A)$.

4. Model and Definition

This section outlines the architecture of the proposed scheme and its associated security model. It details the structure of the graph and describes the framework for the graph encryption scheme.

Our scheme consists of three main entities: the data owner, the cloud server and the users. The data owner holds the graph data, generates the indexes, encrypts both the graph and its indexes and is responsible for key management. The encrypted index is sent to the cloud server, which processes query tokens from users and delivers search results. Users, on the other hand, must request access to specific query levels and the corresponding keys from the data owner. Once they have the search results from the cloud server, they decrypt the data to retrieve the final results.

The graph in our scheme is a labeled structure designed to support PH-kNK searches. This feature allows users to query the graph for vertices that meet specified permission conditions, contain the queried keywords and are within the k-nearest to the queried vertex.

4.1. System Construction

This section discusses the search framework of the hierarchical labeled graph. A formal definition of the hierarchical labeled graph is presented below.

4.1.1. Definition of Hierarchical Labeled Graph

Definition 1 (hierarchical labeled graph).

A graph $G=\left(V,E\right)$ comprises a set of vertices and edges. Each vertex is represented as a tuple $(v_i,w_i,l_i)$ where $v_i\in V$, $w_i\in W$ and $l_i\in L$. Here, V refers to the set of vertex identifiers, W refers the set of keyword identifiers and L refers to the set of security level of each vertex. The set E consists of all the edges in the graph, each edge is denoted by $e=(v_i,v_j)$, where $v_i$ and $v_j$ are two vertices in V.

The graph security framework assigns independent security levels to each vertex through a triple structure $(vertex,word,level)$ formally defined in Definition 1.

The mechanism of user access to vertices is based on Mandatory Access Control (MAC), where both users and vertices are assigned levels of access. The user security level, as well as the level of the vertices, is determined by the data owner, who also provides the necessary authorization. In summary, access control follows hierarchical constraints where users can only retrieve keywords from vertices with security levels $l_i$ satisfying $l_i\le l_u$, where $l_u$ denotes the user security level.

Our scheme does not consider how the data owner assigns the security level. In real word application scenarios, the data owner can follow the related rules and regulations. For example, in healthcare scenarios, the data owner (healthcare institution or research organization) can assign different patient records including clinical trial data, genetic metadata, public research summaries may be assigned different security levels. The data owner assigns access levels to users, and only those with the appropriate security level can access the high-level data.

4.1.2. Graph Encryption Scheme

Below is the framework for the proposed PH-kNK scheme, consisting of seven algorithms: $\Pi$ = {KeyGen, BuildIndex, EncryptIndex, KeyAssign, QueryToken, KNKSearch, Decrypt}. The architecture of the scheme is shown in Figure 3.

Figure 3. Model of PH-kNK scheme.

4.2. Graph Encryption Scheme

The proposed scheme comprises seven core algorithms, which are outlined below:

•

$K\leftarrow \mathrm{KeyGen}\left(\lambda \right)$: This algorithm generates a set of secret keys, using a security parameter $\lambda$ as input. The result is a key set K.

•

$I\leftarrow \mathrm{BuildIndex}\left(G\right)$: Given a graph G and its edges E, the algorithm constructs an encrypted index set I.

•

$I_{enc}\leftarrow \mathrm{EncryptIndex}(K,I)$: This algorithm encrypts the index I produced by BuildIndex, using the key set K and outputs the search index $I_{enc}$.

•

$K_U\leftarrow \mathrm{KeyAssign}\left(K\right)$: This algorithm takes the data owner’s public key K as input and produces a unique user key $K_U$.

•

$T\leftarrow \mathrm{QueryToken}(K_U,S)$: This algorithm generates a query token T by using the user’s secret key $K_U$ and the query information S.

•

$R_{enc}\leftarrow \mathrm{kNKSearch}(T,I_{enc})$: This algorithm takes the query token T and the encrypted index $I_{enc}$ as input, returning an encrypted query result $R_{enc}$.

•

$R\leftarrow \mathrm{Decrypt}(K_U,R_{enc})$: This algorithm decrypts the encrypted query result $R_{enc}$ using the user’s key $K_U$, producing the final result R.

4.3. Security Model

In this paper, the server is considered as semi-honest or “honest-but-curious”, which means it will execute the algorithms of the scheme faithfully, while trying to learn any information about the graph of the data owner. The security goal of the scheme is to minimize the information leakage to the server. Furthermore, we define two leakage functions, ${\mathcal{L}}_1$ and ${\mathcal{L}}_2$. ${\mathcal{L}}_1$ represents the information that the server can learn from the encrypted search index $I_{enc}$ and ${\mathcal{L}}_2$ represents the information that the server can learn from the query token T and the corresponding query result $R_{enc}$.

The formal security definition is described as follows.

Definition 2 (Security Model).

Let Π = (KeyGen, KeyAssign, BuildIndex, EncryptIndex, QueryToken, KnkSearch, Decrypt) be a graph encryption scheme supporting hierarchical top-k keyword search, $\mathcal{A}$ be a semi-honest adversary, $\mathcal{S}$ be a simulator and ${\mathcal{L}}_1$ and ${\mathcal{L}}_2$ be two leakage functions. Consider the following experiments:

$Rea{l}_{\mathcal{A}}\left(\lambda \right)$:

In the setup phase, $\mathcal{A}$ first chooses a graph G and sends it to the challenger. The challenger then runs KeyGen($\lambda$) to generate a set of keys K and runs KeyAssign(K) to produce a user key $K_U$. After that, the challenger runs BuildIndex(G) and Encrypted(K, I) to obtain the encrypted search index $I_{enc}$. The challenger sends $I_{enc}$ to $\mathcal{A}$.

In the query phase, $\mathcal{A}$ adaptively chooses hierarchical top-k keyword search queries of polynomial number. For each query S, the challenger runs QueryToken($K_U,S$) and sends the corresponding query token T to $\mathcal{A}$. Then $\mathcal{A}$ runs KnkSearch(T, $I_{enc}$) and obtains the encrypted query result $R_{enc}$. Finally, $\mathcal{A}$ outputs a bit b as the output of the experiment.

$Idea{l}_{\mathcal{A},\mathcal{S}}(\lambda$):

In the setup phase, $\mathcal{A}$ first chooses a graph G and sends it to the challenger. Then $\mathcal{S}$ simulates a encrypted search index $I_{enc}^{\ast }$ using the leakage function ${\mathcal{L}}_1\left(G\right)$ and sends $I_{enc}^{\ast }$ to $\mathcal{A}$.

In the query phase, $\mathcal{A}$ adaptively chooses hierarchical top-k keyword search queries of polynomial number. For each query S, $\mathcal{S}$ simulates a query token $T^{\ast }$ using the leakage funtion ${\mathcal{L}}_2(G,S)$ and sends $T^{\ast }$ to $\mathcal{A}$. Then $\mathcal{A}$ runs KnkSearch($T^{\ast }$, $I_{enc}^{\ast }$) and obtains the encrypted query result $R_{enc}$. Finally, $\mathcal{A}$ outputs a bit b as the output of the experiment.

We say that the proposed scheme $\Pi$ is (${\mathcal{L}}_1$, ${\mathcal{L}}_2$)-secure against the adaptive chosen-query attack, if for every probabilistic polynomial-time (PPT) adversary $\mathcal{A}$, there exist a simulator $\mathcal{S}$ such that

$$|\mathbf{Pr}[{\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)=1]-\mathbf{Pr}[{\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)=1]|\le \mathrm{negl}\left(\lambda \right),$$

where negl(·) is a negligible function.

5. Algorithm Construction

This section outlines the seven algorithms implemented within the PH-kNK scheme. Table 2 outlines the various notation used in this paper.

Table 2. Notations.

Notations	Denotations
G	A graph
n	The number of vertices in the graph G
$v_i$	vertex $v_i(1\le i\le n)$ in graph
$w_i$	Keyword which vertex $v_i$ contains
$l_i$	Level of vertex $v_i$
V	A tuple of ${(v_i,w_i,l_i)}_{v_i\in \left|V\right|,w_i\in \left|W\right|,l_i\in \left|L\right|}$
E	Edegs in the graph G
$wor{d}_i$	A tuple having $v_i$, $w_i$, $l_i$ in $wordindex$
$di{s}_{ij}$	Shortest distance between vertex $v_i$ and vertex $v_j$
$K_1$	A Secret key for hash and symmetric encryption
$K_2$	A Secret key for order-preserving encryption
$wordindex$	A index generated for search sorted by keywords
$entryindex$	A index indicating where to start the search in $wordindex$
$queryindex$	A search index of PLL algorithm to get $di{s}_{ij}$
$L_{enc}$	A set of encrypted indexes above
PLL	A pruned landmark labeling scheme
OPE	An order-preserving encryption scheme
PRE	A proxy re-encryption scheme, Umbral encryption
SE	A symmetric encryption scheme
HAMC	a hash-based Message Authentication Coding method
g	a pseudorandom function

5.1. Building Blocks

5.1.1. Pruned Landmark Labeling (PLL)

The Pruned Landmark Labeling (PLL) technique consists of two algorithms: PLL_indexgen($graph$) and PLL_search($v_{start}$, $v_{end}$, $index$). The PLL_indexgen algorithm is responsible for generating a search index for the graph, which enhances query performance. In contrast, the PLL_search algorithm calculates the shortest path between two specific vertices, $v_{start}$ and $v_{end}$ in the index.

• PLL_indexgen($graph$) → search index: Generates an efficient search index for the graph.
• PLL_search($v_{start}$, $v_{end}$, $index$) → dis: Calculates the shortest distance between two vertices in the graph.

5.1.2. Order-Preserving Encryption (OPE)

The Order-Preserving Encryption (OPE) algorithm guarantees that for two plaintext values $d_1$ and $d_2$, if $d_1>d_2$, their corresponding encrypted values $c_1$ and $c_2$ maintain the same order $c_1>c_2$. This property allows for secure range queries on encrypted data.

• OPE_Enc(K, d) → c: Encrypts the plaintext value d using the secret key K.
• OPE_Dec(K, c) → d: Decrypts the encrypted value c using the secret key K to retrieve the plaintext.

5.1.3. Proxy Re-Encryption (PRE)

The Proxy Re-Encryption (PRE) scheme facilitates encrypted data sharing among different users. It allows an intermediary (the proxy) to re-encrypt data from one user to another without accessing the plaintext. The key functions of this scheme are:

• PRE_KeyGen() → keypair (pk, sk): Generates a pair of public and private keys.
• PRE_ReKeyGen(skA, pkB, N, t) → N fragments of the re-encryption key: Generates fragments of the re-encryption key, allowing re-encryption from Alice to Bob.
• PRE_Encapsulate(pkA) → K, capsule: Encapsulates a symmetric key and generates a capsule using Alice’s public key.
• PRE_Decapsulate(skA, capsule) → K or ⊥: Decrypts the capsule using Alice’s private key to retrieve the symmetric key.
• PRE_ReEncapsulate(kFrag, capsule) → cFrag: Re-encapsulates a fragment of the capsule using the re-encryption key fragment.
• PRE_DecapsulateFrags(skB, $cFrag\_i$, capsule) → K or ⊥: Uses Bob’s private key to decrypt the capsule fragments and retrieve the symmetric key.
• PRE_Encrypt(K, M) → C: Encrypts a message M using the symmetric key K.
• PRE_Decrypt(K, C) → M or ⊥: Decrypts the ciphertext using the symmetric key and retrieves the original message.

5.2. KeyGen Algorithm

Data owner runs the KeyGen algorithm (Algorithm 1) and produces two randomly generated keys for HAMC and OPE, respectively, with the key length determined by the security parameter $\lambda$. Additionally, it generates a proxy re-encrypted data owner key set $Ownerkey=\left[secretke{y}_O,publicke{y}_O,signingke{y}_O,verifyingke{y}_O,signe{r}_O\right]$ using the PRE_KeyGen algorithm.

Algorithm 1 KeyGen

Input: A security parameter $\lambda$ Output: A set of secret keys K   1: $K_1$ $\stackrel{\$}{\leftarrow }$ ${\left\{0,1\right\}}^{\lambda }$   2: $K_2$ $\stackrel{\$}{\leftarrow }$ ${\left\{0,1\right\}}^{\lambda }$   3: $OwnerKey$ ← PRE_KeyGen()   4: Return K ← $\left(K_1,K_2,OwnerKey\right)$

5.3. Buildindex Algorithm

The BuildIndex algorithm (Algorithm 2) is conducted by the data owner. Firstly, the data owner constructs $wordindex$ and $entryindex$ by categorizing the set of vertex $V=(v,w,l)$ in G into the list $wor{d}_i$ based on their respective keywords $w_i$. Next, arrange the elements in $wor{d}_i$ in descending order according to the vertex security level l. When querying the keyword $w_i$, due to the descending order of $wor{d}_i$, it is only necessary to find the first element in the $entryindex$ that is less than or equal to the queried security level l. The index of the current list $wor{d}_i$ serves as the entry point for querying $w_i$ and the key level l. For the word index, its basic structure is keyword: (vertex, level). For the entry index, its basic structure is keyword: level: entry. The construction of the $querylindex$ is based on a 2-hop hierarchical labeled graph search scheme, with the purpose of enabling minimum distance queries between two points on the graph.

The process of establishing indices $wordindex$, $entryindex$ and $queryindex$ is as follows:

• Initialization of Index $wordindex$: $wordindex$ is initialized by traversing the set W. Each keyword w in W serves as a key, while the associated value is an array of tuples $(v,l)$ where v represents vertices and l indicates levels containing the keyword w. Thus, the format of $wordindex$ entries is $\left(\right[v,l\left]\right)\to w$.
• Initialization of Index $entryindex$: $entryindex$ is initialized for each keyword by creating an array with levels from 0 up to l, associating each level l with an entry index v that corresponds to that level. The $entryindex$ is structured as $\left(\right[l]:v)\to w$. To secure this structure, $entryindex$ employs HMAC encryption on a constant c and entry v, which restricts backward decryption and prevents direct access to subsequent array elements.
• Initialization of Index $queryindex$: $queryindex$ is constructed based on the 2-hop pruned algorithm to compute the shortest distance between two vertices in a query graph. In $queryindex$, each vertex $v_i$ in the graph is a key, with values represented as pairs $(v_j,d)$ where $v_j$ is a reachable vertex and d denotes the shortest distance from $v_i$ to $v_j$. This structure allows efficient querying of shortest paths in the graph.

Algorithm 2 BuildIndex

Input: A graph G Output: A set of indexs I    1: Parse G as $\left(V,E\right)$    2: Parse V as $\left(v,w,l\right)$    3: Initialize a dictionary $wordindex$    4: Initialize a dictionary $entryindex$    5: Initialize a dictionary $queryindex$    6: $wordindex$ = ${\left[wor{d}_i\right]}_{wor{d}_i\in \left|W\right|}$    7: for $\left(v_i,w_i,l_i\right)\in \left|V\right|$  do    8:       for $w_j\in \left|W\right|$ do    9:            if $w_i$ = $w_j$ then  10:                $wor{d}_i$$\leftarrow \left(v_i,w_i,l_i\right)$  11:          $wor{d}_{i^{\prime }}\left(l_{i^{\prime }}\right)\leftarrow$$wor{d}_i\left(l_i\right)desc$  12:          for $l_k\in \left|L\right|$ do  13:                while $wor{d}_{i^{\prime }}\left(l_{i^{\prime }}\right)<=l_k$ do  14:                     $entryindex\left(wor{d}_{i^{\prime }}\left(l_{i^{\prime }}\right)\right)\leftarrow i^{\prime }$  15: Generate PLL index  16: $queryindex\leftarrow$ PLL_indexgen$\left(G\right)$  17: Return I ← $\left(wordindex,entryindex,queryindex\right)$

5.4. Encryptindex Algorithm

The main function of this Algorithm 3 is to encrypt the search index, input the encryption key group K and the index set I to be encrypted and output an encrypted index set $I_{Enc}$, run at the data owner. For $wordindex$, each keyword is encrypted using $K_1$ and HAMC and each vertex in the $wor{d}_i$ list is encrypted with two layers. Firstly, a layer of $K_2$ is used to encrypt OPE and then a data owner public key is used to proxy re-encrypt, outputting ciphertext and capsule where capsule are used to authorize users to decrypt. For $entryindex$, encrypt the keywords using the same HAMC and secret key and OPE for each level. For $queryindex$, it use two layers of encryption including symmetric encryption and proxy re-encryption for each vertex. it does not contain keywords, while vertices use a single-layer $K_1$ sequence preserving encryption OPE.

The algorithm EncryptIndex takes as input a set of indices I and a set of keys K and outputs an encrypted index set $I_{enc}$. First, the key set K is parsed into $K_1$, $K_2$ and $OwnerKey$. Similarly, the index set I is parsed into three parts: $wordindex$, $entryindex$ and $queryindex$.

For each word $wor{d}_i$ in $wordindex$, the algorithm processes its elements as follows: each element $w_i$ is encrypted using the HMAC algorithm with $K_1$, resulting in $w_{i\left(enc\right)}$. Each element $v_i$ is encrypted using the SE algorithm with $K_1$, yielding $v_{i\left(se\right)}$. A capsule is then generated using the $\mathrm{PRE}\text{\_}\mathrm{Encapsulate}$ function and $v_i$ is further encrypted using $\mathrm{PRE}\text{\_}\mathrm{Encrypt}$ with the capsule, producing $v_{i\left(enc\right)}$. For each element $l_i$, the $\mathrm{OPE}\text{\_}\mathrm{Enc}$ algorithm with $K_2$ is applied to generate $l_{i\left(ope\right)}$. Another capsule is generated and $l_i$ is encrypted using $\mathrm{PRE}\text{\_}\mathrm{Encrypt}$ with the capsule, resulting in $l_{i\left(enc\right)}$. The encrypted results for each item in $wordindex$ are stored in $wordinde{x}_{enc}$.

Algorithm 3 EncryptIndex

Input: A set of indexs I and a set of keys K Output: A encrypted index set $I_{enc}$    1: Parse K as $\left(K_1,K_2,OwnerKey\right)$    2: Parse I as $\left(wordindex,entryindex,queryindex\right)$    3: for $wor{d}_i\in \left|wordindex\right|$ do    4:       for $w_i\in wor{d}_i$ do    5:             $w_{i\left(enc\right)}\leftarrow HAMC\left(K_1,w_i\right)$    6:       for $v_i\in wor{d}_i$ do    7:             $v_{i\left(se\right)}\leftarrow$ SE_Encrypt$\left(K_1,v_i\right)$    8:             $capsule\leftarrow$ PRE_Encapsulate$\left(pkA\right)$    9:             $v_{i\left(enc\right)}\leftarrow$ PRE_Encrypt$(capsule,v_i)$  10:       for $l_i\in wor{d}_i$ do  11:             $l_{i\left(ope\right)}\leftarrow$ OPE_Enc$\left(K_2,l_i\right)$  12:             $capsule\leftarrow$ PRE_Encapsulate$\left(pkA\right)$  13:             $l_{i\left(enc\right)}\leftarrow$ PRE_Encrypt$(capsule,l_i)$  14:             Let $wordinde{x}_{enc}$ be the encrypted index of each item in $wordindex$  15: for $wor{d}_i\in \left|entryindex\right|$  do  16:       $w_{i\left(enc\right)}\leftarrow HAMC\left(K_1,w_i\right)$  17:       for $l_i\in wor{d}_i$ do  18:             $l_{i\left(enc\right)}\leftarrow$ OPE_Enc$\left(K_2,l_i\right)$  19: Set c = 0  20: for $v_i\in queryindex$ do  21:       $v_{i\left(se\right)}\leftarrow$ SE_Encrypt$\left(K_1,v_i\right)$  22:       for $(u,d)\in queryindex\left[v_i\right]$ do  23:             u = $HAMC(v_{i\left(se\right)},K2)$  24:             $T_v^c=g(HAMC(K1,v),c)$  25:             $$\begin{gathered} queryindex\left[v_i\right]=\left(u\right|\left|d\right||HAMC(key1,u)⨁ \\ g(T_v^c,c))⨁T_v^c \end{gathered}$$  26:             Set c = c + 1  27:             $capsule\leftarrow$ PRE_Encapsulate$\left(pkA\right)$  28:             $v_{i\left(enc\right)}\leftarrow$ PRE_Encrypt$(capsule,v_i)$  29:             $d_{iu\left(enc\right)}\leftarrow OPE\left(K_2,d_{iu}\right)$  30: Return $capsule,I_{enc}$ ← $(wordinde{x}_{enc},entryinde{x}_{enc},queryinde{x}_{enc})$

For each $wor{d}_i$ in $entryindex$, the algorithm encrypts each element $w_i$ using the HMAC algorithm with $K_1$, producing $w_{i\left(enc\right)}$. Each element $l_i$ is encrypted using the $\mathrm{OPE}\text{\_}\mathrm{Enc}$ algorithm with $K_2$, yielding $l_{i\left(enc\right)}$.

For the $queryindex$, a counter c is initialized to 0. For each element $v_i$ in queryindex, the algorithm encrypts $v_i$ using the SE algorithm with $K_1$, resulting in $v_{i\left(se\right)}$. For each tuple $(u,d)$ in $queryindex\left[v_i\right]$, u is computed using the HMAC algorithm applied to $v_{i\left(se\right)}$ and $K_2$. The value $T_v^c$ is calculated as $g(\mathrm{HMAC}(K_1,v),c)$ and $queryindex\left[v_i\right]$ is updated to $\left(u\right|\left|d\right||\mathrm{HMAC}(K_1,u)⨁g(T_v^c,c))⨁T_v^c$. The counter c is incremented by 1. A capsule is generated using $\mathrm{PRE}\text{\_}\mathrm{Encapsulate}$ and $v_i$ is encrypted using $\mathrm{PRE}\text{\_}\mathrm{Encrypt}$ with the capsule, producing $v_{i\left(enc\right)}$. The value d is encrypted using the OPE algorithm with $K_2$, yielding $d_{iu\left(enc\right)}$.

Finally, the algorithm returns the generated capsule and the encrypted index set $I_{enc}$ which consists of the encrypted $wordinde{x}_{enc}$, $entryinde{x}_{enc}$ and $queryinde{x}_{enc}$. Then the data owner transmits the encrypted index to the server.

5.5. KeyAssign Algorithm

Before a new user requests an encrypted query, the following steps in Algorithm 4 must be carried out: User gets key set from owner who runs generation algorithm to generate a public and private key pair. Then the user needs to ask permission from the data owner, acquire key fragments and also receive the OPE key ($K_2$) to generate query tokens. The user get proxy re-encrypt key fragments (KeyFrags) from data owner. The server runs the same steps as the user except receiving $K_2$.

Algorithm 4 KeyAssign

Input: A data owner secret key and a user public key K Output: A user key set $K_U$   1: $(UserSecretKey,UserPublicKey)$ $\stackrel{\$}{\leftarrow }$ PRE_KeyGen   2: $KeyFrags$ $\stackrel{\$}{\leftarrow }$ PRE_ReKeyGen$(OwnerSecretKey,UserPublicKey)$   3: Return $K_U$ ←$(UserSecretKey,UserPublicKey,KeyFrags,K_2)$

5.6. Query Token Algorithm

When a user initiates a query request, the QueryToken algorithm (Algorithm 5) is run. The algorithm QueryToken takes as input a user key set $K_U$ and a query message S. It outputs a query token T. The user key set $K_U$ is parsed into the public key PublicKey and the secret key SecretKey. The query message S is parsed into keyword, level and vertex. Then the data owner assigns keys by generating a key fragment keyfrag, an encrypted keyword ${\mathrm{wordenc}}_K$ and other necessary keys including K and OwnerKey. The KeyAssign function is used to assign keys based on the keyword, level and vertex.

Algorithm 5 QueryToken

Input: A user key set $K_U$ and query message S  Output: A query token T 1: Parse $K_U$ as $(PublicKey,SecretKey)$ 2: Parse S as $(keyword,level,vertex)$ 3: $KeyFrags,wor{d}_{enc}\leftarrow$ $(K_1,K_2,OwnerKey)$ 4: $(KeyFrags,OwnerPublickey)\leftarrow$ KeyAssign$(keyword,level,vertex)$ 5: $\left(leve{l}_{enc}\right)\leftarrow$ OPE_Enc$\left(level\right)$ 6: $\left(verte{x}_{enc}\right)\leftarrow$ SE$\left(vertex\right)$ 7: Return $I_{enc}\leftarrow (keywor{d}_{enc},leve{l}_{enc},verte{x}_{enc},k)$

Then, the level level is encrypted using the $\mathrm{OPE}\text{\_}\mathrm{Enc}$ function to produce ${\mathrm{level}}_{enc}$. The vertex vertex is encrypted using the SE function to produce ${\mathrm{vertex}}_{enc}$.

The user finally gets the query token T, which consists of the encrypted keyword ${\mathrm{keyword}}_{enc}$, the encrypted level ${\mathrm{level}}_{enc}$, the encrypted vertex ${\mathrm{vertex}}_{enc}$ and the parameter k.

5.7. Knk Search Algorithm

When the server gets a query request and it starts a query trying to get the results from encrypted $entryindex$, first it finds an entry level value that is not less than the input vertex level. Then, it check whether the next value in the entry list is not bigger than the input vertex. If not, search down in order to find the next entry in list. If both of the above conditions are met, then according to the principle of order-preserving encryption, the current entry level value is the input vertex level and it send back the entry for next searching stage. Starting from the corresponding entry in $wor{d}_i$ within $\left|W\right|$, extract all vertices from the list and include them in the result candidate set.

Given the input vertex as src and all points in the result candidate set as des, calculate the distance between Src and des and subsequently add the des vertex along with the calculated distance to the result candidate set. The candidate set of results is sorted in ascending order based on the distance between two points. Subsequently, the first k results are selected and returned as the final result, representing the query result of the input vertex within the security level limit of the topk keyword.

The KNKSearch algorithm (Algorithm 6) takes as input a query token T and a set of encrypted indices $I_{enc}$ and outputs a set of encrypted search results $R_{enc}$. The query token T is parsed into four parts: ${\mathrm{keyword}}_{enc}$, ${\mathrm{level}}_{enc}$, ${\mathrm{vertex}}_{enc}$ and k.

Algorithm 6 kNKSearch

Input: A query token T and aet of encrypted indexs $I_{enc}$ Output: A set of encrypted search results $R_{enc}$    1: Parse T as $\left(keywor{d}_{enc},leve{l}_{enc},verte{x}_{enc},k\right)$    2: for $wor{d}_i\in wordindex$ do    3:       if $wor{d}_i$ = $keywor{d}_{enc}$ then    4:             for $v_{enc}\in wor{d}_i$ do    5:                   $v_{re-enc}\leftarrow$ ReEncapsulation$\left(capsule,keyfrag\right)$    6:                   $v_{ce}\leftarrow$ Decrypt$(secretke{y}_u,publicke{y}_o,capsule,keyfrag,v_{re-enc})$    7:             while $entr{y}_{l_j}<leve{l}_{enc}$ do    8:                   $entr{y}_{l_j}=entr{y}_{l_j}+1$    9: for $l,entry\in entryindex\left\{keywor{d}_{enc}\right\}$ do  10:       if $entry<=leve{l}_{enc}$ then  11:             break  12: set $c=0$  13: while $T_v^c\ne \perp$ do  14:       $T_v^c=g(HAMC(K1,v),c)$  15:       $v_{xor}=(queryindex\left[v_i\right]⨁T_v^c)⨁g(T_v^c,c)$  16:       Parse $v_{xor}$ as $v_{ce}:(u,d)$  17:       if $c>=entry$ then  18:             add $v_{ce}$ to R  19:       $c=c+1$  20: $src=verte{x}_{enc}$  21: for $v_{ce}\in R$ do  22:       $des=v_{ce}$  23:       $distance=$ PLL_search$\left(src,des\right)$  24:       $R\leftarrow v_{ce},distance$  25: $R\leftarrow$$\left(R,distance\right)$ asc  26: for $i<k$ do  27:       $R_{enc}\leftarrow R\left[i\right]$  28: Return $R_{enc}$

For each word ${\mathrm{word}}_i$ in wordindex, the algorithm checks if ${\mathrm{word}}_i$ matches ${\mathrm{keyword}}_{enc}$. If a match is found, for each encrypted value $v_{enc}$ in ${\mathrm{word}}_i$, the algorithm performs the following steps: $v_{re-enc}$ is obtained by applying the ReEncapsulation function to the capsule and key fragment. Then, $v_{\mathrm{ce}}$ is decrypted using the Decrypt function with the user’s secret key ${\sec \mathrm{retkey}}_u$, the owner’s public key ${\mathrm{publickey}}_o$, the capsule, the key fragment and $v_{re-enc}$.

For each entry ${\mathrm{entry}}_{ij}$ in ${\mathrm{word}}_i$, if ${\mathrm{entry}}_{ij}$ is less than ${\mathrm{level}}_{enc}$, it is incremented by 1. The algorithm then iterates over the entries in entryindex associated with ${\mathrm{keyword}}_{enc}$. If an entry is less than or equal to ${\mathrm{level}}_{enc}$, the loop breaks.

A counter c is initialized to 0. While $T_v^c$ is not ⊥, the algorithm computes $T_{v^{\prime }}^c$ as $g\left(\mathrm{HMAC}\right(K1,v),c)$. The value $v_{\mathrm{xor}}$ is calculated as $(\mathrm{queryindex}\left[v_i\right]⨁T_v^c)⨁g(T_v^c,c)$. The algorithm then parses $v_{\mathrm{xor}}$ as $v_{\mathrm{ce}}:(u,d)$. If c is greater than or equal to the current entry, $v_{\mathrm{ce}}$ is added to the result set R. The counter c is incremented by 1.

The source vertex src is set to ${\mathrm{vertex}}_{enc}$. For each $v_{\mathrm{ce}}$ in R, the destination vertex des is set to $v_{\mathrm{ce}}$ and the distance between src and des is computed using the $\mathrm{PLL}\text{\_}\mathrm{search}$ function. The result set R is updated to include $v_{\mathrm{ce}}$ and the computed distance. The results are sorted in ascending order.

Finally, the top k results from R are selected and stored in $R_{enc}$, which is returned as the output of the algorithm.

5.8. Decrypt Algorithm

The user acquires the query result set R returned by the server. After encryption, the vertices within the result set can be locally decrypted. Users have the option to re-encrypt the ciphertext using Capsule and previously authorized kfragments through multiple proxy points. Then, by employing their own private key, the data owner’s public key, the $capsule$ and $kfragment$, they decrypt the re-encrypted ciphertext and obtain the vertex plaintext, which serves as the final query result, thus concluding the query.

The Decrypt algorithm (Algorithm 7) takes as input a user key set $K_U$, the owner’s public key $k_o$ and an encrypted query result $R_{enc}$. It outputs a decrypted set of query results R.

Algorithm 7 Decrypt

Input: A user key set $K_U$, owner’s publickey $k_o$ and query result $R_{enc}$ Output: A decrypted set of query result R   1: Parse $K_U$ as $\left(secretke{y}_u,capsule,keyfrag,K_2\right)$   2: for $v_{re-enc}\in R_{enc}$ do   3:       $v_{se}\leftarrow$ PREdecrypt$\left(secretke{y}_u,k_o,capsule,keyfrag,v_{re-enc}\right)$   4:       $v\leftarrow$ SEDecrypt$\left(K_1,v_{se}\right)$   5:       $dis\leftarrow$ OPE_Dec$\left(distanc{e}_{ope},K_2\right)$   6: Return R

First, the user key set $K_U$ is parsed into four parts: the user’s secret key ${\sec \mathrm{retkey}}_u$, a capsule, a key fragment keyfrag and a key $K_2$.

For each re-encrypted value $v_{re-enc}$ in $R_{enc}$, $v_{\mathrm{se}}$ is obtained by applying the $\mathrm{PRE}\text{\_}\mathrm{decrypt}$ function with the user’s secret key ${\sec \mathrm{retkey}}_u$, the owner’s public key $k_o$, the capsule, the key fragment keyfrag and $v_{re-enc}$. The value v is then decrypted using the SEDecrypt function with the key $K_1$ and the value $v_{se}$. The distance is decrypted using the $\mathrm{OPE}\_\mathrm{Dec}$ function with the key $K_2$ and the encrypted distance $distanc{e}_{ope}$.

The algorithm returns the decrypted set of query results R.

Taking Figure 4 below as an example, the data owner initializes the dictionary of $wordindex$, which contains all keywords $w_1$, $w_2$ as keys. Then, for each keyword $w_i$, a list is created, every element in list represents a vertex in the graph that has keyword $w_i$. The unique value of constant c and $T_v^c$ is used to mark the position of the vertex in the index when encrypting the index. In the second step, in order to improve the query efficiency, the data owner initializes a dictionary called $entryindex$. This index helps to narrow the range of vertices to be searched in $wordindex$. It records the number of vertices that need to be unpacked from $c=0$ in $wordindex$ according to the security level. Similar to $wordindex$, it initializes all keywords in the dictionary as keys. The value of this dictionary consists of a fixed-length list corresponding to the highest permission level. This list contains the entry point for each query level.

Figure 4. An example of query steps.

When a user at security level $l_3$ try to query top-2 vertices containing keyword $w_1$ nearest to $v_3$, the query steps are as following:

• Step 1: User generates a query token T = F($w_1$), SE.Enc$\left(v_3\right),2,$ OPE.Enc$\left(l_3\right)$ and send it to server.
• Step 2: Server uses F$\left(w_1\right)$ as a key to get 4 values OPE.Enc$\left(l_4\right)$, OPE.Enc$\left(l_3\right)$, OPE.Enc$\left(l_2\right)$, OPE.Enc$\left(l_1\right)$ in the $entryindex$. The server uses the user level $l_3$ from the query token to compare with encrypted entries in the entry index. Leveraging the order-preserving encryption (OPE) property, it identifies the position where the previous entry is greater and the next entry is smaller than $l_3$. It retrieves the tuple $(\mathrm{OPE}.\mathrm{Enc}\left(L_3\right),1)$ and extracts the value 1 to access the corresponding entry in the word index $F\left(w_1\right)$. It means server need to skip the first vertex $v_1$ has level $l_4$ higher than user level $l_3$ and get values from index 1 to the end of the list are then retrieved. Here includes the tuple $(\mathrm{SE}.\mathrm{Enc}\left(v_2\right),\mathrm{OPE}.\mathrm{Enc}\left(l_2\right))$.
• Step 3: Finally, $\mathrm{SE}.\mathrm{Enc}\left(v_2\right)$ is combined with $\mathrm{SE}.\mathrm{Enc}\left(v_3\right)$ from the query token and the query index as inputs to the $\mathrm{PLL}\text{\_}\mathrm{search}$ function for further query processing. Server get the distance between $v_2$ and $v_3$ from query index. The queryindex shows that the distance of $v_1$ to $v_3$ is 1 and it can be known that the distance of $v_1$ to $v_3$ and $v_2$ is also 1. Therefore, distance between $v_3$ and $v_2$ is $dis(v_3,v_2)=dis(v_3,v_1)+dis(v_1,v_2)$ = 2 and the final query result of nearest top-2 is $(SE.Enc\left(v_2\right))$. Then user decrypt the result and finally get $v_2$.

6. Analysis and Experiment

6.1. Security Analysis

We first describle two leakage functions in Section 4.3, $L_1$ and $L_2$, which represent the information that an adversary can learn from the encrypted search indices set $I_{enc}=(wordinede{x}_{enc},entryinde{x}_{enc},queryinde{x}_{enc})$ in setup process and query tokens T in query process respectively.

The fuction ${\mathcal{L}}_1$ leaks graph structure, keyword and hierarchy metadata as following: The adversary $\mathcal{A}$ learns $\left|V\right|$ by analyzing the encrypted query index. $\mathcal{A}$ infers number of keywords $\left|W\right|$ and number of vertices containing keyword $v\left(w\right)$ from the encrypted $wordinde{x}_{enc}$. The number of security levels $\left|L\right|$ is revealed via the $entryinde{x}_{enc}$.

The function ${\mathcal{L}}_2$ leaks search pattern, access Pattern, result cardinality as following: $\mathcal{A}$ detects repeated queries via identical tokens of keyword or vertex. The same vertices in two query results can be learned by $\mathcal{A}$. The size of top k results is leaked.

Theorem 1.

Assuming the HAMC, SE, OPE, PRE are secure, the PH-kNK is $({\mathcal{L}}_1,{\mathcal{L}}_2)$-secure against adaptive chosen-query attacks (CQA2) under the semi-honest adversarial model.

Proof. 

To prove Theorem 1, we construct two experiments ${\mathrm{Real}}_{\mathcal{A}}\left(\lambda \right)$ and ${\mathrm{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$ introduced in Section 4.3.

${\mathrm{Real}}_{\mathcal{A}}\left(\lambda \right)$ Experiment:

• $\mathcal{A}$ selects graphs $G_0$ and $G_1$ with identical condition: (1) same number of vertices $\left|V\right|$; (2) same number of edges $\left|E\right|$; (3) same number of keyword $\left|W\right|$ and number of vertices containing same keyword $v\left(m\right)$; (4) same number of security level $\left|L\right|$ and number of vertices containing same level $v\left(l\right)$.
• The challenger $\mathcal{C}$ encrypts $G_b$ ($b\in \{0,1\}$) and sends $I_{enc}$ to $\mathcal{A}$.
• $\mathcal{A}$ adaptively queries and receives tokens/results.
• $\mathcal{A}$ outputs guess $b^{\prime }$. The experiment succeeds if $b^{\prime }=b$.

In setup process, $\mathcal{A}$ can get nothing but leakages information from ${\mathcal{L}}_1$, so $\mathcal{A}$ can not distinguish $G_0$ and $G_1$. In query process, ${\mathcal{L}}_2$ leaks only search or access patterns and result sizes, equal for $G_0$ and $G_1$. If SE, HAMC, OPE, and PRE are secure, $\mathcal{A}$’s advantage is negligible:

$${\mathrm{Adv}}_{\mathcal{A}}=\left|Pr[{\mathrm{Real}}_{\mathcal{A}}\left(\lambda \right)=1]-{\displaystyle \frac{1}{2}}\right|=\mathrm{negl}\left(\lambda \right).$$

${\mathrm{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$ Experiment:

• Simulator $\mathcal{S}$ uses ${\mathcal{L}}_1$ and ${\mathcal{L}}_2$ to generate simulated index $I_{enc}^{\ast }$ and tokens $T^{\ast }$.
• $\mathcal{S}$ replaces cryptographic primitives with random sampling.

Simulated tokens and indexes are indistinguishable due to the security of SE, HAMC, OPE and PRE. $\mathcal{A}$ cannot distinguish $I_{enc}^{\ast }$ and $T^{\ast }$ from real counterparts. Hence, ${\mathrm{Adv}}_{\mathcal{A}}$ in the ideal experiment is also negligible:

$${\mathrm{Adv}}_{\mathcal{A}}=\left|Pr[{\mathrm{Ideal}}_{\mathcal{A}}\left(\lambda \right)=1]-{\displaystyle \frac{1}{2}}\right|=\mathrm{negl}\left(\lambda \right).$$

Conclusion. Since $\mathcal{A}$’s advantages in both experiments are negligible, PH-kNK satisfies $({\mathcal{L}}_1,{\mathcal{L}}_2)$-secure against adaptive chosen-query attacks (CQA2) under the semi-honest adversarial model. □

6.2. Theoretical Analysis

In this section, we analyze the theoretical and practical aspects of the algorithm and provide an analysis of its complexity. The findings are presented in Table 3. In the KeyGen phase, the data owner generates a set of public and private keys, including the HAMC and symmetric encryption key, the order-preserving encryption (OPE) key and the re-encryption key used by the owner to encrypt the vertices. The process is performed by the owner, involving computation and storage. So both the storage and computational complexities are constant.

Table 3. The time and space complexities of algorithms.

	${\mathit{Stor}}_{\mathcal{O}}$	${\mathit{Stor}}_{\mathcal{U}}$	${\mathit{Stor}}_{\mathcal{S}}$	${\mathit{Comp}}_{\mathcal{O}}$	${\mathit{Comp}}_{\mathcal{U}}$	${\mathit{Comp}}_{\mathcal{S}}$
KeyGen	$O\left(\lambda \right)$	-	-	$O\left(\lambda \right)$	-	-
KeyAssign	$O\left(\lambda \right)$	O(1)	$O\left(1\right)$	$O\left(\lambda \right)$	-	-
BuildIndex	$O\left(\right(\left|L\right|+\left|V\right|\left)\right|W|+{\left|V\right|}^2)$	-	-	$O\left(\right(\left|L\right|+\left|V\right|\left)\right|W|+|V\left|m\right)$	-	-
EncryptIndex	-	-	$O\left(\right(\left|L\right|+\left|V\right|\left)\right|W\left|\right)$	$O\left(\right|V\left|\right|W\left|\right)$	-	-
QueryToken	-	$O\left(1\right)$	$O\left(1\right)$	-	$O\left(1\right)$	-
KnkSearch	-	-	$O\left(1\right)$	-	-	$O\left(v\right(w\left)\right)$
Decrypt	-	$O\left(1\right)$	-	-	$O\left(1\right)$	-

$\lambda$: security parameter; $\left|L\right|$: number of hierarchies; $\left|W\right|$: number of keywords; $\left|V\right|$: number of vertices; $v\left(w\right)$: number of vertices containing keyword w; m: number of edges.

In the KeyAssign algorithm phase, the server S locally generates its own set of keys and sends the public key to the owner for assignment. The assigned key fragments are stored by the server. Both of these steps are algorithms with a computational complexity of O(1).

In the BuildIndex phase, the owner constructs the index, which involves: (1) building $wordindex$ where keywords serve as identifiers, having store and computational complexity of O($\left|V\right|$$\left|W\right|$); (2) building $entryindex$ for query at different levels L having store and computational complexity of O($\left|L\right|\left|W\right|$) and (3) building a $queryindex$ having computational complexity of O($\left|V\right|m$) and store complexity of O(${\left|V\right|}^2$). So the final store complexity of BuildIndex is O($\left(\right|L|+\left|V\right|\left)\right|W|+{\left|V\right|}^2$) and computational complexity is O($\left(\right|L|+|V\left|\right)\left|W\right|+\left|V\right|m$). Each step involves the participation of corresponding sets of vertices, so the algorithm’s complexity is determined by the parameters $\left|L\right|$, $\left|V\right|$ and $\left|W\right|$. Here $\left|L\right|$ means number of hierarchies in our experiment, $\left|V\right|$ means number of vertices in used graph and $\left|W\right|$ means how much keywords in keyword list.

In the EncryptIndex algorithm, the owner encrypts the indies and send them to server. This includes encrypting the keywords in the keyword index using HAMC and SE, encrypting the levels using OPE, encrypted $wordindex$ having store and computational complexity of O($\left|V\right|$$\left|W\right|$). For entry index which needs to encrypt the vertices using both OPE and re-encryption having store and computational complexity of O($\left|L\right|\left|W\right|$). The $queryindex$ The encryption operations are performed by the owner, who sends the encrypted index to the server for storage. In the QueryToken algorithm phase, the user generates a query token. The user requests key allocation and generates the token based on the desired vertex, keyword, level and other information. The complexity of this algorithm is O(1).

In the kNKSearch phase, the server performs queries based on the tokens received from the user. The complexity of the query process for different keywords depends on the number of vertices containing the respective keyword $v\left(m\right)$. In the DECRYPT phase, the user receives the encrypted query results from the server and decrypts the encrypted vertices within it.

6.3. Experimental Evaluation

The experiment is conducted under the following environment.

• RAM: 16 G
• operating system: Windows 11
• CPU: 11th Gen Intel(R)Core(TM) i5-11400H @2.70 GHZ
• language: python
• library: 1. The hashlib library to construct a pseudorandom function. 2. The pyope library was employed for order-preserving encryption (OPE). 3. umbral library based on OpenSSL was used for proxy re-encryption. 4. The PrunedLandmarkLabeling(PLL) algorithm was employed to obtain the shortest distances in the graph.
• experiment parameter: 1. we used a 128-bit security parameter. 2. we set 1 to 10 security levels. 3. we set 10 to 10,000 keyword frequency.

We implemented the PH-kNK scheme in Python. To further substantiate our findings, we conducted scalability tests on large datasets to assess the real-world applicability of our scheme: ego-Facebook and Facebook LPPN from the Stanford Large Network Dataset Collection website [31]. As shown in Table 4, these datasets vary in size and complexity, providing a comprehensive testbed for evaluating the robustness of our scheme. The ego-Facebook consists of ’friends lists’ from Facebook. It has 4039 vertices and 88,234 edges. The Facebook LPPN has 22,470 vertices and 171,002 edges. These datasets were chosen for their varying sizes and complexities, providing a robust testbed for assessing the scheme’s efficiency and scalability.

Table 4. Dataset Information.

Dataset	|V|	|E|	|W|
ego-Facebook	4039	88,234	1311
Facebook LPPN	22,470	171,002	4714

A comparative analysis of the our scheme and Aton [21], a state-of-the-art solution for privacy-preserving top-k keyword searches was performed in the experiment. Figure 5a,b illustrate the query time performance of both schemes on the ego-Facebook and Facebook LPPN datasets respectively. The x-axis represents the keyword frequency, defined as the number of vertices containing the specified keyword, ranging from 1 to ${10}^4$. For each keyword frequency, the query vertex v is randomly selected and 100 queries of the same security level are performed, with the average results being recorded. As shown in Figure 5a,b, the PH-kNK scheme generally has greater performance at keyword frequencies of ${10}^3$ and below. However, at a keyword frequency of ${10}^4$ and above, the Aton scheme demonstrates superior query efficiency. “Extreme keyword frequency” refers to a scenario in which a 22,470 vertices graph has only 10 keywords. It means that our solution has more advantages within the range of non-extreme keyword frequencies. Nevertheless, our scheme remains highly competitive in most practical scenarios, where extreme keyword frequencies are less common.

Figure 5. (a) The Relationship of keyword frequency and query time in dataset ego-Facebook. (b) The Relationship of keyword frequency and query time in dataset Facebook LPPN. (c) The Relationship of keyword frequency and query time in dataset ego-Facebook and Facebook LPPN for PH-knk. (d) The Relationship of keyword frequency and query time in dataset ego-Facebook and Facebook LPPN for Aton.

The results demonstrate that the PH-kNK scheme outperforms Aton in scenarios with moderate keyword frequencies (up to ${10}^3$). For instance, on the ego-Facebook dataset, the PH-kNK scheme achieved an average query time of 198 ms for a keyword frequency of 10, compared to 243 ms for Aton. Similarly, on the Facebook LPPN dataset, the PH-kNK scheme recorded an average query time of 277 ms for a keyword frequency of 10, while Aton required 303 ms. The average query efficiency increased by 14.35% in ego-Facebook, 12.86% in Facebook LPPN.

Moreover, we incorporated memory usage and time cost to provide a more comprehensive analysis of efficiency and scalability. As shown in Table 5, We measured memory consumption during critical phases of our scheme on ego-Facebook and Facebook LPPN data set. It can be inferred that the algorithm’s memory overhead is primarily concentrated in the BuildIndex and EncryptIndex stages, while the memory usage for KeyGen and KeyAssign is relatively low. On the other hand, kNKSearch requires loading the search indexes, resulting in a high memory overhead.

Table 5. Memory Usage Analysis.

Process	Dataset	KeyGen	KeyAssign	Build Index	Encrypt Index	kNKSearch
memory peak (kb)	ego-facebook	7.47	92.78	11,652.75	16,697.89	16,868.49
	Facebook LPPN	7.52	93.21	115,566.41	161,575.56	166,739.00
time cost (ms)	ego-facebook	0.09	50.91	1899.33	18,176.5	198.55
	Facebook LPPN	0.09	51.24	61,031.88	1,477,650.34	277.83

As illustrated in Figure 5c,d, the relationship between query time and the number of graph vertices can be summarized as follows: as the number of vertices and edges increases, the query speed descends; conversely, fewer vertices and edges result in faster query performance. This trend is also observed in the Aton scheme.

Furthermore, the search results at various levels are presented in Figure 6. The Aton scheme does not incorporate constraints for security levels concerning keywords and vertices, making it incomparable to our proposed scheme in the context of hierarchical searchable encryption. Regarding hierarchical relationships, our scheme was evaluated by generating 100 random queries for each security level from 1 to 10, with keyword frequencies ranging from 1000 to 3000. The results, as illustrated in Figure 6, demonstrate that higher query levels result in slower performance for higher query levels contain more search results than lower levels.

Figure 6. The Relationship of Search Times and Hierarchies.

Table 6 presents the query time performance of the two schemes under the same dataset and keyword frequency, with the top k values ranging from 10 to 50. As shown, the query time increases as k increases.

Table 6. Top-k query time results.

Scheme	Dataset	k
		10	20	30	40	50
PH-kNK	ego-Facebook	198	217	232	240	262
	Facebook LPPN	277	286	305	316	338
Aton	ego-Facebook	243	259	270	285	302
	Facebook LPPN	303	326	340	361	373

7. Conclusions

Overall, our contributions include the introduction of a novel scheme for kNK graph search, the implementation of fine-grained access control and the utilization of secure encryption techniques. We present the architecture of the proposed scheme, provide a detailed description of the algorithm and conduct simulation experiments to validate its performance. Notably, our scheme incorporates hierarchical search functionality that is currently absent in existing solutions. Experimental results on real-world datasets, such as ego-Facebook and Facebook LPPN, demonstrate that the PH-kNK scheme achieves significant improvements in query efficiency, particularly for moderate keyword frequencies (up to ${10}^3$). Compared to existing solutions like Aton, our scheme outperforms in scenarios with non-extreme keyword frequencies, offering faster query times and better scalability.

Our scheme is applicable to a diverse range of real-world application scenarios such as healthcare, finance and social networks where data privacy is paramount. The ability to perform privacy-preserving searches with fine-grained access control ensures compliance with ethical standards and data protection regulations. These applications highlight the practical relevance of our work.

Future work will focus on addressing scalability challenges across large graph sizes and heterogeneous data types, integrating the scheme with existing infrastructures such as Neo4j and Amazon Neptune. The other possible research could be accomplish dynamic updating of graph structure. Additionally, we plan to explore enhancing the scheme to resist more advanced adversarial models and to incorporate post-quantum cryptographic techniques for long-term security.