Privacy-Preserving Multi-User Graph Intersection Scheme for Wireless Communications in Cloud-Assisted Internet of Things

TL;DR

This paper introduces a secure method for multiple users to perform graph intersection queries in cloud-assisted IoT systems while preserving data privacy.

Contribution

A novel privacy-preserving multi-user graph intersection scheme using proxy re-encryption for cloud-assisted IoT.

Findings

The proposed scheme reduces computational and communication costs for data owners in multi-user scenarios.

Theoretical analysis and simulations confirm the security and practicality of the graph intersection method.

Proxy re-encryption enables flexible graph intersection queries without repeated encryption by data owners.

Abstract

Cloud-assisted Internet of Things (IoT) has become the core infrastructure of smart society since it solves the computational power, storage, and collaboration bottlenecks of traditional IoT through resource decoupling and capability complementarity. The development of a graph database and cloud-assisted IoT promotes the research of privacy preserving graph computation. We propose a secure graph intersection scheme that supports multi-user intersection queries in cloud-assisted IoT in this article. The existing work on graph encryption for intersection queries is designed for a single user, which will bring high computational and communication costs for data owners, or cause the risk of secret key leaking if directly applied to multi-user scenarios. To solve these problems, we employ the proxy re-encryption (PRE) that transforms the encrypted graph data with a re-encryption key to enable the graph intersection results to be decrypted by an authorized IoT user using their own private key, while data owners only encrypt their graph data on IoT devices once. In our scheme, different IoT users can query for the intersection of graphs flexibly, while data owners do not need to perform encryption operations every time an IoT user makes a query. Theoretical analysis and simulation results demonstrate that the graph intersection scheme in this paper is secure and practical.

Figures

Full text

1. Introduction

Internet of Things (IoT) has promoted the integration of the physical and digital worlds, greatly facilitating our life. However, the exponential growth of IoT devices brings great challenge for localized data processing, which promotes the emergence of cloud-assisted IoT. Cloud-assisted IoT can manage decentralized IoT devices through the cloud platform, providing computational and storage services for resource-limited IoT devices.

Graphs can describe not only diverse types of data but also connections among them. They have significant application value and are applied widely in a range of IoT scenarios such as smart home, smart logistics, smart wearables and so on. Since a large amount of graph data are produced or stored on IoT devices, graph computation tasks such as subgraph matching, shortest path computation, and graph intersection have become important in IoT applications.

The accelerating growth of cloud-assisted IoT promotes data owners with IoT devices to outsource the storage and computational task to the cloud server. However, it causes privacy leakage risk: the original graph data of IoT devices usually contain sensitive information (such as social relationships and medical data), so directly uploading them to the cloud may cause the data to be stolen or misused. To solve this problem, privacy-preserving graph computation in cloud-assisted IoT was born. As one of the most important technologies, graph encryption makes use of cryptography methods to protect the data and relationships of graphs. Much research has been conducted for graph encryption that supports various kinds of graph operations, including shortest distance computation [1,2,3,4,5,6], minimum community search [7], subgraph counting [8], subgraph matching [9,10,11,12,13,14], and so on.

Graph intersection is an operation that searches for common sub structures among graphs of different IoT devices through comparing their vertices and edges. It plays an important role in social network mutual friend recommendation, collaborative data analysis across institutions, etc. Unfortunately, little research aims at the privacy-preserving graph intersection [15,16,17], for which the scheme in [16] computes the graph intersection of two parties, the scheme in [17] enables multiple parties to collaboratively calculate the graph intersection directly among the participants, and the scheme in [15] proposes an outsourced graph intersection scheme of multiple data owners for a single user. Other relevant works study privacy-preserving subgraph matching [9,10,11,12,13,14] and outsourced private set intersection [18,19,20,21,22,23,24]. Some of these prior works only consider a single user; data owners encrypt their graphs using public encryption or symmetric encryption while the query user is directly issued the corresponding secret keys so they can perform decryption to obtain the query results. Other works support multiple users by applying access control over them, where users obtain the decryption key through the access control mechanism.

However, there are some problems in the schemes that IoT users directly obtain the decryption key: first of all, if the IoT user permission changes, data owners have to re-encrypt their graph with new keys, causing large computational and communication costs. Secondly, since a trusted authority or the data owner needs to manage key distribution, graph data can be decrypted once the decryption key leaked.

