GraphSE$^2$: An Encrypted Graph Database for Privacy-Preserving Social Search

TL;DR

GraphSE$^2$ is an encrypted graph database designed for privacy-preserving social search, enabling secure, scalable, and efficient queries on large social graphs while protecting user data.

Contribution

It introduces an encrypted structural data model and query decomposition techniques for scalable, privacy-preserving social search in large-scale social networks.

Findings

Supports social search queries on a million-user graph

Achieves efficient parallel encrypted graph data access

Demonstrates practicality on Azure Cloud with extensive evaluations

Abstract

In this paper, we propose GraphSE$^2$, an encrypted graph database for online social network services to address massive data breaches. GraphSE$^2$ preserves the functionality of social search, a key enabler for quality social network services, where social search queries are conducted on a large-scale social graph and meanwhile perform set and computational operations on user-generated contents. To enable efficient privacy-preserving social search, GraphSE$^2$ provides an encrypted structural data model to facilitate parallel and encrypted graph data access. It is also designed to decompose complex social search queries into atomic operations and realise them via interchangeable protocols in a fast and scalable manner. We build GraphSE$^2$ with various queries supported in the Facebook graph search engine and implement a full-fledged prototype. Extensive evaluations on Azure Cloud demonstrate that GraphSE$^2$ is practical for querying a social graph with a million of users.

Tables

Table 1. Table 1. Supported social search operators in GraphSE 2  and its essential atom operations.

Query operator	Example(from (Curtiss et al., 2013))	Atomic operations
		Index Access	Set Operations	Arithmetic	Sorting
term	(term friend:1)	$\surd$			$\surd$
and	(and friend:1 friend:2)	$\surd$	$\surd$		$\surd$
or	(or friend:1 friend:2)	$\surd$	$\surd$		$\surd$
difference	(difference friend:3 (and friend:1 friend:2))	$\surd$	$\surd$		$\surd$
apply	(apply friend: friend:1)	$\surd$	$\surd$	$\surd$	$\surd$

Table 2. Table 2. Notations and Terminologies

Notation	Meaning
$\mathrm{𝐢𝐝}$	the unique identifier of entity
$e_{\mathrm{𝐢𝐝}}$	the encrypted entity $\mathrm{𝐢𝐝}$
$t$	an indexing term in the form of $\text{edge-type}\text{:}{\mathrm{𝐢𝐝}}_{𝗎}$
$\mathrm{DB}$	an inverted indexed database $\left\{(t,\left\{(\text{sort-key},\mathrm{𝐢𝐝})\right\})\right\}$
$\mathrm{DB}\left(t\right)$	a list of $\left\{(\text{sort-key},\mathrm{𝐢𝐝})\right\}$ indexed by $t$
$\left\{𝐄\right\}$	the encrypted posting list with $({⟨\text{sort-key}⟩}^A,e_{\mathrm{𝐢𝐝}})$ pairs
$P_i$	the $i$-th party in GraphSE2 ($i\in \{0,1\}$)
$x$	a numerical value
$𝐗$	a matrix
${⟨x⟩}_i^{\ast }$	the Additive/Yao’s share of a numerical value $x$ in $P_i$
${⟨𝐗⟩}_i^{\ast }$	the Additive/Yao’s share of a matrix $𝐗$ in $P_i$
$𝒢𝒞$	a garbling scheme

Table 3. Table 3. Performance estimation of Friend Recommendation implementations with 1 million users.

	friends-of-friends	apply
Est. # of users/posting list	$130$	$48$k
Est. Storage overhead	$7.28$GB	$2.4$TB
Query delay	$200$ s	$1\text{-}2$ s

Table 4. Table 4. Statistics of Youtube social network dataset.

Node type	# of nodes	Edge type	# of edges
User	$1157827$	friend	$4945382$
Group	$30087$	follow	$293360$

Table 5. Table 5. Benchmark of sorting circuit size and evaluation time, the garbled sorting algorithm is bitonic merging/sorting, we use it to sort 2 l superscript 2 𝑙 2^{l} vector.

Vector length	2	4	8	16	32	64	128
# of AND Gates	4382	9148	19448	41968	91616	201664	446336
GC evaluation time (ms)	17.3	20.3	31.5	48.2	101.0	206.5	440.0
GC comm. overhead (MB)	0.12	0.41	0.46	0.97	2.10	4.49	9.80

Table 6. Table 6. Throughput (Queries/sec) comparison of global sorting for query with different operators.

Operators	term	and/diff.	or
Baseline	$350$	$321$	$301$
Our system	$80$	$80$	$80$

Equations

$$|\mathrm{Pr}[\mathcal{D}({\mathcal{X}}_i)=1]-\mathrm{Pr}[\mathcal{D}({\mathcal{Y}}_i)=1]|\le \mathsf{negl}(\lambda )$$

Full text

Social Search, Graph Database, Encrypted Query Processing

††journalyear: 2019††copyright: acmcopyright††conference: ACM Asia Conference on Computer and Communications Security; July 9–12, 2019; Auckland, New Zealand††booktitle: ACM Asia Conference on Computer and Communications Security (AsiaCCS ’19), July 9–12, 2019, Auckland, New Zealand††price: 15.00††doi: 10.1145/3321705.3329803††isbn: 978-1-4503-6752-3/19/07††ccs: Security and privacy Management and querying of encrypted data††ccs: Security and privacy Social network security and privacy††ccs: Security and privacy Privacy-preserving protocols

1. Introduction

Data breaches in online social networks (OSNs) affect billions of individuals and raise critical privacy concerns across the entire society (Liang et al., 2015; Information is Beautiful, 2018). Besides, driven by the demands on huge storage and computation resources, OSN service providers utilise public commercial clouds as their back-end data storage (AWS, 2018a, b; Engineering, 2018), which further broadens the attack plane (Ren et al., 2012). Therefore, there is an urgent call to improve the control of data confidentiality for cloud providers (Yang et al., 2016; Liu et al., 2016; Li et al., 2016), in particular for current OSN services. The prevailing consensus to prevent data leakage is encryption. However, this approach impairs the functionality of social search, a key enabler for quality OSN services (Sullivan, 2012). Social search allows users to search content of interests created by their friends. Compared with traditional web search, it produces personalised search results and serves for a wide range of OSN services such as friend discovering and user targeting.

The first task to enable privacy-preserving social search is how to scalably query over very large encrypted social graphs. On the one hand, a typical social graph can contain millions or even billions of users. On the other hand, users may generate large volume of contents which will be queried for social search related services (Curtiss et al., 2013). The second and more challenging task is how to realise complex social search queries in an efficient and secure manner. As developed in plaintext systems (e.g., Facebook’s Unicorn (Curtiss et al., 2013)), queries of social search contains set operations on graph-structured data, and the retrieved contents from the graph need to further be analysed (e.g., aggregation and sorting) for advanced services such as friendship-based recommendation.

In the literature, some work (Nayak et al., 2015; Blanton et al., 2013) leverages generic building blocks (e.g., garbled circuits and oblivious data structures) to devise secure computational frameworks for graph algorithms. However, those frameworks do not appear to be scalable for low latency queries over large graphs. For example, a recent garbled circuits based framework (Nayak et al., 2015) takes several minutes to complete a sorting algorithm over a graph with only tens of thousands of nodes. Other work focuses on dedicated privacy-preserving graph algorithms, e.g., neighbour search (Chase and Kamara, 2010; Kamara et al., 2018), and shortest distance queries (Xie et al., 2016; Meng et al., 2015; Wu et al., 2016; Wang et al., 2017). Unfortunately, the above algorithms are limited for or different from the functionality of social search queries.

Contributions. To bridge the gap, in this paper, we propose and implement GraphSE2, the first encrypted graph database that supports privacy-preserving social search. Unlike prior work which either suffers from low scalability or limited functionality, GraphSE2 enables scalable queries over very large encrypted social graphs, and preserves the rich functionality of the plaintext social search systems. Our contributions can be summarised as follows:

• •

We propose an encrypted and distributed graph model built on social graph modelling, searchable encryption, and the data partition technique. It facilitates queries over encrypted graph partitions in parallel, and maintains the locality of graph data and user-generated contents for low query latency.

• •

We devise mixed yet interchangeable protocols to enable complex social search functions. The way of doing this is to decompose queries into atomic operations (i.e., set, arithmetic, and sorting operations) and then adapt suitable cryptographic primitives for efficient realisation. All these operations are tailored to be executed in parallel.

• •

We realise query operators of the Facebook’s social search system Unicorn (Curtiss et al., 2013), i.e., term, and, or, difference, and apply. We also design a query planner that can parse a query to atomic operations and initiate the corresponding primitives.

• •

We formally prove the security of our proposed query protocols under the real and ideal paradigm. Queries, graph data, and results are protected throughout the query process.

• •

We show the practicality of GraphSE2 by implementing a prototype which is readily deployable. It leverages Spark (Zaharia et al., 2010) for setup (data partition and encryption), Redis (Redis Labs, 2017) as the storage back-end, and uses Apache Thrift (Slee et al., 2007) to implement the query planner and query processing logic.

Our comprehensive evaluation on the Youtube dataset (Mislove et al., 2007) with 1 million nodes confirms that all atomic operations are of practical performance. For set queries, GraphSE2 retrieves a content list with $500$ entities within $10$ ms. For an average user ($130$ friends), GraphSE2 takes at most $20$ ms if the set operation involves two indexing terms (attributes); and it takes no more than $100$ ms for five indexing terms. Regarding the computational operations, GraphSE2 takes $100$ ms to handle arithmetic computations over $10^{4}$ entities, and $450$ ms to sort $128$ entities. As a summary, most of the queries for an average user are processed within $1$ s, and throughput is reduced at most $49\%$ compared to the plaintext queries.

Organisation. The rest of this paper is structured as follows. We discuss related work in Section 2. After that, we describe the system overview in Section 4, and present the encrypted and distributed graph data model and the design of atomic operations in Section 5. In Section 6, we introduce the realisation of privacy-preserving social search queries and their security. Next, we describe our prototype implementation in Section 7, and evaluate the performance in Section 8. We give a conclusion in Section 9.

2. Related Work

Privacy-preserving graph query processing. There exist various designs that aim to answer a certain type of queries over the encrypted graph. Structured encryption (Chase and Kamara, 2010) is proposed in the framework of SSE and supports adjacency and neighbouring queries. Some recent work is proposed to support privacy-preserving subgraph queries (Cao et al., 2011; Chang et al., 2016). However, all the above designs enable limited query functionality. Another line of work on privacy-preserving graph processing is to perform shortest-path queries over the encrypted graph. Protocols for this type of queries are devised via oblivious RAM (Xie et al., 2016), structured encryption (Meng et al., 2015), or Garbled Circuit (Wu et al., 2016; Wang et al., 2017). To implement more complicated algorithms, protocols are proposed to use secret sharing and homomorphic encryption for Breadth-first search (BFS) (Blanton et al., 2013), PageRank (Xie and Xing, 2014), and approximate eigen-decomposition (Sharma et al., 2018). We stress that the above work targets on different query functionality other than social search. Note that a recent framework named GarphSC (Nayak et al., 2015) can generate data-oblivious Garbled Circuit (GC) for graph algorithms such as PageRank and Matrix Factorisation. Because oblivious data structures are adapted for large graphs and all computations are realised via GC, it does not appear to achieve low latency for social search queries.

Encrypted database system. Our system is also related to encrypted database systems (Popa et al., 2011; Pappas et al., 2014; Poddar et al., 2016; Papadimitriou et al., 2016; Yuan et al., 2017). CryptDB (Popa et al., 2011) is the first practical encrypted database system, which is built on property-preserving encryption (PPE). It supports SQL queries over encrypted relational data records. BlindSeer (Pappas et al., 2014) proposes a Bloom Filter based index and leverages GC to evaluate arbitrary boolean queries with keywords and ranges. Arx (Poddar et al., 2016) follows the design of CryptDB to support SQL queries, but it uses SSE and GC to reduce the leakage from PPE. Seabed (Papadimitriou et al., 2016) uses additively symmetric homomorphic encryption (ASHE) to perform efficient aggregation over the encrypted data, and develops a schema with padding to mitigate the inference attack (Naveed et al., 2015). EncKV (Yuan et al., 2017) adapts SSE and ORE schemes to design an encrypted and distributed key-value store. However, all the encrypted databases mentioned above are neither designed for graph data nor optimised for social search.

