論文翻訳: On White-Box Cryptography

Abstract

white-box 暗号技術は、暗号アルゴリズムのソフトウェア実装を鍵の復元から保護することを目的としている。white-box 暗号技術は主に DRM のようなアプリケーションにおいて、トークンベースの保護に代替する費用対効果の高い技術として使用されている。この論文では、そのような文脈における white-box 実装の妥当性について一覧の質問と回答で論議する。

Table of Contents

1. Abstract
2. Q1: white-box 暗号とは何か?
3. Q2: コード難読化との違いは何か?
4. Q3: white-box の脅威モデルはどの程度現実的か?
5. Q4: white-box 暗号の適用例は何か?
6. Q5: white-box 実装の一般的な方法論は何か?
7. Q6: white-box 暗号の代替はあるか?
8. Q7: 長所と短所は?
9. Q8: white-box 実装の安全性は?
10. 結論と未解決問題
11. Acknowledgements
12. References
13. 翻訳抄

Q1: white-box 暗号とは何か?

セキュリティプログラムを扱う上での大きな問題はコードに埋め込まれた "センシティブ" (secret, confidential または private) なデータの保護である。通常の解決策はデータを暗号化することだが、正当なユーザは復号化キーにアクセスする必要がありそのキーも保護する必要がある。これは信頼されていないホスト上で実行される、ソフトウェアのみのソリューションではさらに困難である。

white-box 暗号 (white-box cryptography) はソフトウェア実装において秘密鍵が漏洩しないように保護することを目的としている。このような状況では攻撃者 (通常、"正当な" ユーザまたは悪意のあるソフトウェア) が実行環境も制御できることが想定される。これは、攻撃者が暗号アルゴリズムに対するブラックボックスアクセス (つまり入力/出力) のみを与えられるという、より古典的なセキュリティモデルとは対照的である。

Q2: コード難読化との違いは何か?

ソフトウェア実装の保護に関わる補完的な技術には、セキュリティのゴールが異なるがコードの難読化やソフトウェアの耐タンパー性などがある。コード難読化 (code obfuscation) は (暗号) アルゴリズムのリバースエンジニアリングからの保護を目的とし、ソフトウェアの耐タンパー性 (software tamper-resistance) はコードの改変からの保護を目的としている。

これらの技術に共通していることは、結果として得られる実装が直接実行可能でなければならないということである。

Q3: white-box の脅威モデルはどの程度現実的か?

暗号化方式の古典的な (つまりブラックボックス的な) 脅威モデルには、選択平文攻撃 (CPA) モデルと選択暗号文攻撃 (CCA) モデルがある。CPA モデルでは攻撃者が平文を選択してそれに対応する暗号文が与えられる。CCA モデルでは攻撃者が暗号文を選択してそれに対応する平文が与えられる。

white-box 脅威モデルでは、攻撃者はブラックボックスモデルと同じリソースへのアクセスに加え、暗号化/復号化ソフトウェアを完全に制御することができる。攻撃者のゴールは鍵を取り出すことである。暗号化/復号化ソフトウェアを制御できる攻撃者はソフトウェアを利用して鍵を取り出すことなく任意のデータを暗号化/復号化することができるため、なぜこのようなシナリオが意味を持つのか疑問に思うかもしれない。しかし、white-box 実装はユーザ (訳注:攻撃者) に手元のソフトウェアを使わせるという点で有用であることは言うまでもない¹。さらに、同時に他のセキュリティ手段を使用することができる。

