ネットワークワーキンググループ
Request for Comments: 1851
分類: 実験的

P. Karn
Qualcomm
P. Metzger
Piermont
W. Simpson
Daydreamer

1995年9月

ESP トリプル DES 変換
(The ESP Triple DES Transform)

このメモの位置付け

この文書は、インターネットコミュニティに対して実験的プロトコルを規定するものである。
これは、インターネットのいかなる種類の標準をも指定するものではない。
改良のための議論や提言を求めるものである。
このメモの配布に制限はない。
要旨
この文書では IP 暗号ペイロード(ESP)におけるトリプル DES-CBC セキュリティ変換について記述する。
目次
1. はじめに
1.1 鍵
1.2 初期ベクトル
1.3 データ長
1.4 処理能力

2. ペイロード形式

3. アルゴリズム
3.1 暗号化
3.2 復号化

セキュリティに関する考慮事項
謝辞
参考文献
著者の連絡先

1. はじめに
暗号ペイロード(Encapsulating Security Payload:ESP)[RFC-1827] は、ペイロードデータを暗号化することによって、IP データグラムに機密性を提供するものである。
この仕様では US Data Encryption Standard(DES)アルゴリズムの暗号ブロック連鎖(Cipher Block Chaining:CBC)モード [FIPS-46, FIPS-46-1,FIPS-74, FIPS-81] の変形を用いた ESP の利用法について記述している。
トリプル DES(3DES)として知られるこの変形は、平文のそれぞれのブロックを 3 回に渡って処理し、それぞれの回では異なる鍵が使用される [Tuchman79]

この文書では、読者が関連文書の "Security Architecture for the Internet Protocol" [RFC-1825] を深く理解していることを前提としている。
その文書では、IP のためのセキュリティ方式の全体について定義されており、この仕様の重要な背景について記述されている。

1.1. 鍵
通信する組織の間で共有される秘密の 3DES 鍵は、実際には 168 ビットの長さである。
この鍵には DES アルゴリズムによって使用される 3 つの独立した 56 ビット分が含まれる。
この 3 つのそれぞれの 56 ビットの副鍵に、パリティビットとして使用するバイト毎の最下位ビット(least significant bit)を足して、64 ビット(8 バイト)として格納される。
1.2. 初期ベクトル
3DES のこのモードでは、8 バイトの長さの初期ベクトル(IV)が必要とされる。

各データグラムには、それぞれの固有の IV が含まれる。
各データグラムに IV を含むことで、他のデータグラムが落ちたり、配送中に再送要求されたときでも、受け取られたデータグラムの復号化を確実にすることができる。

IV 値の選択法は実装に依存する。

注意事項:
広く受け入れやすい方法に、ある任意に選ばれた値から始まる単純なカウンタを使う方法がある。
この方法は反復を防ぐ方法として容易なものであり、十分に実用に耐えるものであるが、暗号解析により、まれに DES の最初のブロックの対応するビット位置が全く同じ様に増加しているという思わぬ発見をされてしまう可能性がある。
その他の実装では、通常、擬似乱数発生器を通すことによって、予測不可能な結果を示すようにしている。
しかし、セッション鍵が有効である間は、乱数発生の周期を、反復を防ぐことができるほど十分に長くとるように気を付けるべきある。 1.3. データ長
3DES アルゴリズムは 8 バイトのブロック毎に動作する。
これにより、暗号化する前のペイロードデータの最後にパディングが必要となることが多い。

入力と出力の両方が同じバイト数になるので余分な場所を必要とせず、暗号化と復号化を容易に行うことができる。

受信時に、復号化されるべきデータの長さが 8 バイトの整数倍でないならば、 [RFC-1825] にて記述されているように、エラーが示される。

1.4. 処理能力
並列計算を行なうために 3 つの DES-CBC の実装を、連続してパイプライン接続してもよい。
執筆時点では、少なくともあるハードウェアにおける実装では、 1Gbps の速度で暗号化や復号化を行なうことができている [Schneier94, p. 231]
2. ペイロード形式
  
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        セキュリティパラメータインデックス (SPI)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                      初期ベクトル (IV)                        ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                      ペイロードデータ                         ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ... パディング        |  パディング長 | ペイロード番号|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

セキュリティパラメータインデックス (SPI)

このデータグラムに対するセキュリティパラメータを識別する 32 ビットの値。
この値は 0 であってはならない(MUST NOT)。

初期ベクトル (IV)

このフィールドの長さは可変であるが、SPI と 宛先 IP アドレスが同じすべての 3DES データグラムでは、その長さは一定である。
オクテットはネットワーク順序(最上位オクテット(most significant octet)が最初)で送られる [RFC-1700]

この長さは、32 ビットの倍数でなければならない(MUST)。
32 ビットと 64 ビットの長さは必ずサポートされなければならない。
その他の長さの使用については、この仕様の範囲外である。
この長さは、鍵管理の仕組みによって示される。

長さが 32 ビットの場合は、その 32 ビットの値に 32 ビット値のビット補完がされ(連結され)、64 ビットの IV が形成される。
32 ビットと 64 ビットの両方の処理では、ペイロードデータを整列させることができるので、これが最も一般的なフィールド長である。

