ネットワークワーキンググループ 
Request for Comments: 2451 
分類: スタンダードトラック
R. Pereira
TimeStep Corporation
R. Adams
Cisco Systems Inc.
1998年11月

ESP CBC モード 暗号アルゴリズム
(ESP CBC-Mode Cipher Algorithms)

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。
このメモの配布に制限はない。
著作権
Copyright (C) The Internet Society (1998). All Rights Reserved.
要旨 
この文書では、IPSec ESP (暗号ペイロード)プロトコルでの CBC モード暗号アルゴリズムの使用法について説明する。
ある特定の暗号アルゴリズムの使用法のみならず、すべての CBC モード暗号アルゴリズムの使用法についても明確に説明する。
目次 
1. はじめに
1.1 要求条件を指定する用語
1.2 知的財産権表示
2. 暗号アルゴリズム
2.1 モード
2.2 鍵長
2.3 脆弱鍵
2.4 ブロックサイズとパディング
2.5 ラウンド
2.6 背景情報
2.7 性能
3. ESP ペイロード
3.1 ESP 環境での考慮事項
3.2 鍵素材
4. セキュリティに関する考慮事項

5. 参考文献

6. 謝辞

7. 著者の連絡先

8. 著作権表示全文

1. はじめに 
暗号ペイロード(ESP) [Kent98] は、保護すべきペイロードデータを暗号化することによって、IP データグラムに機密性を提供する。
この仕様では、CBC モード暗号アルゴリズムの ESP での使用法について説明する。

この文書では、デフォルトの暗号アルゴリズムである DES の使用法について説明していないが、読者はそれに該当する文書 [Madson98] に精通している必要がある。

この文書では、読者が「インターネットプロトコルのためのセキュリティアーキテクチャ」 [Atkinson95]、「IP セキュリティ文書体系」 [Thayer97]、「IP 暗号ペイロード(ESP)」 [Kent98] の各文書で説明されている用語と概念に精通していることを前提としている。
さらに、この文書は [Kent98] と対になっているため、その関係を意識して読まれなければならない (MUST)

1.1 要求条件を指定する用語 
この文書において、しなければならない (MUST)、してはならない (MUST NOT)、要求される (REQUIRED)、する必要がある (SHOULD)、しないほうがよい (SHOULD NOT)、してもよい (MAY) のキーワードが使用された場合は、[Bradner97] における定義に沿って解釈されるものとする。
1.2 知的財産権表示 
この文書に記述される技術の実装および使用に関係すると主張される、知的財産権およびその他の権利の有効性または範囲に関して、またこのような権利の下でのあらゆる権利が効力を持つ範囲に関して、IETF はいかなる立場もとらず、また、IETF はそのような権利を確認するためのいかなる取り組みを行ったことも表明しない。
スタンダードトラックおよび標準関連文書における権利に関する IETF の手続きは、BCP-11 で見ることができる。
出版を目的に利用可能な権利主張のコピーおよび利用可能となるライセンス保証のコピー、あるいは、この仕様の実装者やユーザによる所有権の使用に対する一般的な権利や許可を得るために行われた試みの結果は、IETF 事務局から入手可能である。
2. 暗号アルゴリズム 
すべての対称ブロック暗号アルゴリズムは、共通の特性と変数を共有する。
これには、モード、鍵長、脆弱鍵、ブロックサイズ、ラウンドが含まれる。
これらのすべてについて以下で説明する。

この文書では、Blowfish [Schneier93]、CAST-128 [Adams97]、3DES、IDEA [Lai] [MOV]、RC5 [Baldwin96] などの特定の暗号アルゴリズムを取り上げているが、この文書で定義されるすべての変数が明確に定義されていれば、他のどのブロック暗号アルゴリズムを ESP で使用しても良い。

