Self-Enforcing Access Control for Encrypted RDF

Self-Enforcing Access Control for Encrypted RDF
Javier D. Fernández,Sabrina Kirrane, Axel Polleres,Simon Steyskal
ESWC 2017– Portorož

Publishing Linked Open Data
Motivation
“Open data and content can be freely used, modified,
and shared by anyone for any purpose” - http://opendefinition.org/
RDB2RDF
RDB2RDF
RDB2RDF
Interface
RDF Store
RDF(a) Document

What about Linked Closed Data?
Motivation
§ What are the incentives for data owners to publish their
data as Closed Data?
§ financial considerations, compliance with institutional/community
norms, privacy requirements, …

Publishing Linked Closed Data
Motivation
§ In order to also cater for Linked Closed Data, existing
infrastructure needs to be extended with suitable
security mechanisms:
Encryption
Selectively grant or
revoke access to data.
Protect data against
unauthorized access.
Access control

Allow Multiple Users Access to Encrypted Data
Concrete example
Alice
Admin
„What‘s my ex:salary?“
„Show me all triples!“
Multiple Users Encryption Granularity

Scenario 1: a key for everything
Encryption is coarse-grained
S P O
ex:Alice foaf:pastProject ex:Project1
ex:Alice ex:salary 30000
ex:Alice foaf:mbox "alice@example.org"
ex:Bob foaf:pastProject ex:Project1
ex:Bob ex:salary 20000
ex:Bob foaf:mbox "bob@example.org"
Alice
Admin
ex:Bob earns
less than me!
What‘s my
ex:salary?
Show me all
triples!
Alice shouldn’t have access
to that information!

Scenario 2: a key for each triple
PAGE 7
S P O
Alice
Admin
I don‘t want
all those
keys..
What‘s my
ex:salary?
Show me all
triples!
Admin has to manage
a lot of keys!

Scenario 3: a key for each user
PAGE 8
S P O
Alice
Admin
I don‘t want
all those
keys..
What‘s my
ex:salary?
Show me all
triples!
Admin has to manage
a lot of keys!

Scenario 4: one key opens multiple locks
Encryption based on patterns
S P O
Alice
Admin
Only 1 key,
that‘s much
better
What‘s my
ex:salary?
Show me all
triples! = (ex:Alice, ex:salary, ?)
= (?, ?, ?)
one key can open
multiple locks

1. Compute the triple vector using a mapping function to map the subject,
predicate, and object value to elements in ℤ 𝑁
2. Functionally encrypt a randomly generated seed using the triple vector
3. Derive an encryption key from our previously generated seed and use AES to
encrypt the triple with an encryption key
4. Return the triple cipher and the decryption key
Encryption of RDF Triples
A Functional Encryption Scheme for RDF
triple vector
key
triple cipher
1)
2) 3)
4)
jpbc http://gas.dia.unisa.it/projects/jpbc/#.WS73m_exW7M

Encryption of RDF Triples
triple vector
triple cipher
𝜎 denotes a mapping function that maps a triple’s
subject, predicate, and object value to elements in ℤ 𝑁
key

Decryption of RDF Triples
𝒚 𝒔 𝒕
𝒚′ 𝒔 𝒕
𝒚 𝒑 𝒕
𝒚′ 𝒑 𝒕
𝒚 𝒐 𝒕
𝒚′ 𝒐 𝒕
−𝑟+ ∗
𝜎(𝐴𝑙𝑖𝑐𝑒) 𝑟+ −𝑟5 ∗
𝜎(𝑝𝑎𝑠𝑡𝑃) 𝑟5 −𝑟; ∗
𝜎(𝑃𝑟𝑜1) 𝑟;
tp = (ex:Alice, foaf:pastProject, ?)
t = (ex:Alice, foaf:pastProject, ex:Project1)
𝐱 𝒔 𝒕𝐩
𝐱′ 𝒔 𝒕𝐩
𝐱 𝒑 𝒕𝐩
𝐱′ 𝒑 𝒕𝐩
𝐱 𝒐 𝒕𝐩
𝐱′ 𝒐 𝒕𝐩
1 𝜎(𝐴𝑙𝑖𝑐𝑒) 1 𝜎(𝑝𝑎𝑠𝑡𝑃) 0 0
−𝑟+ ∗
𝜎 𝐴𝑙𝑖𝑐𝑒 + 𝑟+ ∗
𝜎 𝐴𝑙𝑖𝑐𝑒 + −𝑟5 ∗
𝜎 𝑝𝑎𝑠𝑡𝑃 + 𝑟5 ∗
𝜎 𝑝𝑎𝑠𝑡𝑃 + 0 + 0 = 0
compute the inner-product of their
corresponding triple vector

