ネットワークワーキンググループ
Request for Comments: 1829
分類: スタンダードトラック

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

1995年8月

ESP DES-CBC 変換
(The ESP DES-CBC Transform)

このメモの位置付け

この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態、およびステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照すること。
このメモの配布に制限はない。
要旨
この文書では 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-CBC 変換を実装しなければならない(MUST)。

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

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

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

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

注意事項:
広く受け入れやすい方法に、ある任意に選ばれた値から始まる単純なカウンタを使う方法がある。
この方法は反復を防ぐ方法として容易なものであり、十分に実用に耐えるものであるが、暗号解析により、まれに DES の最初のブロックの対応するビット位置が全く同じ様に増加しているという思わぬ発見をされてしまう可能性がある。

その他の実装では、通常、擬似乱数発生器を通すことによって、予測不可能な結果を示すようにしている。
しかし、セッション鍵が有効である間は、乱数発生の周期を、反復を防ぐことができるほど十分に長くとるように気を付けるべきである。

1.3. データ長
DES アルゴリズムは 8 バイトのブロック毎に動作する。
これにより、暗号化する前のペイロードデータの最後にパディングが必要となることが多い。

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

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

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

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

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

初期ベクトル (IV)

このフィールドの長さは可変であるが、SPI と 宛先 IP アドレスが同じすべての DES-CBC データグラムでは、その長さは一定である。
オクテットはネットワーク順序(最上位オクテット(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. アルゴリズム
DES-CBC では、基本となる DES の暗号化機能が、それぞれの平文のブロックとその前の暗号文のブロックとの XOR に適用され、現在のブロックの暗号文がもたらされる。
これにより、データグラムが損失した場合には、再同期が提供される。

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

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

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

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

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

ペイロードを DES の CBC モードで暗号化すると、同じ長さの暗号文が生成される。

オクテットはネットワーク順序(最上位オクテット(most significant 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 の CBC モードを使用して復号化される。

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

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

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

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

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

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

この文書の執筆時点では、[BS93] にて、2^47 の平文と暗号文の組を必要とする、差分解読法を基本とする選択平文攻撃の紹介がされている。
また、 [Matsui94] では、たった 2^43 の平文と暗号文の組しか必要としない、線形解読法を基本とする既知平文攻撃が紹介されている。
これらの攻撃は実用的なものではないと考えられているが、考慮しなければならないものである。

さらに不安なことに、[Weiner94] では、3.5 時間に 1 つの鍵をクラックすることができる 100 万ドルの DES クラッキングマシンの設計について紹介されている。
これは極めて実用的な攻撃である。

DES 鍵を復元するには、既知の平文が 1、2 ブロックあれば十分である。
なぜなら、IP データグラムは、常に、知られたブロック、もしくは推測可能なヘッダ原文で始まるため、頻繁に鍵を変更しても、この攻撃に対しては防ぐことができないからである。

このような装置を前にすると、相応の価値のある情報を守るには、DES は適切な暗号アルゴリズムではないことが分かる。
このような目的には、おそらくトリプル DES が良い選択である。

しかしながら、これらの潜在的なリスクにも関わらず、ESP DES-CBC の利用によって得られるインターネット環境でのプライバシのレベルは、平文として送られるデータグラムよりも、はるかに大きいものである。

謝辞
この文書は Internet Engineering Task Force (IETF) の IP Security Working Group においてレビューされた。
コメントは ipsec@ans.net メーリングリストに提出して頂きたい。

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

機密性に関する DES の利用については、かなりの部分を SNMPv2 [RFC-1446] の成果をモデルとしている。

Steve Bellovin、Phil Karn、Charles Lynn、Dave Mihelcic、Hilarie Orman、 Jeffrey Schiller、Joe Touch、そして David Wagner からは、このドラフトのより初期のバージョンにおいて役に立つ批評を頂いた。

参考文献
[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.

[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.

[RFC-1446] Galvin, J., and McCloghrie, K., "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC-1446, DDN Network Information Center, April 1993.

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

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

[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

[Weiner94] Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93.

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

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.