|
ネットワーク WG Request for Comments： 2405 分類： スタンダードトラック |
C. Madson Cisco Systems Inc. N. Doraswamy Bay Networks, Inc. 1998年11月 |
この文書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet OfficialProtocolStandards」(STD 1)の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
このメモでは、 IPSec暗号ペイロード(Encapsulating Security Payload:ESP)における機密性の仕組みとして、 明示的IVを伴う暗号ブロック連鎖モードでのDES暗号アルゴリズムの使用法について定義する。
この文書では、暗号ペイロードにおける機密性の仕組みとして、 暗号ブロック連鎖モードでのDES暗号アルゴリズムの使用法について定義する。
DESは対称ブロック暗号アルゴリズムである。 このアルゴリズムは [FIPS-46-2] [FIPS-74] [FIPS-81] にて定義されている。 [Schneier96] では、 いくつかの暗号アルゴリズムに適用可能な暗号ブロック連鎖モードの一般的な定義がされている。
このメモで説明されるように、DES-CBC は認証の仕組みではない。 ([Schneier96]や他で説明されているDES-MACは認証を提供するが、 DES-MACはここでは取り上げない。)
セキュリティサービスを提供するために、 ESPの各部分がどのように結びつくかということに関する詳細な情報については、 [ESP] および [road] を参照のこと。
この文書において、しなければならない(MUST)、 してはならない(MUST NOT)、要求される(REQUIRED)、 することになる(SHALL)、することはない(SHALL NOT)、 する必要がある(SHOULD)、 しないほうがよい(SHOULD NOT)、推奨される(RECOMMENDED)、 してもよい(MAY)、 選択できる(OPTIONAL)のキーワードが使用された場合は、 [RFC-2119] における定義に沿って解釈されるものとする。
DES-CBCは対称秘密鍵ブロックアルゴリズムである。 DES-CBCは64 ビットのブロックサイズを持つ。
DESアルゴリズムは [FIPS-46-2] [FIPS-74] および [FIPS-81] にて定義され、 CBCモードは [Schneier96] に良い記述が存在する。
Phil Karnは90MHz Pentiumで10.45Mbpsを達成するようにDES-CBCソフトウェアをチューニングした。 これは、133MHz Pentiumでは15.9Mbpsを達成する。 DESの処理速度についての見積りは、 他では [Schneier96] に記述されている。
DES-CBCは8オクテット(64ビット)の明示的初期ベクトル(IV)を必要とする。 このIVは保護された(暗号化)ペイロードの直前にくる。 IVは乱数値でなければならない(MUST)。
各データグラムにIVを含むことにより、 一部のデータグラムがドロップした場合、 あるいはデータグラムが配送中に再送要求された場合でも、 各受信データグラムの復号処理が可能となる。
実装時における注意：
一般的な方法は、最初のIVとして乱数データを使用し、 次の暗号化処理用のIVとして、 暗号化処理からの暗号データの最後の8オクテットを使用することである。 これにより、CBCをパケットに論理的に拡張することができる。 また、これは乱数発生器から情報が漏れることを制限する利点も持っている。 使用される仕組みに関わらず、 受信側はこの値がIVであること以外の意味があると仮定してはならない(MUST NOT)。
異なるパケットの非常に似通った平文ブロックのECB暗号化を避けるため、 実装では、IVにカウンタまたはその他のロウハミングディスタンスソースを使用してはならない(MUST NOT)。
[ESP] で定義されているペイロードフィールドは以下の図のように細分化される。
+---------------+---------------+---------------+---------------+ | | + Initialization Vector (IV) + | | +---------------+---------------+---------------+---------------+ | | ~ Encrypted Payload (variable length) ~ | | +---------------------------------------------------------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
この文書で定義されるDES-CBCアルゴリズムは8オクテット(64ビット)のブロックサイズを使用しなければならない(MUST)。
パディングが必要な場合には、 [ESP] で指定される規則に従って行われなければならない(MUST)。
DES-CBCは対称秘密鍵アルゴリズムである。 鍵長は64ビットである。 [鍵が56ビットの有効ビットを持つことから、 これは一般には56ビットの鍵として知られている。 それぞれのバイトの最下位ビットはパリティビットである。]
[arch] では、 ESP変換のための鍵素材を得る一般的な仕組みについて説明されている。 ある量の鍵素材からの鍵の生成は、 マニュアル鍵および自動鍵のセキュリティアソシエーションの間で異なることはない。
この仕組みでは、 この暗号が使用する64ビット鍵の値を生成しなければならない(MUST)。 この仕組みによって粗い鍵の値が生成され、鍵生成処理自身は、 パリティの処理または脆弱鍵のチェックの役割は持たない。
脆弱鍵のチェックを行う必要がある(SHOULD)。 脆弱鍵が発見された場合は、その鍵を拒否し、 新しいSAを要求する必要がある(SHOULD)。
実装上の注意：
実装で脆弱鍵のチェックを行う場合には、 既知の脆弱鍵 [FIPS74] はパリティで調整されていることを認識する必要がある。 脆弱鍵のチェックを行わない場合には、 パリティの処理はローカルの問題である。
必要とする鍵を生成するためには、 強力な疑似ランダム関数を使用しなければならない(MUST)。 この話題に関する議論については、 [RFC1750] を参照のこと。
DESには、いわゆる準脆弱鍵を含むと16の既知の脆弱鍵がある。 脆弱鍵のリストについては [FIPS74] を参照のこと。
[Blaze96] では総当たり攻撃に対するコストと鍵の復元時間について議論されている。 ここでは、1995年末の見積りを基に、総コスト、鍵の復元時間、 40ビットおよび56ビットのDES鍵に対して復元された鍵単位のコストの様々な組み合わせについて示されている。
56ビットのDES鍵空間での総当たり攻撃による検索は、 余分なCPU時間や他の低コストの資源を使用する、 いわゆるカジュアルハッカーにとっては実際的でないと考えられるが、 これはもう少し投資をしようと考えている者にとっては手の届く範囲にある。
例えば、300,000ドルのコストをかけた場合、 56ビットのDES鍵は、 既成技術を使用して平均19日で復元でき、 専用に開発されたチップを使用すればたったの3時間で復元することが可能である。
鍵をより早く復元できる他の攻撃があることと、 総当たり攻撃は実装が最も簡単であるが「最悪のケース」であると見なされていることにも注意する必要がある。
[Wiener94] ではまた、 既知平文攻撃を使用して3.5時間でDES鍵を破ることができる(1993年の見積り)、 100万ドルのマシンについて取り上げられている。 「セキュリティに関する考慮事項」の章において議論されているように、 既知平文攻撃は、おそらく実用的なものである。
平均鍵復元時間と同様に、 時間と共に検索にかかる総コストと平均コストは下がり続けるということにも注意する必要がある。
これまで鍵の有効期間について特定の推奨値を出していないが、 所定のアプリケーションが希望する鍵の有効期間は、 保護すべきデータの価値に関連して感知された脅威(攻撃者が利用可能な資源の量に応じた、経験的推量)に依存するということである。
ここでは量を基準とした有効期間に対して提案されていないが、 十分な量が与えられれば、 既知の平文が蓄積されてしまう確率が増加してしまうということに注意する必要がある。
この文書の執筆時点では、 ある特定の認証アルゴリズムとともにDES-CBCアルゴリズムを使用することを妨げる問題は知られていない。
[このセクションの大部分は、もともと William Allen Simpson と Perry Metzger によって書かれたものである]
ユーザは、この仕様が提供するセキュリティの品質は完全に、 DESアルゴリズムの強度、アルゴリズムの実装の正確さ、 セキュリティアソシエーションの管理の仕組みとその実装におけるセキュリティ、 鍵の強度 [CN94]、 および関係するすべてのノードにおける実装の正確さに依存しているということを理解する必要がある。
[Bell95] および [Bell96] では、 すべての暗号ブロック連鎖アルゴリズムにあてはまるカットアンドペーストスプライシング攻撃について説明されている。 この攻撃は、認証の仕組みを使用することによって対処することができる。
なんらかの対応する認証の仕組みを持たない暗号の仕組みを使用することは強く禁止される。 この暗号は、認証も含むESP変換において使用することができるし、 AHヘッダが共に使用されれば、 認証を含まないESP変換において使用することもできる。 詳細については [ESP]、[AH]、 [arch]、[road] を参照のこと。
デフォルトのESPパディングを使用する場合、
パディングバイトは予測可能な値を持つ。
このパディングバイトによって、
CBCモードでの自身のブロックと以前のブロックにおける改竄の検出のわずかな機能が提供される。
これによってスプライシング攻撃の実行がいくぶん困難となり、
隠れチャネルの可能性が回避される。
この少量の既知の平文は、最近の暗号には問題をもたらすことはない。
この文書の執筆時点では、 サイズがDESブロックのサイズ(64ビット)と同じである247の平文と暗号文の組を必要とする、 差分解読法を基本とする選択平文攻撃が [BS93] にて紹介されている。 また、243の平文と暗号文の組しか必要としない、 線形解読法を基本とする既知平文攻撃は [Matsui94] にて紹介されている。 これらの攻撃は実用的でないと見なされているが、 考慮しなければならないものである。
さらに不安なことに、[Wiener94] では、
3.5時間に1つの鍵をクラックすることができる、
100万ドルのDESクラッキングマシンの設計について紹介されている。
これは極めて実用的な攻撃である。
DES鍵を復元するには、既知の平文が1、2ブロックあれば十分である。 なぜなら、IPデータグラムは常に既知もしくは推測可能なヘッダ文で始まるため、 頻繁に鍵を変更してもこの攻撃を防ぐことができないためである。
このような装置を前にすると、並みの価値の情報を保護する場合でさえも、 DESが優れた暗号アルゴリズムではないことがわかる。 このような目的には、おそらくトリプルDESがよりよい選択であろう。
しかしながら、このような潜在的な危険があるにせよ、 ESP DES-CBCの利用によって得られるインターネット環境でのプライバシーのレベルは、 データグラムを平文として送信する場合よりもはるかに大きいものがある。
IVに乱数値を使うケースについては、 Steve Bellovinによる以下の要約でうまく説明されている。 詳細については [Bell97] を参照のこと。
「CBCモードでの暗号化で、IVとしてカウンタを使用する場合、 あるいは連続するIVの間にあまり違いがでないような他のソースを使用する場合には問題が発生する。 CBCモードでは、暗号化に対する「有効平文」は、 実際の平文と前のブロックの暗号文とのXORとなる。 通常、これは乱数値であり、 つまりこれは平文がきわめて乱数的であることを意味している。 実際の平文のブロックの多くはパケット間でほとんど変化しないため、 これはよいことである。
ただ、平文の最初のブロックでは、 IVが前の暗号文のブロックの代わりとなる。 そのIVが前のIVとほとんど違いがなく、 実際の平文ブロックが前のパケットの平文ブロックとほとんど違わなければ、 そのそれぞれの有効平文にもほとんど違いがない。 これは、ビット位置がわずかに異なる平文ブロックと組み合わされた、 暗号文ブロックの組を持つことを意味している。 これは、分類された暗号解析攻撃にとって妨害となる。」
IVに関する議論は、 実装がIVにロウハミングディスタンスソースを使用しないことを要求するために更新されている。
| [Bell95] | Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Presentation at the 32nd Internet Engineering Task Force, Danvers Massachusetts, 1995年4月. |
| [Bell96] | Bellovin, S., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Security Symposium, 1996年7月. |
| [Bell97] | Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, 1997年 2月 (also http://www.research.att.com/~smb/papers/probtxt.{ps,pdf}). |
| [BS93] | Biham, E., and A. Shamir, "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag,1993年. |
| [Blaze96] | Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., and M. Wiener, "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", currently available at http://www.bsa.org/policy/encryption/cryptographers.html. |
| [CN94] | Carroll, J.M., and S. Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, 1994年7月. |
| [FIPS-46-2] | US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-2, 1993年12月, http://www.itl.nist.gov/div897/pubs/fip46-2.htm (supercedes FIPS-46-1). |
| [FIPS-74] | US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, 1981年4月, http://www.itl.nist.gov/div897/pubs/fip74.htm. |
| [FIPS-81] | US National Bureau of Standards, "DES Modes of Operation", Federal Information Processing Standard (FIPS) Publication 81, 1980年12月, http://www.itl.nist.gov/div897/pubs/fip81.htm. |
| [Matsui94] | Matsui, M., "Linear Cryptanalysis method for DES Cipher", Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994年. |
| [RFC-1750] |
Eastlake, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750, 1994年12月. |
| [RFC-2119] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年 3月. |
| [Schneier96] | Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1996年. ISBN 0-471-12845-7. |
| [Wiener94] | Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, 1994年5月. Presented at the Rump Session of Crypto '93. [Reprinted in "Practical Cryptography for Data Internetworks", W.Stallings, editor, IEEE Computer Society Press, pp.31-79 (1996年). Currently available at ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.] |
| [ESP] |
Kent, S., and R. Atkinson, 「IP 暗号ペイロード(ESP)(IP Encapsulating Security Payload (ESP))」, RFC 2406, 1998年11月. |
| [AH] |
Kent, S., and R. Atkinson, 「IP 認証ヘッダ(IP Authentication Header (AH))」, RFC 2402, 1998年11月. |
| [arch] |
Kent, S., and R. Atkinson, 「インターネットプロトコルのためのセキュリティアーキテクチャ(Security Architecture for the Internet Protocol)」, RFC 2401, 1998年11月. |
| [road] |
Thayer, R., Doraswamy, N., and R. Glenn, 「IPSEC 文書ロードマップ(IP Security Document Roadmap)」, RFC 2411, 1998年11月. |
特に「セキュリティに関する考慮事項」の章をはじめ、 この文書で提供された情報の多くは、Perry MetzgerとWilliam Allen Simpsonが書いた様々なESP-DES関連の文書をもとにしている。
この文書はまた、Jim Huges、 DES-CBCとHMAC-MD5の組み合わせESP変換に関してJim Hughesと作業した人々、 ANXベイクオフの参加者、 IPsecワーキンググループのメンバーによるこれまでの作業の一部を参考としている。
nroffフォーマッティングで手助けしてくれたRob Glenに感謝する。
IPsecワーキンググループへは、 IPsecワーキンググループのメーリングリスト(ipsec@tis.com)および以下のチェアを介してコンタクトをとることが可能である。
Robert Moskowitz
International Computer Security Association
EMail: rgm＠icsa.net
Theodore Y. Ts'o
Massachusetts Institute of Technology
EMail: tytso＠MIT.EDU
Cheryl Madson
Cisco Systems, Inc.
EMail: cmadson＠cisco.com
Naganand Doraswamy
Bay Networks, Inc.
EMail: naganand＠baynetworks.com
株式会社 NTTデータ
開発本部
馬場 達也
EMail： babatt＠nttdata.co.jp
Copyright (C) The Internet Society (1998). All Rights Reserved.
本文書とその翻訳は、複製および他に提供することができる。 また、この文書に論評や説明を加えたり、その実装を補助するものは、 上記の著作権表示およびこの節を付加していれば、 全体あるいは一部であっても一切の制約を課されることなく作成、複製、 発表、配布できる。 ただし、この文書自体に対して、 著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従って、 インターネット標準を開発するために必要な場合や、 RFCを英語以外の言語に翻訳する必要がある場合はそのかぎりでない。
上記の制限は永続的なものであり、 インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は「無保証」で提供され、 インターネットソサエティおよびIETFはすべての保証を明示的にも暗黙的にもおこなわない。 その中には、この情報がいかなる権利も侵害していないという保証や、 商用利用および特定目的における適合性への保証が含まれる。