Patchable (Indistinguishability) Obfuscation: iO for evolving - - PowerPoint PPT Presentation

Patchable (Indistinguishability) Obfuscation: iO for evolving software

Prabhanjan

Ananth

Amit

Sahai

Abhishek

Jain

Software Evolution

1990

Software Evolution

1990 1995

Software Evolution

1990 1995 1997

1990 1995 1997 2000

Software Evolution

Software Evolution

1990 1995 1997 2000 2003

1990 1995 1997 2000 2003 2007

Software Evolution

Software Evolution

1990 1995 1997 2000 2003 2007 2010

Software Evolution

1990 1995 1997 2000 2003 2007 2013 2010

Software Evolution

1990 1995 1997 2000 2003 2007 2013 2010 2016

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

iO for Evolving Software This Work:

This Work: Patchable iO

M M

Why doesn't (static) iO suffice?

iO(M)

M M Update

Why doesn't (static) iO suffice?

iO(M) P M’

M M Update M’

Why doesn't (static) iO suffice?

iO(M) iO(M’) P M’

M M Update M iO( P M

Communication Complexity?

|iO(M’)| ~ |M’|

Communication complexity

~

P

Patchable iO

M M

Patchable iO

iO(M) P GenPatch P

M M ApplyPatch M’

Patchable iO

iO(M) P GenPatch P

Syntax: Patchable iO

• Setup(1k) =sk
• Obfuscate(sk,M) =

M

• GenPatch(sk,P) = P

,

=

• ApplyPatch

M P M’

Syntax: Patchable iO

• Setup(1k) =sk
• Obfuscate(sk,M) =

M

• GenPatch(sk,P) = P

,

=

• ApplyPatch

M P M’

Efficiency:

| | ~ |P|

P

Definitional Issues

• 1. How to Apply Patches

• 1. How to Apply Patches

M0 M1 M2

P1 P2

Sequential Patching:

• 2. How many Patches?

• 2. How many Patches?

Want: Unbounded number of patches (chosen adaptively)

M0 M1 M2

P1 P2

M M M M M M

P

• 3. Patching Multiple Programs

M M M M M M

P

• 3. Patching Multiple Programs

P P P P P

M’ M’ M’ M’ M’ M’

• 3. Patching Multiple Programs

M’ M’ M’ M’ M’ M’

Multi-program Patchable iO

Summary of Requirements

• Patches can modify the program arbitrarily
• modeled as Turing machine
• Patch encoding size only depends on patch size
• Unbounded number of patches
• Support for patching multiple programs

(so far)

Correctness and Security?

Single-Program Patchable iO

• 1. Correctness for Sequential Patching
• For every TM M0 and patch sequence P1,…,PL

,

M2 M1 P2 M1

,

= ApplyPatch

M0 P1 ML

M1=Update(M0, P1) M2=Update(M1, P2) ML=Update(ML-1, PL)

≡ ≡ ≡

= ApplyPatch

,

ML-1 PL

= ApplyPatch

Single-Program Patchable iO

• 1. Correctness for Sequential Patching
• For every TM M0 and patch sequence P1,…,PL

,

M2 M1 P2 M1

• Remark 1: Patches must be applied sequentially “in order”

,

= ApplyPatch

M0 P1 ML

M1=Update(M0, P1) M2=Update(M1, P2) ML=Update(ML-1, PL)

≡ ≡ ≡

= ApplyPatch

,

ML-1 PL

= ApplyPatch

Single-Program Patchable iO

• 1. Correctness for Sequential Patching
• For every TM M0 and patch sequence P1,…,PL

,

M2 M1 P2 M1

• Remark 1: Patches must be applied sequentially “in order”

,

= ApplyPatch

M1 P1

,

ML ML-1 PL

• Remark 2: Each patch can only be used once

M1=Update(M0, P1) M2=Update(M1, P2) ML=Update(ML-1, PL)

≡ ≡ ≡

= ApplyPatch = ApplyPatch

Single-Program Patchable iO

• 2. Security for Adaptive Patches

(M0)0, (M1)0 (Mb)0 (P0)i, (P1)i (Pb)i

Adversary Challenger

(M0)j ≡ (M1)j where (M0)j = Update( (M0)j-1, (P0)j) (M1)j = Update( (M1)j-1, (P1)j)

Single-Program Patchable iO

• 2. Security for Adaptive Patches

(M0)0, (M1)0 (Mb)0 (P0)i, (P1)i (Pb)i

Adversary Challenger

(M0)j ≡ (M1)j where (M0)j = Update( (M0)j-1, (P0)j) (M1)j = Update( (M1)j-1, (P1)j)

Correctness and Security can be generalized to multiprogram setting in a similar manner

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*.

* The input length to the TMs is fixed a priori

In paper, we also consider

• ther types of patching

processes

Incremental/ Updatable Cryptography

• Incremental signatures [BGG94,…]
• Incremental encryption [BGG95,…]

…

Concurrent work: Incremental Obfuscation [Garg-Pandey’15]

Theoretical Applications

Mx=⊥

Set x := y

Functional Encryption for Turing Machines

Functional Key of M Ciphertext of y

Let Mx be an input-less machine that outputs M(x)

Mx=⊥

Set x := y

Functional Encryption for Turing Machines

Functional Key of M Ciphertext of y

Mx=y

Let Mx be an input-less machine that outputs M(x)

Mx=⊥

Set x := y

Functional Encryption for Turing Machines

Functional Key of M Ciphertext of 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

Encode(M)

+

• 1. Decode
• 2. Evaluate M on x

Obf (

)

Template of Single-Program Patchable iO Patchable Obfuscation of M

Input = ( Encode(M), x ) Use an encoding scheme to encode M

Encode(M)

+

• 1. Decode
• 2. Evaluate M on x

Obf (

)

Template of Single-Program Patchable iO Patchable Obfuscation of M

Input = ( Encode(M), x ) Evaluation

On input x,

• Evaluate obfuscated ckt on (Encode(M),x) to get M(x)

What properties should the encoding scheme satisfy?

• 1. Correctness
• 2. Hiding
• 3. Patching

Encode(M)

• 1. Decode
• 2. Evaluate M on x

Obf (

)

+ Patchable Obfuscation of M Template of Single-Program Patchable iO

Properties of Encoding Scheme

• 1. Correctness:

Decoding ‘Encode(M)’ should yield M

• 2. Hiding:

Encode(M0) ≈c Encode(M1)

• 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

We call such a scheme,

patchable encoding scheme

C a n d i d a t e : F u l l y h

• m
• m
• r

p h i c e n c r y p t i

• n

!

Encode(M)

• 1. Decode
• 2. Evaluate M on x

Obf (

)

+ Patchable Obfuscation of M Template of Single-Program Patchable iO

Issue: Adversary can apply encoded patches of his choice

Encode(M)

• 1. Decode
• 2. Evaluate M on x

Obf (

)

+ Patchable Obfuscation of M Template of Single-Program Patchable iO

Issue: Adversary can apply encoded patches of his choice Fix: Sign the patches!

P Encode(P) , sgnPtch Encode(M)

• 1. Verify
• 2. Decode+Upd.
• 3. Evaluate M on x

Obf (

)

+

M

Input = ( Encode(M), Encode(P), sgnPtch, x )

Encode(M)

• 1. Verify
• 2. Decode+Upd.
• 3. Evaluate M on x

Obf (

)

+

M P Encode(P) , sgnPtch

Issue: Adversary can apply patches out of order Apply P50, P4, P10, …

Encode(M)

• 1. Verify
• 2. Decode+Upd.
• 3. Evaluate M on x

Obf (

)

+

M Encode(P) , sgnPtch

Issue: Adversary can apply patches out of order Fix: Authenticate the patched machine!

P

Encode(M)

• 1. Verify
• 2. Decode+Upd.
• 3. Evaluate M on x

Obf (

)

+

M Encode(P) , sgnM/c

sgnM/c ensures that Encode(P) is only applied to Encode(M)

P sgnM/c

signature on Encode(M’)

Encode(M)

• 1. Verify
• 2. Decode + Update
• 3. Evaluate M on x )

