Upload
yolanda-crummett
View
223
Download
0
Embed Size (px)
Citation preview
Addressing the Trust AsymmetryProblem In Grid Computing with
Encrypted Computation
Peter A. DindaPrescience Lab
Department of Computer Science
Northwestern University
http://plab.cs.northwestern.edu
2
Takeaway
• Trust asymmetry is a core, unresolved problem in scalable computing
• Encrypted computation is the right approach
• This community is the right one to solve this problem
3
Outline
• Trust asymmetry problem
• Critique of approaches
• Encrypted computation scheme– Boolean circuits– Basic blocks– Control flow
• Discussion
4
Trust Asymmetry
Input
Program
5
Trust Asymmetry
Input
Program
Secure Channel
6
Trust Asymmetry
Input
Program
Secure Channel
Output
7
Trust Asymmetry
Input
Program
Secure Channel
OutputOutput
8
Trust Asymmetry
Input
Program
Secure Channel
OutputOutput
Protected Execution Environment
9
Trust Asymmetry
Input
Program
Secure Channel
OutputOutput
Protected Execution Environment
10
Trust Asymmetry
• Provider need not trust user at all
• User must trust provider completely
11
Consequences
• Scaling limited to machines user trusts
• Very large scale domain limited to low stakes applications
• SETI@HOME, DESCHALL, etc.
• High stakes applications have limited provider pool
• IBM, Sun, other vendors willing to do indemnification
• Economic inefficiency
12
Approaches
• Trust chains
• Attestation
• Obfuscation
• Encrypted computation
13
Trust Chains
• No direct protection of input, code, or output
• I trust X to do A because Y, who I trust, says I can– Chains of such trust assertions– Digital certificates– Example: SSL Certificates on the web– Example: Grid Certificates [Globus]
14
Problems
• Human in the loop…– Slow
• Or human has to write policy– Easy to get wrong
• Trust chains are complex to understand and evaluate against policy– Area of current research!
• Revocation
15
Attestation
• Certificate chain rooted in trusted hardware attests to software stack of machine [Terra, Paladium]
• Run only if you trust the software stack
16
Problems
• How do you know a software stack is OK?– Human in the loop…– Or writing policy
• What happens when stack changes?– Patches– “Semantic attestation”
17
Obfuscation
• Use compiler optimization technology to make code confusing [Collberg]
18
Problems
• No protection of input or output
• No proofs of difficulty of subversion
19
Encrypted Computation
• Apply techniques invented for encrypted communication
• Algorithm-specific techniques [Sander,Song]
• General purpose techniques– Typically focuses on Boolean circuit
20
General Purpose Encrypted Computation
• Seminal work: Abadi&Feigenbaum– Secure evaluation of Boolean circuit– “Interactive”
• More recently: Non-interactive– Sander and Tschudin: polynomials– Loureiro: Boolean circuits
21
Desirable Properties
• Protect inputs, outputs, and algorithm
• No trust needed at all
• Detect lies
• Analogy with communication– We don’t have to trust an Internet path– Trust is limited to endpoints
22
Problems
• Very abstract and theoretical– No implementations
• Unclear performance issues
• These are things the compiler community can help with
23
Our Simple MethodFor Boolean
Circuits
X
f
Secure Channel
Y
Protected Execution Environment
24
Our Simple Method For Boolean Circuits
X
f
Y
E DOne-time pads
f’E DX’ Y’
Remote Execution
25
Example: Y = fXx1x2
x3
y1
y2
X1 X2 X3 Y1 Y2
0 0 0 0 0
0 0 1 1 0
0 1 0 0 1
0 1 1 1 0
1 0 0 1 0
1 0 1 1 1
1 1 0 0 1
1 1 1 0 1
26
One-time Pad Refresher
• One of the oldest, but most secure encryption systems
• Have random bit sequence E
• Encrypt bit sequence X using X’ = X xor E
• Decrypt by X = X’ xor E
27
XOR as Multiplexor
x
e
e
x
28
Procedure
• Choose pads E and D
• Example– E = 1,0,1– D = 1,0
• Where bit is 1, double-invert
f’=DfE
fX
X’ Y’
Y
E E D D
f’=DfE
fX
X’ Y’
Y
E E D D
29
x1x2
x3y1
y2
f’=DfEX X’ Y’
E E D D
Y
Y=DDfEEX
30
Procedure
• Now “flatten” f’ back into sum of products and re-optimize
31
x1’x2’
x3’y1’
y2’
X1’ X2’ X3’ Y1’ Y2’
0 0 0 0 1
0 0 1 0 0
0 1 0 1 0
0 1 1 1 1
1 0 0 0 0
1 0 1 1 0
1 1 0 0 0
1 1 1 1 1
f’=DfE
32
x1x2
x3
y1
y2
X1 X2 X3 Y1 Y2
0 0 0 0 0
0 0 1 1 0
0 1 0 0 1
0 1 1 1 0
1 0 0 1 0
1 0 1 1 1
1 1 0 0 1
1 1 1 0 1
f
33
Concerns
• Currently no proof of difficulty to subvert
• Circuit growth limit?
• Will an automatic optimizer simply find the original configuration?
• Detecting lies– Embedded test circuit with known behavior
“mixed” into circuit
• How much reuse can we have?
34
Basic Blocks
• Obvious analog on data flow graph does not work
• Must convert data flow graph into Boolean circuit, apply technique, and then generate new basic block from the circuit
35
Control Flow
• Generate Mealy or Moore machine
• Apply technique to combinational element
• Generate new code
36
Concerns
• Code generation could “find” that the transparent implementation is best
• Efficient code generation from Boolean circuit
• Code size blowup
• Performance loss– Will determine in which regimes this is
practical
37
Current Status
• Proving how difficult it is to “unfold” the collapsed circuit
• Working toward proof-of-concept implementation as binary-to-binary translator for .NET CLR
38
Takeaway
• Trust asymmetry is a core, unresolved problem in scalable computing
• Encrypted computation is the right approach
• This community is the right one to solve this problem
Demonstrated straightforward scheme
39
For MoreInformation
• Prescience Lab– http://plab.cs.northwestern.edu
• Virtuoso– http://virtuoso.cs.northwestern.edu
• Join our user comfort study!– http://comfort.cs.northwestern.edu