Wai Kit Wong 1, Ben Kao 2, David W. Cheung 2, Rongbin Li 2, Siu Ming Yiu 2 1 Hang Seng Management College, Hong Kong 2 University of Hong Kong

Introduction Secure-database-as-a-service DO makes use of the resources from SP for hosting its database But SP should not see the content inside the database DB Service provider (SP)Data Owner (DO) Query Answer DB Database should be encrypted Compute query on encrypted data Return an encrypted answer

Application DB Public Cloud Business Data Financial Data Healthcare Data Cloud users Malicious staff in cloud service provider Hacker

Computation on encrypted data – Limitations of related work Homomorphic encryption based approach Fully homomorphic encryption [STOC 2009] Not practical due to high overhead (orders of magnitude slower) Efficient partially homomorphic encryption, e.g., CryptDB [CACM 2012], MONOMI [PVLDB 2013] Do not support composite operation E.g., BASIC_SALARY + BONUS > 60K requires comparison after addition, which cannot be done by this approach Hardware based approach, e.g., Trusted DB [SIGMOD 2011], Cipherbase [SIGMOD 2013] Require specific expensive hardware Decrypt-before-query (DBQ) approach, e.g., ODB [SIGMOD 2002, ICDE 2002], MONOMI [PVLDB 2013] DO computes the query instead of SP  high cost to DO

Our approach: SDB One single encryption scheme that supports multiple operators with data interoperability (explained later) Support a wide range of complex queries Example supported query SELECT SUM(W.WorkingHour*W.HourlyRate) FROM Factory As F, Wages As W INNER JOIN Employee As E ON W.EID = E.EID WHERE (E.x-F.x)^2+(E.y-F.y)^2 < 1000 AND F.FID = 3 GROUP BY (2014 – E.EntryYear) // Looking for employees who live close to factory #3 // #year stayed in the company Numeric:Addition, Multiplication, Power, Comparison JoinEqui-join, Cartesian product AggregateGroup-by, SUM, COUNT Note: the above query cannot be computed by partially homomorphic encryptions

Our approach: SDB Algorithmic approach Do not require special hardware Query processing cost delegated to SP DO involves in query computation, but has a negligible cost SP takes the majority of work

Data encryption in SDB Asymmetric secret sharing A 2 4 A E(r)AeAe E(1)9 E(2)22 System parameter: g=2, n=35 Plain data with 1 column DOSP A column key is stored for A Encrypted data v = mg rx v e mod n v: plain value v e : encrypted value Auxiliary information for facilitating our scheme

Operation on SDB: addition example AB DO SP C A B S E(r)AeAe BeBe SeSe E(1)9318 E(2)22294 p A = 15 p B = 2 E(r)A’ = q A A e S e p A mod n B’ = q B B e S e p B mod n E(1)2926 E(2)41 q A = 18 q B = 4 C e = A’ + B’ mod n 20 5 Auxiliary column for facilitating our scheme Note: there are 2 columns in total DO operates on column keys Small amount of information in communication SP process on each tuple Check our paper for details C = A + B 5 5

Data interoperability The input and the output of our operators are of the same form, so that the output of one operator can be used as input of another operator A AeAe 9 22 B BeBe C CeCe = E = (A+B)*D C CeCe 20 5 D DeDe 5 8 E EeEe 30 5 *=

Importance of data interoperability Data interoperability allows composition of operators to be done, which can significantly increase the query expressiveness supported by our system Example supported query SELECT SUM(W.WorkingHour*W.HourlyRate) FROM Factory As F, Wages As W INNER JOIN Employee As E ON W.EID = E.EID WHERE (E.x-F.x)^2+(E.y-F.y)^2 < 1000 AND F.FID = 3 GROUP BY 2014 – E.EntryYear // Looking for employees who live close to factory #3 // #year stayed in the company multiplication  SUM addition  power  addition  comparison addition  GROUP BY

Some experiment results Measuring the overheads against querying on plain data Dataset: TPC-H (only encrypts sensitive data we selected) α: execution time of SDB / execution time of querying on plain data (in MySQL) All TPC-H queries can be computed. Client cost is low. Server cost may be higher due to processing on encrypted data

Conclusions We developed an encryption scheme that support multiple operators with data interoperability A wide range of complex queries can be answered Our secure database system (SDB) is suitable for the cloud environment DO always has a very small cost The overhead of computation on encrypted data at SP is manageable

System architecture of SDB DBMS Applications SPDO SDB Client Layer SDB Server Layer Query Execution Plan SDB Primitives Memory Result To enjoy existing features of DBMS, e.g., failure recovery To wrap DBMS and perform our secure primitives A layer at DO, work with SP to compute query answer Applications simply use the database service using SQL Key store

Features of SDB Two-party algorithmic approach without requiring special hardware A single encryption scheme supporting multiple operators with data interoperability Support a wide range of complex queries Cost delegated to SP while DO has a negligible cost in query processing Support computation between plain data and encrypted data Non-intrusive architecture design on top of existing DBMS

Experiment on key length Range query varying key length SELECT A, B, C from T WHERE A + B < q Measuring on SP’s processing time

Features of SDB Two-party algorithmic approach without requiring special hardware A single encryption scheme supporting multiple operators with data interoperability Support a wide range of complex queries Cost delegated to SP while DO has a negligible cost in query processing Support computation between plain data and encrypted data Non-intrusive architecture design on top of existing DBMS

Security of our encryption method Malicious SP: E(r)AeAe E(1)9 E(2)22 Encrypted data A 2 4 Plain data SP cannot recover the column key w.r.t. CPA (chosen- plaintext attack) Proof sketch: Reduce to RSA problem Attacker’s knowledge A Unknown column key

Security of our operator Malicious SP: Encrypted data Attacker’s knowledge A B S C Unknown column keys E(r)AeAe BeBe SeSe E(1)9318 E(2)22294 p A = 15 p B = 2 q A = 18 q B = 4 Messages from DO to SP SP cannot recover the column keys (DO’s input) Proof sketch: by simulation. An attacker can simulate the computation by the observed items in the protocol Note: our operator is an instance of SMC (secure multiparty computation) protocol

Summary Fully homomorphic encryption Support general computation (that can be expressed as a circuit) Impractically slow with existing implementation [EUROCRYPT 2012] CryptDB Very efficient query processing for supported query type Support limited query MONOMI Extension of CryptDB, using pre-computation and split client/server execution More queries can be supported May incur high cost to DO (client) SDB Support a wide range of complex queries using our operators with data interoperability Cost delegated to SP while DO has a negligible cost

Some experiment results Comparing SDB with DBQ: Client (DO) downloads the encrypted database, decrypt it and process query on its own MDB (MONOMI): use homomorphic encryptions; the client (DO) takes care the jobs that cannot be computed by homomorphic encryption. Range query varying database size SELECT A, B, C from T WHERE A + B < q Remark: we assume pre-computation cannot be done by MDB in our experiment since the query workload is not known beforehand. With pre-computation, the query can be computed instantly

Some experiment results Measuring the overheads against querying on plain data Dataset: TPC-H (only encrypts sensitive data we selected) α: execution time of SDB / execution time of querying on plain data (in MySQL) All TPC-H queries can be computed. Client cost is low. Server cost may be higher due to processing on encrypted data