Graph processing system. In the plaintext domain, a large number of graph processing systems (Low et al., 2012; Curtiss et al., 2013; Chi et al., 2016) (just to list a few) are proposed to support efficient large graph processing. However, all the above systems only support queries over the graphs in unencrypted form, which are unable to address privacy concerns of sensitive data leakage. Authenticated graph query (Goodrich et al., 2011) is proposed to verify the correctness of graph queries, which could be a complementary work to prevent attacks from malicious adversaries.

3. Background

3.1. Social Graph Model

The social graph consists of nodes (aka entities) and edges (aka relationships of entities) in social networks. As the social graph is a sparse graph (Curtiss et al., 2013), it is normally represented via a set of adjacency lists. Like (Curtiss et al., 2013), we refer to these adjacency lists as posting lists.

Formally, the social graph is an edge-labeled and directed graph $G=(\mathrm{V},\mathrm{E})$, where $\mathrm{V}=\{\mathrm{v}_{1},\mathrm{v}_{2},...\}$ is the entity set and $\mathrm{E}=\{\mathrm{e}_{1},\mathrm{e}_{2},...\}$ is the relationship set. Each posting list contains a list of entities $\{\mathbf{v}\}$, which are (sort-key, $\mathbf{id}$) pairs. The sort-key is an integer that indicates the importance of the entity in a posting list, and the $\mathbf{id}$ is its unique identifier.

The posting lists are indexed by the inverted index, and modelled by the edges in social graph: All edges in $G$ can be represented as a triad $\mathrm{e}=(\mathsf{u},\mathsf{v},\textbf{edge-type})$ which consists of its egress, ingress nodes ($\mathsf{u},\mathsf{v}\in\mathrm{V}$) plus an edge-type which is a string representing the relationship between nodes (e.g., friend, like). The inverted indexing term $t$ is in the form of $\textbf{edge-type}\textbf{:}\mathbf{id}_{\mathsf{u}}$. For example, the user may use $\textbf{friend:}{\mathbf{id}}_{i}$ to get the posting list of user $i$’s friends.

3.2. Oblivious Cross-Tags ($\mathrm{OXT}$) Protocol

Oblivious Cross-Tags ($\mathrm{OXT}$) Protocol (Cash et al., 2013) is an SSE protocol, which proceeds between client $\mathit{C}$ and server $\mathit{S}$. It provides an efficient way to perform conjunctive queries in encrypted database111The scheme proposed in (Kamara and Moataz, 2017) supports disjunctive queries, but it consumes large storage space.. Here we provide a high-level description as needed for the basic operations of our proposed system.

The protocol has two types of data structures. Firstly, for every keyword $w$, an inverted index, referred as ‘$\mathrm{TSet}(w)$’, is built to point to the set $\mathrm{DB}(w)$ of all entity identifiers $\mathbf{id}$s associating with $w$. Each $\mathrm{TSet}(w)$ is identified by an indexing term called $\mathbf{stag}(w)$, and all $\mathbf{id}$ values in $\mathrm{TSet}(w)$ are encrypted via a secret key $K_{w}$. Both $\mathbf{stag}(w)$ and $K_{w}$ are computed as a $\mathrm{PRF}$ applied to $w$ with $\mathit{C}$’s secret keys. Another data structure called ‘$\mathrm{XSet}$’ is built to hold a list of hash values $h(\mathbf{id},w)$ (called ’$\mathbf{xtag}$’) over all entity identities $\mathbf{id}$ and keywords $w$ contained in $\mathbf{id}$, where $h$ is a certain (public) cryptographic hash function. The above two data structures are stored on the server-side.

To search a conjunctive query $(w_{1},w_{2},...,w_{n})$ with $n$ keywords, $\mathit{C}$ sends the ‘search token’ $\mathbf{stag}(w_{1})$ related to $w_{1}$ (called ‘s-term’, we assume it to be $w_{1}$ in the above query) to $\mathit{S}$, which allows the server to run $\mathrm{TSet.Retrieve}(\mathrm{TSet},\mathbf{stag}(w_{1}))$ and retrieve $\mathrm{TSet}(w_{1})$ from the $\mathrm{TSet}$. In addition, $\mathit{C}$ sends ‘intersection tokens’ $\mathbf{xtoken}(w_{1},w_{i})$ (called ‘xtraps’) related to the $n-1$ keyword pairs $(w_{1},w_{i})$ consisting of the ‘s-term’ paired with each of the remaining query keywords $w_{i}$, $2\leq i\leq n$ (called ‘x-terms’). The xtraps allow the server to evaluate the cryptographic hash function of pairs $(\mathbf{id},w_{i})$ without knowing either keyword $w_{i}$ or $\mathbf{id}$. $\mathrm{S}$ checks the existence of $h(\mathbf{id},w_{i})$ in $\mathrm{XSet}$ and filters the $\mathrm{TSet}(w_{1})$ to $n-1$ subsets of entities that contain the pairs $(w_{1},w_{i})$. It only returns the entities that contain all $\{w_{i}\}_{1\leq i\leq n}$ to the client. $\mathit{C}$ finally uses $K_{w}$ to recover the $\mathbf{id}$s of entities.

As mentioned in  (Cash et al., 2013), the security of $\mathrm{OXT}$ parameterised by a leakage function $\mathcal{L}_{OXT}=(N,\mathrm{\phi},\bar{s},\mathrm{SP},\mathrm{XP},\mathrm{RP},\mathrm{IP})$. It depicts what an adversary is allowed to learn about the database and queries via executing $\mathrm{OXT}$ protocol. Informally, considering a vector of queries $\mathsf{q}=(\mathsf{s}\wedge\mathsf{\phi}(\mathsf{x}_{2},...,\mathsf{x}_{n}))$, which consists of a vector of s-terms $\mathsf{s}$, a vector of boolean formulas $\mathsf{\phi}$, and a sequence of x-term vectors $\mathsf{x}_{2},...,\mathsf{x}_{n}$. After executing $\mathsf{q}$ in a chosen database $\mathrm{DB}$, the adversary only can learn:

• •

$N$: The total number of $(\mathbf{id},w)$ pairs.

• •

$\mathsf{\phi}$: The boolean formulae that the client wishes to query.

• •

$\bar{s}$: The repeat pattern in $\mathsf{s}$.

• •

$\mathrm{SP}$: The size of posting lists for $\mathsf{s}$.

• •

$\mathrm{XP}$: The number of x-terms for each query.

• •

$\mathrm{RP}$: The set of result $\mathbf{id}$ matching each pair of (s-term, x-term)-conjunction which is in the form $(\mathsf{s},\mathsf{x}_{i}),2\leq i\leq n$.

• •

$\mathrm{IP}$: The set of result $\mathbf{id}$ both existing in the posting lists of $\mathsf{s}[i]$ and $\mathsf{s}[j]$, which is only revealed when two queries $\mathsf{q}[i],\mathsf{q}[j],i\neq j$ have different s-terms but same x-terms.

3.3. Secure Computation

Additive Sharing and Multiplication Triplets. To additively share ($Shr^{A}(\cdot)$) an $\ell$-bit value $a$, the first party $\mathit{P}_{0}$ generates $a_{0}\in\mathbb{Z}_{2^{l}}$ uniformly at random and sends $a_{1}=a-a_{0}\mod 2^{l}$ to the second party $\mathit{P}_{1}$. The first party’s share is denoted by $\langle a\rangle_{0}^{A}=a_{0}$ and the second party’s is $\langle a\rangle_{1}^{A}=a_{1}$, the modulo operation is omitted in the description later. To reconstruct ($Rec^{A}(\cdot,\cdot)$) an additively shared value $\langle a\rangle^{A}$ in $\mathit{P}_{i}$, $\mathit{P}_{1-i}$ sends $\langle a\rangle_{i}^{A}$ to $\mathit{P}_{i}$ who computes $\langle a\rangle_{0}^{A}+\langle a\rangle_{1}^{A}$. Given two shared values $\langle a\rangle^{A}$ and $\langle b\rangle^{A}$, Addition ($Add^{A}(\cdot,\cdot)$) is easily performed non-interactively. In detail, $\mathit{P}_{i}$ locally computes $\langle c\rangle_{i}^{A}=\langle a\rangle_{i}^{A}+\langle b\rangle_{i}^{A}$, which also can be denoted by $\langle c\rangle^{A}=\langle a\rangle^{A}+\langle b\rangle^{A}$. To multiply ($Mul^{A}(\cdot,\cdot)$) two shared values $\langle a\rangle^{A}$ and $\langle b\rangle^{A}$, we leverage Beaver’s multiplication triplets technique (Beaver, 1991). Assuming that the two parties have already precomputed and shared $\langle x\rangle^{A}$, $\langle y\rangle^{A}$ and $\langle z\rangle^{A}$, where $x,y$ are uniformly random values in $\mathbb{Z}_{2^{l}}$, and $z=xy\mod 2^{l}$. Then, $\mathit{P}_{i}$ computes $\langle e\rangle_{i}^{A}=\langle a\rangle_{i}^{A}-\langle x\rangle_{i}^{A}$ and $\langle f\rangle_{i}^{A}=\langle b\rangle_{i}^{A}-\langle y\rangle_{i}^{A}$. Both parties run $Rec^{A}(\langle e\rangle_{0}^{A},\langle e\rangle_{1}^{A})$ and $Rec^{A}(\langle f\rangle_{0}^{A},\langle f\rangle_{1}^{A})$ to get $e,f$, and $\mathit{P}_{i}$ lets $\langle c\rangle_{i}^{A}=i\cdot e\cdot f+f\cdot\langle x\rangle_{i}^{A}+e\cdot\langle y\rangle_{i}^{A}+\langle z\rangle_{i}^{A}$.

Garbled Circuit and Yao’s Sharing Yao’s Garbled Circuit (GC) is first introduced in (Yao, 1982), and its security model has been formalised in (Bellare et al., 2012). GC is a generic tool to support secure two-party computation. The protocol is run between a “garbler” with a private input $x$ and an “evaluator” with its private input $y$. The above two parties wish to securely evaluate a function $f(x,y)$. At the end of the protocol, both parties learn the value of $z=f(x,y)$ but no party learns more than what is revealed from this output value. In details, the garbler runs a garbling algorithm $\mathcal{GC}$ to generate a garbled circuit $F$ and a decoding table $dec$ for function $f$. The garbler also encodes its input $x$ to $\hat{x}$ and sends it to the evaluator. The evaluator runs an oblivious transfer (OT) (Asharov et al., 2013) protocol with the garbler to acquire its encoded input $\hat{y}$. Finally, the evaluator can compute $\hat{z}$ from $F,\hat{x},\hat{y}$, decode it with $dec$, and share the result $z$ with the garbler. The security proof against a semi-honest adversary under two-party setting is given in (Lindell and Pinkas, 2009).

In the following parts, we assume that $\mathit{P}_{0}$ is the garbler and $\mathit{P}_{1}$ is the evaluator. GC can be considered as a protocol which takes as inputs the Yao’s shares and produces the Yao’s shares of outputs. In particular, the Yao’s shares of 1-bit value $a$ is denoted as $\langle a\rangle_{0}^{Y}=\{K_{0},K_{1}\}$ and $\langle a\rangle_{1}^{Y}=K_{a}$, where $K_{0},K_{1}$ are the labels representing [math] and $1$, respectively. The evaluator uses its shares to evaluate the circuit and gets the output shares (another labels).

Additive shares can be switched to Yao’s shares efficiently. To be more precise, two parties secretly share their additive shares $a_{0}=\langle a\rangle_{0}^{A}$, $a_{1}=\langle a\rangle_{1}^{A}$ in bitwise via Yao’s sharing. The evaluator then receives $\langle a_{0}\rangle^{Y}$ and $\langle a_{1}\rangle^{Y}$ and evaluates the circuit $\langle a_{0}\rangle^{Y}+\langle a_{1}\rangle^{Y}\mod\langle 2^{l}\rangle^{Y}$ to get the label of $a$.

4. System Overview

4.1. System Architecture

