Your SlideShare is downloading. ×
0
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Provable Security4
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Provable Security4

1,025

Published on

大学での暗号の講義(その4) …

大学での暗号の講義(その4)
2008-2010

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,025
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • The main result of this part is that general purpose software obfuscators do *not* exist, even if we use a very weak definition of security. By “general purpose” I mean an obfuscator that takes any program and should output a Scrambled version of this program. This result is joint work with Goldreich, Impagliazzo, Rudich, Sahai, Vadhan and Yang.
  • Before proving such a result we need to formally define what does it mean for An obfuscator to be secure, or at least what it means for an obfuscator to be insecure. We use the following definition. Let O be a candidate obfuscator. That means that O is an algorithm that takes A program as input and outputs a different program. We say that O totally fails on some program P if P can be efficiently recovered from O(P). Note that this means that it is possible to invert the obfuscator and recover the entire Original source code from the supposedly obfuscated version. If this happens then the obfuscator definitely failed. However one may complain that this definition does not capture all possible ways in which an obfuscator can fail. Indeed, if P contained comments Then even the trivial obfuscator that just throws away the comments will not fail totally on P. However, because we Are shooting for a negative result, the stronger notion of failure we require, the better – it will just mean our impossibility result will be stronger. Condition # 2 is meant to avoid trivialities. For example, if P is a program that prints its own source code, then, No matter how you obfuscate P, it will always be possible to recover the source from the obfuscated version by simple executing it. Thus, we require that it will be impossible to recover the source code of P just by executing it. The main theorem of this part is that for every candidate obfuscator O there exists a program P on which O totally fails. I will now give a “taste” of the proof of this theorem.
  • To prove the theorem we will give a family of functions, parametrized by a pair of strings \\alpha,\\beta of length, say 1000, Such that for every O if we choose alpha and beta at random then O will totally fail on P_{\\alpha,\\beta}. For every \\alpha,\\beta we define the program P_{\\alpha,\\beta} as follows: It takes as input a bit b and a string x. If b=0 and x=\\alpha, then P_{\\alpha,\\beta} outputs \\beta. I will now turn to proving this claim. If b=1, then P_{\\alpha,\\beta} interprets the string x as a description of a program! It then runs this program On the input (0,\\alpha). If the output is equal to \\beta then P_{\\alpha,\\beta} outputs the pair (\\alpha,\\beta). In all other cases P_{\\alpha,\\beta} outputs 0. As I said above, I will claim that every obfuscator fails w.h.p. on a P_{\\alpha,\\beta} if alpha,\\beta are chosen at random.
  • I will first show the second condition (i.e., that a random P_{\\alpha,\\beta} is hard to learn). I claim that black box access to P_{\\alpha,\\beta} is completely useless, since there is only negligible probability that one can obtain a non-zero answer from that black-box. Indeed, suppose that someone gives you a black-box that computes P_{\\alpha,\\beta} but you don’t know \\alpha or \\beta. Then, if you feed the box a query of the form (0,x) you will get a zero answer unless you happened to guess \\alpha, which We can assume never happens, since it will only happen with low probability. Now, if you only get zero answers For queries of the form 0,x then you have no information about \\beta, and so you have no way of coming up with a program that outputs \\beta on input \\alpha. This means that you will also get zero answers on queries of the form (1,x). Thus with very high probability you will only get zero answers from the black box. I will now show the first condition. Namely, that it is possible to efficiently recover the source of P_[\\alpha,\\beta} From any P’ which is an obfuscated version of P_{\\alpha,\\beta}. First, note that once we know \\alpha and \\beta Then it is easy to recover the code of P_{\\alpha,\\beta}, and hence we need to show that we can recover \\alpha and \\beta from P’. However, this is quite easy – to get \\alpha and \\beta run P’ on input 1 and *its own code*. Since P’ is a program that on input 0,\\alpha outputs \\beta, it follows that P’(1,P’)=\\alpha,\\beta. This finishes the proof. I just want to comment that this argument used crucially the fact that we could feed P’ as input to itself. This is no longer true if we want to rule out obfuscators for programs with bounded input length. I don’t have time to even hint how we overcome this obstacle , but actually in some sense that part is the technical heart of the paper.
  • I want now to dicuss a bit the meaning of this impossibility result. What we prove is that there doesn’t exist a general purpose obfuscator that takes any program and scrambles it securely. However, a manufacturer of commercial obfuscator might claim that we still didn’t rule out the possibility that his obfuscator is “virtually general purpose”. By this I mean that it is secure for all the programs that come up in practice, Although it will of course fail for our somewhat contrived counterexample. Let’s visualize this hypothetical (or not so hypothetical, see slashdot) obfuscator manufacturer’s argument as follows: We have the set of “useful” programs that come up in practice (don’t worry if you don’t know all these acronyms). Then there is our counter example, which admittedly is not in this set. Then, the manufacturer claims that the set of programs for which his obfuscator is secure contains all the useful programs and hence his obfuscator is “virtually general purpose”. This claim is similar to criticism of NP-completeness results. When we prove that the TSP problem is NP-complete, we prove that it is hard in the worst case, and that no algorithm can solve it on the crazy instances that come from our reduction. However, it may very well be that there is a simple heuristic that solves TSP on all the instances that actually come up in practice. I want to comment that in fact there is a difference between the case of obfuscation and the case of TSP, and actually in our case our negative result means more than may seem at first sight.
  • Transcript

    • 1. 暗号理論における安全性の証明: プログラム難読化( Obfuscation )の研究動向 Yury Lifshits & Boaz Barak の資料を一部借用しています Part of slides are copies from the web pages of Yury Lifshits & Boaz Barak http:// logic.pdmi.ras.ru/~yura/obfuscation.html http:// www.cs.princeton.edu/~boaz / 羽田 知史( IBM 東京基礎研究所) Satoshi Hada (IBM Research - Tokyo) mailto: satoshih at jp ibm com
    • 2. アジェンダ <ul><li>プログラムの難読化( Program Obfuscation )とは? </li></ul><ul><ul><li>アプリケーション </li></ul></ul><ul><ul><li>安全性 </li></ul></ul><ul><li>難読化の安全性をどう定義するか? </li></ul><ul><li>Negative な結果 </li></ul><ul><ul><li>本質的に難読化できないプログラムの存在 </li></ul></ul><ul><li>Positive な結果 </li></ul><ul><ul><li>Point functions </li></ul></ul><ul><ul><li>Re-encryption functions </li></ul></ul><ul><ul><li>Encrypted signature functions </li></ul></ul>
    • 3. プログラムの難読化( Obfuscation )は、プログラムを Unintelligible にする技術です The winning entry for the 1998 International Obfuscated C Code Contest
    • 4. 難読化には様々なアプリケーションがあります <ul><li>実用の観点から </li></ul><ul><ul><li>ソフトウェア保護 </li></ul></ul><ul><ul><li>ソフトウェア Watermarking </li></ul></ul><ul><li>暗号理論の観点から </li></ul><ul><ul><li>秘密鍵暗号から公開鍵暗号の変換 </li></ul></ul><ul><ul><li>Homomorphic Encryption の実現 </li></ul></ul><ul><ul><li>Random Oracle の実現 </li></ul></ul>
    • 5. 難読化の応用(1):秘密鍵暗号から公開鍵暗号への変換 <ul><li>変換のアイデア </li></ul><ul><ul><li>Enc K のプログラムを難読化して、公開鍵として Publish する。 </li></ul></ul><ul><ul><li>秘密鍵は、 K がそのまま使用される。 </li></ul></ul><ul><li>安全性の根拠 </li></ul><ul><ul><li>Enc K のプログラムには、 K が埋め込まれているが、難読化されているので K は漏れないだろう。。。 </li></ul></ul>Enc K Dec K C M M K: 秘密の共有鍵 O(Enc K ) Dec K C M M Enc K を難読化
    • 6. 難読化の応用(2): Homomorphic Encryption の実現 <ul><li>Homomorphic Encryption とは? </li></ul><ul><ul><li>Given C1=E(M1) and C2=E(M2), easy to compute E(M1+M2) and E(M1*M2) </li></ul></ul><ul><li>公開鍵暗号を使った、以下のプログラムを考える </li></ul><ul><ul><li>埋め込まれた情報:秘密鍵公開鍵ペア (pk, sk) </li></ul></ul><ul><ul><li>Step 1 : 入力として、 C1=E(pk, M1) and C2=E(pk, M2) が与えられる </li></ul></ul><ul><ul><li>Step 2 : sk を使って、復号し、 M1 と M2 を計算する </li></ul></ul><ul><ul><li>Step 3: M1+M2 および M1*M2 を pk で暗号化して出力 </li></ul></ul><ul><li>このプログラムを難読化して、 pk といっしょに、 publish すれば、 Homomorphic Public-Key Encryption が構成できる </li></ul><ul><li>安全性の根拠 </li></ul><ul><ul><li>秘密鍵が埋め込まれているが、難読化されているので、漏れることないだろう。。。 </li></ul></ul>
    • 7. 難読化の応用(3): Random Oracle の実現 <ul><li>Random Oracle Model </li></ul><ul><ul><li>An ideal cryptographic setting in which everyone has access to a truly random function </li></ul></ul><ul><li>Pseudorandom functions </li></ul><ul><ul><li>A function is pseudorandom if no adversary can not distinguish it from a truly random function (when the seed is randomly chosen) </li></ul></ul><ul><li>Obfuscating pseudorandom functions may be able to implement the random oracle model. </li></ul>Distinguisher (Adversary) f s u BB access BB access S is a secret seed
    • 8. 難読化のテクニックには様々なものがあります <ul><li>レイアウトの難読化 </li></ul><ul><ul><li>コメントを削除 </li></ul></ul><ul><ul><li>変数名や関数名のスクランブル </li></ul></ul><ul><ul><li>フォーマットの変更 </li></ul></ul><ul><li>データの難読化 </li></ul><ul><ul><li>変数の分割 </li></ul></ul><ul><ul><li>変数のマージ </li></ul></ul><ul><ul><li>順番の入れ替え </li></ul></ul><ul><li>制御文の難読化 </li></ul><ul><ul><li>などなどなど </li></ul></ul>
    • 9. しかし、安全性の評価は難しいです <ul><li>プログラムの長さ </li></ul><ul><ul><li>Operator や Operand の数 </li></ul></ul><ul><li>データフローの複雑さ </li></ul><ul><ul><li>ブロックをまたがる変数参照の数 </li></ul></ul><ul><li>Cyclomatic Complexity </li></ul><ul><ul><li>Decision ポイント( if 文や while 文)の数 </li></ul></ul><ul><li>Nesting Complexity </li></ul><ul><ul><li>ネストの深さ </li></ul></ul>
    • 10. 近年、難読化の安全性を、暗号理論の観点で、議論する研究がさかんです。 赤:主に否定的な結果 青:主に肯定的な結果 <ul><li>R. Canetti,Y. T. Kalai, M. Varia, and D. Wichs,``On Symmetric Encryption and Point Obfuscation&quot;, TCC 2010 </li></ul><ul><li>R. Canetti,Y. G. N. Rothblum, and M. Varia, ``Obfuscation of Hyperplane Membership&quot;, TCC 2010 </li></ul><ul><li>S. Hada, ``Secure Obfuscation for Encrypted Signatures”, Eurocrypt 2010. </li></ul><ul><li>N. Bitansky and R. Canetti, ``On Strong Simulation and Composable Point Obfuscation,&quot; CRYPTO 2010. </li></ul>2010 <ul><li>R. Canetti, M. Varia, ``Non-Malleable Obfuscation, “ TCC’09. </li></ul>2009 <ul><li>R. Canetti, R. R. Dakdouk, ``Obfuscating Point Functions with Multibit Output,” Eurocrypt 2008. </li></ul>2008 <ul><li>D. Hofheinz, J. Malone-Lee, and M. Stam, ``Obfuscation for Cryptographic Purposes,&quot; TCC'07. </li></ul><ul><li>S. Hohenberger, G. N. Rothblum, a. shelat, and V. Vaikuntanathan, ``Securely Obfuscating Re-Encryption,'' TCC'07. </li></ul><ul><li>S. Goldwasser and G. N. Rothblum, ``On Best-Possible Obfuscation,'' TCC'07. </li></ul><ul><li>B. Adida, D. Wikström, ``How to Shuffle in Public,” TCC’07. </li></ul>2007 <ul><li>H. Wee, ``On Obfuscating Point Functions,&quot; STOC'05. </li></ul><ul><li>S. Goldwasser and Y. T. Kalai, ``On the Impossibility of Obfuscation with Auxiliary Input,&quot; FOCS'05. </li></ul>2005 <ul><li>B. Lynn, M. Prabhakaran, and A. Sahai, ``Positive Results and Techniques for Obfuscation,&quot; Eurocrypt’04. </li></ul>2004 <ul><li>B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S. Vadhan, K. Yang,``On the (Im)possibility of Obfuscating Programs,&quot; CRYPTO’01 (ECCC,Report 2001-57) </li></ul>2001 <ul><li>S. Hada, ``Zero-Knowledge and Code Obfuscation,&quot; Asiacrypt'2000. </li></ul>2000
    • 11. アジェンダ <ul><li>プログラムの難読化( Program Obfuscation )とは? </li></ul><ul><ul><li>アプリケーション </li></ul></ul><ul><ul><li>安全性 </li></ul></ul><ul><li>難読化の安全性をどう定義するか? </li></ul><ul><li>Negative な結果 </li></ul><ul><ul><li>本質的に難読化できないプログラムの存在 </li></ul></ul><ul><li>Positive な結果 </li></ul><ul><ul><li>Point functions </li></ul></ul><ul><ul><li>Re-encryption functions </li></ul></ul><ul><ul><li>Encrypted signature functions </li></ul></ul>
    • 12. Obfuscator の定義: Obfuscator は、機能を保持したままプログラムをわかりにくく変換するアルゴリズムです。安全性の定義は非自明です。 <ul><li>プログラムとは? </li></ul><ul><ul><li>Programs as a class of circuits C={C n } </li></ul></ul><ul><ul><ul><li>C n is a set of circuits of input length n </li></ul></ul></ul><ul><ul><ul><li>C n の circuit が一つのプログラムに対応 </li></ul></ul></ul><ul><li>Obfuscator とは? </li></ul><ul><ul><li>Functionality requirement: </li></ul></ul><ul><ul><ul><li>難読化したプログラムは、オリジナルのプログラムと同じ機能をもつべきである。 </li></ul></ul></ul><ul><ul><ul><li>An probabilistic polynomial-time machine O is an obfuscator if for every class of circuits C ={C n }, for any circuit P∈ C n , for every input x, Pr[ P’ ← O(P) : P(x)=P’(x)]=1 </li></ul></ul></ul><ul><ul><li>Security requirement: </li></ul></ul><ul><ul><ul><li>これをどのように定義するかが非自明!!! </li></ul></ul></ul>
    • 13. Simulation Paradigm に基づいて、 Obfuscator の安全性を定義することができます(1) <ul><li>Simulation Paradigm とは、「一切、情報が漏れない」を表現する方法 </li></ul><ul><ul><li>攻撃者が計算できるものは、攻撃の対象がなくても、計算できる。 </li></ul></ul><ul><li>難読化のコンテキストでは? </li></ul><ul><ul><li>攻撃の対象:難読化されたプログラム(のコード) </li></ul></ul><ul><ul><li>攻撃の対象が無い状況:プログラムへ Black-box アクセスだけできる。任意の入力を与えて、出力結果を得ることは可能。 </li></ul></ul><ul><li>Virtual Blackbox Property という性質として定義する </li></ul><ul><ul><li>難読化されたプログラムから計算できるものは、プログラムへの Blackbox アクセスのみからも計算できる </li></ul></ul>
    • 14. Simulation Paradigm に基づいて、 Obfuscator の安全性を定義することができます(2) <ul><li>A probabilistic polynomial-time machine O is an obfuscator if the two requirements are satisfied: </li></ul><ul><li>Functionality requirement: </li></ul><ul><ul><li>∀ class of circuits C ={C n }, ∀ circuit P∈ C n , ∀ input x, Pr[ P’ ← O(P) : P(x)=P’(x)]=1 </li></ul></ul><ul><li>Virtual blackbox property </li></ul><ul><ul><li>∀ class of circuits C, ∀ circuit P∈ C n , ∀ 攻撃者 A, ∃ Simulator S s.t. {P’ ← O(P) : A(P’)} と {S P (1 n )} が Computationally Indistinguishable. </li></ul></ul><ul><ul><li>∀ class of circuits C, ∀ circuit P∈ C n , ∀ 攻撃者 A, ∃ Simulator S s.t. ∀ distinguisher D, ∃negligible function δ(n), s.t. |Pr[ P’ ← O(P) ; o←A(P’); D(o)=1] – Pr[o←S P (1 n ) : D(o)=1] | < δ(n) </li></ul></ul><ul><ul><li>この定義は、簡略化できる。 </li></ul></ul><ul><ul><ul><li>難読化されたプログラム P’ を出力する攻撃者だけを考えればいい </li></ul></ul></ul><ul><ul><li>∀ class of circuits C, ∀ circuit P∈ C n , ∃ Simulator S s.t. ∀ distinguisher D, ∃negligible function δ(n), s.t. |Pr[ P’ ← O(P) ; D(P’)=1] – Pr[P’←S P (1 n ) : D(P’)=1] | < δ(n) </li></ul></ul>
    • 15. しかし、前述の Naïve な安全性の定義は強すぎます <ul><li>A probabilistic polynomial-time machine O is an obfuscator if the two requirements are satisfied: </li></ul><ul><li>Functionality requirement: </li></ul><ul><ul><li>∀ class of circuits C ={C n }, ∀ circuit P∈ C n , ∀ input x, Pr[ P’ ← O(P) : P(x)=P’(x)]=1 </li></ul></ul><ul><li>Virtual blackbox property </li></ul><ul><ul><li>∀ class of circuits C, ∀ circuit P∈ C n , ∃ Simulator S s.t. ∀ distinguisher D, ∃negligible function δ(n), s.t. |Pr[ P’ ← O(P) ; D(P’)=1] – Pr[P’←S P (1 n ) : D(P’)=1] | < δ(n) </li></ul></ul><ul><li>問題点 </li></ul><ul><ul><li>Cが難読化できるためには、 C は Learnable でないといけない </li></ul></ul><ul><ul><ul><li>つまり、 P への Blackbox アクセスが与えられたとき、 P と同じ機能をもつプログラムを再構成できる必要がある </li></ul></ul></ul><ul><ul><li>Learnable ではない C は存在するので、 Impossible to meet this security requirement </li></ul></ul><ul><ul><ul><li>E.g., point functions </li></ul></ul></ul>
    • 16. 攻撃者の計算出力を制限することにより、弱い安全性を定義することも可能です。 <ul><li>アイデア </li></ul><ul><ul><li>攻撃者の目的を、オリジナルのプログラムの predicate の計算に限定する </li></ul></ul><ul><li>A probabilistic polynomial-time machine O is an obfuscator if the two requirements are satisfied: </li></ul><ul><li>Functionality requirement は同じ </li></ul><ul><ul><li>∀ class of circuits C ={C n }, ∀ circuit P∈ C n , ∀ input x, Pr[ P’ ← O(P) : P(x)=P’(x)]=1 </li></ul></ul><ul><li>Virtual blackbox property </li></ul><ul><ul><li>∀ class of circuits C, ∀ circuit P∈ C n , ∀ 攻撃者 A, ∀ predicate π , ∃ Simulator S s.t. ∀ distinguisher D, ∃negligible function δ(n), s.t. |Pr[ P’ ← O(P) ; b←A(P’); b=π(P) ] – Pr[b←S P (1 n ) : b=π(P) ] | < δ(n) </li></ul></ul>
    • 17. アジェンダ <ul><li>プログラムの難読化( Program Obfuscation )とは? </li></ul><ul><ul><li>アプリケーション </li></ul></ul><ul><ul><li>安全性 </li></ul></ul><ul><li>難読化の安全性をどう定義するか? </li></ul><ul><li>Negative な結果 </li></ul><ul><ul><li>本質的に難読化できないプログラムの存在 </li></ul></ul><ul><li>Positive な結果 </li></ul><ul><ul><li>Point functions </li></ul></ul><ul><ul><li>Re-encryption functions </li></ul></ul><ul><ul><li>Encrypted signature functions </li></ul></ul>
    • 18. MAIN RESULT (informal) <ul><li>Thm [BGI+01] : General-purpose obfs, even under very weak defs, do not exist. </li></ul>[BGI+01] Barak, Goldreich, Impagliazzo, Rudich, Sahai, Vadhan, Yang “On the (Im)possibility of Obfuscating Programs”, CRYPTO 2001.
    • 19. DEFINING OBFs <ul><li>Def: O : P  P “totally fails” on P if </li></ul>1. P can be efficiently recovered from O (P) (i.e., complete recovery of source code) 2. P is hard to learn (i.e., can’t recover P using BB access to its function) Thm [BGI+01] : ∀ O ∃ P s.t. O totally fails on P . (assuming OWF exist) * “TASTE” OF PROOF
    • 20. * “TASTE” OF PROOF Pf: Show function family {P  ,  } s.t. O totally fails ( code recovery + hard to learn ) on random member: Thm [BGI+01] : ∀ O ∃ P s.t. O totally fails on P . (assuming OWF exist) Define P  ,  (b,x)=  b=0 , x=   b=1 , x(0,  )=  0 otherwise Claim: ∀ O for random  ,  w.h.p. O totally fails on P  , 
    • 21. * “TASTE” OF PROOF Claim: ∀ O for random  ,  w.h.p. O totally fails on P  ,  Thm [BGI+01] : ∀ O ∃ P s.t. O totally fails on P . (assuming OWF exist) Pf: Show function family {P  ,  } s.t. O totally fails ( code recovery + hard to learn ) on random member: Define P  ,  (b,x)=  b=0 , x=   b=1 , x(0,  )=  0 otherwise
    • 22. Pf: To recover  ,  from P’= O (P  ,  ) - output P’(1,P’) For random  ,  can’t distinguish bet P  ,  and all-zero function using BB access. Define P  ,  (b,x)=  b=0 , x=   b=1 , x(0,  )=  0 otherwise Claim: ∀ O for random  ,  w.h.p. O totally fails on P  ,  Note: In paper, rule out OBFs for programs with bounded input length. Black-box access is useless: Can recover source from obf’d code:
    • 23. MEANING OF RESULT <ul><li>Proved: No general-purpose obf exists. </li></ul>Maybe “virtually general-purpose” obf exists? Similar to critique of NP-completeness results. Counter Ex. “ Useful” progs (DES,RSA,AES,SHA,…) O secure
    • 24. Summary by Scott Aaronson (http://scottaaronson.com/blog/?p=16) <ul><li>There’s no generic, foolproof way to “obfuscate” a computer program. For even if a program looked hopelessly unreadable, you could always feed it its own code as input, which is one thing you couldn’t do if all you had was a “black box” with the same input/output behavior as the program in question. </li></ul>
    • 25. アジェンダ <ul><li>プログラムの難読化( Program Obfuscation )とは? </li></ul><ul><ul><li>アプリケーション </li></ul></ul><ul><ul><li>安全性 </li></ul></ul><ul><li>難読化の安全性をどう定義するか? </li></ul><ul><li>Negative な結果 </li></ul><ul><ul><li>本質的に難読化できないプログラムの存在 </li></ul></ul><ul><li>Positive な結果 </li></ul><ul><ul><li>Point functions </li></ul></ul><ul><ul><li>Re-encryption functions </li></ul></ul><ul><ul><li>Encrypted signature functions </li></ul></ul>
    • 26. 研究の方向性:汎用の Obfuscator は、存在しないので、特定のプログラム用の Obfuscator を考察する必要があります。 <ul><li>A probabilistic polynomial-time machine O is an obfuscator for a class of circuits C ={C n } if the two requirements are satisfied: </li></ul><ul><li>Functionality requirement </li></ul><ul><ul><li>∀ circuit P∈ C n ,∀ input x, Pr[ P’ ← O(P) : P(x)=P’(x)]=1 </li></ul></ul><ul><li>Virtual blackbox property </li></ul><ul><ul><li>∀ circuit P∈ C n , ∀ 攻撃者 A, ∀ predicate π , ∃ Simulator S s.t. ∀ distinguisher D, ∃negligible function δ(n), s.t. |Pr[ P’ ← O(P) ; b←A(P’); b=π(P)] – Pr[b←S P (1 n ) : b=π(P)] | < δ(n) </li></ul></ul>
    • 27. Positive Result (1) : Point Functions は難読化できることが知られています。 <ul><li>P  (x)= </li></ul>1 if x=α 0 otherwise Input: x 埋め込まれる情報 : f(α) Step 1: f(x) を計算 Step 2: f(x)=f(α) なら1を出力 難読化 f(x) は α に関して1ビットも漏らさない特殊な関数。様々な計算量的な困難性の仮定の下での、この関数の設計が研究テーマ。 難読化されたプログラム Input: x 埋め込まれる情報 : α Step 1: x=α なら1を出力
    • 28. Positive Result (1) : 実は、パスワード認証で広く用いられているテクニックであり、その安全性を、難読化の観点で議論することができます。 (user, password) Valid / Invalid Alice α Bob β ・・・ Password Table 難読化 Alice f(α) Bob f(β) ・・・
    • 29. Sampling Obfuscator :多くの暗号プリミティブ(暗号化など)は確率的なプログラムなので、確率的なプログラムの難読化の重要なテーマです。 <ul><li>これまでは、 Deterministic なプログラムを考えてきたが、 Probabilistic なプログラムを考えることもできる。その場合、 Functionality requirement として、難読化されたプログラムが、オリジナルのプログラムと同じ確率分布を生成する、ことを要求する。 </li></ul><ul><li>A probabilistic polynomial-time machine O is a sampling obfuscator for a class of probabilistic circuits C ={C n } if the two requirements are satisfied: </li></ul><ul><li>Functionality requirement </li></ul><ul><ul><li>∀ circuit P∈ C n ,∀ input x, Pr[ P’ ← O(P) : P(x) と P’(x) の確率分布が等しい ]=1 </li></ul></ul><ul><li>Virtual blackbox property </li></ul><ul><ul><li>適切に定義する必要がある </li></ul></ul>
    • 30. Positive Result (2) : Sampling Obfuscator の概念に基づいて、 ReEncryption は難読化できることが知られています。 <ul><li>ReEncryption とは? </li></ul><ul><ul><li>パラメータ : 2つの公開鍵・秘密鍵ペア </li></ul></ul><ul><ul><ul><li>(pk1, sk1) (pk2, sk2) </li></ul></ul></ul><ul><ul><li>入力 </li></ul></ul><ul><ul><ul><li>pk1 で暗号化された暗号文 </li></ul></ul></ul><ul><ul><ul><ul><li>C1=E(pk1,M) </li></ul></ul></ul></ul><ul><ul><li>出力 </li></ul></ul><ul><ul><ul><li>同じメッセージを pk2 で暗号化したときの暗号文 </li></ul></ul></ul><ul><ul><ul><ul><li>C2=E(pk2,M) </li></ul></ul></ul></ul>ReEncryption by メールセンター (sk1 が漏れないように難読か ) (pk1, sk1) (pk2, sk2) E(pk1, M) E(pk1, M) E(pk2, M)
    • 31. Positive Result ( 3 ) : 同様に Encrypted Signatures も難読化できることが知られています。 <ul><li>Encrypted Signatures の処理では、メッセージそのものは暗号化の対象ではないですが、 LotusNotes などの電子メールの署名&暗号化( PGP や S/MIME )のために広く利用されている Sign-then-Encrypt ( StE )の処理へ応用可能です。 </li></ul>Sign Encrypt Alice’s sk (署名鍵) Bob’s pk (暗号化鍵) m c σ Verify Decrypt Alice’s pk (検証鍵) Bob’s sk (復号鍵) 検証結果 c メッセージ 暗号文 難読化の対象 Alice (メール送信者) Bob (メール受信者) σ
    • 32. 従来のメール・アプリケーションでは、 StE の処理は、ローカル・マシンで行われます。署名鍵もローカルマシンで保持されるので安全です。 (e.g., Lotus Notes) Sign-then- Encrypt@ LocalApp Alice’s email application Bob’s email application Server Server Signing keys are stored in local machines
    • 33. 最近の SaaS 環境では、署名鍵はサーバー上に保持され、 StE の処理がサーバー上で行われる必要があります。したがって、署名鍵の漏洩が懸念されます。 (e.g., Lotus Live, Gmail, Hotmail, etc) Sign-then- Encrypt@ Server Alice’s Web Mail Bob’s Web Mail Browser Browser Server Server Key leakage is a potential security issue!! Browsers have no capability of sign-then-encrypt
    • 34. StE プログラムを暗号理論的に難読化することができれば、署名鍵の漏洩を防ぐことができます。 Sign-then- Encrypt@ Server Alice’s Web Mail Bob’s Web Mail Browser Browser Server Server We can obfuscate this program
    • 35. Basic Idea :署名鍵を暗号化することにより難読化する。ただし、暗号化した署名鍵を使っても、 Encrypted Signatures の処理が可能なようにアルゴリズムを設計する。 <ul><li>Design a pair of signature and encryption schemes such that the following two are functionally equivalent: </li></ul><ul><li>signing a message and then encrypting the signature, </li></ul><ul><li>encrypting the signing key and then signing the message under the encrypted signing key. </li></ul>Sign Encrypt m c σ Encrypt Alice’s sk Bob’s pk Sign Obfuscated Encrypted Signature Program Encrypted Alice’s sk
    • 36. Basic Idea <ul><li>Input m </li></ul><ul><li>Output c </li></ul><ul><li>Stored Info: </li></ul><ul><ul><li>Alice’s private signing key </li></ul></ul><ul><ul><li>Bob’s public encryption key </li></ul></ul><ul><li>Code </li></ul><ul><ul><li>Use Alice’s signing key to sign m </li></ul></ul><ul><ul><li>Use Bob’s encryption key to encrypt the signature </li></ul></ul><ul><ul><li>Output the ciphertext </li></ul></ul><ul><li>Input m </li></ul><ul><li>Output c </li></ul><ul><li>Stored Info: </li></ul><ul><ul><li>Alice’s private signing key encrypted by Bob’s public encryption key </li></ul></ul><ul><li>Code </li></ul><ul><ul><li>Use the encrypted Alice’s signing key to sign m </li></ul></ul><ul><ul><li>Output the signature </li></ul></ul>Obfuscation 難読化前 難読化後 プログラム中に保持される情報は暗号化されているので、 Alice の秘密鍵は漏れない
    • 37. 使用する署名と暗号化のアルゴリズム <ul><li>署名アルゴリズム (Sign) </li></ul><ul><ul><li>Key Pair: (v, s) such that v=g s </li></ul></ul><ul><ul><ul><li>g は位数 q (prime) の生成元 for a special group (a bilinear map) </li></ul></ul></ul><ul><ul><ul><li>v: public verification key </li></ul></ul></ul><ul><ul><ul><li>s: private signing key </li></ul></ul></ul><ul><ul><li>署名生成 </li></ul></ul><ul><ul><ul><li>σ=Sign(s, m)=H(m) s , where H is a hash function </li></ul></ul></ul><ul><ul><ul><li>s 乗するだけの簡単な計算 </li></ul></ul></ul><ul><ul><li>検証 </li></ul></ul><ul><ul><ul><li>Bilinear map により簡単にできる(詳細は省略) </li></ul></ul></ul><ul><li>暗号化アルゴリズム (Encrypt) </li></ul><ul><ul><li>Key Pair: (pk, sk) </li></ul></ul><ul><ul><ul><li>pk: public encryption key </li></ul></ul></ul><ul><ul><ul><li>sk: private decryption key </li></ul></ul></ul><ul><ul><li>暗号化関数 </li></ul></ul><ul><ul><ul><li>C←Encrypt(pk, m) とする </li></ul></ul></ul><ul><ul><ul><li>ランダムに暗号文を生成する </li></ul></ul></ul><ul><ul><li>復号の関数については省略 </li></ul></ul>
    • 38. 難読化対象の Encrypted Signature プログラム <ul><li>Input m </li></ul><ul><li>Output (c1, c2) </li></ul><ul><li>Stored Info: </li></ul><ul><ul><li>private signing key: s </li></ul></ul><ul><ul><li>public encryption key: pk </li></ul></ul><ul><li>Code </li></ul><ul><ul><li>σ=Sign(m, s )=H(m) s を計算 </li></ul></ul><ul><ul><li>乱数 r を生成 </li></ul></ul><ul><ul><li>c1=σ r を計算 </li></ul></ul><ul><ul><li>c2=Encrypt(pk, r) を計算 </li></ul></ul><ul><ul><li>(c1,c2) を出力 </li></ul></ul>署名 暗号化
    • 39. 難読化の試み(失敗例) <ul><li>Input m </li></ul><ul><li>Output (c1, c2) </li></ul><ul><li>Stored Info: </li></ul><ul><ul><li>private signing key: s </li></ul></ul><ul><ul><li>public encryption key: pk </li></ul></ul><ul><li>Code </li></ul><ul><ul><li>σ=Sign(m, s )=H(m) s を計算 </li></ul></ul><ul><ul><li>乱数 r を生成 </li></ul></ul><ul><ul><li>c1=σ r を計算 </li></ul></ul><ul><ul><li>c2=Encrypt(pk, r) を計算 </li></ul></ul><ul><ul><li>(c1,c2) を出力 </li></ul></ul>難読化前 <ul><li>Input m </li></ul><ul><li>Output (c1, c2) </li></ul><ul><li>Stored Info: </li></ul><ul><ul><li>s’=s*r mod q (r は乱数 ) </li></ul></ul><ul><ul><li>c2=Encrypt(pk, r) </li></ul></ul><ul><li>Code </li></ul><ul><ul><li>c1=Sign(m, s’ )=H(m) s’ を計算 </li></ul></ul><ul><ul><li>(c1,c2) を出力 </li></ul></ul>Obfuscation 難読化後 (c1,c2) はランダムに生成される (c1,c2) はランダムに生成されない
    • 40. 難読化 <ul><li>Input m </li></ul><ul><li>Output (c1, c2) </li></ul><ul><li>Stored Info: </li></ul><ul><ul><li>private signing key: s </li></ul></ul><ul><ul><li>public encryption key: pk </li></ul></ul><ul><li>Code </li></ul><ul><ul><li>σ=Sign(m, s )=H(m) s を計算 </li></ul></ul><ul><ul><li>乱数 r を生成 </li></ul></ul><ul><ul><li>c1=σ r を計算 </li></ul></ul><ul><ul><li>c2=Encrypt(pk, r) を計算 </li></ul></ul><ul><ul><li>(c1,c2) を出力 </li></ul></ul>難読化前 <ul><li>Input m </li></ul><ul><li>Output (c1, c2) </li></ul><ul><li>Stored Info: </li></ul><ul><ul><li>s’=s*r mod q (r は乱数 ) </li></ul></ul><ul><ul><li>c=Encrypt(pk, r) </li></ul></ul><ul><li>Code </li></ul><ul><ul><li>乱数 r’ を生成し、 s’’=s’*r’ mod q を計算 </li></ul></ul><ul><ul><li>c1=Sign(m, s’’ )=H(m) s’’ を計算( c1=σ r*r’ を計算) </li></ul></ul><ul><ul><li>c と r’ から、 (r*r’ mod q) の暗号文 c2 をランダムに生成(詳細省略するが、こういうことができる特殊な暗号アルゴリズムを使用する必要有り) </li></ul></ul><ul><ul><li>(c1,c2) を出力 </li></ul></ul>Obfuscation 難読化後 (c1,c2) はランダムに生成される 同様に、 (c1,c2) はランダムに生成される
    • 41. まとめ
    • 42. まとめ 安全性の定義 実現可能 実現不可能 安全性の証明が既知 (証明が可能) 安全性の証明が 不可能あるいは 未解決 <ul><li>プログラムの難読化 </li></ul><ul><li>Point Function </li></ul><ul><li>ReEncryption </li></ul><ul><li>Encrypted signature </li></ul><ul><li>NA </li></ul><ul><li>NA </li></ul><ul><li>Generic な難読化は不可能 </li></ul>

    ×