1. Database Laboratory 2013-10-21 TaeHoon Kim

2. /25 Work Progress(Range Query) 2

3. Database Laboratory Regular Seminar 2013-10-21 TaeHoon Kim 3

4. /25 Contents 1.Introduction 2.Security Overview 3.Queries Over Encrypted Data 4.Multiple Principals 5.Application Case Studies 6.Discussion 7.Implementation 8.Experimental Evaluation 9.Related Work 10.Conclusion 4

5. /25 Introduction  Theft of private information is a significant problem An adversary can exploit software vulnerabilities to gain unauthorized access to servers Curious or malicious admin at a hosting or application provider can snoop on private data  One approach to reduce the damage is to encrypt sensitive data  This paper presents CryptDB A system that explores an intermediate design point to provide confidentiality for applications that use database management systems 5 5

6. /25 Introduction  CryptDB addresses two threats 1. A curious database DBA who tries to learn private data 2. An adversary that gains complete control of application and DBMS servers 6 Application DB Server  hackers SQL User 1 User 2 User 3 cloud.berkeley.edu/data/cryptdb.pptx‎ Confidential Data Leaks

7. /25 Introduction  CryptDB addresses these challenges using three key ideas The first is to execute SQL queries over encrypted data  This idea using a SQL-aware encryption strategy The second technique is adjustable query-based encryption The third idea is to chain encryption keys to user passwords, so that each data item in the database can be decrypted only through a chain of keys rooted in the password of one of the users with access to that data 7

8. /25 Security Overview  Threat1 : DBMS Server Compromise Our approach is to allow the DBMS server to perform query processing on encrypted data as it would on an unencrypted database  Threat2 : Arbitrary Threats The solution is to encrypt different data items (e.g., data belonging to different users) with different keys CryptDB provides strong guarantees in the face of arbitrary server-side compromises 8

9. /25 col1/rankcol2/name table1 (emp) SELECT * FROM emp WHE RE salary = 100 SELECT * FROM table1 WH ERE col3 = x5a8c34 Proxy 60 100 800 100 col3/salary Application Security Overview(Threat1) x4be219 x95c623 x2ea887 x934bc1 x5a8c34 x84cec1 x17cea7 x5a8c34 ? 9

10. /25 Queries Over Encrypted Data  SQL-aware Encryption Random(RND) : in indistinguishability under(IND-CPA)  Deterministic(DET) Allows the server to perform equality check, which means it can perform selects with equality predicates, equality joins, GROUP BY, COUNT, DISTINCT  Order-preserving encryption(OPE) OPE allows order relations between data items to be established based on their encrypted values, without revealing the data itself  If x<y, then OPE k (X) < OPE k (Y), for any secret key K 10

11. /25 Queries Over Encrypted Data  Homomorphic encryption (HOM) HOM k (x)*HOM k (y) = HOM k (x+y)  Join (Join and OPE-JOIN) Join support all operations by DET, OPE-JOIN support joins by order relations  Word Search (SEARCH) Search is used to perform searches on encrypted text to support operations such as MySQL’s LIKE operator  Only support full-word keyword searches –Cannot support arbitrary regular expressions 11

12. /25 Queries Over Encrypted Data  Adjustable Query-based Encryption Our goal is to use the most secure encryption schemes that enable running the requested queries  Our idea is to encrypt each data item in one or more onions Each value is dressed in layers of increasingly stronger encryption  To perform optimize adjustable query-based encryption 12

13. /25 Queries Over Encrypted Data  Executing Over Encrypted Data The proxy transforms the query to operate on these onions  For instance, for the schema shown in Figure 3, a reference to the Name column for an equality comparison will be replaced with a reference to the C2-Eq column Read Query Execution Write Query Execution  The proxy encrypts each inserted column’s value with each onion layer that has not yet been stripped off in that column 1 1 2 2 3 3 13

14. /25 Queries Over Encrypted Data  Improving Security and Performance Minimum onion layers  Application developers can specify the lowest onion encryption In-proxy processing  Since the proxy receives the entire result set from the server, sorting these result in the proxy does not require significant amount of computation, and does not increase the bandwidth requirements Training mode Onion re-encryption  When application performs infrequent queries requiring a low onion layer, CryptDB could be extended to re-encrypt onions 14

15. /25 Queries Over Encrypted Data  Performance Optimization Developer annotation  If many column are not sensitive, the developer can instead provide explicit annotation indicating the sensitive field Known query set  Use training mode  Optimize onion sets Ciphertext pre-computing and caching  To reduce this cost, the proxy pre-computes and caches(for OPES) encryptions of frequently used constants under different keys 15