2.1 モード 
この文書で取り上げられるすべての対称ブロック暗号アルゴリズムは、暗号ブロック連鎖(CBC)モードを使用する。
このモードでは、ブロックサイズと同じサイズの初期ベクトル(IV)が必要とされる。
ランダムに生成された IV を使用することにより、暗号アルゴリズムのブロックサイズの最初のブロックにまたがる同一のデータを持つパケットから、同一の暗号文を生成することが回避される。

最初の平文ブロックを暗号化する前に、IV とその平文ブロックとの XOR をとる。
次に、後に続くブロックでは、その平文を暗号化する前に、以前の暗号文ブロックとの XOR をとる。

CBC モードに関しての詳細な情報は、[Schneier95] から得ることができる。

2.2 鍵長 
暗号アルゴリズムには可変長の鍵が使用できるものと、特定の長さの鍵のみが使用できるものがある。
鍵の長さは、そのアルゴリズムの強度と相互に関連しており、長い鍵のほうが短い鍵よりも常に破るのが困難である。

この文書では、すべての鍵長は 8 ビットの整数倍でなければならない (MUST) と規定する。

この文書では、各暗号アルゴリズムのデフォルトの鍵長を指定する。
この長さは、アルゴリズムの専門家の意見によって、アルゴリズムの強度と性能のバランスをとりながら選択されたものである。

   +==============+==================+=================+==========+
   | Algorithm    | Key Sizes (bits) | Popular Sizes   | Default  |
   +==============+==================+=================+==========+
   | CAST-128 [1] | 40 to 128        | 40, 64, 80, 128 | 128      |
   +--------------+------------------+-----------------+----------+
   | RC5          | 40 to 2040       | 40, 128, 160    | 128      |
   +--------------+------------------+-----------------+----------+
   | IDEA         | 128              | 128             | 128      |
   +--------------+------------------+-----------------+----------+
   | Blowfish     | 40 to 448        | 128             | 128      |
   +--------------+------------------+-----------------+----------+
   | 3DES [2]     | 192              | 192             | 192      |
   +--------------+------------------+-----------------+----------+
注釈:

[1] CAST-128 の場合、128 ビットより短い鍵は右端、あるいは最下位にゼロを 128 ビットになるまで詰めなければならない (MUST)
これは、CAST-128 鍵スケジュールが 128 ビットの鍵の入力を想定しているためである。
従って、80 ビットの長さの鍵 `3B5D831CFE` を持つのであれば、128 ビットの長さの鍵 `3B5D831CFE000000` となるようにパディングされる。

[2] 1 つ目の 3DES 鍵は最初の 64 ビットから、2 つ目の鍵はその次の 64 ビットから、3 つ目の鍵は最後の 64 ビットから取り出される。
最初に新しい鍵セットを受け取る際には、実装でパリティ ビットを考慮しなければならない (MUST)
3 つの鍵はそれぞれ、実際はパリティに使用される余分な 8 ビットの付いた 56 ビットの長さの鍵である。

上記のすべての暗号アルゴリズムの最小の鍵長は 40 ビットであること、そして実装では 40 ビット以下の鍵長を使用しないように強く推奨されていることに注意する必要がある。

2.3 脆弱鍵 
脆弱鍵のチェックを行う必要がある (SHOULD)
脆弱鍵が発見された場合、その鍵を拒否し、新しい SA を要求する必要がある (SHOULD)
一部の暗号アルゴリズムは脆弱鍵、または脆弱性のために使用してはならない (MUST) 鍵を持つ。

新しく脆弱鍵が発見される可能性があるため、この文書ではこれらの暗号に可能性のあるすべての脆弱鍵を含むことはしない。
その他の脆弱鍵については、[MOV] や [Schneier] などの暗号関連のソースをチェックしてほしい。

CAST-128:

既知の脆弱鍵なし。
 

RC5:

16 ラウンドで使用される場合は既知の脆弱鍵なし。
 

IDEA:

IDEA には脆弱鍵があることが知られている。
詳細は [MOV] と [Schneier] を参照のこと。
 

Blowfish:

