1. Orthogonal Security With Cipherbase 1 Microsoft Research 2 UW-Madison 3 ETH-Zurich Arvind Arasu 1 Spyros Blanas 2 Ken Eguro 1 Donald Kossmann 3 Ravi Ramamurthy 1 Venkie Ramarathnam 1 Raghav Kaushik 1

2. Problem: Data Confidentiality NameAgeDisease Alice12Flu Bob51Diabetes Chen24Flu Dan36Cold NameAgeDisease X%*!)C!x8J ~4Yz##)zFr#x T$H2!*^@tG <*fB@$BxU3 2 Data DBMS Cloud Admin Super-user with console access Encrypted Data Key DBMS

3. 3 Disease Flu Diabetes Flu Cold Disease !x8J )zFr#x ^@tG BxU3 Strong Encryption (Non-Deterministic) Disease !x8J )zFr#x !x8J BxU3 Deterministic Encryption DBMS Equality Computation Directly On Encrypted Data Paillier encryption: summation Order-preserving encryption: range

4. Limitations Incomplete – SUM(L_EXTENDEDPRICE*(1- L_DISCOUNT)*(1+L_TAX)) Brittle – E.g.: Cannot combine addition and range – O_SHIPDATE > O_ORDERDATE + 30 days Full functionality  Store in the clear 4

5. Goal: Orthogonal Security 5 Full functionality in the server independent of the data encryption SQL Transactions Physical Structures App logic completely decoupled from encryption Clients declare what columns are to be encrypted and how System is functional without any change in app code Orthogonality

6. SELECT * FROM Patient WHERE Disease = ‘Flu’ Overall Workflow NameAgeDisease X%*!)C!x8J ~4Yz##)zFr#x T$H2!*^@tG <*fB@$BxU3 SQL Client Extension Key, metadata Encrypted Query String/Plan SELECT * FROM Patient WHERE Disease = ‘$bG’ X%*!)C!x8J Alice12Flu Encrypted Result 6 App DBMS

7. The Case For Trusted Hardware NameAgeDisease Alice12Flu Bob51Diabetes Chen24Flu Dan36Cold … NameAgeDisease X%*!)C!x8J ~4Yz##)zFr#x T$H2!*^@tG <*fB@$BxU3 … Inaccessible Alice12Flu Disease = ‘Flu’ Trusted Hardware key UM (Untrusted Machine) TM (Trusted Machine) 7 DBMS (Commodity H/W) DBMS (Commodity H/W) sum(l_extendedprice*(1- l_discount) *(1+l_tax))) Leads to orthogonality

8. TM Design Secure Co-processor – Designed for low-performance apps such as ATMs 8 Our choice: FPGA – Used for security-sensitive applications – Well-established applicability for data-intensive applications – Connected to UM by PCI express

9. Encryption, Decryption key 9 DBMS (Commodity H/W) DBMS (Commodity H/W) Design Choice 1:Encryption, Decryption (Industry state of art) NameAgeDisease X%*!)C!x8J ~4Yz##)zFr#x T$H2!*^@tG <*fB@$BxU3 NameAgeDisease Alice12Flu Bob51Diabetes Chen24Flu Dan36Cold SQL Server Buffer Pool Leaks everything Keep data encrypted across the stack UM (Untrusted Machine) TM (Trusted Machine)

10. Data DBMS For Encrypted Columns key 10 DBMS For Clear-Text Columns DBMS For Clear-Text Columns UM (Untrusted Machine) TM (Trusted Machine) Design Choice 2: All Processing In TM Commodity ServerResource-constrained TrustedDB [Bajaj et al., SIGMOD 2011] Goal: Reduce TM footprint PCI Express Security: Encrypt across the stack

11. SQL Server (Buffer Pool, Indexes, Transactions, Query Processor, Query Optimizer, …) DB Expression Evaluation (Stack Machine) Expression Evaluation (Stack Machine) key UM TM 11 Cipherbase: Hardware Software Co-Design Security: Encrypt across the stack

12. SELECT C_Custkey, SUM(O_totalprice) as Revenue FROM Customer, Order WHERE C_Custkey = O_Custkey and C_Nationkey = ‘Nation5’ and O_Orderdate > ‘2012-1-1’ GROUP BY C_Custkey Example SQL Client Extension Key, metadata 12 App

13. Example 13 Client Extension Key, metadata App DBMS

14. Example 14 Dec(C_Nationkey)=Dec(x) Dec(O_Orderdate)>Dec(y) Hash(Dec(C_Custkey)) Hash(Dec(O_Custkey)) Dec(O_Custkey)=Dec(C_Custkey) Dec(C_Custkey1)>Dec(C_Custkey2) Enc(Dec(O_totalprice) + Dec(currentSum)) Memory Mgmt Spooling Specifics of join/sort algorithm Storage engine (buffer pool, locking) Data-flow (GetNext calls) Inter query memory governance Admission control Most processing happens in UM

15. Challenges Performance: – Revisit whole stack (physical structures, QP, QO) – Batch requests to TM – FPGA parallelism Space: – Multi-row/multi-column encryption TM UM key Commodity ServerResource-Constrained PCI Express 15

16. Query Optimization 16 Stack code

17. Query Optimization 17 Stack code

18. Security Sort TM Record 1 < Record 2 True/False Encryption across stack does NOT imply no information leakage Access patterns leak information Sort leaks ordering Cipherbase No Encryption Leak everything Client Leak no information 18 Leak some information Operations on column Leakage Equality (including joins) Frequency distribution Indexing/Sorting /range predicates Order Arithmetic operations Nothing Similar to CryptDB [SOSP,2011]

19. Higher Security Information leakage can be controlled – Insight: full scans naturally have fixed access patterns Our contribution: – Full SQL using scan-based plans – Reveals only intermediate result sizes – Indexing is an open problem Putting it together – Single system with “diallable” column-level knobs – “One size does not fit all” – separate solution for analytical workloads 19

20. Status Implementation status – FPGA Manager integrated with SQL Server – Expression evaluation modified to use FPGA – FPGA supports stack machine – Preliminary implementation of indexing and query optimizer Runs debit-credit benchmark Warm buffer pool: security overhead is 50% – Clear-text TPS: ~12000 – Encrypted TPS: ~8000 20

21. Questions? 21