1. 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

2. 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

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

4. 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

5. 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

6. 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

7. 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

8. Operation on SDB: addition example AB 23 41 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

9. 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 31 29 C CeCe 20 5 += E = (A+B)*D C CeCe 20 5 D DeDe 5 8 E EeEe 30 5 *=

10. 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

11. 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

12. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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