Optimising Query Execution
S P O
= (ex:Alice, ?, ?)
She has to always check
each and every triple

O S P
P O S
3-Index
S P O
= (ex:Alice, ?, ?)
S P O
We use three key-
value B-Trees and data
is encrypted using a
strong hash function

O S P
3-Index
S P O
S P O
= (?, foaf:pastProject, ex:Project1)
P O S
ex:salary 30000 ex:Alice
ex:salary 20000 ex:Bob
foaf:mbox
"alice@example.or
g"
ex:Alice
foaf:mbox "bob@example.org" ex:Bob
foaf:pastProject ex:Project1 ex:Alice
foaf:pastProject ex:Project1 ex:Bob
We use three key-

S O
ex:Alice ex:Project1
ex:Bob ex:Project1
S O
ex:Alice 30000
ex:Bob 20000
S O
ex:Alice "alice@example.org"
ex:Bob "bob@example.org"
Vertical Partitioning
foaf:mbox
ex:salary
foaf:pastProject
S
ex:Alice foaf:pastPro
ex:Alice ex:salar
ex:Alice foaf:mbo
ex:Bob foaf:pastPro
ex:Bob ex:salar
ex:Bob foaf:mbo
= (?, foaf:pastProject, ex:Project1)
We use three key-

S O
ex:Alice ex:Project1
ex:Bob ex:Project1
S O
ex:Alice 30000
ex:Bob 20000
S O
ex:Alice "alice@example.org"
ex:Bob "bob@example.org"
foaf:mbox
ex:salary
foaf:pastProject
= (ex:Alice, ?, ?)
S
ex:Alice foaf:pastPro
ex:Alice ex:salar
ex:Alice foaf:mbo
ex:Bob foaf:pastPro
ex:Bob ex:salar
ex:Bob foaf:mbo
We use three key-

Experiment Setup
Evaluation
§ Real-world datasets from different domains:
§ Census represents the 2010 Australian census
§ Jamendo lists music records and artists
§ AEMET includes sensor data from weather stations in Spain
§ Lehigh University Benchmark (LUBM) data generator to obtain synthetic
datasets

Encrypting and Indexing
Evaluation
§ Both strategies report similar performance results
Ø VP is slightly faster for loading given that only the subject and object is
used to index each triple
§ Encryption overhead
Ø can be of one order of magnitude greater for the smaller datasets
Ø this is greatly reduced for larger datasets
B-Tree
indexes
become
slower the
more triples
are added
(due to
rebalancing)

Query Resolution
Evaluation
§ 3-Index is better than VP for queries with unbound predicates as VP
has to iterate though all predicate tables in this case
§ There is minimum overhead between the plain and encrypted
indexes if a look-up returns only a small amount of results
LUBM Jamendo
if you have
to decrypt
more triples,
it takes
more time
overall

Scalability
Evaluation
§ Our approach allows for parallel encryption/decryption of
triples
Ø scales with the system’s supported level of parallelization
§ Encrypting and indexing (3-Index) 10,000 LUBM triples takes
about:
Ø 76s with 16 available cores
§ Each result triple can be returned as soon as its decryption
has finished!

Results
Conclusion
§ Practical realisation of a functional encryption scheme for
RDF
§ generate decryption keys based on (triple-)patterns
§ a decryption key can decrypt all triples that match its associated triple
pattern
Ø provides a high degree of flexibility and enables controlled access to
encrypted RDF data
§ Evaluation
§ reasonable loading and query performance overheads with respect to
traditional, non-encrypted data retrieval
§ relatively slow for batch decryption, but it is suitable for serving
incremental results
https://aic.ai.wu.ac.at/comcrypt/sld/

Future Work
Conclusion
Evaluate different indexing strategies
Ø optimise the loading time and query performance of large queries
Cater for named graphs
Ø encrypting quads instead of triples and generating keys based on quad
patterns
Triple store for compressed encrypted data
Ø Current implementation uses an offtheshelf key value store
Ø Build a custom triple store based on HDT
Add a “policy” tier
Ø manages the access/revocation of query keys and serve as fully fledged
security framework for Linked Data

Self-Enforcing Access Control
for Encrypted RDF
S P O
Alice
Admin
Only 1 key,
that‘s much
better
Show me
ex:salary?
Show me all
triples!
= (ex:Alice, ex:salary, ?)
= (?, ?, ?)