仕様に従うすべての実装は、64 ビットのフィールド長も正確に処理しなければならない(MUST)。
これにより、既存のハードウェア実装との完全な互換性を保つことができる。

暗号化セッション鍵が有効な間は、値を繰り返さないようにすること。

64 ビットすべてを使用した IV が使用された場合でも、セッション鍵は少なくとも 2**32 のデータグラム毎の頻度で変更する必要がある(SHOULD)。

ペイロードデータ

このフィールド長は可変である。

暗号化の前と復号化の後では、このフィールドは、ペイロード番号フィールドで指定された IP プロトコル/ペイロードヘッダで始まる。
IP-in-IP カプセル化(ペイロード番号 4)の場合には、これは別の IP ヘッダとなることに注意すること。

パディング

このフィールド長は可変である。

暗号化の前に、この部分はパディング長フィールドとペイロード番号フィールドが 8 バイトの境界で整列するように、ここでは指定されない実装に依存した(むしろ乱数的な)値で埋められる。

復号化の後は、これは無視されなければならない(MUST)。

パディング長

このフィールドは、パディングフィールドの長さを示す。
これにはパディング長フィールドとペイロード番号フィールドの長さは含まれない。
この値は、決まって 0 から 7 の間になるが、実際のデータ長は現わさなくても良いため、255までの値になる可能性がある。

このフィールドは、不透明である。
すなわち、値は暗号化の前に設定され、復号化の後にのみ調べられる。

ペイロード番号

このフィールドは、IP プロトコル/ペイロード値を使用することにより、ペイロードデータフィールドの内容を示す。
最新の IP プロトコル/ペイロード値は、最新の "Assigned Numbers" [RFC-1700] にて指定される。

このフィールドは、不透明である。
すなわち、値は暗号化の前に設定され、復号化の後にのみ調べられる。

例えば、IP データグラム全体を暗号化した場合(トンネルモード)、このフィールドには、IP-in-IP カプセル化で定義されている値 4 が含まれる。
3. アルゴリズム
3DES アルゴリズムは、DES-CBC アルゴリズムの単純な変形である。
DES 関数が、3 回にわたるその関数に置き換えられ、暗号化の次に復号化、暗号化と続き、それぞれの処理では、独立した鍵、k1、k2、k3 が使われる。

3 つの鍵(k1、k2、k3)すべてが同じ場合は、3DES は DES-CBC と同等であることに注意すること。
この性質は、3DES ハードウェアの実装を修正することなく、DES モードで動作させることを可能とする。

トリプル DES についてのさらなる説明や実装情報に関しては、[Schneier94] を参照のこと。

3.1. 暗号化
モジュロ 8 の長さが 6 になるように、平文に 0 バイト以上(むしろ任意の)のパディングを付加する。
例えば、平文の長さが 41 ならば、5 バイトのパディングが付加される。

ここで付加されたパディングのバイト数を含むパディング長フィールドを付加する。

ペイロードの始まりのプロトコルヘッダを示す IP プロトコル/ペイロード値を含むペイロード番号フィールドを付加する。

SPI によって示された長さの初期ベクトル(IV)を用意する。

ペイロードをトリプル DES(EDE モード)で暗号化すると、同じ長さの暗号文が生成される。

オクテットはネットワーク順序(最上位オクテット(most signifficant octet)が最初)[RFC-1700] で DES ブロックにマッピングされる。
ペイロードのオクテット 0(モジュロ 8)は 64ビットの DES 入力ブロックの 1-8 ビットに対応し、オクテット 7(モジュロ 8)は DES 入力ブロックの 57-64 ビットに対応する。

示された SPI、IV、ペイロードを用いて、送信先に応じた適切な IP データグラムを組み立てる。

カプセル化された IP ヘッダのトータル/ペイロード長フィールドには、暗号化されたデータ、SPI、IV、パディング、パディング長、そしてペイロード番号の各フィールドのバイト長の合計が反映される。

3.2. 復号化
最初に SPI フィールドが削除され、調べられる。
これは取り決められたパラメータと復号鍵を探すための、ローカルのセキュリティパラメータ表への指標として使用される。

取り決められた IV の形式によって、IV フィールドの長さが決定される。
このフィールドは削除され、適切な 64 ビットの IV 値が形成される。

ペイロードの暗号化部分がトリプル DES(DED モード)を使用して復号化される。

ペイロード番号フィールドが削除され、調べられる。
そのフィールドが認識されない場合には、ペイロードは適切な ICMP メッセージをもって処分される。

パディング長フィールドが削除され、調べられる。
指定された長さのパディングが、復号化されたペイロードの最後から削除され、IP トータル/ペイロード長フィールドがそれに従って調整される。

IP ヘッダと復号化されたペイロードの残った部分が、ペイロード番号フィールドによって指定されたプロトコル受信ルーチンに渡される。