1.1. Contributions

To enable multiple users to flexibly query graph intersection in a privacy-preserving manner, we present a multi-user graph encryption for intersection queries in the cloud-assisted IoT environment. As is described in Figure 1, the system model consists of four types of entities: a trusted authority (TA), the cloud server, data owners, and data users. The contributions of this paper are summarized as follows.

• We present a construction of privacy-preserving graph intersection computation. In our scheme, a TA initializes the system, and it generates public parameters for the system and re-encryption keys for the cloud server. Each data owner encrypts their graph before uploading it to the cloud server. Every time a data user sends a graph intersection query, the cloud server re-encrypts these encrypted graphs with a re-encryption key from the TA to the data user. After calculating the intersection of all these encrypted graphs, it sends the graph intersection to the query user. Following this procedure, our scheme can support data users to query for the graph intersection of data owners securely and flexibly.
• Our scheme supports multi-user scenarios. It allows multiple users to query for the graph intersection, while data owners only need encrypt their data once. On the one hand, it achieves flexible data sharing; on the other hand, it decreases the processing burden placed on data owners.
• In our scheme, the cloud server transforms the ciphertexts intended for TA to ciphertexts that can be decrypted by the query user by using proxy re-encryption, enabling data users to decrypt the result with their own keys, without exposing sensitive data. It reduces the complexity of key management.
• We present the theoretical analysis from aspects of security and performance. The results from our experiments confirm that the scheme is practical and efficient.

1.2. Paper Organization

The related works are summarized in Section 2. We introduce the preliminaries in Section 3. Problem formalization including the system model, threat model, and security goals is presented in Section 4. We give the concrete construction of our scheme in Section 5. The correctness and security analysis are presented in Section 6. In Section 7, we show the performance analysis and experimental evaluation. In the end, we conclude our work in Section 8.

2. Related Work

We summarize the related works including graph encryption and outsourced private set intersection. Our scheme represents a specialized form of graph encryption to compute graph intersection, It is an extension of private set intersection, which computes the intersection of sets instead of graphs.

2.1. Graph Encryption

Chase and Kamara [25] proposed structured encryption schemes that support several kinds of private queries on encrypted data with complex structures. Among all the graph operations, the shortest distance query is the most fundamental one. Meng et al. [26] proposed GRECS composed of three schemes for different security and efficiency requirements; the schemes realize approximate shortest distance queries. Refs. [4,5,6] support exact shortest distance queries, and refs. [1,2,3] solve the problems in the constrained shortest distance query (CSD). Some other schemes [27,28,29,30] can provide users with the shortest path. Other privacy-preserving graph operations include graph search [31,32], minimum community search [7], graph similarity query [33], subgraph counting [8], and so on. The most related works to ours are subgraph matching [9,10,11,12,13,14] and graph intersection [15]. Cao et al. [14] introduced a system called PPGQ that utilizes the “filtering and verification” principle to filter according to a feature-based index and efficient inner product, where data users decrypt the candidate supergeaphs and verify each candidate. Fan et al. [12] transformed the classic Ullmann’s algorithm as a progression of matrix calculations, which is protected by a cyclic group-based encryption scheme. Zuo et al. [10] designed a privacy-preserving subgraph matching scheme that can protect the privacy of the user’s query subgraph and the original graph. It also achieved data integrity. Ge et al. [11] considered another type of subgraph matching that searches for all graphs exhibiting subgraph isomorphism with the query pattern from large amounts of small graphs, and where the query user is able to directly extract the subgraph. Wang et al. [9] designed OblivGM that supports attributed subgraph matching and can also hide search patterns. Based on OblivGM, they further proposed eGrass [13], which considers secure attributed subgraph matching even if the clouds are malicious. However, the techniques used in these schemes cannot support multiple users flexibly without key management; some of them are designed for a single user, while others enable data users to obtain the decryption key through access control.

2.2. Outsourced Private Set Intersection

