Patchable (Indistinguishability) Obfuscation: iO for evolving software Prabhanjan Abhishek Amit Ananth Jain Sahai
Software Evolution 1990
Software Evolution 1990 1995
Software Evolution 1997 1990 1995
Software Evolution 1997 1990 1995 2000
Software Evolution 1997 1990 1995 2003 2000
Software Evolution 1997 1990 1995 2003 2000 2007
Software Evolution 1997 1990 2010 1995 2003 2000 2007
Software Evolution 1997 1990 2010 1995 2003 2000 2013 2007
Software Evolution 1997 1990 2010 2016 1995 2003 2000 2013 2007
Why does software evolve? 1. Changes in hardware requirements 2. Changes in functionality requirements 3. Resolve compatibility issues 4. Performance of the system has to be upgraded 5. Fixing bugs …
How to model Software Evolution?
M Patch P Update M’
Goal: To protect evolving software Ensure software privacy from the user yet allowing for software updates
This Work: iO for Evolving Software
This Work: Patchable iO
Why doesn't (static) iO suffice? iO( M ) M M
Why doesn't (static) iO suffice? iO( M ) M M P Update M’
Why doesn't (static) iO suffice? iO( M ) M M P Update iO( M’ ) M’ M’
Communication Complexity? iO( M M P Update |iO( M’ )| ~ | M’ | M M
Patchable iO Communication complexity P ~
Patchable iO iO( M ) M M P P GenPatch
Patchable iO iO( M ) M M P P ApplyPatch GenPatch M’
Syntax: Patchable iO • Setup (1 k ) = sk • Obfuscate ( sk , M ) = M • GenPatch ( sk , P ) = P • ApplyPatch M M’ = P ,
Syntax: Patchable iO • Setup (1 k ) = sk • Obfuscate ( sk , M ) = M Efficiency: • GenPatch ( sk , P ) = P | | ~ | P | P • ApplyPatch M M’ = P ,
Definitional Issues
1. How to Apply Patches
1. How to Apply Patches Sequential Patching: P 1 P 2 M 0 M 1 M 2
2. How many Patches?
2. How many Patches? Want: Unbounded number of patches (chosen adaptively ) P 1 P 2 M 0 M 1 M 2
3. Patching Multiple Programs M M P M M M M
3. Patching Multiple Programs P P M M P M M P M M P P
3. Patching Multiple Programs M’ M’ M’ M’ M’ M’
Multi-program Patchable iO M’ M’ M’ M’ M’ M’
Summary of Requirements (so far) • Patch encoding size only depends on patch size • Patches can modify the program arbitrarily - modeled as Turing machine • Unbounded number of patches • Support for patching multiple programs
Correctness and Security?
Single-Program Patchable iO 1. Correctness for Sequential Patching • For every TM M 0 and patch sequence P 1 ,…,P L M 1 =Update( M 0, P 1 ) ≡ M 1 = ApplyPatch M 0 P 1 , M 1 P 2 M 2 =Update( M 1, P 2 ) M 2 = ApplyPatch ≡ , P L M L-1 M L M L =Update( M L-1, P L ) = ApplyPatch ≡ ,
Single-Program Patchable iO 1. Correctness for Sequential Patching • For every TM M 0 and patch sequence P 1 ,…,P L M 1 =Update( M 0, P 1 ) ≡ M 1 = ApplyPatch M 0 P 1 , M 1 P 2 M 2 =Update( M 1, P 2 ) M 2 = ApplyPatch ≡ , P L M L-1 M L M L =Update( M L-1, P L ) = ApplyPatch ≡ , • Remark 1 : Patches must be applied sequentially “in order”
Single-Program Patchable iO 1. Correctness for Sequential Patching • For every TM M 0 and patch sequence P 1 ,…,P L M 1 =Update( M 0, P 1 ) ≡ M 1 = ApplyPatch M 1 P 1 , M 1 P 2 M 2 =Update( M 1, P 2 ) M 2 = ApplyPatch ≡ , P L M L-1 M L M L =Update( M L-1, P L ) = ApplyPatch ≡ , • Remark 1 : Patches must be applied sequentially “in order” • Remark 2 : Each patch can only be used once
Single-Program Patchable iO 2. Security for Adaptive Patches ( M 0 ) 0 , ( M 1 ) 0 ( M b ) 0 ( P 0 ) i , ( P 1 ) i (P b ) i Adversary Challenger ( M 0 ) j = Update( ( M 0 ) j-1 , ( P 0 ) j ) ( M 0 ) j ≡ ( M 1 ) j where ( M 1 ) j = Update( ( M 1 ) j-1 , ( P 1 ) j )
Single-Program Patchable iO 2. Security for Adaptive Patches ( M 0 ) 0 , ( M 1 ) 0 ( M b ) 0 ( P 0 ) i , ( P 1 ) i Correctness and Security can be generalized to multiprogram setting in a similar manner (P b ) i Adversary Challenger ( M 0 ) j = Update( ( M 0 ) j-1 , ( P 0 ) j ) ( M 0 ) j ≡ ( M 1 ) j where ( M 1 ) j = Update( ( M 1 ) j-1 , ( P 1 ) j )
Our Results Theorem. Assuming sub-exp. iO for circuits and sub- exp. DDH (or sub-exp. LWE), there exists multi-program patchable iO for TMs * . In paper, we also consider other types of patching processes * The input length to the TMs is fixed a priori
Incremental/ Updatable Cryptography • Incremental signatures [BGG94,…] • Incremental encryption [BGG95,…] … Concurrent work : Incremental Obfuscation [Garg-Pandey’15]
Theoretical Applications
Functional Encryption for Turing Machines Functional Key of M Ciphertext of y M x= ⊥ Set x := y Let M x be an input-less machine that outputs M(x)
Functional Encryption for Turing Machines Functional Key of M Ciphertext of y M x= ⊥ Set M x=y x := y Let M x be an input-less machine that outputs M(x)
Functional Encryption for Turing Machines Functional Key of M Ciphertext of y M x= ⊥ Set x := y ADVANTAGE: Simple construction! previous construction by A-Sahai’16 from iO is more involved
Other Applications of Patchable iO • Multi-Input Functional Encryption for TMs • iO for TMs with unbounded input length - requires reusable patching mechanism
Technical Overview
Template of Single-Program Patchable iO
Template of Single-Program Patchable iO Patchable Obfuscation of M Obf ( 1. Decode ) + Encode( M ) 2. Evaluate M on x Input = ( Encode(M), x ) Use an encoding scheme to encode M
Template of Single-Program Patchable iO Patchable Obfuscation of M Obf ( 1. Decode ) + Encode( M ) 2. Evaluate M on x Input = ( Encode(M), x ) Evaluation On input x, • Evaluate obfuscated ckt on (Encode(M),x) to get M(x)
Template of Single-Program Patchable iO Patchable Obfuscation of M Obf ( 1. Decode ) + Encode( M ) 2. Evaluate M on x What properties should the encoding scheme satisfy? 1. Correctness 2. Hiding 3. Patching
Properties of Encoding Scheme 1. Correctness: Decoding ‘Encode( M )’ should yield M 2. Hiding: Encode( M 0 ) ≈ c Encode( M 1 ) 3. Patching: For patch P: Encode( M ) + Encode( P ) := Encode( M’ )
Properties of Encoding Scheme We call such a scheme, patchable encoding scheme
Properties of Encoding Scheme e : a t d i d n a C c i h p r o m o m o h y l l u F ! n o i t p y r c n e We call such a scheme, patchable encoding scheme
Template of Single-Program Patchable iO Patchable Obfuscation of M Obf ( 1. Decode ) + Encode( M ) 2. Evaluate M on x Issue: Adversary can apply encoded patches of his choice
Template of Single-Program Patchable iO Patchable Obfuscation of M Obf ( 1. Decode ) + Encode( M ) 2. Evaluate M on x Issue: Adversary can apply encoded patches of his choice Fix: Sign the patches!
M P Encode( M ) + Obf ( ) Encode( P ) , sgn Ptch 1. Verify 2. Decode +Upd. 3. Evaluate M on x Input = ( Encode(M), Encode(P), sgn Ptch , x )
M P Encode( M ) + Obf ( ) Encode( P ) , sgn Ptch 1. Verify 2. Decode +Upd. 3. Evaluate M on x Issue: Adversary can apply patches out of order Apply P 50 , P 4 , P 10 , …
M P Encode( M ) + Obf ( ) Encode( P ) , sgn Ptch 1. Verify 2. Decode +Upd. 3. Evaluate M on x Issue: Adversary can apply patches out of order Fix: Authenticate the patched machine!
M P Encode( M ) + Obf ( ) Encode( P ) , sgn M/c 1. Verify 2. Decode +Upd. sgn M/c 3. Evaluate M on x signature on Encode(M’) sgn M/c ensures that Encode(P) is only applied to Encode(M)
Encode( M ) + 1. Verify STATE:= Encode(M), SK ( 3. Evaluate M on x ) 2. Decode + Update
Encode( M ) + 1. Verify STATE:= Encode(M), SK ( 3. Evaluate M on x ) 2. Decode + Update P Encode( P ) Update Encode( M’ ) Encode( P ) Sign Encode( M’ ) to get sgn M/c + sgn M/c
STATE:= Encode(M), SK Issue: Authority needs to maintain large state! Not scalable to multiple programs
STATE:= Encode(M), SK Issue: Authority needs to maintain large state! Solution: Reverse delegation
STATE:= Encode(M), SK Issue: Authority needs to maintain large state! Solution: Reverse delegation (delegate to client)
Implementation Issues 1. The state should be hidden from the user - state contains secret information 2. How does Apple generate secure patches? - It no longer has access to the state
Implementation Issues 1. The state should be hidden from the user - state contains secret information 2. How does Apple generate secure patches? - It no longer has access to the state TOOL: Adaptive garbled TMs for persistent memory [Canetti-Chen-Holmgren-Raykova’16, A-Chen-Chung-Lin-Lin’16]
Recommend
More recommend