+

(

STATE:= Encode(M), SK

Encode(M)

• 1. Verify
• 2. Decode + Update
• 3. Evaluate M on x )

+

(

STATE:= Encode(M), SK

Update

Encode(P)

P

Encode(M’)

Sign Encode(M’) to get sgnM/c

Encode(P) + sgnM/c

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)

STATE:= Encode(M), SK

Implementation Issues

• 1. The state should be hidden from the user
• 2. How does Apple generate secure patches?
• state contains secret information
• It no longer has access to the state

Implementation Issues

• 1. The state should be hidden from the user
• 2. How does Apple generate secure patches?
• state contains secret information
• 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]

• 1. The state should be hidden from the user
• 2. How does Apple generate secure patches?
• state contains secret information
• 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]

For simpler updates, can use garbled RAMs based on owfs

Implementation Issues

Single-Program to Multi-Program?

• 1. Apple maintains garbled TM secret keys for every

user

• 2. The storage capacity puts a bound on number of

users

Idea: Maintain the garbling key at user’s end

Single-Program to Multi-Program?

• 1. Apple maintains garbled TM secret keys for every

user

• 2. The storage capacity puts a bound on number of

users

Idea: Maintain the garbling key at user’s end

TOOL: Functional Encryption [Yao’86, BSW’11, GKPVZ’13, GGHRSW’13]

So far…

• 1. Template for single-program patchable iO
• 2. Single-Program to Multi-program patchable iO

How to implement the template of single-program patchable iO?

Encode(M)

+

• 1. Decode
• 2. Evaluate M on x

Obf (

)

Recall: Template of Single-Program Patchable iO Patchable Obfuscation of M

REQUIRE:

iO for Turing machines construction with the above structure

Encode(M)

+

• 1. Decode
• 2. Evaluate M on x

Obf (

)

Recall: Template of Single-Program Patchable iO Patchable Obfuscation of M

REQUIRE:

iO for Turing machines construction with the above structure

i O w i t h c

• n

s t a n t

• v

e r h e a d

A-Jain-Sahai'15

Implementation Issues

(TECHNICAL PART)

• 1. Make sure the encoding scheme used in AJS’15 is

patchable

• 2. Need to refresh the obfuscated circuit after every

update …

SEE PAPER

Questions?