もし攻撃者が復号化キーを復元できれば、データは復号化されてどのホストのどのソフトウェアでも使用することができる (BORE 攻撃 - break once, run everywhere を参照。これはより深刻な被害をもたらすグローバルクラックを可能にする。

Q4: white-box 暗号の適用例は何か?

white-box 暗号の主な用途はデジタル著作権管理 (DRM; digital rights management) アプリケーションなどの "価値のある" コンテンツを安全に配信することである。ここでの主なゴールは、音楽や動画など、ソフトウェアによって処理された大量のデータが不正に使用されることを防ぐことである。

さらに驚くべきことに、white-box 技術は "軽量" 暗号の開発も可能にする (プライベートな操作だけが "軽量" であることに注意)。例えば:

秘密鍵暗号を公開鍵暗号に変換

秘密鍵暗号アルゴリズム \(E_K\) の white-box 実装 \(\wb(E_K)\) から公開鍵暗号スキームを構築することは (原理的には) 容易である。\(\wb(E_K)\) を持っていれば誰でもメッセージを暗号化することができるが、秘密鍵 \(K\) を持っている人だけが復号化アルゴリズム \(E_K^{-1}\) を使って復号化することができる。

注: この変換が有効であるためには \(E_K\) と \(E_K^{-1}\) が異なっている必要がある。また \(\wb(E_K)\) を公開することが、一方向性 (one-wayness) や better, semantic security のような通常のセキュリティ特性と矛盾しないことを保証する必要がある。

MAC を電子署名に変換

前述のようにして (鍵付き) メッセージ認証コード (MAC_K) スキームを用いて電子署名を生成することができる。秘密鍵 \(K\) が与えられればどのようなメッセージでも MAC_K を使用して署名を算出することができる; さらに、"検証" アルゴリズムのパブリック (かつ認証された) white-box 実装 \(\wb({\rm MAC}_K^{-1})\) を用いることで、誰でも署名の有効性を検証することができる。従来の MAC 構造とは異なり、この検証には秘密 \(K\) を知る必要はない。

注: ここでも否認防止特性を満たすためには "MAC" の算出と検証操作が異なることを仮定する必要がある。暗号論的ハッシュ関数 \(h\) を用い、\(E_K\) と \(E_K^{-1}\) が異なるのであれば、メッセージ \(m\) に対する署名を \(S=E_K(h(m))\) として生成し、\(\wb(E_K^{-1})(S)\) が \(h(m)\) と等しいかどうかをチェックすることで、その正しさを \(\wb(E_K^{-1})\) で検証することができる。

Q5: white-box 実装の一般的な方法論は何か?

white-box 実装の主旨は、鍵に関する全ての情報が "秘匿される" ようにインスタンス化された鍵 (key-instantiated) バージョンを書き換えることである。つまり秘密鍵ごとに、鍵の入力が不要となるように、鍵をカスタマイズしたソフトウェアを実装することである。

AES や DES を含むほとんどの対称型ブロック暗号は S ボックス (substitution boxes) と線形変換を用いて実装されている。このような暗号が、任意の平文を入力するとある鍵に対応する暗号文を返すような巨大なルックアップテーブルとして実装された white-box であると想像してください。この white-box 実装はブラックボックス文脈での同じ暗号とまったく同等のセキュリティを持っているとすると、攻撃者は一致する平文/暗号文のペア以外に何も知ることができない。平文は 64-bit や 128-bit 値が一般的だが、このような理想的なアプローチは実際には実装することはできない。

現在の white-box 実装は上記の基本的な考え方をより小さなコンポーネントに適用している。各コンポーネントを一連のルックアップテーブルとして表現し、ランダムな入力と出力の双方向エンコーディングを挿入して曖昧さを導入することで、結果的にアルゴリズムがランダム化された値を持つ一連のルックアップテーブルの構成に見えるようにしている。

保護をさらに強化するために、暗号化関数 \(E_K\) (また復号化関数 \(E_K^{-1}\)) を組成 \(E'_K = G \circ E_K \circ F^{-1}\) (同様に \(E'_K{}^{-1} = F \circ E_K^{-1} \circ G^{-1}\)) と置き換えることで (鍵に依存しない) 外部エンコーディングを使用することができる。入力エンコード関数 \(F\) と出力エンコード関数 \(G^{-1}\) (同様に \(F^{-1}\) と \(G\)) は、white-box 実装が \(E_K\) (同様に \(E_K^{-1}\)) を計算するために用いられないように、\(E'_K\) (同様に \(E'_K{}^{-1}\)) を算出するプラットフォームで利用できるようにしてはならない。結果として得られる実装は標準的なものではないが、このようなアプローチは多くの DRM アプリケーションにとって合理的である。

Q6: white-box 暗号の代替はあるか?

スマートカードのような耐タンパー性を持つトークンもキー復元攻撃の防止に役に立つ。一般的に、暗号鍵はトークンの不揮発性メモリに格納され、暗号はトークン内部で算出される。したがって、このようなトークンはブラックボックスデバイスとみなすことができる。しかし残念ながらそう簡単には行かない。トークンはいわゆるサイドチャネル攻撃の影響を受けやすい。