As shown in Figure 1, GraphSE2 has two entities: the on-premise social search service front-end ($\mathcal{SF}$) and the index server cluster ($\mathcal{ISC}$) with several index servers ($\mathcal{IS}$s) in an untrusted cloud. Note that this setting is consistent with many off-the-shelf social network service providers such as Airbnb (AWS, 2018a) and Instagram (Engineering, 2018), who use cloud data storage as the back-end to manage large graphs and massive user-generated data contents. Also, such architecture is now natively supported by public clouds, e.g., AWS Outposts (AWS, 2018c). GraphSE2 aims to improve the protection of data confidentiality at the back-end, which is usually the high-value target for adversaries in practice.

During the setup phase, $\mathcal{SF}$ partitions the social graph to disjoint subgraphs and builds two instances of SSE indexes of each subgraph for the queries on structured information. The generated indexes are uploaded to two non-colluded $\mathcal{ISC}$s with multiple $\mathcal{IS}$s respectively. The sort-keys are co-located with the corresponding indexes in the form of additive shares on the above two $\mathcal{ISC}$s for the arithmetic operations and sorting. Specifically, each $\mathcal{IS}$ has one of the two additive shares, and it pairs with a counter-party in the other cluster, which maintains the same index but holds the other share. Upon receiving a query from its users, $\mathcal{SF}$ uses a query planner to parse the query into atomic operations (see Section 5.3) to generate a query plan. It then sends the query tokens of atomic operations to all $\mathcal{IS}$s to execute the query plan. After that, each $\mathcal{IS}$ requests the structured information via the tokens. Based on the matched encrypted contents, it executes arithmetic operations and scoring/ranking algorithms with its counter-party. Finally, the encrypted result is returned to $\mathcal{SF}$.

In this architecture, we consider a scenario of secure computation sourcing where the in-house $\mathcal{SF}$ assigns the computation to the $\mathcal{IS}$s in two untrusted but non-colluding clusters $\mathcal{ISC}_{0}$ and $\mathcal{ISC}_{1}$. Such a model of secure multi-party computation is formalised in (Kamara et al., 2011) and applied in many existing studies (Nikolaenko et al., 2013; Baldimtsi and Ohrimenko, 2015; Mohassel and Zhang, 2017). Built on this model, GraphSE2 offers two advantages: (i) $\mathcal{SF}$ is not required to be involved with any computation after it distributes the data to the servers, and (ii) the computation process can benefit from the mixture of multi-party computation protocols that enable efficient arithmetic operation, comparison, and sorting at the same time. Note that the communication between $\mathcal{IS}$s will not be the system bottleneck, because $\mathcal{IS}$s can be deployed in cloud clusters with dedicated datacenter networking support. This is consistent with prior studies based on the same architecture (Mohassel and Zhang, 2017).

4.2. High-level Description

Before introducing the details of our system, we elaborate on the design overview and underlying design intuitions. To query large social graphs, GraphSE2 develops an encrypted and distributed graph model. It is built on graph modelling, searchable encryption, and the standard data partition algorithm. Each server evenly stores an encrypted disjoint part of the whole graph. Meanwhile, this model is designed to co-locate the encrypted contents with the disjoint part containing the users who generate or relate to the contents. As a result, GraphSE2 not only maximises the system scalability but also preserves data locality for low query latency.

To facilitate the realisation of various social search queries in the encrypted domain, GraphSE2 first splits these complex queries into two stages, i.e., content search over the structured social graph and computational operations on the retrieved contents. Within the above stages, queries are further decomposed into atomic operations, i.e., Index Access, Set Operations, Arithmetic operations, and Sorting. Since the first stage commonly performs set operations over the social graph, GraphSE2 realises our proposed graph model via a well-known searchable encryption scheme for boolean queries (aka OXT (Cash et al., 2013)). The second stage requires a combination of different computations to further analyse user contents. For example, collaborative filtering (Breese et al., 1998) first obtains the scores of user contents via several addition and multiplication operations and then sorts the scores for an accurate recommendation.

To accelerate sophisticated computations in the second stage, GraphSE2 mixes different secure computation protocols. Note that such philosophy also appears in recent privacy-preserving computation applications (Demmler et al., 2015; Mohassel and Zhang, 2017). Unlike prior work, GraphSE2 customises the mixed protocols for social search queries and adapts them to our distributed graph model. In particular, GraphSE2 represents the importance (score) of user-generated contents as the additive shares and deploys two distributed $\mathrm{OXT}$ instances at two non-colluded server clusters to store both the graph partitions and corresponding shares respectively. Doing so allows GraphSE2 to support parallel and batch addition and multiplication without the interaction between servers222Multiplication involves a round of interaction between two servers, but they are in the same partition of two clusters.. To achieve fast sorting, GraphSE2 first converts additive shares to Yao’s shares inside garbled circuits (GC) and then invokes a tailored distributed sorting protocol via GC. Each pair of servers in two clusters can perform local sorting in parallel, and then the intermediate results are aggregated for global sorting. Within the protocol, the underlying scores are hidden against servers from either of the two parties.

4.3. Threat Assumptions

In this work, we assume that $\mathcal{SF}$ is a private server dedicatedly maintained by the OSN service provider. It is a trustworthy party in the proposed model. Similar to the real-world OSN service provider (e.g. Airbnb), all users should submit their queries to $\mathcal{SF}$ through webpages or mobile apps. We assume that $\mathcal{SF}$ utilises the secure channel and cryptographic techniques to protect users’ secrets. On the other hand, we assume that all $\mathcal{IS}$s are located in the untrusted domain. Meanwhile, we consider that the two clusters are semi-honest but not colluding parties. Each cluster performs social search faithfully but intends to learn additional information such as query terms, result $\mathbf{id}$s and ranking values from the graph. Besides, those clusters hold user data and perform query functions, and thus they are high-value targets of adversaries. We assume that the two clusters can be compromised by two different passive adversaries, but the two adversaries will not collude. GraphSE2 aims to protect the confidentiality of the private information in the social graph when the data storage back-end of the social search service is deployed at an untrusted domain.

4.4. Query Operators

GraphSE2 follows a typical plaintext social search system (Curtiss et al., 2013) to define the operators (see Table 1).

In general, all operators in GraphSE2 aim to retrieve posting lists from the encrypted graph index. The simplest form of these operators is term, which retrieves a single posting list via an Index Access operation. Like the other social search system, GraphSE2 also supports and and or operators, which yield the intersection and union of posting lists via Set Operations respectively. In addition, it supports difference operator, which yields results from the first posting list that are not present in the others. Moreover, GraphSE2 supports the unique query operator of Unicorn system (Curtiss et al., 2013), i.e., apply. The operator allows GraphSE2 to perform multiple rounds of posting list retrieval to retrieve contents that are more than one edge away from the source node.

To enable quality search services (e.g., friendship-based recommendation), the retrieved posting lists should be scored/ranked before returning to users. As mentioned in Section 4, the additive shares of sort-keys are stored with its indexes. As a result, most of the query operators (e.g., term, and, difference and or) can use these shares to perform Sorting on the retrieved contents. Furthermore, it is often useful to return results in an order different from sorting by sort-keys. For instance, collaborative filtering (Breese et al., 1998) evaluates an arithmetic formula about friendships and ratings on items to produce the personalised scores for recommended items. The new score is a better prediction than the sort-keys, as the later only reflects the overall preference in the community (e.g., the hit-count on the item). The defined operators natively support arithmetic computations via the additive shares affixed with indexes. Specifically, apply operator has the capability to support the secure evaluation on complicated scoring formulas with Arithmetic operations: It can access different types of entities (e.g., user’s friends, items liked by users, etc.) in a multiple round-trip query, which means it can combine the scores of different entities and cache the intermediate result for next round computations.

5. The Proposed System

We give a list of needed notations in our system construction and security analysis in Table 2. The detailed definitions of preliminaries we used are given in Section 3.

5.1. Encrypted Graph Data Model

To support social search operations in (Curtiss et al., 2013) on an encrypted social graph (see Section 3.1 for details), GraphSE2 creates the OXT index (i.e., $\mathrm{TSet}$ and $\mathrm{XSet}$, see Section 3.2 for details) for encrypted graph structure access in $\mathcal{ISC}$s, and the additive shares are integrated with the corresponding index to support complex computations. Specifically, to support simple graph structure data access, each posting list is encrypted and stored as a $\mathrm{TSet}$ tuple in the $\mathcal{ISC}$: $(\mathbf{stag}(\textbf{edge-type}\textbf{:}\mathbf{id}_{\mathsf{u}}),\{\mathbf{E}\})$. The $\mathrm{TSet}$ tuple consists of the $\mathbf{stag}$ of indexing term as the key and the encrypted posting list $\{\mathbf{E}\}$ as the value. Each element in $\{\mathbf{E}\}$ is an encrypted tuple $\mathbf{E}_{\mathbf{id}}=(\langle\text{sort-key}\rangle^{A},e_{\mathbf{id}})$, which keeps the encryption $e_{\mathbf{id}}$ of entity $\mathbf{id}$. Additionally, the sort-key of entity is shared as additive sharing value. GraphSE2 associates it with the encrypted entity $\mathbf{id}$ to support complex computations. Moreover, GraphSE2 evaluates the cryptographic hash function of $(\mathbf{id},\textbf{edge-type}\textbf{:}\mathbf{id}_{\mathsf{u}})$ pairs to generate an $\mathrm{XSet}$ for complex set operations.

5.2. Encrypted and Distributed Graph Index

In order to support the system to process the query in parallel, GraphSE2 distributes the encrypted graph across multiple index servers for each cluster.

GraphSE2 devises a partition strategy that shards the posting lists by hashing on result $\mathbf{id}$. Figure 2 gives an example of the proposed partition strategy in an $\mathcal{ISC}$ with two $\mathcal{IS}$s. We employ a modulo partition strategy, which split the original posting list into multiple non-duplicate parts, but other graph partition strategies (e.g., (Low et al., 2012)) can also be applied to shard the social graph. The design has three advantages in the context of distributed environment. First, it maintains the availability in the event of server failure. Furthermore, the sharding strategy enables the distributed system to finish most of the set operations and the consequent scoring, ranking and truncating in $\mathcal{IS}$s. It splits the computation loads into distributed servers to improve the efficiency and also cuts down the communication cost between $\mathcal{IS}$s and $\mathcal{SF}$. Finally, it does not affect the security of GraphSE2 because the adversary who compromises an $\mathcal{ISC}$ gets the same view (the whole encrypted database) as the adversary in a single $\mathrm{OXT}$ instance. If the adversary cannot access all $\mathcal{IS}$s in the $\mathcal{ISC}$, only the view on a fraction of the encrypted database is learned..

5.3. Atomic Operations

As mentioned in Section 4.4, the social search queries are implemented by a set of operators. We observe that these operators can be decomposed to a set of atomic operations. We now describe the implementation of these atomic operations in the encrypted domain. For each atomic operation, we explain how we adapt and optimise it in the proposed system.

5.3.1. Index Access

We start with Index Access operation, which is used to retrieve the neighbouring nodes of the target user with the given edge-type (e.g., friend, likes) from the social graph. Algorithm 1 outlines the searching procedure using $\mathrm{TSet}$ operations. On receiving the search keyword, $\mathcal{SF}$ firstly generates a search token $\tau$, which is $\mathbf{stag}(t)$ of the indexing term $t$. $\mathcal{IS}$ can use $\tau$ to search $\mathrm{TSet}$ and get the encrypted posting list $\mathrm{TSet}(t)$ as the return. Index Access operation can be easily extended to run in parallel. More specifically, $\mathcal{SF}$ broadcasts search token $\tau$ to all $\mathcal{IS}$s. After that, each $\mathcal{IS}$ uses $\tau$ to get its local partition of the whole encrypted posting list and sends it back.

Security. The security of Index Access is guaranteed by the security property of $\mathrm{TSet}$. Informally, Index Access is $\mathcal{L}_{\bf T}$-semantically-secure against adaptive attacks where $\mathcal{L}_{\bf T}$ is the leakage function of $\mathrm{TSet}$. $\mathcal{L}_{\bf T}$ is well-defined and discussed in (Cash et al., 2013). It ensures Index Access only leaks the number of edges in the encrypted social graph.

5.3.2. Set Operations