In outsourced private set intersection (O-PSI), data owners outsource the PSI computation the cloud server. Kerschbaum [18] firstly presented an outsourced PSI scheme on the basis of Bloom filter and HE. Since then, various PSI schemes have been proposed. Ref. [19] extended the scale of PSI protocol to billion-element sets by using a high-efficiency data structure from the Sparsehash library. Abadi et al. [20] presented two delegated private set intersection schemes, of which O-PSI employs additive homomorphic encryption, and EO-PSI makes use of hash tables instead of public key encryption, which provides higher efficiency. Ali et al. [21] designed a protocol in which data owners can define access control policies such that only data owners who satisfy specific attributes can query for PSI results. Since the cloud server can be malicious, the schemes in [22,23,24,34] realized both privacy preservation and verifiability; their PSI computations were combined with the resultant verification mechanisms that enable clients to verify whether the results are correct. Sharma [35] designed a framework named PRISM which is based on secret sharing, where data owners upload their data to non-colluding clouds to perform secure set operations based on secret sharing. All these works support private set intersection among sets, but how to securely compute the intersection of graphs has yet to be studied.

3. Preliminaries

We summarize concepts and basic tools of our scheme: to realize secure graph intersection, we employ the proxy re-encryption (PRE) based on bilinear pairings.

3.1. Graph Intersection

Definition 1. (Graph Intersection). Given t graphs $[eqn]$ , the graph intersection is defined as $[eqn]$ satisfying the following:

• For each vertex $[eqn]$ , $[eqn]$ and $[eqn]$ .
• For each vertex $[eqn]$ , $[eqn]$ and $[eqn]$ .

Figure 2 is an example: the intersection of graph $[eqn]$ and $[eqn]$ is G.

3.2. Bilinear Pairings

Bilinear pairings is a map presented as $[eqn]$ , where $[eqn]$ and $[eqn]$ are cyclic groups of prime order p, generator $[eqn]$ . It satisfies the following properties:

• Bilinearity. $[eqn]$ , for all $[eqn]$ and $[eqn]$ .
• Non-degeneracy. $[eqn]$ .
• Computability. $[eqn]$ can be computed efficiently.

3.3. Proxy Re-Encryption

Our graph encryption scheme is based on the proxy re-encryption (PRE) technique. We employ the PRE scheme in the following [36]:

1. $[eqn]$ . Given a security parameter $[eqn]$ , $[eqn]$ constructs a bilinear map $[eqn]$ where $[eqn]$ and $[eqn]$ are groups of prime order p, and generator $[eqn]$ , return the public parameters $[eqn]$ .
2. $[eqn]$ . An entity chooses a random $[eqn]$ as the private key; their public key is $[eqn]$ .
3. $[eqn]$ . The re-encryption key $[eqn]$ can be generated with delegator a’s private key $[eqn]$ and delegatee b’s public key as $[eqn]$
4. $[eqn]$ . To encrypt a message $[eqn]$ under $[eqn]$ : sample $[eqn]$ , $[eqn]$ , $[eqn]$ . The ciphertext $[eqn]$ .
5. $[eqn]$ . Given the re-encryption key $[eqn]$ , ciphertext $[eqn]$ can be re-encrypted as follows: sample $[eqn]$ , $[eqn]$ , $[eqn]$ . The re-encrypted ciphertext $[eqn]$ .
6. $[eqn]$ . Entity b can decrypt $[eqn]$ using their private key $[eqn]$ : $[eqn]$

4. Problem Formalization

4.1. System Model

There are four types of roles in the system—data owners, data users, cloud server, and a trusted authority, as shown in Figure 1:

• Cloud Server. The cloud server possesses strong storage and computational capabilities: it receives and stores encrypted graph data uploaded by data owners, performs graph re-encryption and intersection operations, and finally it provides the results to the data user.
• Data Owner $[eqn]$ . Each data owner has a graph $[eqn]$ that participates in graph intersection computation. To ensure the confidentiality of the graph $[eqn]$ , they will encrypt $[eqn]$ before uploading it to the cloud server.
• Data User. A data user may query for the intersection of graphs from $[eqn]$ . In order to save storage and computational costs, they outsource the computational task to the cloud server, and finally obtains the encrypted result from the cloud server and decrypts it.
• Trusted Authority. As a trusted third party, the $[eqn]$ initializes the system with a security parameter $[eqn]$ , generates a set of public parameters $[eqn]$ . It is also responsible for generating re-encryption keys that enable the cloud server to convert the ciphertexts for them to be decryptable by the data user.

4.2. Threat Model