Blowfish に対する脆弱鍵が知られている。
所定の S-box に同一のエントリを作成する鍵が脆弱鍵である。
残念ながら、S-box 値を生成する前に、脆弱鍵をテストする方法はない。
ただし、このような鍵がランダムに生成される可能性は少ない。
 

3DES:

DES は、いわゆる準脆弱鍵 (semi-weak keys) と脆弱可能性鍵 (possibly-weak keys) を含むと 64 の脆弱鍵を持つ [Schneier95、280-282ページ]。
しかし、これらの鍵がランダムに選ばれる可能性は無視できるものである。

DES-EDE3 では、脆弱鍵または補助鍵 (complementation key) を拒否する必要性は知られていない。
あらゆる弱点は複数鍵を使用することで排除される。

ただし、最初の 2 つまたは最後の 2 つの独立した 64 ビットの鍵が等しい場合(k1 == k2 または k2 == k3)には、3DES の動作は DES と同一となる。
実装者はこのような性質を示す鍵を拒否しなければならない (MUST)

2.4 ブロックサイズとパディング 
この文書で取り上げられているすべてのアルゴリズムは、8 オクテット(64ビット)のブロックサイズを使用する。

パディングは、[Kent98] の指定に従い、ペイロード番号フィールドとパディング長フィールドを整列させるために使用される。
パディングは、暗号化されるデータを 8 オクテット(64 ビット)境界で整列させるのに十分でなければならない。

2.5 ラウンド 
この変数は、ブロックの暗号化回数を決定する。
この変数をネゴシエートしてもよいが (MAY)、ネゴシエートしない時でも、デフォルト値は常に存在しなければならない (MUST)
   +====================+============+======================+
   | Algorithm          | Negotiable | Default Rounds       |
   +====================+============+======================+
   | CAST-128           | No         | key<=80 bits, 12     |
   |                    |            | key>80 bits, 16      |
   +--------------------+------------+----------------------+
   | RC5                | No         | 16                   |
   +--------------------+------------+----------------------+
   | IDEA               | No         | 8                    |
   +--------------------+------------+----------------------+
   | Blowfish           | No         | 16                   |
   +--------------------+------------+----------------------+
   | 3DES               | No         | 48 (16x3)            |
   +--------------------+------------+----------------------+
2.6 背景情報 
CAST-128:

CAST デザインプロシジャは、もともとカナダのオンタリオ州キングストンにある、クイーンズ大学の Carlisle Adams と Stafford Tavares によって開発されたものである。
その後の強化は、何年にも渡って Entrust Technologies の Carlisle Adams と Michael Wiener によって行われてきた。
CAST-128 は、CAST デザインプロシジャの適用結果であり、[Adams97] にてその概要が説明されている。
 

RC5:

RC5 暗号化アルゴリズムは、DES の代替となる高性能のソフトウェアおよびハードウェア暗号の要求に応じて、RSA Data Security Inc. の Ron Rivest によって開発されたものである。
これは特許となっている(pat.no. 5,724,428)。
RC5 は、[MOV] および [Schneier] にて説明されている。
 

IDEA:

Xhejia Lai と James Massey によって IDEA (International Data Encryption Algorithm)アルゴリズムが開発された。
このアルゴリズムは、[Lai]、[Schneier]、[MOV] において詳細に説明されている。

IDEA アルゴリズムの特許は、ヨーロッパおよび米国で認可されており、日本では認可申請中である。
IDEA を商用目的で利用するためにはライセンスが必要である。

特許およびライセンスに関する情報の連絡先:

Ascom Systec AG, Dept. CMVV
Gewerbepark, CH-5506
Magenwil, Switzerland
Phone: +41 64 56 59 83
Fax: +41 64 56 59 90
idea@ascom.ch
http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html


Blowfish:

この Blowfish ブロック暗号アルゴリズムは、Counterpane Systems の Bruce Schneier によって開発された。
このアルゴリズムは、[Schneier93]、[Schneier95]、[Schneier] にて詳細に説明されている。
 

3DES:

