EFKG: An Efficient and Fine-Grained Access Control Encrypted Knowledge Graph

Abstract

As knowledge graphs are increasingly applied in sensitive domains such as healthcare, ensuring data confidentiality and fine-grained access control over outsourced graph data has become critical. In this paper, we propose EFKG, an Efficient and Fine-grained Access Control Encrypted Knowledge Graph construction scheme that simultaneously achieves data confidentiality, fine-grained access control, and high-performance multi-hop search over encrypted knowledge graphs. Compared with existing approaches, EFKG not only supports efficient single-hop and multi-hop retrieval with $O\left(1\right)$ complexity per hop, but also satisfies fine-grained access control requirements in multi-user settings. Regarding security, we rigorously prove that EFKG achieves $\mathcal{L}$-adaptive security under the standard leakage function paradigm. Extensive experiments on real-world datasets confirm that EFKG achieves microsecond-level single-hop search and scalable multi-hop traversal, offering a superior trade-off between efficiency, security, and functionality.

1. Introduction

Knowledge graphs [1], as a predominant paradigm for representing and organizing structured knowledge, model complex relationships among entities in the form of triples $(s,p,o)$ and have been widely deployed in core AI areas such as semantic search and recommendation systems. With the proliferation of cloud computing, outsourcing knowledge graphs to cloud servers to reduce local costs and enable data collaboration has become a mainstream trend. However, cloud servers are typically abstracted as “honest-but-curious” semi-trusted entities that may infer sensitive information from stored ciphertexts and query interaction patterns, posing severe threats to data confidentiality.

Secure outsourced knowledge graphs face two critical demands. The first is data and structural confidentiality—preventing the server from inferring sensitive insights such as entity associations from ciphertexts and access patterns. The second is fine-grained access control, which enables data owners to define differentiated policies based on user attributes and restrict access to specific sub-structures of the graph. Attribute-based encryption (ABE) is a desirable cryptographic primitive for achieving fine-grained control [2]. However, deeply integrating ABE with efficient searchable encryption (SE) without significantly sacrificing retrieval performance, while achieving both confidentiality and fine-grained control, remains a challenging technical problem.

Existing works still exhibit significant limitations in addressing the above challenges. First, traditional searchable encryption is mainly designed for flat document collections [3] and cannot natively support structured relational queries and multi-hop traversals over knowledge graphs. Second, for efficiency, most existing encrypted knowledge graph schemes adopt a single symmetric key [4,5,6], such that any authorized user can access the entire graph, entirely sacrificing fine-grained access control. Third, although some attribute-based searchable encryption schemes attempt to introduce fine-grained control [7], applying ABE to each individual triple independently leads to prohibitive ciphertext expansion and decryption overhead, rendering them impractical for large-scale graph data.

To overcome these limitations, this paper proposes EFKG, an Efficient and Fine-grained Access Control Encrypted Knowledge Graph construction scheme. The main contributions are as follows:

• Efficient multi-hop search with fine-grained access control: We propose EFKG, an encrypted knowledge graph scheme that integrates fine-grained access control with efficient multi-hop search. By organizing the graph into subject-based linked lists and enforcing subject-level access policies via ABE, we construct secure indexes that underpin highly efficient retrieval.
• Formal security model and rigorous proof: Based on standard cryptographic assumptions and the leakage function paradigm in searchable encryption, we rigorously prove that EFKG achieves $\mathcal{L}$-adaptive security and provide a proof of correctness.
• Extensive experimental validation: Experiments on real-world graph datasets show that EFKG achieves an excellent trade-off between query efficiency and storage overhead. Both index look-up and cross-subject jumps achieve constant time complexity, and the overall retrieval overhead is proportional to the size of the returned results, meeting practical deployment requirements.

The remainder of this paper is organized as follows: Section 2 reviews related work; Section 3 presents the system model and definitions; Section 4 details the construction of EFKG; Section 5 provides the security analysis; Section 6 evaluates the performance; finally, Section 7 concludes the paper and discusses future research directions.

2. Related Work

This section reviews three research directions most relevant to our work: searchable encryption, attribute-based encryption, and encrypted knowledge graphs.

2.1. Searchable Encryption

Searchable Symmetric Encryption (SSE) enables keyword search over encrypted data with high computational efficiency and has been extensively studied [8,9]. However, traditional SSE is designed for flat document collections and cannot natively support structured relational queries or multi-hop traversals over knowledge graphs. Chase and Kamara [10] pioneered structured encryption for complex data structures, and subsequent graph encryption schemes [11,12] have extended this direction, though accommodating complex graph topologies remains challenging. Dynamic SSE schemes with forward and backward privacy have also been proposed [9,13], but applying them to structural graph updates is non-trivial.

2.2. Attribute-Based Encryption

Attribute-based encryption (ABE), particularly Ciphertext-Policy ABE (CP-ABE) [2], enables fine-grained access control by embedding access policies into ciphertexts. Its applications in resource-constrained IoT environments and multi-authority cloud scenarios have been widely surveyed [14,15,16]. However, directly applying ABE to large-scale knowledge graphs faces severe efficiency bottlenecks due to ciphertext expansion and expensive bilinear pairing operations during decryption. Attribute-based searchable encryption (ABSE) schemes [7,16,17,18] attempt to combine the advantages of ABE and SSE, but remain oriented towards document-level keyword search and do not effectively decouple data retrieval from authorization verification for graph-structured data.

2.3. Encrypted Knowledge Graphs

Encrypted retrieval over knowledge graphs is an emerging interdisciplinary field. Early work by Cao et al. [19] studied privacy-preserving queries on encrypted graphs but relied on a single symmetric key without differentiated access control.

Subsequent research on encrypted graph queries has advanced in several directions: oblivious subgraph matching [11], shortest-distance and reachability queries [12,20,21,22], and privacy-preserving social-graph search [23,24]. Du et al. [25] further studied dynamic graph encryption with forward privacy. These schemes support rich query semantics but share a common limitation—any user with a valid trapdoor can access the entire retrieved subgraph, precluding fine-grained, subject-level access differentiation. Research on encrypted relational databases, exemplified by CryptDB [26], faces similar structural challenges without native graph-topology support.

In parallel, encrypted knowledge graph schemes specifically targeting triple-based graph structures have been developed. Xue et al. [4], Lin et al. [5], and Chen et al. [6] proposed structured encryption supporting multi-hop queries and, in the case of DSSE-KG, dynamic updates. However, all these schemes operate under a single symmetric key, granting any authorized user access to the entire graph and entirely forgoing attribute-level authorization. On the access control side, ABSE schemes [7,16] have introduced attribute-based encryption into searchable encryption for IoT and healthcare data sharing, but remain confined to document-level keyword search without extension to graph-structured data.