We consider $[eqn]$ and data owners to be trustworthy, data owners will honestly model their graph data and encrypt them. The cloud server is considered semi-honest, implying that it executes our protocol honestly, but it may try to infer sensitive information during computation such as the original and intersection graph, through methods such as statistics and analysis.

4.3. Security Goals

• Graph data confidentiality. Any information about original graphs except for information in leakage functions should not be obtainable by the cloud server or other adversaries; only the part in the intersection with graphs from other data owners can be learned by an authorized data user.
• Query result confidentiality. The graph intersection results in a ciphertext form that can only be decrypted by an authorized data user with their own key. It remains confidential from the cloud server, data owners, other data users, and adversaries.

4.4. Security Definition

We adopt the adaptive chosen query attack (CQA2) security definition in the graph intersection scheme, which is defined as follows:

Definition 2. (CQA2-Security). Let $[eqn]$ be our private graph intersection scheme, and let $[eqn]$ and $[eqn]$ be leakage functions. $[eqn]$ denotes the adversary, and $[eqn]$ denotes the simulator. Supposing λ is the security parameter, the experiments in the ideal world and real world are defined as follows:

• • $[eqn]$ : $[eqn]$ outputs graphs $[eqn]$ . The experiment generates a pair of keys $[eqn]$ by $[eqn]$ and generates the re-encryption key $[eqn]$ by $[eqn]$ . Then, $[eqn]$ makes queries for intersections of randomly chosen t graphs $[eqn]$ , for each query, and the experiment computes computes $[eqn]$ and sends the encrypted graphs $[eqn]$ to $[eqn]$ . It then compute the encrypted intersection graph $[eqn]$ $[eqn]$ $[eqn]$ and gives it to $[eqn]$ . At the end of the experiment, $[eqn]$ outputs a bit $[eqn]$ as the experiment result.*
• • $[eqn]$ : $[eqn]$ outputs graphs $[eqn]$ . Then, $[eqn]$ makes queries for intersections of randomly chosen t graphs $[eqn]$ . Based on leakage functions $[eqn]$ and $[eqn]$ , $[eqn]$ produces encrypted graphs $[eqn]$ and sends them to $[eqn]$ , then $[eqn]$ simulates and sends the query results $[eqn]$ to $[eqn]$ . At the end of the experiment, $[eqn]$ outputs a bit $[eqn]$ as the experiment result.*

We say the graph encryption scheme Π is $[eqn]$ -secure against the adaptive chosen query attack if for any probability polynomial time (PPT) adversary $[eqn]$ , there exists a PPT simulator $[eqn]$  that

$$[eqn]$$

where $[eqn]$ denotes a negligible function.

5. Construction of Our Scheme

We present our scheme for secure graph intersection computation, including the construction overview and concrete construction.

5.1. Construction Overview

Our scheme consists of the following six algorithms:

1. $[eqn]$ . The procedure $[eqn]$ is executed by the $[eqn]$ , the trusted third party, taking a secure parameter $[eqn]$ as input and producing a set of public parameters $[eqn]$ as output.
2. $[eqn]$ . Upon input of a security parameter $[eqn]$ and public parameter $[eqn]$ , we use this algorithm to generate a pair of public–private keys $[eqn]$ .
3. $[eqn]$ . Given the public parameter $[eqn]$ , $[eqn]$ ’s private key $[eqn]$ , and the public key $[eqn]$ of the data user $[eqn]$ , the algorithm outputs a re-encryption key $[eqn]$ that allows ciphertexts encrypted by data owners to be transformed into ciphertexts intended for the data user $[eqn]$ .
4. $[eqn]$ . It is the graph encryption algorithm executed by data owner $[eqn]$ ; taking the graph $[eqn]$ , public key of the $[eqn]$ , and $[eqn]$ as inputs, it outputs the encrypted graph $[eqn]$ .
5. $[eqn]$ . This algorithm takes public parameter $[eqn]$ , the re-encryption key $[eqn]$ , and ciphertexts $[eqn]$ uploaded by the data owner $[eqn]$ , and the cloud server performs re-encryption on $[eqn]$ , resulting in new ciphertexts $[eqn]$ . The cloud server calculates the graph intersections and outputs the encrypted result $[eqn]$ .
6. $[eqn]$ .Taking the inputs of private key $[eqn]$ and re-encrypted ciphertext $[eqn]$ , this algorithm returns the subgraph G.

5.2. Concrete Construction

