Trace Oblivious Program Execution A Programming Language Approach to Security Chang Liu

advertisement
Trace Oblivious Program Execution
A Programming Language Approach to Security
Chang Liu
University of Maryland
Dating: Genetically
Not leaking
their sensitive
genomic data
to anyone else!
Good match?
2
An Idealized Solution
Trusted Third Party
Genetically compatible?
Two Promising Approaches to
Implement the Trusted Third Party
Secure
Processor
With trusted
hardware
Secure
Multi-Party
Computation
Without trusted
hardware
Two Promising Approaches to
Implement the Trusted Third Party
Secure
Processor
With trusted
hardware
Secure
Multi-Party
Computation
Without trusted
hardware
Cloud with a Secure Processor
Secure
processor
Memory
Disk
AEGIS, XOM, Intel SGX
Is this solution
secure?
NO! It is easy to learn memory access
patterns through physical attacks
• E.g. replace DRAM DIMMs with NVDIMMs that have nonvolatile storage to record accesses
Problem: Access patterns to
even encrypted data leak
sensitive information.
Secure
processor
Breast
cancer
Liver
problem
Kidney
problem
Zhuang, et al. HIDE: an infrastructure for efficiently protecting information leakage on the address bus. ACM SIGPLAN Notices, 2004.
Islam, et al. Access Pattern disclosure on Searchable Encryption: Ramification, Attack and Mitigation, In NDSS, 2012
Cash, et al. Leakage-abuse attacks against searchable encryption. In CCS 2015.
One Common Problem:
Trace Oblivious Computation
Secure processor
No leakage through
trace patterns
Real-life
program
Oblivious
program
Easy to convert to
compact circuits
The Challenge
Secure computation
One Generic Solution:
Oblivious RAM
𝑂(𝑝𝑜𝑙𝑦 log 𝑁)
• Somewhat practical, but still
moderately expensive
[𝑖]
[𝑀[𝑖]]
ORAM
Scheme
• Poly-logarithmic cost per
access
𝑖
Read M[i]
• Hide access patterns
• Redundancy
• Data Shuffling
Stefanov et al., Path ORAM: An extremely simple oblivious RAM protocol. In CCS 2013
Maas, et al., Phantom: Practical oblivious computation in a secure processor. In CCS 2013.
Wang, et al., Circuit ORAM On Tightness of the Goldreich-Ostrovsky Lower Bound. In CCS 2015
Given a computation (C program),
what data (variables) do we place
inside an ORAM?
Naïve answer: all of them
Key observation:
Accesses that do not depend on secret
inputs need not be hidden
Example: FindMax
int max(public int n, secret int h[]) {
public int i = 0;
secret int m = 0;
while (i < n) {
if (h[i] > m) then m = h[i];
i++;
h[] need not be in ORAM.
}
Encryption suffices.
return m;
}
Dynamic Memory Accesses:
Main loop in Dijkstra
for(int i=1; i<n; ++i) {
dis[]: Not in ORAM
vis[], e[][]: Inside ORAM
int bestj = -1;
for(int j=0; j<n; ++j)
if(!vis[j] && (bestdis < 0 || dis[j] < bestdis))
bestdis = dis[j];
vis[bestj] = 1;
for(int j=0; j<n; ++j)
if(!vis[j] && (bestdis + e[bestj][j] < dis[j]))
dis[j] = bestdis + e[bestj][j];
}
Using PL to help
We build compilers to automate this analysis
• Recognize code whose access patterns do not leak
information
• Minimize the usage of ORAM
Formal security
• Memory-trace oblivious type system
Liu, et al. Memory Trace Oblivious Program Execution, In CSF 2013. NSA Best Scientific Cybersecurity Paper Award, 2013
GhostRider
A Hardware-Compiler Codesign System
GhostRider Compiler
Optimizer
Secure Type Checker
Formally
Enforce MTO
Convey HC2
Platform
Assembly Code
Secure Processor
Scratchpad
DRAM
Controller
ERAM
Controller
ORAM 1
Controller
…
ORAM 𝑛
Controller
Liu, et al. GhostRider: A Hardware-Software System for Memory Trace Oblivious Computation. In ASPLOS 2015 (Best Paper Award)
Slowdown w.r.t.
non-secure baseline
FPGA Evaluation
𝟏 × ~𝟏𝟐 × slowdown than non-secure baseline
Little overhead over non-secure baseline
for some programs
For programs whose memory trace patterns heavily
depend on the input, speedup is small
Proposed Work:
Distributed Oblivious Computing
Programs
Information leakage from
various traces
Network
Timing
Cache
Termination
Instruction
Memory
Page swap
Open Problem: More Expression Language for
Oblivious Computation
How to enforce an ORAM
implementation is secure?
Work in progress toward PLDI 2016
Open Problem: Practical Parallel ORAM
…
…
Dachman-Soled, et al. Oblivious Network RAM and Leveraging Parallelism to Achieve Obliviousness, to appear in Asiacrypt 2015
Open problem: Practical Distributed System
Intel SGX
Memory
Secondary Storage
Page 1
Page 1
Page 2
Page 2
Page Swap
Page 3
Page 3
Page 4
Page 4
Page 5
Page 5
Software adversaries (OS)
Open problem: Easy Programmability
How to make as few
modifications as possible
to legacy code?
Security Type Systems
User Defined
Function
Execution
Plan
My other work in this spectrum
• Secure Computation
• Automating Efficient RAM-Model Secure Computation (S&P 14)
• ObliVM: A Programming Framework for Secure Computation (S&P 15)
• Performance
• Up to 𝟐𝟓𝟎𝟎 × smaller circuit compared with the best previous
automated approach
• Up to 𝟏𝟎𝟔 × better performance
• Open sourced at http://www.oblivm.com
Developing security applications are challenging
1. Trusted hardware have been deployed for years, but few
applications leverage them
2. Cryptography implementations are way behind
cryptographic research
Building Programming Tools
to Facilitate This Process
Q&A
Thank you!
Download