To provide a systematic overview of the landscape,

Table 1. Comparison of representative encrypted graph schemes.

Scheme	Multi-Hop	Fine-Grained AC	KG-Native
Xue et al. [4]	✓	×	✓
Hu et al. [20]	✓	×	×
Du et al. [25]	✓	×	×
Wang et al. [23]	✓	×	×
Song et al. [24]	✓	×	×
Yin et al. [7]	×	✓	×
Lin et al. [5]	✓	×	✓
Chen et al. [6]	✓	×	✓
EFKG (this work)	✓	✓	✓

summarizes representative encrypted graph and knowledge graph schemes along three dimensions: multi-hop query support, fine-grained access control, and native knowledge graph capability.

As shown in Table 1, existing schemes either achieve multi-hop traversal under a single symmetric key without attribute-level authorization (e.g., Xue et al., Lin et al., Chen et al.), or introduce ABE for fine-grained access control but remain confined to document-level keyword search (Yin et al.). EFKG is the first scheme to simultaneously support efficient multi-hop traversal on knowledge graphs with fine-grained, subject-level access control.

3. Model and Definitions

To ensure rigor and consistency throughout the paper, this section provides unified definitions for the core symbols used throughout the scheme. Auxiliary symbols specific to the underlying linked-list construction will be defined as needed in Section 4. The global core symbols and their meanings are shown in

Table 2. Notation.

Symbol	Meaning
$\mathcal{G}$	Knowledge graph
${\mathcal{T}}_s$	Set of all triples with subject s
$\lambda$	System security parameter
$PRF$	Pseudorandom function
H	Cryptographic hash function
$Sym$	Symmetric encryption scheme
$ABE$	Attribute-based encryption scheme
$P{P}_{ABE}$	Public parameters of the ABE scheme
$MS{K}_{ABE}$	Master secret key of the ABE scheme
$S{K}_{ABE}$	ABE private key of an authorized user
$K_1,K_2$	Searchable encryption keys
${\mathbb{A}}_s$	Access policy associated with subject s
$k_s$	Symmetric key associated with subject s
$C_s$	ABE ciphertext of content key $k_s$
$t{d}_s$	Search trapdoor for querying subject s
$CT$	Ciphertext table
$ET$	ABE ciphertext table
$IT$	Index table

.

3.1. System Model

The scheme involves four types of entities: a Trusted Authority, a Data Owner, a Cloud Server, and Authorized Users. The responsibilities and interactions of these entities are illustrated in Figure 1 and described as follows:

• Trusted Authority (TA): Responsible for global system initialization, generating the ABE public parameters $P{P}_{ABE}$, master secret key $MS{K}_{ABE}$, and searchable encryption master keys $K_1,K_2$. TA issues ABE private keys $S{K}_{ABE}$ to users according to their attribute sets, and generates query trapdoors $t{d}_s$ on behalf of users. TA is assumed to be fully trusted.
• Data Owner (DO): Possesses the original knowledge graph $\mathcal{G}$. DO defines the access policy ${\mathbb{A}}_s$ for each subject s, obtains encryption parameters from TA, performs encryption and index building locally, and outsources the resulting ciphertext structures and index to the cloud server.
• Cloud Server (CS): Provides ciphertext storage and retrieval services. CS receives the ciphertexts uploaded by DO, responds to trapdoor queries from authorized users, executes the search protocol, and returns matching ciphertext results. CS follows the “honest-but-curious” semi-trusted assumption.
• Authorized Users: Obtain ABE private keys $S{K}_{ABE}$ from TA. To query a subject, a user requests a trapdoor from TA, submits it to CS, and decrypts the returned results using their ABE private key to recover the plaintext triples.

Figure 1. EFKG system model.

Figure 1. EFKG system model.

3.2. Threat Model

This paper adopts the standard “honest-but-curious” threat model in the searchable encryption domain. Under this model, the cloud server CS faithfully follows the protocol to perform storage and query operations, but may attempt to infer additional sensitive information from the ciphertext data, query trapdoors, and response results it observes. Specific threat assumptions are as follows:

• TA and DO are assumed to be fully trusted and will not leak any system master keys or plaintext data;
• CS is a semi-trusted entity that honestly executes the protocol but attempts to analyze data and acquire extra knowledge.

3.3. Security Definition

The security of this scheme is formally defined based on the standard leakage function paradigm. Let $\mathcal{G}$ denote the knowledge graph and $Q=(q_1,q_2,\dots ,q_t)$ denote the query sequence. The leakage function $\mathcal{L}=({\mathcal{L}}_{Setup},{\mathcal{L}}_{Query})$ is defined as follows:

Definition 1 (Leakage Function).

The leakage function consists of the following two components:

• ${\mathcal{L}}_{Setup}\left(\mathcal{G}\right)=\left\{\right|{\mathcal{T}}_s{\left|\right\}}_{s\in S}$: the initialization phase only leaks the number of triples per subject, reflecting the macro-scale of the graph without revealing specific topological connections.
• ${\mathcal{L}}_{Query}(\mathcal{G},Q)=(SP,AP)$: the query phase leaks the search pattern $SP$ (revealing whether two queries target the same subject) and the access pattern $AP$ (revealing the set of ciphertext identifiers returned by a query and the traversal path).

Beyond the explicitly defined leakage above, the scheme strictly protects the confidentiality of triple contents, the details of access policies, and the graph-structured information of non-queried subjects. Based on this, security is characterized by the indistinguishability between the real experiment and the ideal experiment:

• Real Experiment ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$: The challenger runs $Setup$ to generate parameters and sends them to the adversary $\mathcal{A}$. $\mathcal{A}$ submits a challenge graph ${\mathcal{G}}^{*}$, the challenger runs $BuildIndex$ to generate the real ciphertexts and returns them. Subsequently, the adversary adaptively issues trapdoor queries, and the challenger computes the real trapdoor responses. Finally, the adversary outputs a guess bit b.
• Ideal Experiment ${\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$: The simulator $\mathcal{S}$ generates simulated ciphertexts only using the leakage information ${\mathcal{L}}_{Setup}\left({\mathcal{G}}^{*}\right)$. During the query phase, $\mathcal{S}$ returns simulated trapdoors based solely on ${\mathcal{L}}_{Query}$. Finally, the adversary outputs a guess bit b.

Definition 2 ($\mathcal{L}$-Adaptive Security).

A searchable encrypted knowledge graph scheme is $\mathcal{L}$-adaptively secure if for any probabilistic polynomial-time adversary $\mathcal{A}$, there exists a polynomial-time simulator $\mathcal{S}$ such that the advantage of the adversary in distinguishing the real experiment from the ideal experiment is negligible:

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

(1)

3.4. Algorithm Definition

The EFKG scheme consists of the following six polynomial-time algorithms, defining the complete functional interface of the system:

• $Setup\left(1^{\lambda }\right)\to (P{P}_{ABE},MS{K}_{ABE},K_1,K_2)$: Executed by TA. Takes the security parameter as input and outputs ABE public parameters, master secret key, and two master keys.
• $KeyGen(MS{K}_{ABE},\mathbb{A})\to S{K}_{ABE}$: Executed by TA. Takes the master secret key and a user’s attribute set $\mathbb{A}$ as input and outputs the user’s ABE private key.
• $BuildIndex(\mathcal{G},P{P}_{ABE},K_1,K_2)\to (CT,ET,IT)$: Executed by DO. Takes the knowledge graph and encryption parameters as input and outputs the ciphertext table $CT$, ABE ciphertext table $ET$, and index table $IT$.
• $Trapdoor(K_1,K_2,s)\to t{d}_s$: Executed by TA. Takes the two master keys and a query subject s as input and outputs the search trapdoor $t{d}_s$.
• $Search(t{d}_s,CT,ET,IT)\to (\mathcal{R},\mathcal{C})$: Executed by CS. Takes a trapdoor and the ciphertext tables as input and outputs the list of encrypted triples $\mathcal{R}$ and the corresponding set of ABE ciphertexts $\mathcal{C}$.
• $Decrypt(\mathcal{R},\mathcal{C},S{K}_{ABE})\to {\mathcal{T}}^{\prime }$: Executed by the user. Takes ciphertext results, ABE ciphertexts, and the private key as input and outputs a set of plaintext triples ${\mathcal{T}}^{\prime }$, or ⊥ (when permissions are insufficient).

4. Scheme Construction

This section elaborates on the construction details of the EFKG scheme. The core design philosophy is to achieve deep decoupling of retrieval and authorization as well as efficient graph traversal over ciphertexts. Specifically, we adopt the following key mechanisms:

• Subject-based chain structure and hash binding: Triples with the same subject are organized into a linked list. Node pointers are encrypted via XOR with a hash derived from the current ciphertext and a random number, breaking the correlation between ciphertexts and achieving unlinkability.
• Self-contained ciphertext multi-hop navigation: An encrypted multi-hop component is embedded in each linked-list node, encapsulating the complete trapdoor of the next-hop subject. This enables the server to perform constant-time cross-index jumps in the ciphertext space without user involvement.
• Two-layer encryption architecture: Symmetric keys encrypt triple contents, and the symmetric keys are in turn encrypted by ABE. The server only performs lightweight retrieval and synchronously returns ABE ciphertexts, confining the expensive pairing operations to the user side.

4.1. Initialization and Key Generation

4.1.1. System Initialization

This algorithm is executed by TA. It takes the security parameter $1^{\lambda }$ as input and outputs the system public parameters and master keys. The specific steps are:

• Run the ABE initialization algorithm to generate ABE public parameters $P{P}_{ABE}$ and master secret key $MS{K}_{ABE}$;
• Randomly select two symmetric master keys $K_1,K_2\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$;
• Output system parameters $(P{P}_{ABE},MS{K}_{ABE},K_1,K_2)$. Here, $P{P}_{ABE}$ is public to all entities, $MS{K}_{ABE}$ is kept secret by TA, and $K_1,K_2$ are distributed to the DO via secure channels.

4.1.2. User Key Generation

When a new user joins the system, TA verifies the user’s attribute set $\mathbb{A}$, runs $ABE.KeyGen(MS{K}_{ABE},\mathbb{A})$ to generate the corresponding ABE private key $S{K}_{ABE}$, and distributes it via a secure channel.

4.2. Knowledge Graph Encryption

This algorithm is executed by the DO. It takes the knowledge graph $\mathcal{G}$, ABE public parameters $P{P}_{ABE}$, and master keys $(K_1,K_2)$ as input, and outputs three ciphertext tables: the triple ciphertext table $CT$, the ABE ciphertext table $ET$, and the index table $IT$. The detailed construction is shown in Algorithm 1.

Algorithm 1  $BuildIndex(\mathcal{G},P{P}_{ABE},K_1,K_2)$

1: Initialize empty tables $CT,ET,IT$

2: for each distinct subject $s\in \mathcal{G}$  do

3:    Randomly generate content key $k_s\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

4:    Determine access policy ${\mathbb{A}}_s$ for subject s, compute ABE ciphertext $C_s=ABE.Enc(P{P}_{ABE},{\mathbb{A}}_s,k_s)$

5:    Store $C_s$ in $ET$, record its physical address $add{r}_s^{ABE}$

6:    Retrieve the set of triples with subject s: ${\mathcal{T}}_s={\left\{{(s,p,o)}_i\right\}}_{i=1}^n$, where $n=|{\mathcal{T}}_s|$

7:     for $i=1$ to n  do

8:      Encrypt triple: $c{t}_i=Sym.En{c}_{k_s}\left({(s,p,o)}_i\right)$

9:      Randomly generate mask seed: $r_i\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$

10:    Compute local hash key: $K_i=H(c{t}_i\parallel PRF(K_1,s)\parallel r_i)$

11:    if $i=n$  then

12:        Compute next node address ciphertext: $n{c}_i=0^{\lambda }\oplus K_i$

13:     else

14:        Compute next node address ciphertext: $n{c}_i=add{r}_{i+1}\oplus K_i$

15:     end if

16:     if object o is a subject in $\mathcal{G}$  then

17:        Compute next-hop trapdoor: $T_o=(PRF(K_1,o),PRF(K_2,o))$

18:        Compute multi-hop ciphertext: $h{c}_i=T_o\oplus K_i$

19:     else

20:        Pad with random string: $h{c}_i\stackrel{\$}{\leftarrow }{\{0,1\}}^{|T_o|}$

21:     end if

22:     Create linked-list node $N_i=(c{t}_i,r_i,n{c}_i,h{c}_i)$, store it at address $add{r}_i$ in $CT$

23:    end for

24:    Set linked-list head address: $hea{d}_s=add{r}_1$

25:    Compute index value: $I_s=(hea{d}_s\parallel add{r}_s^{ABE})\oplus PRF(K_2,s)$

26:    Insert key-value pair $(PRF(K_1,s),I_s)$ into index table $IT$

27: end for

28: return$(CT,ET,IT)$

The structures and security properties of the three generated ciphertext tables, as illustrated in Figure 2, are analyzed below:

• Triple ciphertext table $CT$: Stores all encrypted linked-list nodes. Each node $N_i$ contains four fields: ciphertext $c{t}_i$, plaintext random number $r_i$, encrypted pointer $n{c}_i$, and multi-hop component $h{c}_i$. Since the pointer mask $K_i$ is generated by hashing the ciphertext itself together with a random number, masks of different nodes are mutually independent. The server cannot establish cross-node correlations, ensuring ciphertext unlinkability.
• ABE ciphertext table $ET$: Uses physical address $add{r}_s^{ABE}$ as the key to store the ABE ciphertext $C_s$ corresponding to subject s. This table is physically separated from $CT$, which is key to decoupling retrieval from authorization.
• Index table $IT$: The key is $PRF(K_1,s)$ and the value is the pair $(hea{d}_s\parallel add{r}_s^{ABE})$ encrypted via XOR with $PRF(K_2,s)$. The server must possess both components of the trapdoor to locate and decrypt the index entry.

Figure 2. Schematic diagram of the EFKG ciphertext structure.

Figure 2. Schematic diagram of the EFKG ciphertext structure.

4.3. Trapdoor Generation

When an authorized user needs to query subject s, the user submits a request to the TA. The TA computes the dual-key trapdoor for subject s:

$$t{d}_s=\left(PRF(K_1,s),PRF(K_2,s)\right)$$

(2)

and sends $t{d}_s$ to the CS via a secure channel. The two parts of the trapdoor respectively correspond to the query key for the index table and the decryption mask for the index value.

A natural concern is that routing every query through the TA creates a single-point bottleneck. We argue that this design is both necessary and justifiable: trapdoor generation requires the master keys $K_1,K_2$, and delegating them to the DO or individual users would create additional compromise points. Meanwhile, the per-trapdoor cost is only two PRF evaluations (sub-microsecond), so the practical bottleneck is the secure channel, not computation. This overhead can be mitigated by offline batch pre-generation for frequently queried subjects, or by caching trapdoors at the cloud server in accordance with the search pattern leakage already admitted in ${\mathcal{L}}_{Query}$.

4.4. Search

Upon receiving the trapdoor $t{d}_s$, the CS executes the ciphertext retrieval protocol. This protocol consists of two sub-processes: single-hop retrieval and multi-hop traversal.

4.4.1. Single-Hop Retrieval

Single-hop retrieval locates the linked list of the target subject and extracts all ciphertexts, as shown in Algorithm 2.

Algorithm 2 $Search(t{d}_s,IT,CT,ET)$

1: Parse trapdoor $t{d}_s=(t_1,t_2)$, where $t_1=PRF(K_1,s)$, $t_2=PRF(K_2,s)$

2: Look up $t_1$ in $IT$ to obtain index value $I_s$

3: Decrypt index entry: $(hea{d}_s\parallel add{r}_s^{ABE})=I_s\oplus t_2$

4: Read ABE ciphertext $C_s$ from $ET$ using $add{r}_s^{ABE}$

5: Initialize result set $\mathcal{R}\leftarrow \varnothing$, current address $cur\leftarrow hea{d}_s$

6: while  $cur\ne 0^{\lambda }$do

7:      Read node $N_i=(c{t}_i,r_i,n{c}_i,h{c}_i)$ from $CT$

8:      $\mathcal{R}\leftarrow \mathcal{R}\cup \left\{c{t}_i\right\}$

9:      Recover local hash key: $K_i=H(c{t}_i\parallel t_1\parallel r_i)$

10:    Decrypt next node pointer: $next=n{c}_i\oplus K_i$

11:    Update $cur\leftarrow next$

12: end while

13: return$(\mathcal{R},C_s)$

In single-hop retrieval, the server first uses the first half of the trapdoor to locate the index and the second half to decrypt and obtain the head of the linked list and the ABE ciphertext address. During linked-list traversal, because $K_i$ depends on the preceding ciphertext and a random nonce, the server can only decrypt sequentially and cannot predict the length of the list or jump arbitrarily, thereby hiding the local topological structure of the graph.

4.4.2. Multi-Hop Query

Multi-hop queries over knowledge graphs are realized through the multi-hop component $h{c}_i$ within nodes. During linked-list traversal, each node may carry a trapdoor pointing to the object subject of its triple. The server decrypts the $h{c}_i$ field of every traversed node, probes the index table $IT$, and collects all valid next-hop subjects into a frontier. The next hop then performs breadth-first expansion from all subjects in the frontier simultaneously, naturally supporting branching graph traversals without any user interaction. The detailed procedure is shown in Algorithm 3.

The core advantage of the BFS-based multi-hop traversal is twofold. First, each node requires only one XOR operation ($h{c}_i\oplus K_i$) to recover a full trapdoor candidate $(PRF(K_1,o),PRF(K_2,o))$, whose format is identical to a valid search trapdoor. Second, by processing all nodes in the current linked list and collecting every valid next-hop subject into the frontier, the algorithm naturally supports branching graph traversals—when a subject links to multiple object subjects, all branches are explored in parallel at the next hop. This design achieves efficient graph navigation over ciphertexts while preserving the complete multi-hop semantics of knowledge graph queries, and significantly reduces the round-trip latency compared with schemes that require per-hop user involvement.

Algorithm 3  $MultiHopSearch(t{d}_s,h,IT,CT,ET)$

1: Initialize overall result set $\mathcal{R}\leftarrow \varnothing$, ABE ciphertext set $\mathcal{C}\leftarrow \varnothing$

2: Initialize frontier $F\leftarrow \left\{t{d}_s\right\}$

3: for  $j=1$ to h do

4:     Initialize next frontier $F_{next}\leftarrow \varnothing$

5:     for each $td\in F$  do

6:      Parse $td=(t_1,t_2)$

7:      Look up $t_1$ in $IT$ to obtain I

8:      Decrypt index entry: $(head\parallel add{r}^{ABE})=I\oplus t_2$

9:      Read ABE ciphertext C from $ET$ using $add{r}^{ABE}$

10:       $\mathcal{C}\leftarrow \mathcal{C}\cup \left\{C\right\}$

11:       $cur\leftarrow head$

12:       while $cur\ne 0^{\lambda }$  do

13:           Read node $N_i=(c{t}_i,r_i,n{c}_i,h{c}_i)$ from $CT$

14:           $\mathcal{R}\leftarrow \mathcal{R}\cup \left\{c{t}_i\right\}$

15:           $K_i\leftarrow H(c{t}_i\parallel t_1\parallel r_i)$

16:           $t{d}_{temp}\leftarrow h{c}_i\oplus K_i$

17:           Parse $t{d}_{temp}=(t_1^{\prime },t_2^{\prime })$

18:           if $t_1^{\prime }$ exists in $IT$  then

19:         $F_{next}\leftarrow F_{next}\cup \left\{t{d}_{temp}\right\}$

20:           end if

21:           $next\leftarrow n{c}_i\oplus K_i$

22:           $cur\leftarrow next$

23:       end while

24:     end for

25:     if $F_{next}=\varnothing$  then

26:       break {No reachable subject in next hop}

27:     end if

28:    $F\leftarrow F_{next}$

29: end for

30: return$(\mathcal{R},\mathcal{C})$

4.5. Decryption

After receiving $(\mathcal{R},\mathcal{C})$ returned by the server, the user executes Algorithm 4 to recover the plaintext triples. This process ensures the enforcement of fine-grained access control.

Algorithm 4  $Decrypt(\mathcal{R},\mathcal{C},S{K}_{ABE})$

1: Initialize plaintext set ${\mathcal{T}}^{\prime }\leftarrow \varnothing$

2: for each $C_s\in \mathcal{C}$  do

3:    Attempt ABE decryption: $k_s=ABE.Dec(S{K}_{ABE},C_s)$

4:    if $k_s\ne \perp$  then

5:    for each $ct\in \mathcal{R}$  do

6:           Attempt symmetric decryption: $(s,p,o)=Sym.De{c}_{k_s}\left(ct\right)$

7:           if decryption succeeds and integrity check passes then

8:         ${\mathcal{T}}^{\prime }\leftarrow {\mathcal{T}}^{\prime }\cup \left\{(s,p,o)\right\}$

9:           end if

10:       end for

11:       break {Decryption for current subject completed}

12:    end if

13: end for

14: return  ${\mathcal{T}}^{\prime }$

Due to the two-layer encryption architecture, even if a user obtains all ciphertext triples associated with a given subject, the user cannot recover the content key $k_s$ unless their ABE private key satisfies policy ${\mathbb{A}}_s$, and thus cannot decrypt any plaintext information. This enables EFKG to enforce fine-grained access control precisely at the subject level.

5. Security Analysis

Based on the security model defined in Section 3, this section presents a formal analysis and proof of the security of the EFKG scheme. We first provide the leakage function definition required for the security proof, then state the security theorem, and rigorously prove that the scheme achieves standard $\mathcal{L}$-adaptive security by constructing a polynomial-time simulator.

5.1. Leakage Function Definition

According to the general security definitions in the searchable encryption domain, the security of the scheme is bounded by the leakage function $\mathcal{L}$. The leakage functions involved in this scheme are defined as follows:

Definition 3 (Leakage Function ${\mathcal{L}}_{Setup}$).

Given the security parameter λ and the knowledge graph $\mathcal{G}$, ${\mathcal{L}}_{Setup}\left(\mathcal{G}\right)=\left\{\right|{\mathcal{T}}_s{\left|\right\}}_{s\in S}$. That is, the initialization phase only leaks the number of triples corresponding to each subject s. This information reflects the basic topological scale of the knowledge graph but does not reveal specific entity contents, relationship types, or graph connectivity details.

Definition 4 (Leakage Function ${\mathcal{L}}_{Query}$).

Given the security parameter λ, the knowledge graph $\mathcal{G}$, and the query subject s, ${\mathcal{L}}_{Query}(\mathcal{G},s)=(SP,AP)$, where

• Search Pattern: Reveals whether the current query is a repeated query (i.e., whether the queried subject s has appeared in the historical query sequence).
• Access Pattern: Reveals the set of encrypted triple identifiers returned by the query and the corresponding linked-list traversal order.

This leakage conforms to the general setting of standard searchable encryption schemes.

5.2. Security Theorem

Theorem 1 ($\mathcal{L}$-Adaptive Security).

Assume that the pseudorandom function $PRF$ is secure, the symmetric encryption scheme $Sym$ is IND-CPA secure, the attribute-based encryption scheme $ABE$ is IND-CPA secure, and the hash function H is secure under the random oracle model. Then the proposed EFKG scheme is $\mathcal{L}$-adaptively secure under the leakage function $\mathcal{L}=({\mathcal{L}}_{Setup},{\mathcal{L}}_{Query})$ defined above.

Specifically, for any probabilistic polynomial-time (PPT) adversary $\mathcal{A}$, there exists a polynomial-time simulator $\mathcal{S}$ such that the advantage of the adversary in distinguishing the real experiment ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ from the ideal experiment ${\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$ is negligible.

5.3. Security Proof

Proof of Theorem 1.

We prove the security of the scheme by constructing a polynomial-time simulator $\mathcal{S}$. The simulator $\mathcal{S}$ only utilizes the output of the leakage functions ${\mathcal{L}}_{Setup}$ and ${\mathcal{L}}_{Query}$ to generate a view that is indistinguishable from the real execution. The simulation process is as follows:

1. Simulating the ABE Ciphertext Table $ET$. The simulator $\mathcal{S}$ receives the leakage information ${\mathcal{L}}_{Setup}\left(\mathcal{G}\right)=\left\{\right|{\mathcal{T}}_s{\left|\right\}}_{s\in S}$. For each subject s in the knowledge graph, $\mathcal{S}$ performs the following operations:

• Randomly select an element $C_s^{\prime }\in {\mathcal{C}}_{ABE}$ from the ABE ciphertext space.
• Store $C_s^{\prime }$ in the simulated ABE ciphertext table $E{T}^{\prime }$, and record its simulated address $add{r}_{ABE}^{\prime }$.

Since the underlying ABE scheme satisfies IND-CPA security, and in the real scheme the ciphertext $C_s$ is the encryption of the content key $k_s$ under the access policy ${\mathbb{A}}_s$, without knowing the master secret key and the plaintext key, the random ciphertext $C_s^{\prime }$ generated by the simulator is computationally indistinguishable from the real ciphertext $C_s$.

2. Simulating the Triple Ciphertext Table $CT$ and Index Table $IT$. The simulator $\mathcal{S}$ uses the leakage information $|{\mathcal{T}}_s|$ (i.e., the number of triples for each subject s) to construct simulated linked-list structures. For each subject s:

• Generate simulated trapdoor components: $\mathcal{S}$ randomly picks two independent random strings $k_s^{\prime },m_s^{\prime }\leftarrow {\{0,1\}}^{\lambda }$ from the key space, serving as the simulated values of $PRF(K_1,s)$ and $PRF(K_2,s)$ in the real scheme, respectively.
• Build simulated linked list $L_s^{\prime }$: Generate a simulated linked list containing $|{\mathcal{T}}_s|$ nodes. For the i-th node $N_i^{\prime }$ in the linked list: randomly pick a string $c{t}_i^{\prime }\in {\{0,1\}}^{\left|ct\right|}$ as the simulated encrypted triple, and a random number $r_i^{\prime }\leftarrow {\{0,1\}}^{\lambda }$. By the IND-CPA security of $Sym$, a random string is indistinguishable from the real ciphertext. Randomly generate the simulated next-pointer ciphertext $n{c}_i^{\prime }\leftarrow {\{0,1\}}^{\left|addr\right|}$ and the simulated multi-hop component ciphertext $h{c}_i^{\prime }\leftarrow {\{0,1\}}^{|T_o|}$. To ensure that the server can correctly traverse the simulated linked list during queries (satisfying the access pattern $AP$), $\mathcal{S}$ programs the random oracle H. $\mathcal{S}$ computes a local hash key $K_i^{\prime }$ and programs it as $H(c{t}_i^{\prime }\parallel k_s^{\prime }\parallel r_i^{\prime }):=K_i^{\prime }$, such that $n{c}_i^{\prime }=add{r}_{i+1}^{\prime }\oplus K_i^{\prime }$ and $h{c}_i^{\prime }=T_{next}^{\prime }\oplus K_i^{\prime }$ (where $T_{next}^{\prime }$ is the simulated trapdoor component corresponding to the next-hop subject). Since in the ideal experiment $\mathcal{S}$ can perfectly control the output of H, the logical links between the simulated nodes are consistent with the real linked-list traversal process.
• Simulate index entry: $\mathcal{S}$ computes the simulated index value $I_s^{\prime }=(hea{d}_s^{\prime }\parallel add{r}_{ABE}^{\prime })\oplus m_s^{\prime }$, and inserts the key-value pair $(k_s^{\prime },I_s^{\prime })$ into the simulated index table $I{T}^{\prime }$.

3. Simulating Trapdoor Generation. When the adversary initiates a query for subject s, the simulator $\mathcal{S}$ uses the information provided by the leakage function ${\mathcal{L}}_{Query}$ (especially the search pattern $SP$) to generate simulated trapdoors:

• If subject s is queried for the first time, $\mathcal{S}$ returns the previously generated simulated tuple $t{d}_s^{\prime }=(k_s^{\prime },m_s^{\prime })$ for this subject.
• If subject s has been queried before, according to the search pattern $SP$, $\mathcal{S}$ must return the exact same trapdoor $t{d}_s^{\prime }=(k_s^{\prime },m_s^{\prime })$ as the previous query.

In the real scheme, the trapdoor $t{d}_s$ is generated by pseudorandom functions, i.e., $t{d}_s=(PRF(K_1,s),PRF(K_2,s))$. Due to the security of $PRF$, its output is indistinguishable from truly random strings. Therefore, the random tuple $(k_s^{\prime },m_s^{\prime })$ generated by the simulator is indistinguishable from the real trapdoor $t{d}_s$.

4. Indistinguishability Analysis. In summary, the indistinguishability between the real experiment and the ideal experiment relies on the following computational assumptions and cryptographic properties:

• IND-CPA security of $ABE$: Guarantees that the real ciphertext $C_s$ in the $ET$ table is indistinguishable from the random element $C_s^{\prime }$ generated by the simulator.
• IND-CPA security of $Sym$: Guarantees that the triple ciphertext $c{t}_i$ in the $CT$ table is indistinguishable from the random string $c{t}_i^{\prime }$.
• Security of $PRF$: Guarantees the pseudorandomness of the location key ($PRF(K_1,s)$ vs. $k_s^{\prime }$) and the decryption mask ($PRF(K_2,s)$ vs. $m_s^{\prime }$) in the index table $IT$, making the encrypted index entries indistinguishable.
• Random Oracle Model: Guarantees the security of the linked-list pointer and multi-hop component masks ($K_i$ vs. $K_i^{\prime }$). In the real scheme, $K_i$ depends on the ciphertext and a random number and behaves as a pseudorandom string; in the ideal experiment, $\mathcal{S}$ endows it with perfect logical consistency by programming H. Both exhibit the same distribution from the adversary’s perspective.

Since the simulated ciphertext tables $(C{T}^{\prime },E{T}^{\prime },I{T}^{\prime })$ and the simulated trapdoor $t{d}_s^{\prime }$ generated by the simulator $\mathcal{S}$ are computationally indistinguishable from the outputs of the real world, for any PPT adversary, its advantage in distinguishing the real experiment from the ideal experiment is negligible. The theorem is proved. □

6. Performance Evaluation

To evaluate the practical performance of the EFKG scheme, we implemented all algorithms in C++ on a Linux platform. All tests ran in single-threaded mode, except for the multi-threading scalability experiment reported at the end of Section 6.1. The detailed experimental environment configuration is summarized in

Table 3. Experimental environment configuration.

Component	Specification
CPU	Intel Core i5-1135G7
Memory	16 GB DDR4
Operating System	Fedora Linux 42
Compiler	GCC 15.2.1
Cryptographic Library	OpenSSL 3.0
Pairing Library	PBC 0.5.14

.

To comprehensively evaluate the scheme on knowledge graphs of varying scales and structures, we selected four real-world datasets ranging from thousands to millions of entities for benchmarking, and compared EFKG against the DSSE-KG scheme [6] across all metrics. The dataset characteristics are shown in

Table 4. Characteristics of real-world datasets.

Dataset	Entities	Triples	Avg. List Len
Wiki-Vote	7115	103,689	14.57
Email-Enron	36,692	367,662	10.02
Email-EuAll	265,214	420,045	1.58
WikiTalk	2,394,385	5,021,410	2.10

.

The datasets span three orders of magnitude in entity count and cover both sparse graphs (Email-EuAll, WikiTalk) and dense graphs (Wiki-Vote, Email-Enron), representing two typical real-world knowledge graph scenarios.

6.1. Index Construction Performance

BuildIndex is the most computationally expensive phase in the EFKG scheme, requiring one ABE per entity. Its time complexity is $O(N_e·T_{\mathrm{ABE}}+N_t·T_{\mathrm{sym}})$, where $N_e$ is the number of entities, $N_t$ is the number of triples, $T_{\mathrm{ABE}}\approx 6\mathrm{ms}/\mathrm{entity}$ is the unit ABE time for a 1-attribute policy, and $T_{\mathrm{sym}}\approx 0.9\mathsf{\mu }\mathrm{s}/\mathrm{triple}$ is the unit symmetric encryption time. Since $T_{\mathrm{ABE}}\gg T_{\mathrm{sym}}$, the construction time is dominated by ABE. Figure 3 compares the index construction time between EFKG and DSSE-KG across the four datasets. The time is presented in minutes on a logarithmic scale.

As shown in Figure 3, EFKG’s construction time is 33×–265× slower than DSSE-KG—the price of supporting fine-grained access control. The gap widens on entity-dense datasets because ABE (≈6 ms/entity) dominates the construction cost: on WikiTalk (2.39 M entities), the measured 3.7 h build time closely matches the theoretical ABE cost. However, BuildIndex is a one-time offline operation, and each entity’s ABE is inherently independent, making this phase embarrassingly parallel. To validate parallel scaling, we benchmarked multi-threaded BuildIndex on Wiki-Vote using OpenMP with 1–8 threads (3 runs per configuration), as reported in

Table 5. Multi-threaded BuildIndex performance on Wiki-Vote.

Threads	Wall Time (s)	Speedup	Parallel Efficiency
1	42.82	1.00×	100.0%
2	22.77	1.88×	94.0%
4	14.39	2.97×	74.4%
8	12.52	3.42×	42.8%

and Figure 4.

As shown in Table 5, BuildIndex achieves a 1.88× speedup at 2 threads and 2.97× at 4 threads, confirming near-linear scaling up to the physical core count of the test platform (i5-1135G7, 4C/8T). Beyond 4 threads, hyper-threading yields diminishing returns (3.42× at 8 threads), limited by memory bandwidth contention during concurrent ABE. Extrapolating to a 16-core server, the 3.7 h WikiTalk build would achieve 8–10× speedup, well under 30 min.

6.2. Search Performance

The core characteristic of EFKG search is that it relies solely on lightweight cryptographic operations (SHA-256 and XOR), completely avoiding expensive pairing operations. Single-hop search time depends only on the linked-list length of the target subject and is independent of the total knowledge graph scale:

$$T_{\mathrm{search}}=L·t_{\mathrm{node}}$$

(3)

where $L=N_t/N_e$ is the average linked-list length and $t_{\mathrm{node}}\approx 0.40\mathsf{\mu }\mathrm{s}$ is the time to traverse a single linked-list node (including one SHA-256 hash, one XOR operation, and one hash table lookup). DSSE-KG, by contrast, requires AES-256-CTR keystream generation per node traversal, yielding a unit cost of approximately $1.01\mathsf{\mu }\mathrm{s}$. Figure 5 presents the single-hop search latency comparison on a linear scale. EFKG achieves a speedup of 2.65× to 5.06× relative to DSSE-KG across all datasets.

Sparse graphs are particularly efficient: Email-EuAll and WikiTalk achieve search latencies of 2.58 $\mathsf{\mu }\mathrm{s}$ and 2.30 $\mathsf{\mu }\mathrm{s}$, respectively. Even on the densest graph Wiki-Vote ($L=14.57$), EFKG search takes only 8.26 $\mathsf{\mu }\mathrm{s}$—approximately 460× faster than the ABE decryption cost. This confirms that EFKG’s two-layer design successfully isolates expensive pairing operations from the search path.

6.3. Multi-Hop Retrieval Performance

Multi-hop retrieval is a distinctive capability of encrypted knowledge graphs, enabling traversal across entity relationships. The worst-case number of nodes visited in an h-hop retrieval is:

$$N_{\mathrm{visited}}={\displaystyle \sum _{i=1}^h}{L}^i$$

(4)

When $L>1$, the traversal cost grows exponentially with the number of hops. EFKG’s multi-hop search leverages the $hc$ field embedded in each linked-list node to recover the trapdoor for the next-hop subject with $O\left(1\right)$ overhead per node, enabling efficient BFS-style expansion. Figure 6 compares the 1-hop, 2-hop, and 3-hop retrieval latencies between EFKG and DSSE-KG on each dataset (note the logarithmic y-axis).

The experimental results reveal three key findings:

(1) EFKG’s advantage amplifies with hop count. On WikiTalk, the speedup jumps from 4.50× at 1 hop to 198.81× at 2 hops and 191.44× at 3 hops, because the per-node traversal cost advantage (0.40 $\mathsf{\mu }\mathrm{s}$ vs. 1.01 $\mathsf{\mu }\mathrm{s}$) is multiplied by the exponentially growing number of visited nodes.

(2) Sparse graphs exhibit outstanding multi-hop efficiency. Email-EuAll ($L=1.58$) and WikiTalk ($L=2.10$) achieve 3-hop latencies of 4.37 ms and 14.15 ms, respectively, making practical multi-hop queries entirely feasible on communication and social network graphs.

(3) Dense graphs face exponential fan-out challenges. Wiki-Vote ($L=14.57$) traverses approximately 3320 nodes at 3 hops (5.69 ms, a 32.58× speedup over DSSE-KG), while Email-Enron ($L=10.02$) reaches 21.53 ms—at the edge of real-time acceptability. In practice, hop limits or build-time pruning strategies can control traversal costs on dense subgraphs.

6.4. Storage Overhead

Ciphertext storage consists of three components: the CT table (encrypted triple nodes), the ET table (ABE ciphertexts), and the IT table (index entries). The per-element storage breakdown is detailed in

Table 6. Per-element storage overhead.

Component	Field Description	Size
CT node	$c{t}_i$: AES-256-GCM ciphertext of the serialized triple	25 B
	$r_i$: mask seed ($\lambda =256$ bits)	32 B
	$n{c}_i$: encrypted next-node pointer ($\lambda$ bits)	32 B
	$h{c}_i$: multi-hop component ($2\lambda$ bits)	64 B
ET ciphertext ($C_s$: ABE-encrypted content key)		422 B
IT entry ($PRF(K_1,s)\to$ encrypted index value)		64 B

.

The 153 B CT node comprises the four fields of each linked-list node $N_i=(c{t}_i,r_i,n{c}_i,h{c}_i)$ defined in Algorithm 1, with $r_i$ already included in the per-triple total.

The total ciphertext size is given by:

$$S_{\mathrm{EFKG}}=N_t·153+N_e·(422+64)\mathrm{bytes}$$

(5)

For comparison, DSSE-KG’s storage comprises four structures: SA (184 B/triple), ST (86 B/entity), UT (40 B/triple), and Enc (41 B/triple), totaling $N_t·265+N_e·86$ bytes.

Table 7. EFKG ciphertext storage composition (MB).

Dataset	CT	ET	IT	Total
Wiki-Vote	15.19	2.86	0.43	21.80
Email-Enron	54.00	14.76	2.24	83.06
Email-EuAll	62.05	106.88	16.19	204.01
WikiTalk	748.19	967.13	146.14	2069.50

provides a detailed breakdown of EFKG’s storage composition across the four benchmark datasets, and

Table 8. EFKG vs. DSSE-KG storage comparison.

Dataset	L	EFKG (MB)	DSSE-KG (MB)
Wiki-Vote	14.57	21.80	30.86
Email-Enron	10.02	83.06	112.90
Email-EuAll	1.58	204.01	145.84
WikiTalk	2.10	2069.50	1668.10

compares the total storage between EFKG and DSSE-KG.

Several observations emerge:

(1) ABE amortization effect. On dense graphs (Wiki-Vote, $L=14.57$), each 422 B ABE ciphertext is amortized over 14.57 triples (≈29 B/triple), yielding a modest 16.26× expansion. On sparse graphs (Email-EuAll, $L=1.58$), each triple bears ≈267 B of ABE overhead, driving expansion to 34.16×.

(2) Density-dependent cross-scheme comparison. EFKG is more storage-efficient on dense graphs (71–74% of DSSE-KG’s storage) because its CT node (153 B/triple) is more compact than DSSE-KG’s SA entry (184 B/triple). On sparse graphs, the fixed ABE cost dominates, and EFKG exceeds DSSE-KG by 24–40%.

(3) Practical viability. WikiTalk (2.4 M entities, 5 M triples) requires approximately 2.07 GB, readily accommodated by modern servers. The CT, ET, and IT tables can be deployed independently, with CT loaded on demand during search and ET accessed only at decryption. Extrapolating to soc-LiveJournal1 (69 M triples, 4.85 M entities), estimated storage is approximately 12.9 GB—within a single commodity server.

6.5. Discussion and Comparison with Existing Work

Comparing EFKG against DSSE-KG across all evaluation dimensions reveals a consistent trade-off. In terms of construction performance, EFKG is 33×–265× slower than DSSE-KG due to the per-entity ABE cost; however, this is a one-time offline operation, and our multi-threading experiment (Table 5) confirms near-linear parallel scalability that can reduce the gap to practical levels on multi-core hardware. In terms of search performance, EFKG achieves a 2.65×–5.06× speedup over DSSE-KG because its per-node traversal relies on lightweight SHA-256 and XOR operations (0.40 $\mathsf{\mu }\mathrm{s}$/node) rather than AES-256-CTR keystream generation (1.01 $\mathsf{\mu }\mathrm{s}$/node). This advantage amplifies dramatically in multi-hop scenarios: the per-node cost differential is multiplied by the exponentially growing number of visited nodes, yielding up to 191× speedup at 3 hops on WikiTalk. In terms of storage, EFKG is more compact on dense graphs ($L>3.54$) where the ABE overhead is well amortized, while DSSE-KG holds an advantage on sparse graphs where the fixed per-entity ABE cost dominates. Overall, EFKG trades a one-time construction cost for (i) persistent search acceleration across all query types, (ii) fine-grained, subject-level access control absent from DSSE-KG, and (iii) storage efficiency on the moderate-to-dense graphs most common in real-world knowledge graph applications.

These results also bound the scheme’s applicability. EFKG is best suited to moderately dense graphs ($L\gtrsim 2$) where access control is required and the search speedup over DSSE-KG is most pronounced; for extremely sparse graphs the ABE overhead may favor non-authorizing schemes, and for very dense hub-dominated graphs the exponential multi-hop fan-out (Section 6.3) suggests practical deployment with hop limits.

7. Conclusions

To address the challenge of simultaneously achieving retrieval efficiency and fine-grained access control in outsourced knowledge graphs, this paper proposes EFKG, an efficient fine-grained access control encrypted knowledge graph construction scheme. By designing a subject-based linked-list structure and a two-layer encryption mechanism, the scheme achieves deep decoupling between subject-level access control and ciphertext retrieval. Concurrently, the embedded self-contained multi-hop navigation components enable the cloud server to perform constant-time cross-subject jumps in the ciphertext space, natively supporting efficient graph traversal. Rigorous security proofs and experiments on real-world datasets demonstrate that EFKG achieves excellent retrieval efficiency and practical value while ensuring $\mathcal{L}$-adaptive security.

In summary, the key innovations of EFKG are threefold. First, the subject-based linked-list structure organizes triples of the same subject into a hash-chained sequence with XOR-masked pointers, enforcing subject-level ABE access policies while keeping inter-node correlations hidden from the server. Second, the self-contained ciphertext navigation mechanism embeds the complete trapdoor of the next-hop subject within each linked-list node, enabling the cloud server to perform constant-time cross-subject jumps during BFS traversal without any per-hop user interaction. Third, the two-layer encryption architecture—symmetric encryption for triple contents and ABE for content keys—decouples lightweight server-side retrieval from expensive client-side pairing operations, ensuring that the most frequent operation (search) remains at the microsecond level irrespective of graph scale.

While EFKG demonstrates a favorable balance among efficiency, security, and functionality, several promising directions remain for future work: (i) extending the scheme to support dynamic ciphertext-graph updates with provable forward and backward privacy, potentially via append-only index structures with versioned masks; (ii) investigating predicate-level ultra-fine-grained access control to enable authorization at finer granularity than the subject level; (iii) designing practical attribute and content-key revocation protocols, possibly leveraging proxy re-encryption to offload ciphertext updates to the cloud server without exposing content keys; and (iv) evaluating more complex graph query primitives beyond multi-hop traversal, such as path queries and subgraph pattern matching over encrypted knowledge graphs.