The details of our secure graph intersection scheme is described in this section. We summarize the notations in our construction in Table 1.

5.2.1. Setup

Given the security parameter $[eqn]$ , $[eqn]$ completes the setup phase and generates the following public parameters: a bilinear map $[eqn]$ , where $[eqn]$ and $[eqn]$ are groups of prime order p, and generator $[eqn]$ , a collision-resistant hash function $[eqn]$ . The public parameters $[eqn]$ .

5.2.2. KeyGen

$[eqn]$ chooses the private key $[eqn]$ randomly from $[eqn]$ , and the public key is $[eqn]$ . Similarly, data user $[eqn]$ also generates their own public–private key pair $[eqn]$ , where $[eqn]$ .

5.2.3. ReKeyGen

When user $[eqn]$ initiates a query request, $[eqn]$ generates the re-encryption key for $[eqn]$ : $[eqn]$ .

5.2.4. Enc

Data owner $[eqn]$ models their graph as $[eqn]$ , $[eqn]$ is the vertex set, and each $[eqn]$ represents the unique ID value of a vertex. $[eqn]$ is the adjacency matrix, which can be represented as

$$[eqn]$$

where each element $[eqn]$ ( $[eqn]$ is a random number that $[eqn]$ ), $[eqn]$ indicates that there is an edge connecting nodes $[eqn]$ and $[eqn]$ , while $[eqn]$ indicates that there is no edge between the two nodes.

To ensure the confidentiality of the graph, $[eqn]$ performs the following operations on $[eqn]$ as shown in Algorithm 1.

• Vertices Hashing. $[eqn]$ performs a hash computation on the vertices set to obtain the corresponding hashed set $[eqn]$ .
• Graph Encryption. $[eqn]$ encrypts $[eqn]$ using proxy re-encryption (PRE). To elaborate in detail, given $[eqn]$ , adjacency matrix $[eqn]$ , $[eqn]$ . For each element $[eqn]$ , choose $[eqn]$ randomly from $[eqn]$ , compute $[eqn]$ , where $[eqn]$ . For each element $[eqn]$ , choose $[eqn]$ randomly from $[eqn]$ , and compute $[eqn]$ where $[eqn]$ . The encrypted graph is $[eqn]$ , where the encrypted vertices set $[eqn]$ , and the encrypted adjacency matrix

$$[eqn]$$

Algorithm 1 Enc.Input: public parameter $[eqn]$ , $[eqn]$ ’s graph $[eqn]$ , $[eqn]$ ’s public key $[eqn]$ .Output: encrypted graph $[eqn]$ .

• 1:for each element $[eqn]$  do
• 2:    $[eqn]$ .
• 3:    $[eqn]$ .
• 4:end for
• 5: $[eqn]$ .
• 6: $[eqn]$ .
• 7:for each element $[eqn]$  do
• 8:    $[eqn]$ .
• 9:end for
• 10:Set

$$[eqn]$$

• 11:return $[eqn]$ .

5.2.5. GraphIntersection

The GraphIntersection in Algorithm 2 works as follows: Algorithm 2 GraphIntersection.Input: public parameter $[eqn]$ , the re-encryption key $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ . Output:  $[eqn]$ .

• 1: $[eqn]$ .

• 2:Obtain the encrypted vertices set $[eqn]$ according to $[eqn]$ .

• 3:for each element $[eqn]$  do

• 4:    $[eqn]$ .

• 5:end for

• 6:The re-encrypted node set $[eqn]$ .

• 7:for each encrypted matrix $[eqn]$ , $[eqn]$  do

• 8:   Choose the elements $[eqn]$ in the encrypted matrix $[eqn]$ where $[eqn]$ and constructs the submatrix $[eqn]$

• 9:   for each element $[eqn]$  do

• 10:      $[eqn]$ .

• 11:   end for

• 12:   The re-encrypted matrix $[eqn]$

• 13:end for

• 14:Compute the element-wise product of re-encrypted matrices $[eqn]$ .

• 15:return  $[eqn]$ .