この DES の変形は、いわゆる「トリプル DES」または DES-EDE3 として知られているもので、各ブロックを 3 回、それぞれ異なる鍵で処理するものである。
DES の動作を複数回適用するこの技術は、[Tuchman79] にて提案された。

                  P1             P2             Pi
                   |              |              |
            IV->->(X)    +>->->->(X)    +>->->->(X)
                   v     ^        v     ^        v
                +-----+  ^     +-----+  ^     +-----+
            k1->|  E  |  ^ k1->|  E  |  ^ k1->|  E  |
                +-----+  ^     +-----+  ^     +-----+
                   |     ^        |     ^        |
                   v     ^        v     ^        v
                +-----+  ^     +-----+  ^     +-----+
            k2->|  D  |  ^ k2->|  D  |  ^ k2->|  D  |
                +-----+  ^     +-----+  ^     +-----+
                   |     ^        |     ^        |
                   v     ^        v     ^        v
                +-----+  ^     +-----+  ^     +-----+
            k3->|  E  |  ^ k3->|  E  |  ^ k3->|  E  |
                +-----+  ^     +-----+  ^     +-----+
                   |     ^        |     ^        |
                   +>->->+        +>->->+        +>->->
                   |              |              |
                   C1             C2             Ci
DES-EDE3-CBC アルゴリズムは、DES-CBC アルゴリズム [FIPS-46] の単純な変形である。
「外側」チェイニング技術が使用されている。

DES-EDE3-CBC では、初期ベクトル(IV)と、最初の 64 ビット(8 バイト)の平文ブロック(P1)との XOR をとる。
鍵付き DES 関数が 3 回繰り返され、暗号化(Ek1)に続いて復号化(Dk2)、そして暗号化(Ek3)が行われ、このブロックの暗号文(C1)が生成される。
各繰り返しでは独立した鍵、k1、k2、k3 が使用される。

後に続くブロックでは、前の暗号文ブロックと、現在の平文(Pi)との XOR をとる。
鍵付き DES-EDE3 暗号化関数が、そのブロックの暗号文(Ci)を生成する。

復号化するためには、関数の順序が逆となり、k3 で復号化、k2 で暗号化、k1 で復号化、そして前の暗号文ブロックとの XOR と続く。

ここで、3 つの鍵(k1、k2、k3)のすべてが同一である場合、DES-EDE3-CBC は DES-CBC と等しいことに注意すること。
この性質によって、DES-EDE3 のハードウェア実装を変更すること無しに DES モードで動作させることが可能となる。

トリプル DES に関する詳細な説明と実装に関する情報については、[Schneier95] を参照のこと。

2.7 性能 
これらのアルゴリズムや他の暗号化アルゴリズムの処理速度の見積もりの比較表については [Schneier97] を、最新の性能比較については [Bosseleaers] を参照のこと。
3. ESP ペイロード 
ESP ペイロードは、IV とそれに続く暗号文から構成される。
[Kent98] にて定義されているペイロードフィールドは、以下の図のように細分化される。
   +---------------+---------------+---------------+---------------+
   |                                                               |
   +               Initialization Vector (8 octets)                +
   |                                                               |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   ~              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
IV フィールドは、使用されている暗号アルゴリズムのブロックサイズと同じサイズでなければならない (MUST)
IV はランダムに選択されなければならない (MUST)
一般的には、最初の IV にランダムなデータを使用し、暗号化処理からの暗号化データの最後のブロックを次の暗号化処理の IV として使用する。

各データグラムに IV を含むことにより、一部のデータグラムがドロップしたり、データグラムが配送中に再送要求された場合でも、各受信データグラムの復号化を実行できることが保証される。

異なるパケットの非常に似通った平文ブロックの ECB 暗号化を避けるため、実装では、IV にカウンタあるいはその他のロウハミングディスタンスソースを使用してはならない (MUST NOT)