このような脅威モデルはグレーボックス暗号 (gray-box cryptography) と呼ばれることもある。攻撃者は暗号アルゴリズムの入力と出力に加えてサイドチャネル情報にアクセスすることができる。攻撃者がデバイスを所有しているということは、一連の実験を行い、実行時間、消費電力、電磁波などの情報を収集し、そこから秘密鍵を推測することができるということです。これらの攻撃は現在十分に理解されており、最近のスマートカードの実装では効率的な (ハードウェア/ソフトウェア) 対策が施されている。

グレーボックス暗号には probing などの物理的な攻撃や fault 攻撃も含まれている。後者の例では攻撃者は失敗を誘発させ、失敗した出力から秘密情報を復元を試みることができる。このような攻撃に対してはセンサー (ハードウェアレベル) や空間・時間の冗長性 (ハードウェアまたはソフトウェアレベル) など基地の防御策があります。

グレーボックスのコンテキストで利用可能なすべての攻撃は white-box のコンテキストでも容易に適用可能であり、実行も容易であることに注意。

Q7: 長所と短所は?

セキュリティ問題以外でハードウェアーベースのソリューションと比較した場合の white-box ソリューションの利点をいかに列挙する。セキュリティについては次のセクションで説明する。

利点: white-box ソリューションは:

• コスト効率が良い: 配布や設置が容易である。
• 更新が容易: セキュリティ上の欠陥が発見さらた場合、ソフトウェアの更新やパッチの配布をリモートで行う事ができる。

欠点: whtie-box ソリューションは:

• 桁違いに遅く、メモリや処理能力などのより多くのリソースを必要とする。
• 対称鍵暗号に限定されており、公開鍵アルゴリズムの white-box 実装は知られていない。

Q8: white-box 実装の安全性は?

絶対的に安全なシステムは存在しない (し、そのようなケースは決してない)。システムが安全だと言えるのはセキュリティモデルに基づいており、攻撃者のゴール (例えば鍵の復元) と、攻撃者がアクセスできるリソース (例えば選択された暗号文を解読するオラクル、CCA モデル) を定義する。

white-box のコンテキストでは攻撃者のリソースは事実上無限であるため定義することははるかに困難である。我々が期待できるのは既知の関連する驚異をすべて効率的な方法で防ぐことである。セキュリティは実装に大きく依存し、実装が不十分であれば強いアルゴリズムを使う必要はない。さらに white-box 実装は既知の攻撃に対してより敏感であり、特に fault 攻撃を受けやすくなる。

結論と未解決問題

報告されている殆どの攻撃は暗号アルゴリズムの弱点ではなくソフトウェアセキュリティ上の欠点を利用している。このことはソフトウェアの保護がより高い検討に値することを示唆しており、安全なアプリケーションの設計プロセスにおいて white-box のコンテキストに関連する驚異に注意深く対処する必要がある。

標準的なブロック暗号を white-box のコンテキストで実装するための完全に満足できるソリューションは現在のところ存在しない (既知の提案はすべて多かれ少なかれ壊れている)。より高い耐性を実現するための進歩が求められている。場合によって状況はさらに悪く、white-box 暗号における 2 つの未解決問題を挙げる:

• 動的なケース: 鍵が時間によって頻繁に変わる場合、
• 公開鍵のケース: 公開鍵技術が使用される場合 (例えば鍵交換、電子署名など)

この 2 つのケースでは既知のソリューションはなく、white-box のコンテキストでセキュリティを構築するにはトークンベースの方式しかない。

white-box 実装は鍵復元攻撃に対する防御として単独で使用することはできず、他の技術 (非技術的なものを含む) と組み合わせて使用する必要がある。white-box 暗号はまだ黎明期にあり商用製品に広く採用されるにはさらなる研究が必要である。グレーボックス実装 (つまりトークンベースのソリューション) はより成熟しているため必要に応じて優先的に使用すべきである。white-box 技術の普及に反するもう一つのポイントはペナルティコストが発生することであり、これは桁違いに遅くより多くのリソースを必要とする²。一方で、white-box 暗号のある種の技術は、実装に対する能動的な攻撃 (例えば fault 攻撃) に対するグレーボックス実装のセキュリティを改善するために使用することができることを指摘している。最後に、セキュリティにはコストが掛かり、その結果完璧にすることはできない (すべきではない) ことを指摘する。適切なセキュリティレベルは、アプリケーション (保護すべきものの価値)、環境 (すなはち脅威モデル)、および対応するセキュリティソリューションを開発するためのコストによって決定される。