This operation involves the boolean expression with multiple indexing terms. GraphSE2 uses it to query the encrypted graph-structured data and finds the neighbouring nodes and the corresponding user-generated content that satisfy the given boolean expression. In GraphSE2, we adapt $\mathrm{OXT}$ protocol to support this atomic operation, but some of the other SSE protocols supporting conjunctive queries (e.g. (Lai et al., 2018)) can also be readily adapted as the building block of GraphSE2. The $\mathrm{OXT}$ protocol supports conjunctive queries of the form $t_{1}\wedge t_{2}\wedge...\wedge t_{n}$ natively, but it can be extended to support the boolean query of the form $t_{1}\wedge\phi(t_{2},...,t_{n})$, where $t_{1}$ is the ‘s-term’, and $\phi(t_{2},...,t_{n})$ is an arbitrary boolean expression (Cash et al., 2013). As shown in Algorithm 2, the extended protocol follows the basic steps to obtain search tokens and search in $\mathrm{TSet}$ and $\mathrm{XSet}$ interactively. Nevertheless, it introduces additional steps (line 3, 13, 15–17 in Algorithm 2) to solve the boolean expression $\phi(t_{2},...,t_{n})$. Specifically, $\mathcal{SF}$ substitutes all indexing terms $t_{i}$ to boolean variables $v_{i}$ ($i=2,...,n$) and generates a boolean function $\hat{\phi}(v_{2},...,v_{n})$. $\mathcal{SF}$ then sends $\hat{\phi}(v_{2},...,v_{n})$ to $\mathcal{IS}$. $\mathcal{IS}$ sets the value of $v_{i}$ to the truth values of $h(\mathbf{id}_{c},t_{i})\in\mathrm{XSet}$. Then, it evaluates $\hat{\phi}(v_{2},...,v_{n})$ and returns $\mathbf{E}_{c}$ as a result if $\hat{\phi}$ outputs true.

The $\mathrm{Boolean\ Query}$ algorithm can be utilised to enable set operations of social search queries as shown in Table 1, which will be discussed in the following section.

Security. In cryptographic terms, the $\mathrm{OXT}$ protocol is proved to be $\mathcal{L}_{\mathrm{OXT}}$-semantically-secure against adaptive attacks, where $\mathcal{L}_{\mathrm{OXT}}$ is the leakage function defined in (Cash et al., 2013). It ensures that the untrusted server only learns the information defined in the leakage function, but no other information about the query and underlying dataset. We refer the reader to Section 3.2 for more details.

5.3.3. Arithmetic

GraphSE2 uses Arithmetic operations to support complex scoring functions over the retrieved content from Set Operations. Arithmetic operations in GraphSE2 involve the secure two-party computation between two $\mathcal{ISC}$s. Here, we introduce the simplest model of GraphSE2, where each $\mathcal{ISC}$ only has one $IS$, for ease of presentation on how to use additive shares (see Section 3.3 for detailed definition) to compute addition and multiplication under two-party setting. Note that this model can be extended to support multiple pairs of $\mathcal{IS}$s.

In GraphSE2, the posting list is generalised as a matrix and the arithmetic operations are evaluated over the matrix. The reason for that is, instead of running the scoring function with arithmetic operations multiple times for each item of the posting list, the batch processing can reduce the system overhead and support scoring algorithms in parallel. We denote the matrix of sort-keys returned from a structured information query by $\mathbf{S}$, and the corresponding shared matrix is denoted by $\langle\mathbf{S}\rangle^{A}$. Given two shared matrices $\langle\mathbf{A}\rangle^{A}$ and $\langle\mathbf{B}\rangle^{A}$, the addition operation ($Add^{A}(\langle\mathbf{A}\rangle^{A},\langle\mathbf{B}\rangle^{A})$) can be evaluated non-interactively by computing $\langle\mathbf{C}\rangle^{A}=\langle\mathbf{A}\rangle^{A}+\langle\mathbf{B}\rangle^{A}$ in each party. To multiply two shared matrices ($Mul^{A}(\langle\mathbf{A}\rangle^{A},\langle\mathbf{B}\rangle^{A})$), two $\mathcal{IS}$s generate the multiplication triplets, which are shared matrices: $\langle\mathbf{X}\rangle^{A},\langle\mathbf{Y}\rangle^{A},\langle\mathbf{Z}\rangle^{A}$. $\mathbf{X}$ has the same dimension as $\mathbf{A}$, $\mathbf{Y}$ has the same dimension as $\mathbf{B}$, and $\mathbf{Z}=\mathbf{X}\times\mathbf{Y}\mod 2^{l}$. $\mathcal{IS}_{i}$ computes $\langle\mathbf{E}\rangle_{i}^{A}=\langle\mathbf{A}\rangle_{i}^{A}-\langle\mathbf{X}\rangle_{i}^{A}$ and $\langle\mathbf{F}\rangle_{i}^{A}=\langle\mathbf{B}\rangle_{i}^{A}-\langle\mathbf{Y}\rangle_{i}^{A}$, and sends it to its counter-party. Both parties then recover $\mathbf{E},\mathbf{F}$ and let $\langle\mathbf{C}\rangle_{i}^{A}=i\cdot\mathbf{E}\times\mathbf{F}+\langle\mathbf{X}\rangle_{i}^{A}\times\mathbf{F}+\mathbf{E}\times\langle\mathbf{Y}\rangle_{i}^{A}+\langle\mathbf{Z}\rangle_{i}^{A}$.

The multiplication operation relies on the triplets, which should be generated before the actual computation. In addition, each party keeps their $\langle\mathbf{X}\rangle^{A},\langle\mathbf{Y}\rangle^{A}$ in secret during the generation process, otherwise, they can recover $\mathbf{A},\mathbf{B}$ after two parties exchanged $\langle\mathbf{E}\rangle^{A},\langle\mathbf{F}\rangle^{A}$. Thus, GraphSE2 introduces a secure offline protocol (Mohassel and Zhang, 2017) to generate the triplets via OT, it utilises the following relationship: $\mathbf{Z}=\langle\mathbf{X}\rangle_{0}^{A}\times\langle\mathbf{Y}\rangle_{0}^{A}+\langle\mathbf{X}\rangle_{0}^{A}\times\langle\mathbf{Y}\rangle_{1}^{A}+\langle\mathbf{X}\rangle_{1}^{A}\times\langle\mathbf{Y}\rangle_{0}^{A}+\langle\mathbf{X}\rangle_{1}^{A}\times\langle\mathbf{Y}\rangle_{1}^{A}$ to compute the shares of $\mathbf{Z}$. The resulting offline protocol is only required to compute the shares of $\langle\mathbf{X}\rangle_{0}^{A}\times\langle\mathbf{Y}\rangle_{1}^{A}$ and $\langle\mathbf{X}\rangle_{1}^{A}\times\langle\mathbf{Y}\rangle_{0}^{A}$ as the other two terms can be computed locally.

We illustrate the computing process of $\langle\mathbf{X}\rangle_{0}^{A}\times\langle\mathbf{Y}\rangle_{1}^{A}$ in the offline protocol. The basic step of the offline protocol is to use $\langle\mathbf{X}\rangle^{A}_{0}$ and a column from $\langle\mathbf{Y}\rangle^{A}_{1}$ to compute the share of their product. This is repeated for each column in $\langle\mathbf{Y}\rangle^{A}$ to generate $\langle\mathbf{X}\rangle_{0}^{A}\times\langle\mathbf{Y}\rangle_{1}^{A}$. Therefore, for simplicity, we focus on the above basic step: We assume that the size of $\langle\mathbf{X}\rangle^{A}$ is $\mathrm{s}*\mathrm{t}$ and we denote each element in $\langle\mathbf{X}\rangle^{A}$ as $\langle x_{i,j}\rangle^{A}_{0}$, $i=1,...,\mathrm{s}$ and $j=1,...,\mathrm{t}$. In addition, we assume each column of $\langle\mathbf{Y}\rangle^{A}$ has $\mathrm{t}$ elements, which are denoted as $\langle y_{j}\rangle^{A}_{1}$, $j=1,...,\mathrm{t}$. The computation process is listed as follows:

• •

$\mathcal{IS}_{0}$ runs a correlated-OT protocol (COT) (Asharov et al., 2013), and sets the correlation function to $f_{b}(x)=\langle x_{i,j}\rangle^{A}_{0}\cdot 2^{b}+x\mod 2^{l}$ for $b=1,...,l$.

• •

For each bit $b$ of $\langle y_{j}\rangle^{A}_{1}$, $\mathcal{IS}_{0}$ chooses a random value $r_{b}$ for each bit and runs $COT(r_{b},f_{b}(r_{b});\langle y_{j}\rangle^{A}_{1}[b])$ with $\mathcal{IS}_{1}$.

• •

If $\langle y_{j}\rangle^{A}_{1}[b]=0$, $\mathcal{IS}_{1}$ gets $r_{b}\mod 2^{l}$; If $\langle y_{j}\rangle^{A}_{1}[b]=1$, $\mathcal{IS}_{1}$ gets $f_{b}(r_{b})=\langle x_{i,j}\rangle^{A}_{0}\cdot 2^{b}+r_{b}\mod 2^{l}$. It is equivalent to get $\langle y_{j}\rangle^{A}_{1}[b]\cdot\langle x_{i,j}\rangle^{A}_{0}\cdot 2^{b}+r_{b}\mod 2^{l}$ in $\mathcal{IS}_{1}$ side.

• •

$\mathcal{IS}_{1}$ sets $\langle\langle x_{i,j}\rangle^{A}_{0}\cdot\langle y_{j}\rangle^{A}_{1}\rangle_{1}^{A}=\Sigma_{b=1}^{l}\langle y_{j}\rangle^{A}_{1}[b]\cdot\langle x_{i,j}\rangle^{A}_{0}\cdot 2^{b}+r_{b}\mod 2^{l}$, and $\mathcal{IS}_{0}$ sets $\langle\langle x_{i,j}\rangle^{A}_{0}\cdot\langle y_{j}\rangle^{A}_{1}\rangle_{0}^{A}=\Sigma_{b=1}^{l}(-r_{b})\mod 2^{l}$.

After computing $\langle\langle x_{i,j}\rangle^{A}_{0}\cdot\langle y_{j}\rangle^{A}_{1}\rangle^{A}$, the $j$-th element of the $i$-th row in $\langle\langle\mathbf{X}\rangle_{0}^{A}\times\langle\mathbf{Y}\rangle_{1}^{A}\rangle^{A}$ is $\Sigma_{j=1}^{\mathrm{t}}\langle\langle x_{i,j}\rangle^{A}_{0}\cdot\langle y_{j}\rangle^{A}_{1}\rangle^{A}$. Analogously, $\mathcal{IS}_{0}$ and $\mathcal{IS}_{1}$ can compute the share of $\langle\mathbf{X}\rangle_{1}^{A}\times\langle\mathbf{Y}\rangle_{0}^{A}$ in the same way.

Security. Additive sharing scheme offers security guarantees to Arithmetic operations in GraphSE2 via its computational indistinguishable property. More specific, as discussed in (Pullonen et al., 2012), the scheme can create a uniformly distributed input and output to protects the original input/output of Arithmetic operation under the threat model of GraphSE2, i.e., semi-honest but non-colluding two-party.

5.3.4. Sorting

This is a required operation in order to rank the computed scores from Arithmetic operations. A naive solution is to recover all scores from additive shares in $\mathcal{SF}$ and sort them as plaintext. However, transmitting all rank results to $\mathcal{SF}$ is a bandwidth-consuming task, the sort operation can be very inefficient as the result. Therefore, GraphSE2 chooses to mix the additive sharing scheme and Yao’s Garbled Circuit (see Section 3.3 for details) to support arithmetic operations and comparison at the same time, as it avoids the communication overhead from sending the shares back to $\mathcal{SF}$. To protect the privacy of score values, the generated circuit should have a fixed sequence of comparison for a given size of inputs (i.e., achieving the trace-oblivious), and it should not reveal the actual scoring value after circuit evaluation.

