Transcript Orthogonal Security With Cipherbase Arvind Arasu1 Spyros Blanas2 Donald Kossmann3 1Microsoft Ken Eguro1 Ravi Ramamurthy1 Research Raghav Kaushik1 Venkie Ramarathnam1 2UW-Madison 3ETH-Zurich.

Orthogonal Security With
Cipherbase
Arvind Arasu1
Spyros Blanas2
Donald Kossmann3
1Microsoft
Ken Eguro1
Ravi Ramamurthy1
Research
Raghav Kaushik1
Venkie Ramarathnam1
2UW-Madison
3ETH-Zurich
Problem: Data Confidentiality
DBMS
DBMS
Key
Encrypted
Data
Data
Name
Age
Disease
Name
Age
Disease
Alice
12
Flu
X%*!
)C
!x8J
Bob
51
Diabetes
~4Yz
##
)zFr#x
Chen
24
Flu
T$H2
!*
^@tG
Dan
36
Cold
<*fB
@$
BxU3
Cloud Admin
• Super-user with
console access
2
Computation Directly On Encrypted Data
DBMS
Equality
Disease
Flu
Deterministic
Encryption
Disease
!x8J
Diabetes
)zFr#x
Flu
!x8J
Cold
BxU3
Disease
Strong Encryption
Paillier encryption:
!x8J summation
(Non-Deterministic)
Order-preserving
encryption: range
)zFr#x
^@tG
BxU3
3
Limitations
• Incomplete
– SUM(L_EXTENDEDPRICE*(1L_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
Goal: Orthogonal Security
Full functionality in the server independent of the data
encryption
• SQL
• Transactions
Orthogonality
• 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
5
Overall Workflow
SQL
App
Alice
12
Flu
SELECT *
FROM Patient
WHERE Disease = ‘Flu’
Client
Extension
Encrypted Query String/Plan
SELECT *
FROM Patient
WHERE Disease = ‘$bG’
DBMS
X%*!
)C
!x8J
Encrypted Result
Key,
metadata
Name
Age
Disease
X%*!
)C
!x8J
~4Yz
##
)zFr#x
T$H2
!*
^@tG
<*fB
@$
BxU3
6
The Case For Trusted Hardware
Leads to orthogonality
TM (Trusted Machine)
UM (Untrusted Machine)
DBMS
(Commodity H/W)
Trusted
Hardware
key
sum(l_extendedprice*(1Disease = ‘Flu’
l_discount)
Alice
12 *(1+l_tax)))
Flu
Name
Name Age
Age
Disease
Disease
Alice
X%*!
12
)C
Flu
!x8J
Bob
~4Yz
51
##
Diabetes
)zFr#x
Chen
T$H2
24
!*
Flu
^@tG
Dan
<*fB
36
@$
Cold
BxU3
Inaccessible
……
7
TM Design
• Secure Co-processor
– Designed for low-performance apps
such as ATMs
• Our choice: FPGA
– Used for security-sensitive
applications
– Well-established applicability for
data-intensive applications
– Connected to UM by PCI express
8
Design Choice 1:Encryption, Decryption
(Industry state of art)
UM (Untrusted Machine)
SQL Server
Keep data encrypted
across the stack
Buffer Pool
Name
Age
Disease
TM (Trusted Machine)
12
Flu
DBMS
Bob
51
Diabetes
(Commodity
H/W)
Alice
Chen
24
Flu
Dan
36
Cold
Encryption,
Decryption
key
Leaks everything
Name
Age
Disease
X%*!
)C
!x8J
~4Yz
##
)zFr#x
T$H2
!*
^@tG
<*fB
@$
BxU3
9
Design Choice 2: All Processing In TM
Commodity Server
Security:
Encrypt across
the stack
Resource-constrained
UM (Untrusted Machine)
DBMS
For Clear-Text
Columns
Data
TM (Trusted Machine)
PCI Express
DBMS For
Encrypted
Columns
key
Goal: Reduce TM
footprint
TrustedDB [Bajaj et al., SIGMOD 2011]
10
Cipherbase: Hardware Software Co-Design
Security: Encrypt across the stack
UM
TM
SQL Server
(Buffer Pool, Indexes,
Transactions, Query
Processor, Query
Optimizer, …)
Expression
Evaluation
(Stack Machine)
key
DB
11
Example
App
SELECT C_Custkey, SUM(O_totalprice) as Revenue
SQL
FROM Customer, Order
WHERE C_Custkey = O_Custkey and
C_Nationkey = ‘Nation5’ and
O_Orderdate > ‘2012-1-1’
GROUP BY C_Custkey
Client
Extension
Key,
metadata
12
Example
𝛾𝑠𝑜𝑟𝑡 , sum(o_totalprice)
App
⋈ ℎ𝑎𝑠ℎ
Client
Extension
𝜎C_Nationkey=x
𝜎O_Orderdate>y
DBMS
𝐶𝑢𝑠𝑡𝑜𝑚𝑒𝑟
𝑂𝑟𝑑𝑒𝑟𝑠
Key,
metadata
13
Example
Inter query memory governance
Admission control
𝛾𝑠𝑜𝑟𝑡 , sum(o_totalprice)
Memory Mgmt
Spooling
⋈ ℎ𝑎𝑠ℎ
Specifics of
join/sort algorithm
𝜎C_Nationkey=x
Dec(C_Custkey1)>Dec(C_Custkey2)
Enc(Dec(O_totalprice) +
Dec(currentSum))
Hash(Dec(C_Custkey))
Hash(Dec(O_Custkey))
Dec(O_Custkey)=Dec(C_Custkey)
𝜎O_Orderdate>y
Dec(O_Orderdate)>Dec(y)
𝐶𝑢𝑠𝑡𝑜𝑚𝑒𝑟
𝑂𝑟𝑑𝑒𝑟𝑠
Dec(C_Nationkey)=Dec(x)
Data-flow (GetNext calls)
Most processing happens in UM
Storage engine (buffer pool, locking)
14
Challenges
Commodity Server
UM
Resource-Constrained
PCI Express
TM
key
• Performance:
– Revisit whole stack (physical structures, QP, QO)
– Batch requests to TM
– FPGA parallelism
• Space:
– Multi-row/multi-column encryption
15
Query Optimization
⋈
𝜎
𝜎
Stack code
𝑅
𝑆
16
Query Optimization
𝜎
⋈
𝜎
Stack code
𝑅
𝑆
17
Security
• Encryption across stack does
NOT imply no information
leakage
• Access patterns leak information
• Sort leaks ordering
True/False
Sort
TM
Record 1
<
Record 2
Cipherbase
Leak some information
No Encryption
Leak
everything
Client
Leak no information
Operations on
column
Leakage
Equality
(including joins)
Frequency
distribution
Indexing/Sorting Order
/range predicates
Arithmetic
operations
Similar to CryptDB [SOSP,2011]
Nothing
18
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
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
Questions?
21