• ¹また、暗号化 (または復号化) ソフトウェアがエンコードされた入力を必要とし、エンコードされた出力を生成するように外部エンコーディングを使うことができることにも注意。このため、white-box 実装は暗号化アルゴリズム (同様に復号化アルゴリズム) を単独で評価するために使用することはできない。Q5 参照。
• ²ただしテクノロジーが進化しているためこの問題はあまり気にはならないはずである。また特定の状況下ではパフォーマンスへの影響がそれほど劇的ではないことも確認している。

Acknowledgements

I am grateful to B. Preneel and B. Wyseur for sending a copy of [7]. I am also grateful to O. Billet, E. Diehl, and C. Salmon-Legagneur for comments

References

1. J. Algesheimer, C. Cachin, J. Camenisch, and G. Karjoth. Cryptographic security for mobile code. In 2001 IEEE Symposium on Security & Privacy, pages 2–11, IEEE Press, 2001.
2. J. Bringer, H. Chabanne, and E. Dottax. White-box cryptography: Another attempt. Cryptology ePrint Archive, Report 2006/468, December 2006. Available at URL http://eprint.iacr.org/2006/468.
3. O. Billet, H. Gilbert, and C. Ech-Chatbi. Cryptanalysis of a white-box AES implementation. In Selected Areas in Cryptography − SAC 2004, volume 3357 of Lecture Notes in Computer Science, pages 227–240. Springer, 2004.
4. B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S. Vadhan, and K. Yang. On the (im)possibility of obfuscating programs. In Advances in Cryptology − CRYPTO 2001, volume 2139 of Lecture Notes in Computer Science, pages 1–18. Springer, 2001.
5. S. Chow, P. Eisen, H. Johnson, and P.C. van Oorschot. White-box cryptography and an AES implementation. In Selected Areas in Cryptography − SAC 2002, volume 2595 of Lecture Notes in Computer Science, pages 250–270. Springer, 2003.
6. S. Chow, P. Eisen, H. Johnson, and P.C. van Oorschot. A white-box DES implementation for DRM applications. In Digital Rights Management − DRM 2002, volume 2696 of Lecture Notes in Computer Science, pages 1–15. Springer, 2003.
7. J. Cappaert, B. Wyseur, and B. Preneel. Software security techniques. Internal report, COSIC, Katholieke Universiteit Leuven, October 2004.
8. Louis Goubin, Jean-Michel Masereel , and Michael Quisquater. Cryptanalysis of white box DES implementations. Cryptology ePrint Archive, Report 2007/035, February 2007. Available at URL http://eprint.iacr.org/2007/035.
9. M. Jacob, D. Boneh, and E.W. Felten. Attacking an obfuscated cipher by injecting faults. In Digital Rights Management − DRM 2002, volume 2696 of Lecture Notes in Computer Science, pages 16–31. Springer, 2003.
10. H.E. Link and W.D. Neumann. Clarifying obfuscation: Improving the security of white-box DES. In International Conference on Information Technology: Coding and Computing − ITCC 2005, volume 1, pages 679–684. IEEE Press, 2005. Also available as Cryptology ePrint Archive, Report 2004/025, January 2004 at URL http://eprint.iacr.org/2004/025.
11. A. Main and P.C. van Oorschot. Software protection and application security: Understanding the battleground. International Course on State of the Art and Evolution of Computer Security and Industrial Cryptography, Heverlee, Belgium, June 2003.
12. A.J. Menezes, P.C. van Oorschot, and S.A.Vanstone. Handbook of Applied Cryptography. CRC Press, 1997.
13. T. Sander and C.F. Tschudin. Towards mobile cryptography. In 1998 IEEE Symposium on Security & Privacy, pages 215–224, IEEE Press, 1998.
14. P.C. van Oorschot. Revisiting software protection. In Information Security − ISC 2003, volume 2851 of Lecture Notes in Computer Science, pages 1–13. Springer, 2003.
15. Brecht Wyseur, Wil Michiels, Paul Gorissen, and Bart Preneel. Cryptanalysis of white-box DES implementations with arbitrary external encodings. Cryptology ePrint Archive, Report 2007/104, March 2007. Available at URL http://eprint.iacr.org/2007/104.

翻訳抄

white-box 暗号について Q&A 形式で解説する 2008 年の論文。発表当時の状況に依存する記述も多いので現状どうなっているかは追加で知る必要がある。

1. Marc Joye. On White-Box Cryptography, In Security of Information and Networks, pp.7–12, Trafford Publishing, 2008.