Local Sorting. To enable sorting on $\mathcal{IS}$s, GraphSE2 leverages an efficient scheme in (Demmler et al., 2015) to switch from additive sharing to Yao’s sharing. It then adopts the sorting network (Batcher, 1968) to generate the optimised sorting circuit. Finally, the garbler concatenates the sorting network with an XOR gate and applies a random mask $R$ to mask the score values. As a result, the evaluator can use decode table $dec$ to figure out the rank, but it does not know the score values. Thus, the local sorting algorithm in GraphSE2 can be divided into five phases. Figure 3 illustrates the process of local sorting.

Given $\mathcal{IS}_{0}$ as the garbler and $\mathcal{IS}_{1}$ as the evaluator, both parties pre-share a scoring vector $\mathsf{x}=\{\langle x_{i}\rangle^{A}\}_{i=1}^{\mathrm{k}}$, GraphSE2 runs the protocol $\textsc{LocalSort}(\mathsf{x})$ to sort the vector and returns a sorted vector in descending order of $\mathsf{x}$, the protocol can be summarised as follows:

• •

Phase 1: $\mathcal{IS}_{0}$ runs $\mathcal{GC}$ to generate the circuit in Figure 3 as well as its decode table $dec$. It then sends the circuit and the decode table $dec$ to $\mathcal{IS}_{1}$. Doing so ensures that $\mathcal{IS}_{1}$ only can see the final result with random mask $R$.

• •

Phase 2: $\mathcal{IS}_{0}$ sends the encoded inputs of its additive shares $\{\langle x_{i}\rangle_{0}^{A}\}_{i=1}^{\mathrm{k}}$ with a payload vector $\{i\}_{i=1}^{\mathrm{k}}$ indicating the position. This prevents $\mathcal{IS}_{1}$ from learning the additive shares of $\mathcal{IS}_{0}$.

• •

Phase 3: $\mathcal{IS}_{1}$ retrieves the encoded inputs of its additive shares $\{\langle x_{i}\rangle_{1}^{A}\}_{i=1}^{\mathrm{k}}$ and payload vector from $\mathcal{IS}_{0}$ via OT protocol. This prevents $\mathcal{IS}_{0}$ from learning the additive shares of $\mathcal{IS}_{1}$.

• •

Phase 4: $\mathcal{IS}_{0}$ generates the encoded input of a random mask $R$ to perform the last XOR gate to protect the vector.

• •

Phase 5: $\mathcal{IS}_{1}$ uses the given inputs to evaluate the circuit, and uses $dec$ to decode the outputs.

Since the circuit puts a mask $R$ after sorting, $\mathcal{IS}_{1}$ only gets the ranking $\{r_{i}\}_{i=1}^{k}$ without knowing the actual scores.

Global Sorting. The above sorting strategy is a suitable and efficient solution for the simplest model, i.e., only one $\mathcal{IS}$ in each $\mathcal{ISC}$. However, it can be problematic when each $\mathcal{ISC}$ has several $\mathcal{IS}$s. In this case, no $\mathcal{IS}$ can provide a full sorted list as each $\mathcal{IS}$ only has a disjoint part of the whole graph. Hence, $\mathcal{SF}$ still needs to perform another inefficient plaintext sorting.

Therefore, GraphSE2 uses a specific protocol which runs by a chosen coordinator of each $\mathcal{ISC}$. The protocol can perform an extra round of sorting upon the results from local sort while keeping the scoring value in secret. Assuming that each $\mathcal{ISC}$ has $n$ different $\mathcal{IS}$s, $\mathcal{IS}_{00}$ and $\mathcal{IS}_{10}$ are chosen to be the coordinators for $\mathcal{ISC}_{0}$ and $\mathcal{ISC}_{1}$, respectively. After local sorting, evaluator in $\mathcal{ISC}_{1}$ sends a vector of masked scoring values $\{x_{i,j}\oplus R_{j}\}$ where $i=1,...,\mathrm{k}$ and $j=1,...,\mathrm{n}$ to $\mathcal{IS}_{10}$ and garbler in $\mathcal{ISC}_{0}$ sends the masks $\{R_{j}\}_{j=1}^{\mathrm{n}}$ to $\mathcal{IS}_{00}$. In the global sorting, GraphSE2 switches the roles of $\mathcal{IS}_{10}$ and $\mathcal{IS}_{00}$ (i.e., $\mathcal{IS}_{10}$ is the garbler, and $\mathcal{IS}_{00}$ is the evaluator) for two reasons: It prevents $\mathcal{IS}_{10}$ from evaluating two circuits at the same time, as $\mathcal{IS}_{10}$ also needs to evaluate another local sorting circuit for its partition. Furthermore, it facilitates pipeline data processing. The partial result of each $\mathcal{IS}$ can be sent to $\mathcal{IS}_{10}$ and $\mathcal{IS}_{00}$ for global sorting separately. Once the $\mathcal{IS}_{10}$ and $\mathcal{IS}_{00}$ get the first result, they can start to run encoding and OT. The protocol $\textsc{GlobalSort}(\mathsf{x})$ is summarised as follows:

• •

Phase 1: $\mathcal{IS}_{10}$ runs $\mathcal{GC}$ to generate the circuit in Figure 4 and the decode table $dec$. It then sends the circuit and $dec$ to $\mathcal{IS}_{00}$.

• •

Phase 2: $\mathcal{IS}_{10}$ sends the encoded inputs $\{x_{i,j}\oplus R_{j}\}$ where $i=1,...,\mathrm{k}$ and $j=1,...,\mathrm{n}$ with a payload vector $\{i\}_{i=1}^{\mathrm{n\cdot k}}$.

• •

Phase 3: $\mathcal{IS}_{00}$ retrieves encoded masks $\{R_{j}\}_{j=1}^{\mathrm{n}}$ via OT protocol.

• •

Phase 4: $\mathcal{IS}_{00}$ uses the given inputs to evaluate the circuit, and uses $dec$ to decode the outputs. The result is sent to $\mathcal{SF}$ in descending order.

Security. The security properties of Garbled Circuit (Bellare et al., 2012) and OT (Asharov et al., 2013) ensure the security of Sorting in GraphSE2 in the following three aspects: Firstly, no adversary can learn the input of its counter-party when sorting (i.e., the other additive share in $\textsc{LocalSort}(\mathsf{x})$ and the masked score/mask in $\textsc{GlobalSort}(\mathsf{x})$). Secondly, the output of $\textsc{LocalSort}(\mathsf{x})$ is masked by a one-time mask, which is a uniformly random number. It protects the original score vector because the evaluator only learns the masked values from output. Finally, for the output of $\textsc{GlobalSort}(\mathsf{x})$, only the decode table of rank is sent to the evaluator, which also ensures that the evaluator only learns global rank without knowing the actual ranking score.

6. Query Realisation

In GraphSE2, $\mathcal{SF}$ receives queries as the query strings in the form of s-expression. It is composed of several operators to describe the set of results the client wishes to receive (see Table 1). In the following sections, we introduce the operators in GraphSE2 and their security properties.

6.1. Graph Operators

GraphSE2 uses atomic operations in Section 5.3 to realise all operators in Table 1. In this section, we present the detailed constructions of these operators. Note that we only consider the operators as the outermost operators, i.e., they are not nested in any other query strings, because the query plan generation highly depends on the outermost operators.

term. The term operator runs an Index Access operation to retrieve a posting list. In addition, if there is a requirement to rank the result, the Sorting operation is able to return a sorted posting list which puts the record with higher relevance at the beginning of the list.

and. This operator is natively supported by the BooleanQuery algorithm. As mentioned in Section 5.3, conjunctive queries with nested queries (e.g., $t_{1}\wedge\phi(t_{2},...,t_{n})$) are processed by evaluating the boolean expression $\phi$ in $\mathrm{XSet}$. It is obvious that the and operator is executed in a sub-linear time, as its complexity is proportional to the size of $\mathrm{TSet}(t_{1})$.

difference. The difference operator is extended from BooleanQuery algorithm. Considering the query (difference friend:3 (and friend:1 friend:2)) from Table 1, it aims to find the friends of $\textbf{user}_{3}$, who are neither $\textbf{user}_{1}$’s friends nor $\textbf{user}_{2}$’s friends. The boolean expression, in this case, is $\textbf{friend:1}\land\textbf{friend:2}$, but the results that satisfy the expression are removed from the results of the query $(\textbf{term}\ \textbf{friend:3})$. In summary, difference operator excludes the results that satisfy the boolean expression $\phi$. Therefore, the s-expression with difference operator is represented as $t_{1}\wedge\neg\phi(t_{2},...,t_{n})$. Comparing with the and operator, it returns the results only if the boolean expression $\phi$ returns false instead of true.

or. The complexity of the original approach for processing disjunctive queries is linear to the size of database (Cash et al., 2013). To achieve a sub-linear time complexity, we leverage the above difference and term operators to build a new disjunctive query operator. In particular, the s-expression starts with or operator can be processed via a list of difference expressions and an additional term expression. For instance, if a disjunctive query has three indexing terms: $t_{1},t_{2},t_{3}$, the corresponding s-expression is ($\textbf{or}\ t_{1}\ t_{2}\ t_{3}$), and it is parsed as: $(\textbf{difference}\ t_{1}\ (\textbf{or}\ t_{2}\ t_{3})),(\textbf{difference}\ t_{2}\ t_{3}),(\textbf{term}\ t_{3})$. The above three s-expressions return three different sets of results, and the composite of them is the final result of or operator. The correctness of the above approach can be easily proved by the set operation: $t_{1}\lor t_{2}\lor t_{3}=(t_{1}\textbackslash(t_{2}\lor t_{3}))\lor(t_{2}\textbackslash t_{3})\lor t_{3}$.

In general, a disjunctive s-expression with $n$ indexing terms can be rewritten as $n-1$ s-expressions with difference operator and $1$ s-expressions with term operator. The complexity is proportional to $|t|\cdot M$, where $|t|$ is the number of disjunctive indexing terms and $M$ is the result size of the most frequent term $\max(\{|\mathrm{TSet}(t_{i})|\}_{i=1}^{n})$.

6.2. Apply Operator

The apply is a unique operator in Unicorn (Curtiss et al., 2013), which enables graph-traversal. The basic idea is to retrieve the results of nested queries and use these results to construct and execute a new query. For example, given an s-expression (apply friend: friend:$\mathbf{id}_{1}$), $\mathcal{SF}$ issues a query (term friend:$\mathbf{id}_{1}$) and collects $N$ users, it then generates the second query $(\textbf{or}\ \textbf{friend:}\mathbf{id}_{1,1}\ ...\ \textbf{friend:}\mathbf{id}_{1,N})$ to get the entities that are more than one edge away from the user $\mathbf{id}_{1}$ in the encrypted graph-structured data.

GraphSE2 defines a query structure to construct apply operator. In details, the query structure is a tuple of (prefix, s, filter), where the prefix (e.g., friend:) is prepended to the given $\mathbf{id}$ to form the indexing terms, s is an s-expression with $N$ indexing terms (e.g., (term ?)), and filter indicates the ranking algorithm for its results. To execute an apply operator, $\mathcal{SF}$ pre-processes the input $\mathbf{id}$ with a given prefix in the query structure and uses processed $\mathbf{id}$ to execute the s-expression s from the query structure. $\mathcal{ISC}$ handles the query from the s-expression and applies the designated filter in the query structure to refine the result. Consequently, $\mathcal{SF}$ can retrieve a list of $\mathbf{id}$ as the result of the nested query structure. GraphSE2 leverages as input the retrieved $\mathbf{id}$ and outer query structure to repeat the above procedure until it reaches the outermost query structure. Algorithm 3 gives the detailed implementation of the apply.

The apply operator processes necessary steps on behalf of its users to improve the efficiency of GraphSE2. For example, it would be possible for users to ask recommendation from friends: both $\mathcal{SF}$ and client can execute a two-step query to retrieve friend list in advance and issue an additional query to get the recommendation. Compared to the latter strategy, the apply operator runs in $\mathcal{SF}$ can highly reduce the workload on the client side: it saves the network latency of transmitting intermediate result between $\mathcal{SF}$ and client, addition to the computational cost of aggregation and regeneration. Furthermore, $\mathcal{SF}$ can further optimise the query and adopt the different scoring strategy by giving its semantic context (as shown in the following example).

