1. Spring School on Lattice-Based Crypto, Oxford
Cryptographic Program Obfuscation
Craig Gentry
IBM T.J. Watson Research Center
March 2017
Spring School on Lattice-Based Crypto, Oxford

2. Code Obfuscation
Make programs “unintelligible” while maintaining their functionality
Example from Wikipedia:
Why do it?
How to define “unintelligible”?
Can we achieve it?
xinU / lreP rehtona tsuJ";sub ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&& close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print

3. Why Obfuscation? Hiding secrets in software AES encryption Plaintext
strutpatent.com
Ciphertext

4. Why Obfuscation? Hiding secrets in software
AES encryption  Public-key encryption
Plaintext
xinU / lreP rehtona tsuJ";sub ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&& close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
Ciphertext

5. Why Obfuscation? Hiding secrets in software Verify credentials
Put software components together
Credentials
Verify credentials
Output data
Data

6. Why Obfuscation? Hiding secrets in software
Put software components together … inseparably.
Digital rights management (DRM)
Credentials
xinU / lreP rehtona tsuJ";sub ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&& close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
Data

7. Why Obfuscation? Hiding secrets in software
Uploading my expertise to the web
Game of Go
Next
move

8. Why Obfuscation? Hiding secrets in software
Uploading my expertise to the web without revealing my strategies
xinU / lreP rehtona tsuJ";sub ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&& close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
Game of Go
Next
move

9. Why Obfuscation? Hiding secrets in software My brain What I see
What I say

10. Why Obfuscation? Hiding secrets in software
My brain… made digital… securely!!!
What I see
xinU / lreP rehtona tsuJ";sub ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&& close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
What I say

11. Defining Obfuscation
An obfuscator makes a program “unintelligible” while preserving its functionality.
For all circuits (functions) C in some class C, obfuscator O is:
Functionality preserving: O(C)(x) = C(x) for all inputs x
Efficient: O(C)’s running time is polynomial in C’s
“Unintelligible”: O(C) hard to analyze/reverse-engineer.
Minimal requirement: One-wayness: Hard to recover C from O(C)
Maximal requirement: O(C) is like a “black box” that evaluates C

12. Strong Black Box Obfuscation
A natural formal interpretation
For any efficient adversary A, there’s a simulator S, such that for any circuit C:
A(O(C)) ≈C.I. SC(1|C|)
What it means: A learns no more from O(C) than S does from oracle access to C.
This definition is impossible to meet!
If C is “unlearnable” (like a pseudorandom function), S cannot efficiently output a circuit C’ equivalent to C.
A definitely learns something that S doesn’t.

13. Even Weak Black Box Obfuscation is Impossible!
There are circuit families C that are unobfuscatable.
Shh, hang on. I can hear something.

14. Indistinguishability Obfuscation (iO)
For any efficient adversary A, for any equal-length circuits C1, C2 that compute the same function:
|Pr [A(O(C1))=1] - Pr [A(O(C2))=1]| is negligible.
What it means: If two circuits compute same function, adversary cannot distinguish which was obfuscated.
Also defined by Barak et al.

15. (Inefficient) IO is Always Possible
Set O(C) = lexicographically first circuit of size |C| that computes same function as C.
Canonicalize
Canonicalization inefficient in general if P ≠ NP.

16. Efficient IO ≈ Pseudo-Canonicalization
O(C1) and O(C2) may not be equal, … just indistinguishable
If adversary A can distinguish, we can use A to solve a crypto problem

17. Limitation of IO Only promises to pseudo-canonicalize C
Does not (necessarily) promise to hide C’s secrets

18. But IO is “Best-Possible” Obfuscation
An indistinguishability obfuscator is “as good" as any other obfuscator that exists. [GR07]

19. Best-Possible Obfuscationx x
Indist. Obfuscation
Indist. Obfuscation ≈
Best Obfuscation
Padding
Some circuit C
Computationally Indistinguishable
Some circuit C
C(x)
C(x)

20. Many Applications of IO
OWFs+iO → public key enc. [DH76, GGHRSW13, SW13]
Witness encryption: Encrypt x so only someone with proof of Riemann Hypothesis can decrypt [GGSW13]
Functional encryption: Noninteractive access control system where Dec(KeyY, Enc(x)) → F(X,Y) [GGHRSW13]
Many more …

21. Aside: Obfuscation vs. HEx + 
F(x)
Result in the clear F
Encryption x + 
F(x) or
Result encrypted

