We demonstrate GOOSE, an open-source framework for secure graph outsourcing and SPARQL evaluation. We showcase the workow of GOOSE over various real-world use cases, the scalability of GOOSE, and the security properties that GOOSE guarantees in the honest-butcurious cloud security model.
Enhancing Semantic Web technologies with security and privacy guarantees is an
important and popular problem [
We take a complementary look by addressing the security issues that occur
when outsourcing an RDF graph to the cloud and querying the outsourced graph
with SPARQL. Our scenario is inspired by the database as a service cloud
computing model [
We demonstrate GOOSE, an open-source framework that relies on
cryptographic schemes and secure multi-party computation to achieve desirable
security properties: (i) no cloud node can learn the graph, (ii) no cloud node can learn
at the same time the query and the query answers, and (iii) an external network
observer cannot learn the graph, the query, or the query answers. GOOSE has
been presented3 as a full paper at the DBSec 2020 [
In Sect. 2, we present an overview of GOOSE, whereas in Sect. 3 we describe our demonstration scenarios. Due to lack of space, we omit several details (related work, theoretical and empirical analysis) that can be found in the GOOSE ? Copyright c 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 3 https://www.youtube.com/watch?v=ZhtpulFf3rs
(1) Enc(Q) User (4) Enc(Ans(G; Q)) (3) Enc(Ans(Gb; Qb))
Answers Translator (2) Enc(Qb)
SPARQL Engine (0) Enc( V ) (0) Enc( ) (0) Enc(Eb)
Fig. 1. Architecture of GOOSE.
TravelsTo
Paris
Alice
ReadsAbout TravelsTo
Charlie
Follows Follows
Follows Follows
Bob David
TravelsTo ReadsAbout
Milan
conference paper [
In Fig. 1, we show the architecture of GOOSE, which has 5 participants: data
owner (DO), who owns the graph that it outsources to the cloud in order to be
queried, user (U), who submits graph queries to the cloud and receives query
answers, and 3 cloud participants: query translator (QT), SPARQL engine (SE)
and answers translator (AT). Each Enc from Fig. 1 uses the AES [
We focus on Unions of Conjunctions of Regular Path Queries (UCRPQ) that are at the core of SPARQL 1.16, including recursive queries via Kleene star. By Ans(G; Q) we denote the answers of query Q over a graph G, using standard SPARQL semantics. For example, the UCRPQ (?x; ?z) (?x; Follows+; ?y), (?y; TravelsTo; ?z) selects nodes ?x; ?z s.t. there exists node ?y s.t. one can go from ?x to ?y with a path in the language of \Follows+" and can go from ?y to ?z with a path in the language of \TravelsTo". The answers of this query on the 4 https://github.com/radu1/goose 5 https://www.w3.org/TR/rdf11-concepts/ 6 https://www.w3.org/TR/sparql11-query/ graph from Fig. 2 are (Alice, Milan), (Alice, Paris), (Bob, Milan), (Bob, Paris), (David, Paris). For example, the tuple (Alice, Paris) is an answer because of paths Alice Follows Bob Follows David Follows Charlie and Charlie TravelsTo Paris, where ?x; ?!y; ?z are map!ped to Alice, C!harlie, Paris, respectively. ! Step 0. The graph outsourcing (i.e., the 3 outgoing arrows from DO in Fig. 1) is done only once at the beginning by DO. Intuitively, DO sends to each cloud participant a piece of G s.t. each participant can perform its task during query evaluation but no participant can reconstruct the entire graph. To to so, DO generates 2 random bijections: (for edge labels) and V (for graph nodes). By 1 we denote the inverse of (this is needed later on at the end of query evaluation). For our example graph in Fig. 2, DO may generate: V =fAlice ! 5; Bob ! 3; Charlie ! 0; David ! 1; Milan ! 2; Paris ! 4g =fFollows ! 1; ReadsAbout ! 2; TravelsTo ! 0g: DO uses these 2 functions to hide graph edges: by Eb we denote the hidden set of edges generated from E, where nodes are replaced using V , and edge labels are replaced using . On our example in Fig. 2, edge (Alice, Follows, Bob) becomes (5, 1, 3), edge (Alice, ReadsAbout, Paris) becomes (5, 2, 4), and nally:
Eb = f(5;1;3); (5;2;4); (5;0;4); (3;1;5); (3;1;1); (3;0;2); (0;0;4); (1;1;0); (1;2;2)g: Each message sent over the network is encrypted with the key shared between DO and the corresponding cloud participant, which can decrypt the message upon reception. Messages are encrypted to avoid that an external observer that sees them in clear is able to learn the graph G. The distribution of graph storage among cloud participants makes that none of them can learn the graph G.
We next discuss query evaluation i.e., steps 1{4 cf. Fig. 1, done for each query submitted by U. Each message exchanged over the network during query evaluation is encrypted with the key shared between corresponding participants, such that an external observer cannot learn the query and its answers. Step 1. U submits query Q to QT. For example, recall the aforementioned query (?x; ?z) (?x; Follows+; ?y); (?y; TravelsTo; ?z).
Step 2. QT translates Q by replacing all labels used in Q using the function received from DO. By Qb we denote the query Q translated using . On our example, query from step 1 becomes (?x; ?z) (?x; 1+; ?y); (?y; 0; ?z). Step 3. SE evaluates translated query Qb received from QT at step 2 on the graph with hidden nodes and edge labels as de ned by Eb received from DO during step 0. To do so, SE simply uses some standard SPARQL engine as a black-box, without any change to the query engine7. We denote the result of SE by Ans(Gb; Qb), where the true answers Ans(G; Q) are still hidden using function
V . On our example, Ans(Gb; Qb) = f(5; 2); (5; 4); (3; 2); (3; 4); (1; 4)g. Step 4. AT uses function V 1 to translate hidden query answers Ans(Gb; Qb) into true query answers. On our example, AT recovers Ans(G; Q) =f(Alice, Milan), (Alice, Paris), (Bob, Milan), (Bob, Paris), (David, Paris)g that AT sends to U. 7 In our implementation, we rely on Apache Jena https://jena.apache.org/
We (i) introduce via examples the complete work ow of GOOSE and the class
of supported SPARQL queries using real-world scenarios, (ii) emphasize the
scalability of GOOSE, and (iii) point out the security properties of GOOSE and
the security model in which these properties hold.
(i) GOOSE by example. On the GitHub repository of GOOSE (URL given in
Sect 1), in the directory running-example, we included the script example.sh
that reproduces the running example from Sect. 2 and [
Going back to the demo, we stress that the aforementioned running example script provided on the GOOSE repository can be easily run on a laptop. If one tries the script and gets some error, it is likely that there are some missing packages. GOOSE is written in Python, and uses Apache Jena (written in Java) for SPARQL evaluation and gMark (written in C++) for graph and query workload generation. The script install-libraries.sh installs the necessary libraries. Before running this script, one should be aware that, depending on the former state of her computer, it may be more or less trivial to go back to that state8.
In addition to the running example, we have a prede ned script that relies
on four real-world cases based on gMark: uniprot (biological data where proteins
interact with other proteins, are encoded on genes, etc.), shop (online shop selling
di erent types of products to users, etc.), social-network (social network where
persons know other persons, work in companies, etc.), and bib (bibliographical
data about researchers that author papers published in journals or conferences,
etc.). We discuss how to use this script when describing the next scenario.
(ii) Scalability. The idea of this scenario is to generate graphs of increasing sizes
and observe that GOOSE has a linear time behavior for the graph outsourcing. As
for the query evaluation, we generate queries having diverse properties (w.r.t.
arity, selectivity, shape, and use of recursion), run GOOSE, and zoom on the
time taken by each step of GOOSE. One should observe that the bottleneck of
secure query evaluation in GOOSE does not come from the use of cryptographic
primitives, but is due to the SPARQL engine used as a black-box, in particular for
8 We leave as future work the \dockerization" suggested by Anonymous Reviewer 1.
evaluating recursive queries. These observations should con rm the theoretical
and empirical analysis detailed in the full paper on GOOSE [
The script script-complete-workflow.sh allows to run such a complete
work ow. As currently con gured, the script should generate the large-scale
experiment reported in [