Overview
Public Key Encryption
data owner will encrypt data to
the public key of a specific user
only a user possessing the corresponding
private key can decrypt the ciphertext
§ Encryption is targeted towards a specific user
§ Decryption is an all or nothing operation; either:
a) a ciphertext is fully decrypted and the original data is recovered
b) it fails and nothing is learned.
Figure taken from http://www.infosectoday.com/Articles/Intro_to_Cryptography

Functional Encryption to the Rescue!
More fine-grained control over access to encrypted data
§ Functional Encryption
§ secret keys correspond to functions in some class 𝐹
§ each ciphertext is associated with a (secret) attribute of some
attribute space 𝛴
§ a ciphertext associated with 𝐼 ∈ 𝛴 can be decrypted by a secret
key 𝑠𝑘G corresponding to the function 𝑓 ∈ 𝐹 iff 𝑓(𝐼) = 1.
§ Inner-product Functional Encryption
§ Each ciphertext is associated with a (secret) attribute vector 𝒚
§ Each secret key corresponds to a vector 𝒙 that is incorporated into
its respective boolean function 𝑓 𝒙
𝑓 𝒙(𝒚) = 1 iff 𝒙 J 𝒚 = 0
J. Katz et al.: “Predicate Encryption Supporting Disjunctions,Polynomial
Equations, and Inner Products”. J. Cryptology,26(2): 191–224, 2013.

Generating Decryption Keys
serves as a wildcard

Query Resolution (cold)
Evaluation
§ 3-Index reports a noticeable better performance than VP
for queries with unbound predicates
§ VP has to iterate though all predicate tables in this case.
§ 3-Index and VP remain competitive wrt. their non-secure
counterparts, if a look-up returns only a small amount of
results
§ Decrypting Jamendo entirely took about 2256s using VP
and 2808s using 3-Index
§ Leading to triple decryption rates of 465 triples/sec and
374 triples/sec respectively Each result triple can be
returned as soon as its
decryption has finished!

Query Resolution (cold)
Evaluation
§ 3-Index reports a noticeable better performance than VP
for queries with unbound predicates
§ VP has to iterate though all predicate tables in this case.
§ 3-Index and VP remain competitive wrt. their non-secure
counterparts, if a look-up returns only a small amount of
results
§ Decrypting Jamendo entirely took about 2256s using VP
and 2808s using 3-Index
§ Leading to triple decryption rates of 465 triples/s and
374 triples/s respectively
Each result triple can be
returned as soon as its
decryption has finished!
5M LUBM triples Jamendo

𝒚 𝒔 𝒕
𝒚′ 𝒔 𝒕
𝒚 𝒑 𝒕
𝒚′ 𝒑 𝒕
𝒚 𝒐 𝒕
𝒚′ 𝒐 𝒕
−𝑟+ ∗
𝜎(𝐴𝑙𝑖𝑐𝑒) 𝑟+ −𝑟5 ∗
𝜎(𝑝𝑎𝑠𝑡𝑃) 𝑟5 −𝑟; ∗
𝜎(𝑃𝑟𝑜1) 𝑟;
tp = (ex:Alice, ex:salary, ?)
t = (ex:Alice, foaf:pastProject, ex:Project1)
𝐱 𝒔 𝒕𝐩
𝐱′ 𝒔 𝒕𝐩
𝐱 𝒑 𝒕𝐩
𝐱′ 𝒑 𝒕𝐩
𝐱 𝒐 𝒕𝐩
𝐱′ 𝒐 𝒕𝐩
1 𝜎(𝐴𝑙𝑖𝑐𝑒) 1 𝜎(𝑠𝑎𝑙𝑎𝑟𝑦) 0 0
−𝑟+ ∗
𝜎 𝐴𝑙𝑖𝑐𝑒 + 𝑟+ ∗
𝜎 𝐴𝑙𝑖𝑐𝑒 + −𝑟5 ∗
𝜎 𝑝𝑎𝑠𝑡𝑃 + 𝑟5 ∗
𝜎 𝑠𝑎𝑙𝑎𝑟𝑦 + 0 + 0
≠ 0

3-Index

Self-Enforcing Access Control for Encrypted RDF

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Viewers also liked

Viewers also liked (8)

Similar to Self-Enforcing Access Control for Encrypted RDF

Similar to Self-Enforcing Access Control for Encrypted RDF (20)

More from Sabrina Kirrane

More from Sabrina Kirrane (8)

Recently uploaded

Recently uploaded (20)

Self-Enforcing Access Control for Encrypted RDF