22. GGHRSW Obfuscation Construction
Two Steps:
Obfuscate NC1 Circuits
Uses branching programs (a la Barrington and Kilian)
Encodes permutation matrices using “multilinear maps”
Bootstrap obfuscation of NC1 to obfuscation of P
Simple provable transformation
Uses FHE and statistically sound NIZKs

23. NC1 Obfuscation  P Obfuscation
Homomorphic Encryption +
F(x) x
NC1 Circuit
CondDec
F(x)

24. NC1 Obfuscation  P Obfuscation
Homomorphic Encryption +
F(x) x
xinU / lreP rehtona tsuJ";sub
NC1 Circuit
CondDec
Obfuscate only this part
F(x)
Output of P obfuscator

25. Conditional Decryption with iO
We have iO, not “perfect” obfuscation
But we can adapt the CondDec approach
We use two HE secret keys

26. iO for CondDec → iO for All Circuits
π, x, and two ciphertexts c0 = EncPK0(F(x)) and c1 = EncPK1(F(x)) ≈
CondDecF,SK1(·, …, ·)
Indist. Obfuscation
π, xi’s, and two ciphertexts c0 = EncPK0(F(x)) and c1 = EncPK1(F(x))
F(x) if π verifies
Indist. Obfuscation
CondDecF,SK0(·, …, ·)
F(x) if π verifies

27. Analysis of Two-Key Technique
1st program has secret SK0 inside (but not SK1).
2nd program has secret SK1 inside (but not SK0).
But programs are indistinguishable
So, neither program “leaks” either secret.
Two-key trick is very handy in iO context.
Similar to Naor-Yung ’90 technique to get encryption with chosen ciphertext security

28. iO for NC1 Construction Complicated… Also, not very efficient…
Also, security is iffy…
Main ingredient: Cryptographic multilinear maps

29. Multilinear Map Schemes

30. What is a cryptographic mmap?
An FHE scheme that leaks.
Zero test: Anyone can distinguish when 0 is encrypted.

31. Why would you do that? FHE is awesome (of course):
I give the cloud encrypted program E(P)
For (possibly encrypted) x, cloud can compute E(P(x))
I can decrypt to recover P(x)
Cloud learns nothing about P, or even P(x)
But it has a shortcoming…
What if I want the cloud to learn P(x) (but still not P)?
So that the cloud can take some action if P(x) = 1.
Cryptographic mmaps can be positioned to “leak” a ‘0’ precisely when some condition is satisfied.

32. Mmaps from Homomorphic NTRU [GGH13]
NTRU ctext that encrypts m at “level d” has form e/sd.
e is small,
e = m mod p
s is the secret key
To decrypt, multiply by sd and reduce mod p.
Given level-d encodings c1 = e1/sd and c2 = e2/sd, how do we test whether they encode the same m?
If they encode same thing, then e1-e2 = 0 mod p. Moreover, (e1-e2)/p is a “small” polynomial.

33. Adding a Zero/Equality Test to NTRU
Zero-Testing parameter: z = h∙sd/p for “medium-size” h (e.g. |h| ≈ q3/4)
z(c1-c2) = h(e1-e2)/p
If c1, c2 encode same thing, |h(e1-e2)/p| is “medium-sized”
Otherwise, denominator p hopefully makes result look random mod q (when p is a polynomial, not a scalar).

34. Aren’t Mmap Schemes Broken?
Yes and no.
Key agreement: Broken!
All attempts to get multipartite key agreement “naturally” from mmaps are broken.
Obfuscation: Not broken!
Since obfuscation is all-powerful, you can even get multipartite KA from it “unnaturally”.

35. Two “Modes” of Using MMAPS
The Mathematics of Modern Cryptography
Private Encoding vs. Public Encoding
Encoding requires trapdoor
Modeled as “Multilinear Jigsaw Puzzles” [GGHRSW13]
Sufficient for many/most obfuscation schemes
Largely untouched by known attacks
Encoding/re-randomization is available to anyone
Via public encoding of zero
Needed for key-agreement, some hardness assumptions
Current mmaps are broken when used in this mode

36. The Future of Obfuscation and MMaps
A bumpy ride…
My guess: Variants of current obfuscation schemes will remain unbroken.
But we need better schemes:
More practical
Reducible to nice computational assumptions
Ideally, noise-free!

37. Thank You! Questions? ?
TIME EXPIRED ?