Example: Friend Recommendation. The friend recommendation is a good example for the use of the apply operator. According to the Homophily theory (McPherson et al., 2001), people with higher similarity have a higher probability to become friend. In this context, the system aims to recommend the friends-of-friends to its user according to the order of similarities. Hence, we apply a simple ranking function which returns the sorted similarity value directly for both outer and nested query for this application.

It is also possible to implement the friends-of-friends query without the apply operator. Intuitively, friends-of-friends also can be treated as an edge type, GraphSE2 may explicitly store the friends-of-friends list and use the indexing term friends-of-friends:id to index it. Therefore, the friend recommendation problem is easily processed by the term operator. However, such a naive solution blows up the memory consumption on $\mathcal{IS}$: as shown in Table 3, the estimated size of friends-of-friends posting list is almost 370x larger than the original friend list of a typical user (Curtiss et al., 2013). In GraphSE2, each encrypted tuple occupies $56$ bytes memory space (See Section 5 for the detailed discussion), it indicates that the friends-of-friends posting lists for 1 million users consumes $2.4$TB RAM.

The apply operator also reduces the query latency: it is expensive to sort the posting lists of friends-of-friends:id with 48k entities inline in Garbled Circuit (it needs $200$ s to evaluate the corresponding circuit). In comparison, introducing an extra round to query enables $\mathcal{IS}$ to truncate the result, and makes the sorting process more efficient. For example, if GraphSE2 applies a filter to return the top $10$ results to $\mathcal{SF}$ for the nested query, the result size can be reduced to around $1000$ users with a higher similarity. Also, the reduced result size is moderate to evaluate sort circuit on it. Under our settings in Section 8, the system replies either a full result list after $5$-$6$ s or a truncated result list after $1$-$2$ s.

6.3. Security Analysis

In Section 5.3, we discuss the security of each atomic operation. Here, we analyse the security of the overall system. Specifically, we formulate the security of GraphSE2 based on the prior work of SSE (Curtmola et al., 2011; Cash et al., 2013) and further combine the security of additive sharing and Garbled Circuit to depict the security of query operators. Throughout the analysis, we consider a query in GraphSE2 containing a boolean formula $\phi$ and a tuple of indexing terms $(t_{1},t_{2},...,t_{n})$.

Overview. The main idea of analysing the security of GraphSE2 is similar to that in SSE scheme (Curtmola et al., 2011; Cash et al., 2013). Specifically, the analysis constructs a simulator of GraphSE2 to show that the adversary in GraphSE2 only learns the controlled leakage parameterised by a leakage function $\mathcal{L}$, after querying a vector of queries $\mathbf{q}$. Note that the simulator of GraphSE2 is slightly different from the original SSE simulator, we outline these different points as the sketch of our security analysis. Firstly, we update the leakage function of SSE ($\mathrm{OXT}$ in GraphSE2) to additionally capture the ranks leaked in query results. Secondly, we slightly modify the capability of adversaries to fit our two-party model: an adversary in our system is able to see the view on the corrupted cluster as well as the output of the counter-party. Under the new adversary model, the joint distribution of the outputs of both the adversary and the counter-party can be properly simulated by an efficient algorithm with the updated leakage function. Finally, as GraphSE2 has the submodules implemented by SSE, additive share scheme, and Yao’s Garbled Circuit, the simulator of GraphSE2 can be constructed by combining the simulators of these submodules. For instance, our simulator uses the output of SSE simulator as the input of garbled circuit simulator in order to simulate the query operators with structured data access and sorting.

Due to the page limit, the updated leakage function is given in Appendix A.1 and the detailed proof is in Appendix A.2.

Discussion. Note that there exist some emerging threats against the building blocks of GraphSE2. Regarding SSE, leakage-abuse attacks (Cash et al., 2015; Zhang et al., 2016) can help an attacker to explore the information learned during queries. To mitigate them, recent studies on padding countermeasures (Cash et al., 2015; Bost and P-A, 2017) and forward/backward privacy (Bost et al., 2017; Sun et al., 2018) are proposed and shown to be effective. We leave the integration of these advanced security features to our system as future work. Regarding sorting, GraphSE2 reveals the rank of the query result. Recent work (Kellaris et al., 2016; Kornaropoulos et al., 2019) demonstrates that the underling data values are likely to be reconstructed if an adversary knows ranks and some auxiliary information of queries and datasets. Currently, we do not consider such a strong adversary, and how to fully address the above threat remains as an interesting problem.

7. Implementation

We implement a prototype system for evaluating the performance of GraphSE2. To build this prototype, we first realise the cryptographic primitives in Section 3. Specifically, we use the symmetric primitives, i.e., AES-CMAC and AES-CBC, from Bouncy Castle Crypto APIs (The Legion of the Bouncy Castle, 2007). In addition, we use a built-in curve from Java Pairing-based Cryptography (JPBC) (Caro and Iovino, 2011) library (Type A curve) to support the group operations in $\mathrm{OXT}$. The security parameter of symmetric key encryption schemes is 128-bit, and the security parameter of the elliptical curve cryptographic scheme is 160-bit. Regarding the secure two-party computation, we set the field size to $2^{31}$. Therefore, we can use regular arithmetics on Java integer type to implement the modulo operations, as it is significantly faster than the native modulo operation in Java BigInteger type (i.e., we observed that it is 50x faster). We involve this optimisation into the implementation of additive sharing scheme in the finite field $\mathbb{Z}_{2^{31}}$, the addition (multiplication) operations is calculated by several regular addition and multiplication operations with the modulo operation. Oblivious Transfer and Garbled Circuit are implemented by using FlexSC (Wang, 2018). It implements the extended OTs in (Asharov et al., 2013) and several optimisations for the garbled circuit, which make it a practical primitive under Java environment.

The prototype system consists of three main components: the encrypted database generator, the query planner in $\mathcal{SF}$ and the index server daemon in $\mathcal{ISC}$. The encrypted database generator is running on a cluster with Hadoop (Apache, 2015). It partitions the plaintext data, runs the adapted $\mathrm{OXT}$ to convert the data into encrypted tuples with the additive share of sort-keys and stores these tuples on each $\mathcal{IS}$. We leverage Spark (Zaharia et al., 2010) to execute these tasks in-memory and enable the pipelining data processing to further accelerate this process. The generated tuples are stored in the in-memory key-value store Redis (Redis Labs, 2017) in the form of $\mathrm{TSet}$ on each $\mathcal{IS}$ for querying purpose later. In addition, the generated $\mathrm{XSet}$ is kept in the external storage of each $\mathcal{IS}$ to support the set operations. All queries are handled by the query planner and index server daemons by following the query processing flow in Section 4.1. Thrift thread pool proxy (Slee et al., 2007) is deployed to handle the queries in index server daemons.

To improve the runtime performance of our prototype, each posting list is segmented into fixed-size blocks indexed by its $\mathbf{stag}(t)$ and a block counter $c$ for the $\mathbf{stag}$. As the final result of the block counter indicates the total number of blocks for each $\mathbf{stag}$, it is also stored in Redis after the whole posting list is converted to encrypted tuples. Those counters enable $\mathcal{IS}$ to retrieve multiple tuples in parallel. We also introduce a startup process for $\mathrm{OXT}$ protocol and secure two-party computation in index server daemons. In terms of the $\mathrm{OXT}$ matching, the index server daemon creates a Bloom Filter (Bloom, 1970) to load the $\mathrm{XSet}$ into memory during the startup process. In our prototype, we deploy the Bloom filter from Alexandr Nikitin as it is the fastest Bloom filter implementation for JVM (Nikitin, 2017). We set the false positive rate to $10^{-6}$, and the generated Bloom Filter only occupies a small fraction of $\mathcal{IS}$ memory. Besides generating the Bloom Filter, each index server also pre-computes several multiplication triplets and sorting circuits and periodically refreshes it to avoid extra computational cost on-the-fly.

Our prototype system implementation consists of four main modules with roughly 3000 lines of Java code, we also implement a test module with another 1000 lines of Java code.

8. Experimental Evaluations

8.1. Setup

Platform. We deploy the index server daemons in a cluster ($\mathcal{ISC}$) with 6 virtual machine instances in the Microsoft Azure platform. All VMs are E4-2s v3 instances, configured with 2 Intel Xeon E5-2673 v4 cores, 32GB RAM, 64GB SSD external storage and 40Gbps virtualised NIC. Another D16s v3 instance is created in Azure to run $\mathcal{SF}$ with the query planner and client; it is equipped with 16 Intel Xeon E5-2673 v3/v4 cores, 64GB RAM, 128GB SSD external storage and 40Gbps virtualised NIC. We also have the other three E4-2s v3 instances controlled by $\mathcal{SF}$; we use them to run the encrypted database generator for generating the encrypted index. All VMs are installed with Ubuntu Server 16.04LTS.

Dataset. We use a Youtube dataset from (Mislove et al., 2007), which is an anonymised Youtube user-to-user links and user group memberships network dataset. The detailed statistical summary is given in Table 4. We recognise the user-to-user links as friend edge and user group memberships as follow edge from this dataset. The generated posting lists are indexed by above two edge types and user $\mathbf{id}$s. As the social network in our Youtube dataset is an unweighted network, we randomly generate a weight between $1$ and $100$ for each edge to evaluate the arithmetic and sort operations of GraphSE2.

Baseline. To evaluate the performance of GraphSE2, we create a graph search system by removing/replacing cryptographic operations in this baseline system. Specifically, we leverage hash function to generate $\mathbf{xtag}$ instead of using expensive group operations. The index and sort-key are stored in plaintext, which means that the $\mathcal{IS}$ can compute and sort without any network communication for OT and multiplication triplets. Finally, the query planner provides the indexing term in plaintext instead of $\mathbf{stag}$ to the $\mathcal{IS}$ as query token. Nonetheless, we still use the PRF value of indexing term and the block counter as tuple index, because we want to keep the table structure of $\mathrm{TSet}$ unaltered to make our system comparable to the baseline. We use this baseline system to evaluate the overhead from cryptographic operations as GraphSE2 implements the same operators as Facebook Unicorn (Curtiss et al., 2013).

8.2. Evaluation Results

EDB Generation. Firstly, we demonstrate the runtime performance of the encrypted database generator. The generator needs to partition and create additive shares from the original plaintext data, and to generate the adapted $\mathrm{OXT}$ index for each $\mathcal{IS}$. GraphSE2 uses $\mathcal{SF}$ to locally generate the partitions and additive shares for our dataset and then uses the dedicated cluster to generate the encrypted graph index in parallel. The result on our $5$ million records dataset shows that it only takes $54$ s to pre-process data on $\mathcal{SF}$ and $7.4$ mins to generate the encrypted index via Spark.

Storage. Recall that GraphSE2 uses adapted $\mathrm{OXT}$ index to support boolean queries over the encrypted graph, which needs to generate two dedicated data structure (i.e., $\mathrm{TSet}$ and $\mathrm{XSet}$). As a result, GraphSE2 consumes more storage capacity than the baseline system (see Figure 5), because it is required to keep more information (i.e., $\mathbf{xtag}$ in ciphertext), and because it stores encrypted index which is larger than the corresponding plaintext. By using the $\mathrm{TSet}$, we observe that our system increases the memory consumption of Redis by $85\%$ (557MB in $\mathrm{TSet}$ and 300MB in plaintext), which is slightly smaller than the theoretical memory consumption overhead ($100\%$ according to Figure 5). The reason is that GraphSE2 also keeps the number of blocks of each posting list (see Section 7) to accelerate the tuple retrieving process333If the size of posting list is unknown, the system needs to sequentially retrieve the tuple from blocks, as the key is derived from $\mathbf{stag}$ and block counter. Otherwise, the tuples can be retrieved in parallel.. As shown in Figure 5, the block counter requires an additional $20$ bytes of memory consumption for each indexing term both in $\mathrm{TSet}$ and in plaintext. It introduces the same extra cost on GraphSE2 as well as in the baseline system, and makes the memory consumption overhead smaller than the theoretical expectation.

For $\mathrm{XSet}$ storage overhead, GraphSE2 increases it by 17x (1.5GB versus 90MB), mostly due to the fact that the size group element is much larger than a PRF value. But the Bloom Filter successfully saves the memory consumption in runtime, because the size of Bloom Filter only depends on the false positive rate and the number of total elements inside (the number of edges in our system) (Bloom, 1970), and it is much smaller than $\mathrm{XSet}$ itself. By fixing the false positive rate to $10^{-6}$, the runtime overhead of $\mathrm{XSet}$ in our system is identical to the baseline system (only 18MB in RAM).

