1 / 37

Cryptographic Program Obfuscation: Making Programs "Unintelligible

Explore the concept of obfuscation in cryptographic programs, using examples from Wikipedia. Discuss the motivations and challenges of achieving unintelligibility while maintaining functionality.

jacklyns
Download Presentation

Cryptographic Program Obfuscation: Making Programs "Unintelligible

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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? @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord ($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 @P=split//,".URRUU\c8R";@d=split//,"\nrekcahxinU / lrePrehtonatsuJ";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord ($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 • 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 @P=split//,".URRUU\c8R";@d=split//,"\nrekcahxinU / lrePrehtonatsuJ";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord ($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 http://www.arco-iris.com/George/images/game_of_go.jpg Game of Go Next move

  8. Why Obfuscation? • Hiding secrets in software • Uploading my expertise to the webwithout revealing my strategies @P=split//,".URRUU\c8R";@d=split//,"\nrekcahxinU / lrePrehtonatsuJ";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord ($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 @P=split//,".URRUU\c8R";@d=split//,"\nrekcahxinU / lrePrehtonatsuJ";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord ($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 classC, 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, C2that 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 Obfuscation x x Indist. Obfuscation Indist. Obfuscation ≈ Padding Best Obfuscation Some circuit C Some circuit C Computationally Indistinguishable 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. HE Obfuscation F F F(x) +  x Result in the clear Encryption F F F(x) +  x 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 F(x) + x Homomorphic Encryption F F NC1 Circuit CondDec F(x)

  24. NC1 Obfuscation  P Obfuscation F(x) + x Homomorphic Encryption F F @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{ @p{"r$p“… 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 π, xi’s, and two ciphertexts c0 = EncPK0(F(x)) and c1 = EncPK1(F(x)) π, x, and two ciphertexts c0 = EncPK0(F(x)) and c1 = EncPK1(F(x)) Indist. Obfuscation Indist. Obfuscation ≈ CondDecF,SK0(·, …, ·) CondDecF,SK1(·, …, ·) F(x) if π verifies 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, c2encode 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 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 The Mathematics of Modern Cryptography • 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 ?

More Related