|
ネットワーク WG Request for Comments： 2451 分類： スタンダードトラック |
R. Pereira TimeStep Corporation R. Adams Cisco Systems Inc. 1998年11月 |
この文書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
この文書では、 IPSec ESP(暗号ペイロード)プロトコルでのCBCモード暗号アルゴリズムの使用法について説明する。 ある特定の暗号アルゴリズムの使用法のみならず、 すべてのCBCモード暗号アルゴリズムの使用法についても明確に説明する。
暗号ペイロード(ESP) [Kent98]は、 保護すべきペイロードデータを暗号化することによって、 IPデータグラムに機密性を提供する。 この仕様では、CBCモード暗号アルゴリズムのESPでの使用法について説明する。
この文書では、 デフォルトの暗号アルゴリズムであるDESの使用法について説明していないが、 読者はそれに該当する文書 [Madson98] に精通している必要がある。
この文書では、 読者が「インターネットプロトコルのためのセキュリティアーキテクチャ」 [Atkinson95]、 「IPセキュリティ文書体系」 [Thayer97]、 「IP暗号ペイロード(ESP)」 [Kent98] の各文書で説明されている用語と概念に精通していることを前提としている。 さらに、この文書は [Kent98] と対になっているため、 その関係を意識して読まれなければならない(MUST)。
この文書において、しなければならない(MUST)、 してはならない(MUST NOT)、要求される(REQUIRED)、 する必要がある(SHOULD)、しないほうがよい(SHOULD NOT)、 してもよい(MAY)のキーワードが使用された場合は、 [Bradner97] における定義に沿って解釈されるものとする。
この文書に記述される技術の実装および使用に関係すると主張される、 知的財産権およびその他の権利の有効性または範囲に関して、 またこのような権利の下でのあらゆる権利が効力を持つ範囲に関して、 IETFはいかなる立場もとらず、また、 IETFはそのような権利を確認するためのいかなる取り組みを行ったことも表明しない。 スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きは、 BCP-11で見ることができる。 出版を目的に利用可能な権利主張のコピーおよび利用可能となるライセンス保証のコピー、 あるいは、 この仕様の実装者やユーザによる所有権の使用に対する一般的な権利や許可を得るために行われた試みの結果は、 IETF事務局から入手可能である。
すべての対称ブロック暗号アルゴリズムは、共通の特性と変数を共有する。 これには、モード、鍵長、脆弱鍵、ブロックサイズ、ラウンドが含まれる。 これらのすべてについて以下で説明する。
この文書では、Blowfish [Schneier93]、 CAST-128 [Adams97]、3DES、 IDEA [Lai] [MOV]、 RC5 [Baldwin96] などの特定の暗号アルゴリズムを取り上げているが、 この文書で定義されるすべての変数が明確に定義されていれば、 他のどのブロック暗号アルゴリズムをESPで使用しても良い。
この文書で取り上げられるすべての対称ブロック暗号アルゴリズムは、 暗号ブロック連鎖(CBC)モードを使用する。 このモードでは、 ブロックサイズと同じサイズの初期ベクトル(IV)が必要とされる。 ランダムに生成されたIVを使用することにより、 暗号アルゴリズムのブロックサイズの最初のブロックにまたがる同一のデータを持つパケットから、 同一の暗号文を生成することが回避される。
最初の平文ブロックを暗号化する前に、 IVとその平文ブロックとのXORをとる。 次に、後に続くブロックでは、その平文を暗号化する前に、 以前の暗号文ブロックとのXORをとる。
CBCモードに関しての詳細な情報は、 [Schneier95] から得ることができる。
暗号アルゴリズムには可変長の鍵が使用できるものと、 特定の長さの鍵のみが使用できるものがある。 鍵の長さは、そのアルゴリズムの強度と相互に関連しており、 長い鍵のほうが短い鍵よりも常に破るのが困難である。
この文書では、 すべての鍵長は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ビット以下の鍵長を使用しないように強く推奨されていることに注意する必要がある。
脆弱鍵のチェックを行う必要がある(SHOULD)。 脆弱鍵が発見された場合、その鍵を拒否し、 新しいSAを要求する必要がある(SHOULD)。 一部の暗号アルゴリズムは脆弱鍵、 または脆弱性のために使用してはならない(MUST)鍵を持つ。
新しく脆弱鍵が発見される可能性があるため、 この文書ではこれらの暗号に可能性のあるすべての脆弱鍵を含むことはしない。 その他の脆弱鍵については、 [MOV] や [Schneier] などの暗号関連のソースをチェックしてほしい。
この文書で取り上げられているすべてのアルゴリズムは、 8オクテット(64ビット)のブロックサイズを使用する。
パディングは、[Kent98] の指定に従い、 ペイロード番号フィールドとパディング長フィールドを整列させるために使用される。 パディングは、 暗号化されるデータを8オクテット(64ビット)境界で整列させるのに十分でなければならない。
この変数は、ブロックの暗号化回数を決定する。 この変数をネゴシエートしてもよいが(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) | +--------------------+------------+----------------------+
CASTデザインプロシジャは、 もともとカナダのオンタリオ州キングストンにある、 クイーンズ大学のCarlisle AdamsとStafford Tavaresによって開発されたものである。 その後の強化は、何年にも渡ってEntrust TechnologiesのCarlisle AdamsとMichael Wienerによって行われてきた。 CAST-128は、CASTデザインプロシジャの適用結果であり、 [Adams97] にてその概要が説明されている。
RC5暗号化アルゴリズムは、 DESの代替となる高性能のソフトウェアおよびハードウェア暗号の要求に応じて、 RSA Data Security Inc.のRon Rivestによって開発されたものである。 これは特許となっている(pat. no.5, 724, 428)。 RC5は、[MOV] および [Schneier] にて説明されている。
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ブロック暗号アルゴリズムは、Counterpane SystemsのBruce Schneierによって開発された。 このアルゴリズムは、[Schneier93]、 [Schneier95]、 [Schneier] にて詳細に説明されている。
この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] を参照のこと。
これらのアルゴリズムや他の暗号化アルゴリズムの処理速度の見積もりの比較表については [Schneier97] を、 最新の性能比較については [Bosseleaers] を参照のこと。
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)。
例えば、ある特定の認証規則の使用などの、 これらのアルゴリズムと他のESPの機能との間の相互動作に関する既知の問題は現在存在していない。
鍵交換プロトコルからこのESPアルゴリズムに送信される最小ビット数は、 鍵長と同等かそれ以上でなければならない。
暗号の暗号化鍵および復号化鍵は、 鍵素材の最初の<x>ビットから取り出される。 ここで、<x>は必要な鍵長を表す。
実装では、 実装するハードウェアおよびソフトウェアの設定における性能を考慮した場合に可能である最大の長さの鍵を使用することを推奨する。 ここで、暗号化は安全なチャネルの両側に確実に影響を及ぼすため、 クライアント側のみならずサーバ側においても性能を考慮しなければならないことに注意すること。
乱数を使用する場合についての詳細は、[Bell97] を参照のこと。
より詳細なセキュリティに関する考慮事項については、 実際の暗号アルゴリズムについて記述している文書を読むことを薦める。
[Adams97] Adams, C, "The CAST-128 Encryption Algorithm", RFC2144, 1997年.
[Atkinson98]Kent, S. and R. Atkinson,
「インターネットプロトコルのためのセキュリティアーキテクチャ(Security
Architecture for the Internet Protocol)」,
RFC 2401,
1998年11月.
[Baldwin96] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, 1996年10月.
[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, 1997年2月 (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, 1997年3月.
[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, 1977年1月.
[Kent98] Kent, S. and R. Atkinson,
「IP暗号ペイロード(ESP)(IP Encapsulating Security Payload (ESP))」,
RFC 2406, 1998年11月.
[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,
「明示的IVを伴うESP DES-CBC暗号アルゴリズム(The ESP DES-CBC
Cipher Algorithm With Explicit IV)」,
RFC 2405, 1998年11月.
[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, 1995年9月, http://www.counterpane.com/bfdobsoyl.html
[Schneier97] B. Scheier, "Speed Comparisons of Block Ciphers on a Pentium." 1997年2月, http://www.counterpane.com/speed.html
[Thayer97] Thayer, R., Doraswamy, N. and
R. Glenn,
「IPSEC文書ロードマップ(IP Security Document Roadmap)」,
RFC 2411, 1998年11月.
[Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", IEEE Spectrum, v. 16 n. 7, 1979年7月, pp. 40-41.
この文書は、主要な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に感謝する。
Roy Pereira
TimeStep Corporation
電話： +1 (613) 599-3610 x 4808
EMail： rpereira＠timestep.com
Rob Adams
Cisco Systems Inc.
電話： +1 (408) 457-5397
EMail： adams@cisco.com
協力してくれた方々
Robert W. Baldwin
RSA Data Security, Inc.
電話： +1 (415) 595-8782
EMail： baldwin＠rsa.com or baldwin＠lcs.mit.edu
Greg Carter
Entrust Technologies
電話： +1 (613) 763-1358
EMail： carterg＠entrust.com
Rodney Thayer
Sable Technology Corporation
電話： +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
株式会社 NTTデータ
開発本部
馬場 達也
EMail： baba＠rd.nttdata.co.jp
Copyright (C) The Internet Society (1998). All Rights Reserved.
本書とその翻訳は、複製および他に提供することができる。 また、本書に論評や説明を加えたり、その実装を補助するものは、 上記の著作権表示およびこの節を付加していれば、 全体あるいは一部であっても一切の制約を課されることなく作成、 複製、発表、配布できる。 ただし、この文書自体に対して、 著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従って、 インターネット標準を開発するために必要な場合や、 RFCを英語以外の言語に翻訳する必要がある場合はそのかぎりでない。
上記の制限は永続的なものであり、 インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は「無保証」で提供され、 インターネットソサエティおよびIETFはすべての保証を明示的にも暗黙的にもおこなわない。 その中には、この情報がいかなる権利も侵害していないという保証や、 商用利用および特定目的における適合性への保証が含まれる。