MPC Cloud Database with Sense of Security

Introduction Cloud computing – IT as a service from third party service provider Security in cloud environment – Adversary corrupts the service provider? – Goal: protect sensitive data

Related Work Encryption Approach – NetDB2, IBM (Outsourced database) – Relational Cloud, CryptDB (MIT, CIDR 2011) – TrustedDB using secure hardware (VLDB 2011 demo, Radu Sion) Secure Multi-Party Computation Approach – ShareMind

NetDB2 Tuple 1xxxyyy Tuple 2aaabbb Tuple 1!a4a3g Tuple 2L%jm*K Value-level encryption SELECT * WHERE value = `xxx’SELECT * WHERE value = `!a4’ DB Encrypted DB Tuple 1P2 Tuple 2P1 + Partition information Partition: P1: < `m’; otherwise P2 SELECT * WHERE value < `xxx’SELECT * WHERE value in [P1, P2] Simple deterministic encryption

CryptDB Onion-encryption: multiple encryption done on 1 data 10 Original data encrypt E 1 (10) = A*65h OPES: numeric comparisons E 2 (A*65h) = BB647 Deterministic encryption Equality can be done Non-deterministic encryption No computation is feasible E 3 (BB647) = If the user wants more computation power, decrypt to the desired level (one way!)

ShareMind Key: Secret sharing + recursive processing A B C Service Provider 1 Service Provider 2 Service Provider 3 Query Result D E F D + E + F = Result DB DB = A + B + C

Comparisons of the two approaches Encryption-based methods – Provide limited computation capabilities – Security strength depends on the encryption function For example, deterministic encryption may allow a frequency analysis attack – `Male’, `Female’ => `%k9)2’, `Ah475’ – `Ah475’ x 21; `%k9)2’ x 5 in DB group MPC-based methods (Our choice) – More generic operators – Security: no knowledge gained by service providers

A downside of MPC-based approach DB ABC SP2SP1SP3 Owner DBA BC SP1SP2 Owner Model 1: What if all service providers collude? Model 2: Owner has to join in MPC operations, (storage and computation) cost not less than hosting DB on its own

Research problem Owner keeps a small share A (small storage) Goal: – Without A, SP1 and SP2 cannot recover DB or any information about DB! (similar security strength as MPC) – Owner has minimal involvement in MPC (low cost) DB A BC SP1SP2 Owner Model 3

Secure multiparty computation Background

Secret sharing (around 1980) 10 Secret 4 6 shares AliceBob 6+4 = 10 What is the secret value? Alice’s share would be 5? 20? -3? The secret is recovered only when the two parties exchange their shares

Secret sharing General case s Secret s1s1 s2s2 …snsn The secret can be divided into n parties, for any n s = g(s 1, s 2, …, s n ) Example: Sum of all shares (modular) Bitwise XOR of all shares Product, string concatenation, etc… Security requirement: Given k < n shares, it is hard to recover s

Secure multiparty computation Party 1 x1x1 Party 2 x2x2 Party n xnxn … Objective: Every party obtains f(x 1, x 2, …, x n ) but cannot observe any other information apart from its own data r = f(x 1, x 2, …, x n ) r r r

New approach

Before we proceed…. Clarifying the security Negative result – Ideal security: Querying workflow: user issues query => service providers compute result and return to user Knowledge gained by service providers: NONE. Not even anything about query and result! – A solution achieving ideal security is not more efficient than a non-outsourcing solution (not using cloud)

Knowledge gained by service provider Output space of a simple selection query: varies from no tuple to the entire database – Even larger space if we consider joins Example knowledge gain – If the output size is small, the service provider knows it is not the case that the query selects entire table To hide the above information, each returned query result should be at least of size = entire table

Security in secure database Each service provider can observe – Query content The tables that are related to the query Number of conditions, types of conditions, attributes that are related But not other info about query – Query answer the set of shares of tuples in some query answer But not other content

Example query SELECT Name FROM Employer WHERE Salary > 6000 Transformed query may look like to one service provider SELECT ATTRIBUTE_7 FROM TABLE_A WHERE ATTRIBUTE_3 > X WITH SHARE_X = 1000 Answer Tom Kitty Answer T Ki Answer o t m ty The other two parties may get SHARE_X = 2000 and SHARE_X = 3000

Scheme A Shares compression – The shares of the DB is generated randomly – Who decides the random shares? Lets use a secure pseudo random generator IDX IDShare f(ID) = ID + 5 IDShare IDShare Share AShare BShare C Randomly generated

Storage cost Almost constant – The owner just needs to remember The function f (role like a key in encryption) The set of IDs (assume the IDs are continuous, just remember the lowest value and the highest value) Storage part is easy, how about computation? IDShare …… f(ID) = ID + 5

Review of comparison (example) protocol – simplified version Goal: x>y? Step 1: work out x-y Step 2: get the sign bit and the result x1 y1 x2 y2 x3 y3 r r + x1 – y1 r + x1 + x2 – y1 – y2 r + x - y r

Efficiency bottleneck Query: X > 6000 – Number of MPCs = number of tuples – Cost at owner = linear scan on data IDShare IDShare IDShare Share AShare BShare C IDX One comparison MPC for this tuple!

How the owner can contribute its own shares efficiently? Again, compression x1 y1 x2 y2 x3 y3 r r + x1 – y1 x1 y1 x2 y2 x3 y3 r r + x1 – y1 r IDShare Share A f(ID) = ID + 5 IDr f2(ID) = ID + 3f3(ID) = 3 ID IDr g(ID) = ID + 3 g(ID) = -ID + 8 Cost become constant!