• Vertices Re-encryption. Given the hash sets $[eqn]$ , the cloud server computes their intersection. Denote the intersection by $[eqn]$ and the intersection of graph nodes as $[eqn]$ . The graph node corresponding to element $[eqn]$ actually has different ordinality in the original graphs. We denote the ordinality of the node of the original graph $[eqn]$ corresponding to $[eqn]$ by $[eqn]$ . There are t encrypted node sets, and since the t encrypted node sets can be decrypted to the same node intersection set, we only need to choose a random one to re-encrypt it, which can be written as $[eqn]$ . For each $[eqn]$ , we re-encrypt it using proxy re-encryption (PRE). Specifically, for $[eqn]$ , choose $[eqn]$ randomly from $[eqn]$ , and compute $[eqn]$ , with the re-encrypted $[eqn]$ . The cloud server can precompute $[eqn]$ for every node for the decryption phase. Finally, the cloud server obtains the re-encrypted vertices sets $[eqn]$ .

• Matrices Re-encryption. The cloud server continues to calculate the re-encrypted adjacency matrix. It chooses the elements $[eqn]$ in the encrypted matrix $[eqn]$ where $[eqn]$ and constructs the submatrix

$$[eqn]$$

For each $[eqn]$ , we re-encrypt it using proxy re-encryption (PRE). Specifically, for $[eqn]$ , we choose $[eqn]$ randomly from $[eqn]$ , and compute $[eqn]$ , with the re-encrypted $[eqn]$ . The cloud server can also precompute $[eqn]$ for every element for the decryption phase. Finally, the cloud server obtains the re-encrypted matrix

$$[eqn]$$

• Graph Intersection Computation. The cloud server then computes

$$[eqn]$$

At the end, the calculated result $[eqn]$ is sent to the querying user $[eqn]$ .

5.2.6. Dec

The $[eqn]$ shown in Algorithm 3 works as follows:

• Vertices Decryption. According to the graph re-encryption in Algorithm 2, the re-encrypted node set corresponding to the intersection set $[eqn]$ is $[eqn]$ , where $[eqn]$ . It can be obtained that $[eqn]$ . Finally, we obtain the set of intersections of vertices $[eqn]$ .
• Matrix Decryption. The edges set intersection $[eqn]$ can be decrypted with $[eqn]$ as follows:

$$[eqn]$$

Finally, the data user $[eqn]$ recovers the intersection of the graphs G by using V and E. Algorithm 3 Dec.Input:  $[eqn]$ , $[eqn]$ , $[eqn]$ .Output: G.

• 1:for  $[eqn]$   do
• 2:   Decrypt $[eqn]$ .
• 3:end for
• 4: $[eqn]$ .
• 5: $[eqn]$
• 6:return  $[eqn]$

6. Correctness and Security Analysis

6.1. Correctness Analysis

Theorem 1. If all follow the algorithms within the scheme, then the query user can obtain the correct graph intersection result.

Proof. We prove that the query user can obtain $[eqn]$ .When calculating graph intersection, the cloud server first acquires a set of common hash values $[eqn]$ . Since each value in the hash set $[eqn]$ corresponds uniquely to an element in the ciphertext set $[eqn]$ , the encrypted node subset can be correctly extracted from $[eqn]$ as $[eqn]$ . The cloud server then re-encrypts it to obtain the re-encrypted node set $[eqn]$ , which can be decrypted to obtain $[eqn]$ , to be specific, given $[eqn]$ and $[eqn]$ , $[eqn]$ .The cloud server constructs the submatrices, re-encrypts the elements in the matrices and performs the Hadamard product on these matrices to obtain

$$[eqn]$$

The data user decrypts to obtain the intersection matrix with their private key $[eqn]$

$$[eqn]$$

□

6.2. Security Analysis

This section conducts a comprehensive security evaluation of the proposed scheme. Our analysis unfolds in two key phases: initially formalizing the leakage functions, followed by a rigorous proof that the scheme is CQA-2 secure.

• Leakage function $[eqn]$ : Given a query $[eqn]$ , where $[eqn]$ , the leakage function $[eqn]$ reveals the information inferred from encrypted graphs $[eqn]$ and their encrypted intersection graph $[eqn]$ , including the vertex count of each individual graph and the vertex count of the graph intersection. Thus, $[eqn]$ where $[eqn]$ are formally described as follows:

• • $[eqn]$ . $[eqn]$ is is a t-sized array, where $[eqn]$ for $[eqn]$ .
• • $[eqn]$ . $[eqn]$ signifies the total vertices in the graph intersection which denoted as $[eqn]$ .