Query Delay. To understand the query delay introduced by cryptographic primitives, we measure the cryptographic overhead from these cryptographic primitives independently. To evaluate the query delay introduced by the set operations, we choose an indexing term a from friend edges with fixed selectivity ($130$, as the average user has $130$ friends according to Unicorn paper (Curtiss et al., 2013)), and we further choose several variable indexing terms v from friend edges with selectivity from $1$ to $502$. Figure 6 illustrates query delay on Index Access v and two variants of two-term Boolean Query. In Index Access v query, the query only consists of s-term v, and the figure shows that its execution time is linear to the size of corresponding posting lists. The other two-term queries combine the previous queries with the fixed term a. In the first of these two queries, we use a as x-term, each tuple from $\mathrm{TSet}({\bf v})$ should be checked wtih the cost of an exponentiation, which requires $2$ to $79$ ms to process. In the last one, a is used as s-term, where we observe that the execution time is kept invariable ($20$ ms), irrespective of the variable selectivity of the xterm v. It demonstrates that GraphSE2 can respond a query related to the moderate users with a tiny latency, and it is also able to reply query about popular users with a slightly bigger but still modest delay.

The secure addition and multiplication is supported by additive sharing scheme with a relatively small overhead, because in most cases, the two servers non-interactively do the computation tasks by using regular arithmetic operations, and because the expensive tasks, such as multiplication triplets generation, are pre-computed in the startup process. Figure 8a and 8b demonstrate the execution delay of addition and multiplication over the different size of vectors. We can see that the addition operation with two vectors containing $10^{4}$ entities can be done within $2$ ms. For the multiplication operation, it needs $80$ ms to compute the product of $10^{4}$ entities because it requires several efficient but non-negligible communications with the counter-party.

As the sorting algorithm is implemented by Garbled Circuit, we provide a benchmark about the size of the circuit and the corresponding evaluation time. The results are listed in Table 5. Note that we do not report the circuit generation time as it is generated in the startup process. The reported result demonstrates the practicality of our sorting strategy: the local sorting generally involves fewer entities after partition ($30$ if the system sorts a result list with $130$ users), which takes $100$ ms to sort. Additionally, the local sort can help to truncate the result before sending it for global sorting, which makes the sorting algorithm in Garbled Circuit more efficient (less than $440$ ms for a vector with $128$ entities).

We further examine the query delay from set operations under multiple-keyword setting by using the same a as s-term, but we add more variable terms $\{\mathbf{v_{n}}\},\mathbf{n}\in[1,5]$ as x-term. Figure 7 shows that each additional x-term increases the query delay by $20$ ms, which means a query with $5$ x-terms can still be processed within $100$ ms.

Communication. We measure the inter-cluster communication overhead, because it includes the main communication overhead in GraphSE2, which is to send the garbled sorting circuit as well as the labels of inputs to the counter-party. Note that this is much larger than sending the multiplication triplets ($12$ bytes for each) and the encrypted $\mathbf{id}$ ($16$ bytes for each). We demonstrate the communication overhead for different size of the circuit in Table 5. It shows that for an average user with approximately $130$ friends, the two-party only requires to transmits $9.80$MB data to sort them. This overhead is negligible both in our evaluation platform (40Gbps NIC in Azure intranet) and the other public clouds such as AWS.

Throughput. To evaluate the impact of our system on throughput, we measure the server throughput for different types of operators. For each operator, we compare the throughput results between GraphSE2 and the baseline. Figure 9 and Table 6 show the throughput test results for GraphSE2 and baseline. In all the cases, we group our 6 VM instances into 2 clusters with 3 VMs to fulfil the two-party settings. All VMs are running with only one core involved in the computation, and we simulate $10000$ parallel client processes to send the query to the server, which ensures $100\%$ workload on the server side. The results show that the throughput penalty is mainly from the sorting: the local sorting decreases the throughput by $38\%$ to $49\%$. We also observe that the global sorting is the bottleneck of the whole system (see Table 6), it gives a constant query throughput for all operators, which means it runs longer to obtain the final result. However, for the operators without sorting, the throughput loss is modest (only $4\%$ to $16\%$).

9. Conclusion

This paper presents an encrypted graph database, named GraphSE2. It enables privacy-preserving rich queries in the context of social network services. Our system leverages the advanced cryptographic primitives (i.e., $\mathrm{OXT}$, and mixing protocol with additive sharing and Garbled Circuit) with strong security guarantees for queries on structured social graph data, and queries with computation, respectively. To lead to a practical performance, GraphSE2 generates an encrypted index on a distributed graph model to facilitate parallel processing of the proposed graph queries. GraphSE2 is implemented as a prototype system, and our evaluation on YouTube dataset illustrates its efficiency on social search.

Appendix A Security Definition and Proof

A.1. Leakage Function

Recall the security definition from (Curtmola et al., 2011; Cash et al., 2013): The security of SSE is parameterised by a leakage function $\mathcal{L}_{\bf SSE}$, which depicts the scope of information about data and queries that the adversary is allowed to learn through the interaction with server.

Therefore, we start by giving the leakage function of query operators in GraphSE2. As shown in Section 5.3, all operators in GraphSE2 inherit the leakage of $\mathrm{OXT}$ (Cash et al., 2013) (i.e., $\mathrm{TSet}$ leakage $\mathcal{L}_{\bf T}$ and $\mathrm{OXT}$ leakage $\mathcal{L}_{\mathrm{OXT}}$).

Furthermore, all operators produce a sorted list as the return, it additionally introduces a new leakage about the rank of retrieved entities. We define a new leakage function $\mathcal{L}_{\rm R}$ to capture this new leakage. In particular, $\mathcal{L}_{\rm R}$ consists of two sub-functions $\{f_{0},f_{1}\}$ which are defined as follows:

• •

$f_{0}$: it takes as input the transcript of $\mathrm{OXT}$ and outputs a sorting circuit $F_{\it sort}$ and its input labels.

• •

$f_{1}$: it takes as input the transcript of $\mathrm{OXT}$ and outputs the rank $r_{\mathbf{id}}$ for every $e_{\mathbf{id}}$, where $r_{\mathbf{id}}\in\mathcal{N}$ is the rank of $e_{\mathbf{id}}$.

Note that the adversary can only corrupt one of the two parties in our system which means the adversary only can access one of the above two sub-functions during the simulation.

The overall leakage function $\mathcal{L}$ consists of the leakage from $\mathrm{OXT}$ as well as $\mathcal{L}_{\rm R}$.

A.2. Security Proofs

Based on the above leakage function, we give a security analysis for GraphSE2 following the real/ideal paradigm.

To start with, we define the real/ideal models for the query operators (e.g., term, and, etc.) that only involve structured data access and Garbled Circuit sorting, we denote the execution of the above query operators as query protocol $\Pi_{1}$.

The query protocol $\Pi_{1}$ is executed between a client $\mathit{C}$ ($\mathcal{SF}$) and two parties $\mathit{P}_{i},i\in\{0,1\}$ ($\mathcal{ISC}$s). In real model, an adversary $\mathcal{A}$ can choose a social dataset $\mathrm{DB}$ and let $\mathit{C}$ generate the corresponding encrypted database $\mathrm{EDB}$ and give it to $\mathcal{A}$. Then, $\mathcal{A}$ chooses a query list $\mathbf{q}$ to run in the two-party servers. To respond, each party firstly accesses $\mathrm{EDB}$ to retrieve contents and gives the transcript to $\mathcal{A}$. Later, they perform two-party sorting via Garbled Circuit scheme. During the sorting, $\mathcal{A}$ is able to see all inbound/outbound messages in the corrupted party.

We let $\mathrm{VIEW}^{i}_{\Pi_{1}}(1^{\lambda},\mathrm{DB},\mathbf{q})$ be the entire view of $\mathit{P}_{i}$ in an execution of $\Pi_{1}$. Let $\mathrm{OUT}^{i}_{\Pi_{1}}(1^{\lambda},\mathrm{DB},\mathbf{q})$ be the outputs of party $\mathit{P}_{i}$ in the end of a $\Pi_{1}$ execution. Considering the security assumption of untrusted but non-colluded adversaries on the two-party setting, an adversary $\mathcal{A}$ can corrupt one party at most. The assumption restricts that $\mathcal{A}$ only can get the entire view of the corrupted party and the outputs from the counter-party. Hence, $\mathrm{VIEW}^{i}_{\Pi_{1}}(1^{\lambda},\mathrm{DB},\mathbf{q})$ and $\mathrm{OUT}^{(1-i)}_{\Pi_{1}}(1^{\lambda},\mathrm{DB},\mathbf{q})$ are exactly the real model of $\mathcal{A}$ who corrupts $\mathit{P}_{i}$. In this case, we denote the adversary as $\mathcal{A}_{i}$ and set

$\mathrm{REAL}_{\Pi_{1},\mathcal{A}_{i}}(1^{\lambda},\mathrm{DB},\mathbf{q})\overset{def}{=}$

$(\mathrm{VIEW}^{i}_{\Pi_{1}}(1^{\lambda},\mathrm{DB},\mathbf{q}),\mathrm{OUT}^{(1-i)}_{\Pi_{1}}(1^{\lambda},\mathrm{DB},\mathbf{q}))$.

In the ideal model, the $\mathrm{EDB}$ of the chosen $\mathrm{DB}$ is generated by the simulator of $\mathrm{OXT}$ $\mathit{Sim}_{\mathrm{OXT}}$. In the query phase, each party processes the chosen query list $\mathbf{q}$ and returns the transcript to $\mathcal{A}$ via $\mathit{Sim}_{\mathrm{OXT}}$. Then, they hand their inputs to a trusted party $\mathit{TP}$ to perform sorting. We denote the above protocol executed in the ideal model as $\Pi_{1}^{{}^{\prime}}$. The view of $\mathcal{A}_{i}$ in the ideal model consists of the view on $\mathit{P}_{i}$ and the output of counter-party $\mathit{P}_{(1-i)}$. We set

$\mathrm{IDEAL}_{\Pi_{1}^{{}^{\prime}},\mathcal{A}_{i}}(1^{\lambda},\mathrm{DB},\mathbf{q})\overset{def}{=}$

$(\mathrm{VIEW}^{i}_{\Pi_{1}^{{}^{\prime}}}(1^{\lambda},\mathrm{DB},\mathbf{q}),\mathrm{OUT}^{(1-i)}_{\Pi_{1}^{{}^{\prime}}}(1^{\lambda},\mathrm{DB},\mathbf{q}))$.

Before we formalise the security of $\Pi_{1}$, we give the definition of computationally indistinguishable:

Definition 1 (Computationally Indistinguishable).

*Assuming a distribution ensemble $\mathcal{X}=\{\mathcal{X}_{i}\}_{i\in\mathcal{I}}$ is a sequence of random variables indexed by $\mathcal{I}$. Two distribution ensembles $\mathcal{X}=\{\mathcal{X}_{i}\}_{i\in\mathcal{I}}$ and $\mathcal{Y}=\{\mathcal{Y}_{i}\}_{i\in\mathcal{I}}$ are computationally indistinguishable, denoted as $\mathcal{X}\overset{c}{\equiv}\mathcal{Y}$, if for every probabilistic polynomial-time distinguisher $\mathcal{D}$, there exists a negligible function $\mathsf{negl}(\cdot)$, such that for every $i\in\mathcal{I}$

[TABLE]

.

The security of $\Pi_{1}$ is defined as follows:

Definition 2.

*Let $\Pi_{1}$, $\Pi_{1}^{{}^{\prime}}$ be as above. protocol $\Pi_{1}$ is said to be $\mathcal{L}$-semantically secure where $\mathcal{L}$ is the leakage function defined as before if for every non-adaptive adversary $\mathcal{A}_{i}$ in the real model, there exists a simulator $\mathcal{S}_{i}$ in the ideal model such that