16. /25 Multiple Principle: Policy Annotations  Policy Annotations 1. The developer must define the principal types(using PRINCTYPE) used in her application, such as users, groups, or messages 2. The developer must specify which columns in her SQL schema contain sensitive data, along with the principals that should have access to data using the ENC_FOR annotation 3. Programmers can specify rules for how to delegate the privileges of one principal to other principals, using the speak for relation 16

17. /25  Observation : Each row in certain tables naturally specifies 1. how data should be encrypted msgidsenderid privmsgs_to: 51 96 recipientid 6 2 msgidmsgtext 5 “secret message” 6 privmsgs: “hello world” Multiple Principle: Policy Annotations 17

18. /25 1. Principals CREATE TABLE privmsgs ( msgid int, subject varchar(255) msgtext text ); CREATE TABLE privmsgs_to ( msgid int, rcpt id int, sender id int, ); CREATE TABLE users ( userid int,username varchar(255), ); Securing phpBB private messages: 3. HAS_ACCESS_TO2. ENCRYPT_FOR ENCRYPT_FOR PRINC msgid TYPE msg, ENCRYPT_FOR PRINC msgid TYPE msg PRINC TYPES physical_user EXTERNAL; PRINC TYPES user, msg; PRINC sender_id TYPE user HAS_ACCESS_TO PRINC msgid TYPE msg, PRINC rcpt_id TYPE user HAS_ACCESS_TO PRINC msgid TYPE msg PRINC username TYPE physical_user HAS_ACCESS_TO PRINC userid TYPE user Multiple Principle: Policy Annotations cloud.berkeley.edu/data/cryptdb.pptx‎ 18

19. /25 Multiple Principle: Key chaining cloud.berkeley.edu/data/cryptdb.pptx‎ 19 Username: Alice Password: asdf Username: Tomas Password: dfga userid 1 userid 2 msgid 5 SKu1 SKu2 SKm5 SKa = dblab SKb = dblab E SKa [SKu1] E SKb [SKu2] E SKu1 [SKm5] E SKu2 [SKm5] “secret messag e” All key chaining operations d one at proxy, keys stored enc rypted at DB server Also use public key pair

20. /25 Application Study  PhpBB e.g)xpressEngine board A widely used open source forum with a rich set of access control settings HotCRP  A popular conference review application Grad-apply  A graduate admissions system used by MIT EECS

21. /25 Discussion / Implementation  CryptDB cannot support on encrypted Data Not support both computation and comparison on the same column  SELECT age*2+10 FROM …  WHERE salary > age*2+10 (1)rewritten into a sub-query (2)re-encrypted in the proxy  CryptDB proxy consist of a C++ Lib and a Lua module  CryptDB used MySQL proxy  CryptDB implementation consists of ~ 18,000 lines of C++ Code and ~150 lines of Lua Code

22. /25 Performance Evaluation  Performance environment MySQL 5.1.54 server : 2 machines  2.4 GHz Intel Xeon E5620 4-core processors  12 GB of RAM CryptDB proxy and the clients : 8 machines  2.4 GHz AMD Opteron 8431 6-core processors  64 GB of RAM Use a shared Gigabit Ethernet network  Use TPC-C query set  Compare with MySQL CryptDB CryptDB with only Random encryption(RND) :strawman

23. /25 Performance Evaluation  Throughput of different types of SQL queries from the TPC-C query

24. /25 Related work  Theoretical approaches ([Gentry’10], [Gennaro et al., ’10]) Inefficient  Search on encrypted data (e.g., [Song et al., ’00]) Restricted set of queries, inefficient  Systems proposals (e.g., [Hacigumus et al., ’02])] Lower degree of security, rewrite the DBMS, client-side processing  Software checks (e.g., PQL, UrFlow, Resin) No protection against adversaries with complete access to servers

25. /25 Conclusion  We presented CryptDB, a system that provides a practical and a strong level of confidence in the face of two significant threats 1. A curious database DBA who tries to learn private data 2. An adversary that gains complete control of application and DBMS servers  Our Evaluation show that CryptDB can support operations over encrypted data

26. /25  Note that, All ppt contents is based on “cloud.berkeley.edu/data/cryptdb.pptx‎” and paper by Christof Kim(TaeHoon Kim) :D If ppt contents contains error, plz recommend to me taehun3718@gmail.com :D taehun3718@gmail.com

27. /25 SELECT * FROM emp WHERE salary = 100 UPDATE table1 SET col3onion1 = DecryptRND(key, col3onion1) Any value JOIN SEARCH DET RND SELECT * FROM table1 WHERE col3onion1 = x 5a8c34 DET emp: ranknamesalary 27