• Leakage function $[eqn]$ : The leakage function $[eqn]$ reveals information during multiple queries including query pattern leakage, which reveals whether a particular query has been issued previously, and intersection pattern leakage, which indicates the number of common vertices shared among different queries. Let $[eqn]$ be a sequence of graph intersection queries, where $[eqn]$ corresponds to a collection of graphs $[eqn]$ . They are formally stated as follows.

Definition 3. (Query pattern leakage). The query pattern leakage function $[eqn]$ is modeled as a $[eqn]$ matrix, where each entry $[eqn]$ signifies whether $[eqn]$ and $[eqn]$ are identical. We denote each entry $[eqn]$ as $[eqn]$ .

Definition 4. (Intersection pattern leakage). The intersection pattern leakage function $[eqn]$ is represented as a $[eqn]$ matrix, where each entry $[eqn]$ contains common hashes between graph intersections corresponding to queries $[eqn]$ and $[eqn]$ , denoted as $[eqn]$ . Since the hash function is deterministic, hash values have one-to-one correspondence with vertices, and $[eqn]$ indicates the common vertices between $[eqn]$ and $[eqn]$ without leaking their identities.

Thus, the leakage function $[eqn]$ .

Theorem **2.If H is a secure hash function and $[eqn]$ is a secure proxy re-encryption algorithm, then our graph encryption scheme Π is $[eqn]$ -secure against an adaptive chosen query attack.

Proof. To demonstrate the security of our scheme, we construct a simulator S. Based on $[eqn]$ , $[eqn]$ , $[eqn]$ generates counterfeit encrypted graphs $[eqn]$ as well as the encrypted graph intersection result $[eqn]$ for query $[eqn]$ . If for any probability polynomial time adversary $[eqn]$ , it cannot differentiate the two experiments $[eqn]$ and $[eqn]$ , then our scheme is considered to be secure.Simulating the encryption. Given $[eqn]$ and leakage functions $[eqn]$ and $[eqn]$ , $[eqn]$ first checks if $[eqn]$ has been previously encountered; if it has, $[eqn]$ provides the previous results. Otherwise, $[eqn]$ behaves as follows: it generates t graphs whose scales and vertices relationships satisfy the conditions in leakage functions $[eqn]$ and $[eqn]$ . Then, $[eqn]$ encrypts the t graphs using the hash function and proxy re-encryption algorithm to obtain the encrypted form of the t graphs, represented as $[eqn]$ , as well as t hash sets $[eqn]$ .Simulating the graph intersection computation. Given $[eqn]$ , $[eqn]$ first obtains the hash sets intersection $[eqn]$ and the encrypted vertices set intersection $[eqn]$ . Then, it generates the re-encryption key $[eqn]$ with a randomly chosen $[eqn]$ , and re-encrypts $[eqn]$ . Finally, $[eqn]$ constructs the submatrices from $[eqn]$ , re-encrypts them using $[eqn]$ , and multiplies the re-encrypted submatrices to obtain the encrypted intersection matrix $[eqn]$ .Since the hash function H and proxy re-encryption algorithm $[eqn]$ are secure, any PPT adversary $[eqn]$ cannot distinguish the fake encrypted graphs $[eqn]$ , the fake hash sets $[eqn]$ , and fake encrypted intersection matrix $[eqn]$ from real ones, i.e., $[eqn]$ cannot distinguish between experiments in the ideal world and those in the real world. Thus, we have

$$[eqn]$$

where $[eqn]$ is a negligible function.Therefore, our scheme is $[eqn]$ -secure against an adaptive chosen query attack. □

7. Performance Analysis

In Table 2, we evaluate our scheme in comparison with related works across several dimensions including cryptographic primitives, privacy, cloud-assisted computation, multi-owners and multi-users. Scheme [16] computes the graph intersection of two parties. In scheme [17], multiple parties are able to collaboratively calculate the intersection of their graphs. Instead of outsourcing their graphs to a cloud server, they perform secure multi-party computation directly among the participants. Zuo et al. [15] enabled the cloud server to compute the graph intersection of multiple data owners for a single user. However, none of them support multi-users to query for graph intersection with cloud assisted computations.

7.1. Theoretical Analysis