3.1 ESP 環境での考慮事項 
例えば、ある特定の認証規則の使用などの、これらのアルゴリズムと他の ESP の機能との間の相互動作に関する既知の問題は現在存在していない。
3.2 鍵素材 
鍵交換プロトコルからこの ESP アルゴリズムに送信される最小ビット数は、鍵長と同等かそれ以上でなければならない。

暗号の暗号化鍵および復号化鍵は、鍵素材の最初の <x> ビットから取り出される。
ここで、<x> は必要な鍵長を表す。

4. セキュリティに関する考慮事項 
実装では、実装するハードウェアおよびソフトウェアの設定における性能を考慮した場合に可能である最大の長さの鍵を使用することを推奨する。
ここで、暗号化は安全なチャネルの両側に確実に影響を及ぼすため、クライアント側のみならずサーバ側においても性能を考慮しなければならないことに注意すること。

乱数を使用する場合についての詳細は、[Bell97] を参照のこと。

より詳細なセキュリティに関する考慮事項については、実際の暗号アルゴリズムについて記述している文書を読むことを薦める。

5. 参考文献 
[Adams97] Adams, C, "The CAST-128 Encryption Algorithm", RFC2144, 1997.

[Atkinson98]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[Baldwin96] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.

[Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}).

[Bosselaers]A. Bosselaers, "Performance of Pentium implementations", http://www.esat.kuleuven.ac.be/~bosselae/

[Bradner97] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, Springer-Verlag, pp. 224-230.

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

[Kent98] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[Lai] X. Lai, "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

[Madson98] Madson, C. and N. Dorswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.

[MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. ISBN 0-8493-8523-7

[Schneier] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7

[Schneier93]B. Schneier, "Description of a New Variable-Length Key, 64-Bit Block Cipher", from "Fast Software Encryption, Cambridge Security Workshop Proceedings", Springer-Verlag, 1994, pp. 191-204. http://www.counterpane.com/bfsverlag.html

[Schneier95]B. Schneier, "The Blowfish Encryption Algorithm - One Year Later", Dr. Dobb's Journal, September 1995, http://www.counterpane.com/bfdobsoyl.html

[Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a Pentium." February 1997, http://www.counterpane.com/speed.html

[Thayer97] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

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

6. 謝辞 
この文書は、主要な ESP 暗号アルゴリズム文書を統合したものである。
この統合は、すべての ESP アルゴリズムの共通性の理解をさらに促進するとともに、ESP におけるアルゴリズムの開発をより発展させるために行われたものである。

この文書の内容は、他の IPsec 文書の他に、Stephen Kent からの提案、および IPsec メーリングリストでの継続した議論に基づいている。

CAST の入力とレビューを行ってくれた Entrust Technologies の Carlisle Adams と Paul Van Oorschot に特に感謝する。

以前の ESP 3DES 文書の編集者全員(W. Simpson、N. Doraswamy、P. Metzger、P. Karn)に感謝する。

ESP-RC5 のオリジナルの作業を行った、TimeStep の Brett Howard に感謝する。

IDEA およびその他の暗号の入力を行ってくれた、Markku-Juhani Saarinen、Helger Lipmaa、Bart Preneel に感謝する。

7. 著者の連絡先 
Roy Pereira
TimeStep Corporation

Phone: +1 (613) 599-3610 x 4808
EMail: rpereira@timestep.com
 

Rob Adams
Cisco Systems Inc.

Phone: +1 (408) 457-5397
EMail: adams@cisco.com
 

協力してくれた方々

Robert W. Baldwin
RSA Data Security, Inc.

Phone: +1 (415) 595-8782
EMail: baldwin@rsa.com or baldwin@lcs.mit.edu
 

Greg Carter
Entrust Technologies

Phone: +1 (613) 763-1358
EMail: carterg@entrust.com
 

Rodney Thayer
Sable Technology Corporation

Phone: +1 (617) 332-7292
EMail: rodney@sabletech.com
 

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
 

翻訳者

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

EMail: babatt@nttdata.co.jp

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

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。