Security of Databases

1. Data Outsourcing
Security of Database

2. Purpose
A Practical and Privacy-Preserving Outsourced Database

3. Outline
• Outsourcing
• Long White Cloud (LWC)
• Previous approaches
• Future works

4. Where to have outsourcing!?

5. Secure Data
A Naive Approach
• Use standard encryption techniques
• No operations could be performed

6. SSE Scheme
Searchable Symmetric Encryption
• Introduced by Song in 2000
• Fully Homomorphic Encryption (FHE)
• Oblivious RAM (ORAM)
• Secure Multi-Party Computation (SMC)
• Problem ?!

7. Problems
1. Information Leakage
Correlation between the queries and the matched data
Solution :
ORAM and PIR:
 To minimize information leakage
 Very costly
 Not scale well
 When dealing with dynamic data

8. Problems
2. Lack of Support for a Full-Fledged Multi-User Access
a) All users share the same key (Single User (SU) schemes)
b) have a read-only key shared among all the users
and one special key for inserting/updating data
(Semi Fledged Multiple User (SFMU) schemes)
Misplacing a key or revoking access
Generation of a new key and re-encryption

9. Solution
A Full-Fledged Multi-User (FFMU) scheme:
• Any authorized user is able to read and write
• Users are able to join and leave the organization at
any time without affecting rest of the users.
LWC !

10. Long White Cloud
• Sub-linear Dynamic SSE
• Supports high throughput of queries
• Minimizes information leakage
• Designed for large organizations
Main Idea:
Using a hybrid private/public cloud approach
• Private part of the infrastructure
to store the encrypted data
 Speeding up the query processing
to minimize information leakage
on their local premises
• The rest to a public cloud provider

11. Long White Cloud

12. Long White Cloud
• DataBase User (DBU)
• DataBase Administrator (DBA)
• Operations Proxy Server (OPS)
• Private Cloud
• Cloud Server (CS)
• Public Cloud
• Key Management Authority (KMA)
• responsible for issuing encryption keys

13. How to initialize the system?!
Step 1: Set up the OPS
Step 2: Prepare the DB on CS
Step 3: Bringing the KMA online

14. • Encrypting and Sending
queries to OPS
What are the steps?
• Fetching data from CS by
OPS
• Doing calculation in OPS
• Encrypting data and sending
responses to DBU
2
1
3
4
1
2
4
3

15. Details
• (𝐾 𝐷𝐵𝑈, 𝐾 𝑈)
• DBU has Both, OPS has the first
• First encrypted by 𝐾 𝑈 then 𝐾 𝐷𝐵𝑈
• First Encryption : Deterministic and
Symmetric to be searchable ( Just
keywords)
• Second Encryption: Semantically secure

16. Example of Encryptions
The first Encryption:
“select * from Staff WHERE
"𝐾 𝑈 (name) ="𝐾 𝑈 (Alice)
AND "𝐾 𝑈 (age) = "𝐾 𝑈 (25)”
The second Encryption:
All the data

17. Details

18. Cloud Server
Blocks, Slots ( Records), Cells
B+ Tree:
An encrypted keyword, and a pointer points to
a list of (bi; sj) indicating the record store
location on the CS.

19. Oblivious Access
Problem:
• All users have 𝐾 𝑈
• Revoked users can access CS!
Solution:
• Using a pseudo-random permutation
• Keeping seed in OPS

20. Security Analysis
γ − k blocks are picked randomly
K : needed blocks
γ: random blocks
Fills a number of empty slots with random
bit strings for each block

21. Security Analysis
• Search Pattern Privacy (SPP)
• Distinguishing if two (or more)
queries are the same or not
• Achieved by random blocks
• Access Pattern Privacy (APP)
• Unable to learn if two (or more)
real result sets overlap or not
• Achieved in 2 levels:
• Having Blocks
• Random Blocks

22. Security Analysis
• Size Pattern Privacy (SzPP):
• Unable to learn the size of returned (real)
records.
• Achieved in 2 levels:
• Fetching data in blocks NOT slots
• Having γ
• Operation Pattern Privacy (OPP):
• Unable to tell if the executed query is a
select, update, delete, or insert.
• Achieved by γ
• Deleting by changing the flag

23. Threats
1. External attack on OPS
2. Due to deterministic encryption
APP, SPP and OPP is in danger

24. Experimental Evaluation
• Intel i5-4670 3:40 GHz processor
• 8 GB of RAM
• Linux Ubuntu 15.04
• Programmed in C
• Compiled using GCC version 4.9.2
• No parallel operations or hyper-threading
• OPS: picked up 2·k blocks
• (k: needed blocks to execute the query)

25. Experimental Evaluation
End-to-end search time in LWC Query throughput comparisons for database schemes.

26. Experimental Evaluation
Time taken for executing an insert query in LWC. Time taken for executing a delete query in LWC

27. Future Works
Untrusted Cloud Servers

28. • Shujie Cui, Ming Zhang, Muhammad Rizwan Asghar and Giovanni Russello (The University of
Auckland, New Zealand). Long White Cloud (LWC): A Practical and Privacy-Preserving
Outsourced Database
Reference
• http://www.onlinetech.com/
• D. Cash, P. Grubbs, J. Perry, and T. Ritsenpart. Leakage-abuse attacks against
searchable encryption.