In Table 3, we show the computational complexity of each phase including $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , and $[eqn]$ . The complexity analysis is denoted by the following operations: the exponentiation E in $[eqn]$ , the exponentiation $[eqn]$ in $[eqn]$ , the bilinear pairing e, and multiplication in $[eqn]$ . We consider t data owners; the intersection graph of them has s nodes. n indicates that the graph encrypted has n nodes. $[eqn]$ is the size of a group element in $[eqn]$ , and $[eqn]$ is the size of a group element in $[eqn]$ .

In the phase of $[eqn]$ and $[eqn]$ , it needs one exponentiation in $[eqn]$ ; the key size is 1 group element in $[eqn]$ . In the $[eqn]$ phase, to encrypt a graph with n nodes, we need to compute n hashes. For each of the n nodes and $[eqn]$ elements in the matrix, we need to compute one exponentiation in $[eqn]$ , one exponentiation in $[eqn]$ , one pairing e, and one multiplication M in $[eqn]$ , resulting in $[eqn]$ operations. In the $[eqn]$ phase, the vertex set intersection and the submatrices totally contain $[eqn]$ elements, and each element re-encryption requires $[eqn]$ operations. Combining with $[eqn]$ operations during the multiplication of matrices, totally $[eqn]$ is needed. During the $[eqn]$ phase, a data user needs to decrypt the set of node intersection of size s and the matrix of size $[eqn]$ . Each of these elements requires $[eqn]$ to decrypt, so the complexity is $[eqn]$ .

7.2. Experiments

In this section, we analyze the performance of our scheme through a series of experiments.

7.2.1. Experimental Setting

We perform the experiments on an Ubuntu 22.04 operating system in the VMware Workstation on a PC with an i9-13900H CPU and 16 GB RAM. We implement the scheme using Go programming language based on the PBC library for Go [37]. We adopt the type A pairing which generates a pairing on the curve $[eqn]$ over the field $[eqn]$ . In our experiment setting, the large prime q is 512 bits, and the group order of $[eqn]$ is set to 160 bits. We instantiate hash function H with SHA-256. Table 4 shows the execution time of basic operations using for 100 times. We evaluate the performance using real-world graph data LastFM Asia social network [38]. The LastFM Asia social network is an undirected graph with 7627 nodes and 27,806 edges. We randomly choose subgraphs as graph data for data owners while controlling the number of common vertices among them to ensure the intersections are not empty.

7.2.2. Experimental Results

We demonstrate the experimental results in Figure 3.

Figure 3a shows the encryption time for graphs of different size at the data owner. Since we perform the encryption for each node and each element in the adjacency matrix, the encryption time grows with the size of the graph. As we can see, with the vertex count of the graph varying from 200 to 1200, the encryption time increases from 29.62 s to 1040.72 s. Since each data owner is required to encrypt their graph only once, the encryption time is acceptable in practice.

In Figure 3b, we show the computational cost at the cloud server. The computation time is influenced by the amount of data owners and the graph intersection size. As shown in the theoretical analysis, the cloud server needs to perform, in total, $[eqn]$ operations with t data owners and s vertices in the graph intersection. We simulate this phase with data owners ranging from 100 to 500 and the vertex count in the graph intersection ranging between 20 and 80. Simulations show that the workload of the cloud server is heavy such that the computation cost rises as both the amount of the data owners and the graph intersection size increase, for example, it takes 5,143,852 s to compute the graph intersection of 500 data users with 80 common vertices. Specifically, the size of the graph intersection plays a more dominant role in determining the computation time compared to the amount of data owners.

As depicted in Figure 3c, the decryption of the data user is time saving. The decryption time is related to the size of graph intersection, and the data user only needs to perform less-time-consuming operations including exponents and multiplications in $[eqn]$ . As we can see, the time of decrypting graph intersection with 20 vertices is 115.35 ms, and that with 100 vertices is 2.93 s.

8. Conclusions

In this paper, we introduce a privacy-preserving multi-user graph intersection scheme in the cloud-assisted IoT environment, realizing the privacy-preserving graph intersection computation. It supports multiple data users to query for the intersection of graphs of multiple data owners. We prove our scheme is secure under reasonable assumptions. The performance assessment and experimental validation on real-world graph data confirm the efficiency and practicality of our scheme. In the future, we will explore how to realize the privacy-preserving graph intersection query against malicious cloud servers and consider further improving the efficiency to make the scheme applicable to larger-scale graph data.