$\{\mathrm{REAL}_{\Pi_{1},\mathcal{A}_{i}}(1^{\lambda},\mathrm{DB},\mathbf{q})\}_{i\in\{0,1\}}\overset{c}{\equiv}\{\mathrm{IDEAL}_{\Pi_{1}^{{}^{\prime}},\mathcal{S}_{i}}(1^{\lambda},\mathrm{DB},\mathbf{q})\}_{i\in\{0,1\}}$*

We further define our adaptive model as in (Cash et al., 2013). In such a model, the query list $\mathbf{q}$ is not given to the challenger in the above two games. Instead, $\mathcal{A}$ adaptively chooses each query after receiving $\mathrm{EDB}$.

We assume that $\Pi_{1}$ runs in a hybrid model where parties are given access to the trusted party computing the ideal function of OT. We show that $\Pi_{1}$ is secure with the given leakage function in this hybrid model. It follows from the standard composition theorems (Canetti, 2000) that $\Pi_{1}$ is secure with the given leakage function if the trusted party is replaced by secure protocol (i.e., real OT).

Theorem 1.

In the OT-hybrid model execution, protocol $\Pi_{1}$ is $\mathcal{L}$-semantically secure against non-adaptive adversaries, assuming that $\mathrm{OXT}$ protocol is $\mathcal{L}_{\mathrm{OXT}}$-semantically secure against non-adaptive adversaries, that the Garbled Circuit (GC) construction is secure against semi-honest but non-colluding adversaries.

Proof.

Let $\mathcal{A}_{i}$ denote an adversary corrupts $\mathit{P}_{i}$ attacking the protocol in a hybrid model where the parties run OT via trusted entities (OT-hybrid model). As the view of garbler and evaluator are different in $\Pi_{1}$, we consider separately the cases $i=0$ and $i=1$. We further denote the ensemble of $\mathit{C}$, the counter-party of $\mathit{P}_{i}$ and the trusted party $\mathit{TP}$ as the challenger $\mathcal{C}$ in our simulation. In both cases, we show that we can construct a simulator $\mathcal{S}_{i}$ running in our ideal model where the parties involve a trusted entity computing $\Pi_{1}^{{}^{\prime}}$, which returns the same view as $\mathcal{A}_{i}$’s in the hybrid model.

$\mathcal{S}_{i}$ is constructed as follows:

1. (1)

$\mathcal{S}_{i}$ chooses the $\mathrm{DB}$ and $\mathbf{q}$ and simulates $\mathcal{A}$. It firstly gives $\mathrm{DB}$ to $\mathcal{C}$. $\mathcal{C}$ runs $\mathit{Sim}_{\mathrm{OXT}}(\mathcal{L}_{\mathrm{OXT}}(\mathrm{DB}))$ and return $\mathrm{EDB}$ to $\mathcal{S}_{i}$. 2. (2)

For the given query list $\mathbf{q}$, $\mathcal{S}_{i}$ processes $\mathit{Sim}_{\mathrm{OXT}}(\mathcal{L}_{\mathrm{OXT}}(\mathrm{DB},q))$ and receives the output $\mathbf{tr}_{i}$ from $\mathit{Sim}_{\mathrm{OXT}}$. The output $\mathbf{tr}_{i}$ is identical to the transcript of $\mathrm{OXT}$ except that the query result of $\mathrm{OXT}$ only includes the encrypted id $e_{\mathbf{id}}$, but in $\Pi_{1}^{{}^{\prime}}$, the query result is a list of encrypted tuples $\{\mathbf{E}\}=\{(\langle x\rangle^{A},e_{\mathbf{id}})\}$.

This completes the the simulation of the structured data access part of $\Pi_{1}$. 3. (3)

Next, $\mathcal{S}_{i}$ hands $\mathbf{tr}_{i}$ to $\mathcal{C}$ and simulates the sorting procedure. As each party runs the same query on the same partition of the $\mathrm{OXT}$ index, the size of transcript is equal. $\mathcal{C}$ runs $f_{0}(\mathbf{tr}_{0},\mathbf{tr}_{1})$ to generate an array of sorting circuits $\mathbf{F}$ with $|\mathbf{tr}|$ circuits and $f_{1}(\mathbf{tr}_{0},\mathbf{tr}_{1})$ to generate an array of ranks $\mathbf{R}[e_{\mathbf{id}}]$ indexing by the $e_{\mathbf{id}}$ from $\mathbf{tr}$. 4. (4)

For each $\mathbf{tr}_{i}[j],1\leq j\leq|\mathbf{tr}|$, if $i=0$ (garbler):

1. (a)

$\mathcal{S}_{0}$ sends $\mathbf{tr}_{0}[j]$ to the $\mathcal{C}$ and receives $\mathbf{F}[j]$ and its input labels $\langle\mathrm{X}\rangle_{0}^{Y}$ from $\mathcal{C}$. In addition, $\mathcal{S}_{0}$ is able to get the labels $\langle\mathrm{X}_{0}\rangle_{1}^{Y}$ of its additive shares $\langle\mathrm{X}\rangle_{0}^{A}$. There is no message from the counter-party. 2. (b)

The counter-party ($\mathit{P}_{1}$) uses its $\mathbf{tr}_{1}[j]$ to retrieve a $\mathcal{L}_{\rm R}$-simulated ranked list $\{\bar{\mathbf{E}}\}=\{(r_{\mathbf{id}},e_{\mathbf{id}})\}$ from $\mathbf{R}[e_{\mathbf{id}}]$. 3. (c)

After execution, $\mathcal{S}_{0}$ outputs $\{\mathrm{EDB},\mathbf{tr}_{0}[j],\mathbf{F}[j],\langle\mathrm{X}\rangle_{0}^{Y},\langle\mathrm{X}_{0}\rangle_{1}^{Y}\}$ as $\mathrm{VIEW}^{0}_{\Pi_{1}^{{}^{\prime}}}(1^{\lambda},\mathrm{DB},\mathbf{q})$ and $\{\{\bar{\mathbf{E}}\}\}$ as $\mathrm{OUT}^{1}_{\Pi_{1}^{{}^{\prime}}}(1^{\lambda},\mathrm{DB},\mathbf{q})$. 5. (5)

If $i=1$ (evaluator):

1. (a)

$\mathcal{S}_{1}$ simulates OT protocol by generating the labels $\langle\mathrm{X}_{1}\rangle_{1}^{Y}$ for each evaluator’s input $\langle x\rangle_{1}^{A}$. 2. (b)

$\mathcal{S}_{1}$ retrieves ranks from $\mathbf{R}[e_{\mathbf{id}}]$ and constructs $\{\bar{\mathbf{E}}\}$. 3. (c)

Then, in the usual way (e.g. (Lindell and Pinkas, 2009; Bellare et al., 2012)), $\mathcal{S}_{1}$ simulates a sorting circuit $F_{\it sort}$ in such a way that given the input labels chosen by $\mathcal{S}_{1}$, the output of the circuit is precisely $\{\bar{\mathbf{E}}\}$. 4. (d)

Finally, $\mathcal{S}_{1}$ outputs $\{\mathrm{EDB},\mathbf{tr}_{1}[j],F_{sort},\langle\mathrm{X}_{0}\rangle_{1}^{Y},\langle\mathrm{X}_{1}\rangle_{1}^{Y},\{\bar{\mathbf{E}}\}\}$ as $\mathrm{VIEW}^{1}_{\Pi_{1}^{{}^{\prime}}}(1^{\lambda},\mathrm{DB},\mathbf{q})$ and $\{\emptyset\}$ as $\mathrm{OUT}^{0}_{\Pi_{1}^{{}^{\prime}}}(1^{\lambda},\mathrm{DB},\mathbf{q})$.

To complete the proof, we use the above simulator to show that

$\{\mathrm{REAL}_{\Pi_{1},\mathcal{A}_{i}}(1^{\lambda},\mathrm{DB},\mathbf{q})\}_{i\in\{0,1\}}\overset{c}{\equiv}\{\mathrm{IDEAL}_{\Pi_{1}^{{}^{\prime}},\mathcal{S}_{i}}(1^{\lambda},\mathrm{DB},\mathbf{q})\}_{i\in\{0,1\}}$:

1. (1)

$\mathrm{EDB}$ and $\mathbf{tr}$ in the real model are generated by running $\mathrm{OXT}$ protocol, while in the ideal model, they are simulated by given the output of leakage function. 2. (2)

For $i=0$ (garbler):

1. (a)

In the real model, the garbler constructs the sorting circuit correctly based on garbler’s inputs, while in the ideal model the garbled circuit is a dummy circuit in $\mathbf{F}$ with the given input labels from $\mathcal{C}$. 2. (b)

In the real model, the evaluator gets the output $\{\bar{\mathbf{E}}\}$ after evaluating the circuit. In the ideal model, the output is obtained from the trusted entity via the output of leakage function $\mathcal{L}_{\rm R}$. 3. (3)

For $i=1$ (evaluator):

1. (a)

In the real model, $F_{\it sort}$ and the input label sent by the garbler is correctly generated based on garbler’s inputs, while in the ideal model the garbled circuit is simulated based on the random generated input labels and the output of leakage function $\mathcal{L}_{\rm R}$ from $\mathcal{C}$. It ensures that the circuit returns the same output in two models. 2. (b)

Both in the real and ideal model, the garbler does not output a result in the end of the protocol execution.

The security properties of $\mathrm{OXT}$ ensures the indistinguishability of structured data access part. For the sorting part, The privacy property of Garbled Circuit (Bellare et al., 2012) ensures that the adversary only can learn the inputs from the circuit and output with a negligible probability. It concludes that for every non-adaptive adversary $\mathcal{A}_{i}$, it has negligible probability to learn more information than the defined leakage function $\mathcal{L}$. ∎

We now show that our theorem is also valid for adaptive models.

Theorem 2.

In the OT-hybrid model execution, protocol $\Pi_{1}$ is $\mathcal{L}$-semantically secure against adaptive adversaries, assuming that $\mathrm{OXT}$ protocol is $\mathcal{L}_{\mathrm{OXT}}$-semantically secure against adaptive adversaries, that the Garbled Circuit (GC) construction is secure against semi-honest but non-colluding adversaries.

Proof.

First of all, $\mathrm{OXT}$ protocol has been proved to be $\mathcal{L}_{\mathrm{OXT}}$-semantically secure against adaptive adversaries (Cash et al., 2013). The only concern here is how to handle the adaptivity towards sorting.

To simulate the response for adaptive queries, the simulator should adaptively generate the ranks $\mathbf{R}[e_{\mathbf{id}}]$ for $e_{\mathbf{id}}$ list, This is in contrast to the non-adaptive simulator, where it can generates $\mathbf{R}[e_{\mathbf{id}}]$ as determine by the leakage. Instead, the simulator uses the STag and $e_{\mathbf{id}}$ list from the transcript to maintain a bidimensional array $\mathbf{R}[STag,e_{\mathbf{id}}]$. It adaptively updates $\mathbf{R}[STag,e_{\mathbf{id}}]$ for each new $e_{\mathbf{id}}$ which does not exist in $\mathbf{R}[STag,e_{\mathbf{id}}]$. ∎

Finally, we show that the defined operator (i.e., apply) is also secure after involving arithmetic computations. We slightly modify our hybrid model by adding an ideal function $f_{A}$, which evaluates arbitrary addition/multiplications using the ideal function of additive sharing scheme. The new hybrid model is defined as ($f_{A}$,OT)-hybrid model.

Theorem 3.

In the ($f_{A}$,OT)-hybrid model execution, protocol $\Pi_{1}$ is $\mathcal{L}$-semantically secure against adaptive adversaries, assuming that $\mathrm{OXT}$ protocol is $\mathcal{L}_{\mathrm{OXT}}$-semantically secure against adaptive adversaries, that the Garbled Circuit (GC) construction is secure against semi-honest but non-colluding adversaries.

Proof.

We have shown that the output ranks can be simulated without using the actual additive shares in Theorem 1, 2. Informally, it also indicates that $\Pi_{1}$ can also securely perform structured data access and sorting under the ($f_{A}$,OT)-hybrid model. In addition, previous work shows that the additive sharing scheme can securely compute the given arithmetic formulas (Pullonen et al., 2012). The standard sequential modular composition (Canetti, 2000) implies that $\Pi_{1}$ with sub-protocols evaluating $f_{A}$ and OT remains secure with the same leakage $\mathcal{L}$ in the real model. ∎