| ネットワーク WG Request for Comments： 1829 分類： スタンダードトラック |
P. Karn Qualcomm P. Metzger Piermont W. Simpson Daydreamer 1995年 8月 |
ESP DES-CBC 変換
(The ESP DES-CBC Transform)
このメモの位置付け
概要
目次
暗号ペイロードの仕様に準拠するすべての実装は、この DES-CBC
変換を実装しなければならない（MUST）。
この文書では、読者が関連文書の "Security Architecture for the
Internet Protocol" [RFC-1825]
を深く理解していることを前提としている。その文書では、IP
のためのセキュリティ方式の全体について定義されており、この仕様の重要な背景について記述されている。
各データグラムには、それぞれに固有の IV が含まれる。各データグラムに IV
を含むことで、他のデータグラムが落ちたり、配送中に再送要求された場合でも、受け取られたデータグラムの復号を確実にすることができる。
IV 値の選択法は実装に依存する。
その他の実装では、通常、擬似乱数発生器を通すことによって、予測不可能な結果を示すようにしている。
しかし、セッション鍵が有効である間は、乱数発生の周期を、反復を防ぐことができるほど十分に長くとるように気を付けるべきである。
入力と出力の両方が同じバイト数になるので余分な場所を必要とせず、暗号化と復号を容易に行うことができる。
受信時に、復号されるべきデータの長さが 8
バイトの整数倍でないならば、 [RFC-1825]
に記述されているように、エラーが示される。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| セキュリティ・パラメータ・インデックス (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 初期ベクトル (IV) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ペイロードデータ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... パディング | パディング長 | ペイロード番号|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
この長さは、32 ビットの倍数でなければならない（MUST）。32 ビットと 64
ビットの長さは必ずサポートされなければならない。その他の長さの使用については、この仕様の範囲外である。この長さは、鍵管理の仕組みによって示される。
長さが 32 ビットの場合は、その 32 ビットの値に 32
ビット値のビット補完がされ（連結され）、64 ビットの IV
が形成される。32 ビットと 64
ビットの両方の処理では、ペイロードデータを整列させることができるので、これが最も一般的なフィールド長である。
仕様に従うすべての実装は、64
ビットのフィールド長も正確に処理しなければならない（MUST）。これにより、既存のハードウェア実装との完全な互換性を保つことができる。
暗号化の前と復号の後では、このフィールドは、ペイロード番号フィールドで指定された
IP プロトコル/ペイロードヘッダで始まる。IP-in-IP カプセル化（ペイロード番号 4）の場合には、これは別の IP
ヘッダとなることに注意すること。
暗号化の前に、この部分はパディング長フィールドとペイロード番号フィールドが
8
バイトの境界で整列するように、ここでは指定されない実装に依存した（むしろ乱数的な）値で埋められる。
復号の後は、これは無視されなければならない（MUST）。
このフィールドは、不透明である。すなわち、値は暗号化の前に設定され、復号の後にのみ調べられる。
このフィールドは、不透明である。すなわち、値は暗号化の前に設定され、復号の後にのみ調べられる。
DES についてのさらなる説明や実装情報に関しては、[Schneier94] を参照のこと。
ここで付加されたパディングのバイト数を含むパディング長フィールドを付加する。
ペイロードの始まりのプロトコルヘッダを示す 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、パディング、パディング長、そしてペイロード番号の各フィールドのバイト長の合計が反映される。
取り決められた IV の形式によって、IV
フィールドの長さが決定される。このフィールドは削除され、適切な 64 ビットの IV
値が形成される。
ペイロードの暗号化部分が DES の CBC
モードを使用して復号される。
ペイロード番号フィールドが削除され、調べられる。そのフィールドが認識されない場合には、ペイロードは適切な ICMP
メッセージをもって処分される。
パディング長フィールドが削除され、調べられる。指定された長さのパディングが、復号されたペイロードの最後から削除され、IP
トータル/ペイロード長フィールドがそれに従って調整される。
IP
ヘッダと復号されたペイロードの残った部分が、ペイロード番号フィールドによって指定されたプロトコル受信ルーチンに渡される。
その他の考慮事項として、アプリケーションは、たとえそれを選択する確率が低かったとしても
[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
の利用によって得られるインターネット環境でのプライバシのレベルは、平文として送られるデータグラムよりも、はるかに大きいものである。
この仕様の文章の一部は、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
からは、このドラフトのより初期のバージョンにおいて役に立つ批評を頂いた。
[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, 1994年 7月.
[FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, 1977年 1月.
[FIPS-46-1] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, 1988年 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月.
[FIPS-81] US National Bureau of Standards, "DES Modes of Operation", Federal Information Processing Standard (FIPS) Publication 81, 1980年 12月.
[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, 1993年 4月.
[RFC-1700] Reynolds, J., and Postel, J., "Assigned
Numbers",
STD 2, RFC-1700, USC/Information Sciences Institute, 1994年
10月.
[RFC-1800] Postel, J., "Internet Official Protocol
Standards",
STD 1, RFC-1800, USC/Information Sciences Institute, 1995年
7月.
[RFC-1825] Atkinson, R., "Security Architecture for the
Internet Protocol",
RFC-1825, Naval Research Laboratory,
1995年 7月.
[RFC-1826] Atkinson, R., "IP Authentication Header",
RFC-1826, Naval Research Laboratory, 1995年 7月.
[RFC-1827] Atkinson, R., "IP Encapsulating Security
Protocol (ESP)",
RFC-1827, Naval Research Laboratory,
1995年 7月.
[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
翻訳者のアドレス
NTTデータ通信株式会社
馬場 達也baba＠open.rd.nttdata.co.jp
著作権表記全文
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.