セキュリティに関する考慮事項
利用者は、この仕様によって提供されるセキュリティの品質は、完全に、トリプル DES アルゴリズムの強度、そのアルゴリズムの実装の正確さ、鍵管理の仕組みとその実装のセキュリティ、鍵の強度 [CN94]、そして、すべての参加ノードにおける実装の正確さに依存しているということを理解する必要がある。

その他の考慮事項として、アプリケーションは、たとえそれを選択する確率が低かったとしても [Schneier94, p 223]、3 回の DES の処理のすべてにおいて弱い鍵を選択しないように注意することが良い。

もともと、DES はグループであると思われていた。
しかし、それが違うことが示された [CW92]
DES は、グループではないため、DES を複数回処理した場合の構成は、単純に DES を異なる鍵で使用したものとは一致しない。

独立した鍵を使用するトリプル DES は、単純に予想されるように、3 倍の鍵長の暗号システムと同様に、総当たり攻撃による破壊を難しくするものではない。
二重暗号化にかかると単純に予想される時間内に三重暗号化を総当たりで破ることができるかは、空間と時間のトレードオフであるということが示されてきた。

しかし、2DES は、中間一致攻撃によって、DES を破るのよりもさらに複雑なものを必要とせずに破ることが可能である [ibid]。
このため、独立した鍵を使用する 3DES は、実際にはこのレベルのセキュリティを提供する必要がある。
独立した鍵に対する現在知られている攻撃よりもいくらか高速な(16 倍)、2 つの独立した鍵を使用する 3DES への攻撃が、[OW91] にて紹介されている。

[Bell95] に記述されているカットアンドペースト攻撃は、すべての暗号ブロック連鎖アルゴリズムの性質を不正に利用するものである。
あるブロックが伝送中に破損した場合、復号化の際に、それとそれに続くブロックの両方に対しては、復号化の処理に誤りが発生するが、それに続くすべてのブロックは正しく復号化される。
攻撃者が同じ鍵に対して正当なアクセスができるならば、同じエンジンの他の利用者が以前に暗号化したデータを挿入したり、繰り返したりするために、この仕組みを利用することができ、平文が漏れることとなる。
たいていの(ICMP、TCP、UDP)トランスポートチェックサムは、この攻撃を検出することができるが、それ自身は暗号的な強度が考慮されていない。
このような場合は、利用者別やコネクション別のインテグリティチェックが必要とされる [RFC-1826]

3 DES は、総当たり攻撃を受ける余地があまりないため、DES より十分に強力であると広く信じられている。
しかし、3DES の実際の暗号解析に、総当たり法が利用される可能性は全くないということに気付くべきである。
代わりに、差分解読法 [BS93] または、線形解読法 [Matsui94] の変形が利用される可能性がある。
また、現在のコンピュータのスピードの向上を考えると、総当たり攻撃に対して永久に安全な暗号アルゴリズムはないということも覚えておくべきである。

すべての暗号システムに対して言えることであるが、これらのセキュリティが破られた場合のアプリケーションが持つ潜在的なリスクについての責任者は、暗号、特に暗号解析の開発に対して細心の注意を払うべきであり、3DES が弱いと証明された場合には、他の変換に移行させるべきである。

謝辞
この仕様の文章の一部は、SIP、SIPP、および IPv6 Working Group における Randall Atkinson の成果から得られたものである。

コメントは ipsec@ans.net メーリングリストに提出して頂きたい。

参考文献
[Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995.

[BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993.

[CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994.

[CW92] Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a Group", Advances in Cryptology -- Crypto '92 Proceedings, Berlin: Springer-Verlag, 1993, pp 518-526.

[FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977.

[FIPS-46-1] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988.

[FIPS-74] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981.

[FIPS-81] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980.

[Matsui94] Matsui, M., "Linear Cryptanalysis method dor DES Cipher," Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994.

[MH81] Merle, R.C., and Hellman, M., "On the Security of Multiple Encryption", Communications of the ACM, v. 24 n. 7, 1981, pp. 465-467.

[OW91] van Oorschot, P.C., and Weiner, M.J. "A Known-Plaintext Attack on Two-Key Triple Encryption", Advances in Cryptology -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991, pp. 318-325.

[RFC-1800] Postel, J., "Internet Official Protocol Standards", STD 1, RFC 1800, USC/Information Sciences Institute, July 1995.

[RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC-1825, Naval Research Laboratory, July 1995.

[RFC-1826] Atkinson, R., "IP Authentication Header", RFC-1826, Naval Research Laboratory, July 1995.

[RFC-1827] Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC-1827, Naval Research Laboratory, July 1995.

[Schneier94] Schneier, B., "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2

[Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.

著者の連絡先
このメモに関する質問は、以下の連絡先までお願いする。

Phil Karn
Qualcomm, Inc.
6455 Lusk Blvd.
San Diego, California 92121-2779

karn@unix.ka9q.ampr.org

Perry Metzger
Piermont Information Systems Inc.
160 Cabrini Blvd., Suite #2
New York, NY 10033

perry@piermont.com

William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071

Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

著作権表示全文
Copyright (C) The Internet Society (1995). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.