RFC 4196 - The SEED Cipher Algorithm and Its Use with IPsec 日本語訳

URL : https://tools.ietf.org/html/rfc4196
タイトル : RFC 4196 - SEED暗号アルゴリズムおよびIPSecでの使用
翻訳編集 : 自動生成

Network Working Group                                           H.J. Lee
Request for Comments: 4196                                     J.H. Yoon
Category: Standards Track                                       S.L. Lee
                                                                J.I. Lee
                                                                    KISA
                                                            October 2005

            The SEED Cipher Algorithm and Its Use with IPsec

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2005）。

Abstract

抽象

This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

この文書では、IPsecカプセル化セキュリティペイロード（ESP）のコンテキスト内で機密性の仕組みとして、明示的IVで、暗号ブロック連鎖モードのSEEDのブロック暗号アルゴリズムの使用を記載しています。

1. Introduction

1. はじめに

1.1. SEED

1.1. シード

SEED is a national industrial association standard [TTASSEED] and is widely used in South Korea for electronic commerce and financial services that are operated on wired and wireless communications.

SEEDは国家の産業協会標準[TTASSEED]で、広く有線および無線通信上で動作している電子商取引や金融サービスのために韓国で使用されています。

SEED is a 128-bit symmetric key block cipher that has been developed by KISA (Korea Information Security Agency) and a group of experts since 1998. The input/output block size of SEED is 128-bit and the key length is also 128-bit. SEED has the 16-round Feistel structure. A 128-bit input is divided into two 64-bit blocks, and the right 64- bit block is an input to the round function with a 64-bit subkey that is generated from the key scheduling.

SEEDは、KISA（韓国情報セキュリティ機関）によって開発された128ビットの対称鍵ブロック暗号と1998年以来、専門家のグループSEEDの入力/出力ブロックサイズは128ビットであり、キーの長さも128でありますビット。 SEEDは16段のFeistel構造を有しています。 128ビット入力は、2つの64ビットのブロックに分割され、右64ビットブロックは、鍵スケジュールから生成される64ビットサブキーとラウンド関数に入力されます。

SEED is easily implemented in various software and hardware, and it can be effectively adopted to a computing environment with restricted resources, such as mobile devices and smart cards.

SEEDは、簡単に様々なソフトウェアやハードウェアに実装され、それが効果的なモバイルデバイスやスマートカードなどの制限されたリソースを持つコンピューティング環境に適用することができます。

SEED is robust against known attacks including DC (Differential cryptanalysis), LC (Linear cryptanalysis), and related key attacks. SEED has gone through wide public scrutinizing procedures. It has been evaluated and is considered cryptographically secure by credible organizations such as ISO/IEC JTC 1/SC 27 and Japan CRYPTREC (Cryptography Research and Evaluation Committees)[ISOSEED][CRYPTREC].

SEEDは、DC（差分解読法）、LC（線形解読法）、および関連鍵攻撃など、既知の攻撃に対して堅牢です。 SEEDは、広い公共の精査の手続きを経ています。それは評価されていると、そのようなISO / IEC JTC 1 / SC 27や日本CRYPTREC（暗号研究評価委員会）[ISOSEED] [CRYPTREC]など、信頼できる機関によって暗号化された安全な考えられています。

The remainder of this document specifies the use of SEED within the context of IPsec ESP. For further information on how the various pieces of ESP fit together to provide security services, please refer to [ARCH], [ESP], and [ROAD].

このドキュメントの残りの部分では、IPsec ESPのコンテキスト内SEEDの使用を指定します。 ESPの各種セキュリティサービスを提供するために一緒に収まる方法の詳細については、[ARCH]、[ESP]、および[ROAD]を参照してください。

1.2. Terminology

1.2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119 [KEYWORDS].

キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、（図示のように、大文字で）この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" は可能になっていますRFC 2119 [KEYWORDS]で説明されるように解釈されます。

2. The SEED Cipher Algorithm

2. SEED暗号アルゴリズム

All symmetric block cipher algorithms share common characteristics and variables, including mode, key size, weak keys, block size, and rounds. The following sections contain descriptions of the relevant characteristics of SEED.

すべての対称ブロック暗号アルゴリズムは、モード、鍵サイズ、弱鍵、ブロックサイズ、およびラウンドを含む、共通の特性と変数を共有します。次のセクションでは、SEEDの関連する特性の説明が含まれています。

The algorithm specification and object identifiers are described in [ISOSEED] [SEED]. The SEED homepage, http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of information about SEED, including a detailed specification, evaluation report, test vectors, and so on.

アルゴリズム仕様とオブジェクト識別子は、[SEED] [ISOSEED]に記載されています。 SEEDのホームページ、http://www.kisa.or.kr/seed/seed_eng.htmlは、これに関する詳細な仕様など、SEED、評価報告書、テストベクトル、との情報が豊富に含まれています。

2.1. Mode

2.1. モード

NIST has defined 5 modes of operation for the Advanced Encryption Standard (AES) [AES] and other FIPS-approved ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic Codebook), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter). The CBC mode is well-defined and well-understood for symmetric ciphers, and is currently required for all other ESP ciphers. This document specifies the use of the SEED cipher in the CBC mode within ESP. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets that have identical data that spans the first block of the cipher algorithm's block size

CBC（暗号ブロック連鎖）、ECB（電子コードブック）、CFB（暗号フィードバック）、OFB（出力：NISTは、AES（Advanced Encryption Standard）[AES]と他のFIPS承認の暗号[MODES]のための操作の5つのモードが定義されていますフィードバック）、およびCTR（カウンター）。 CBCモードでは、明確に定義された対称暗号のために十分に理解され、現在、他のすべてのESP暗号のために必要とされます。この文書では、ESP内のCBCモードでのSEED暗号の使用を指定します。このモードは、ブロックサイズと同じサイズで初期化ベクトル（IV）を必要とします。ランダムに生成されたIVの使用は、暗号アルゴリズムのブロックサイズの最初のブロックにまたがる同一のデータを有するパケットから同一の暗号文の発生を防止します

The IV is XOR'd with the first plaintext block before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext before it is encrypted.

IVは、それが暗号化される前に、最初の平文ブロックとのXORをとります。それが暗号化される前に、次に連続するブロックのために、前の暗号文ブロックが、現在の平文とXORされます。

More information on the CBC mode can be obtained in [MODES] [CRYPTO-S]. For use of the CBC mode in ESP with 64-bit ciphers, please see [CBC].

CBCモードの詳細については、[MODES] [CRYPTO-S]で得ることができます。 64ビットの暗号とESPにおけるCBCモードを使用する場合は、[CBC]を参照してください。

2.2. Key Size and Numbers of Rounds

2.2. キーサイズとラウンドの数

SEED supports 128-bit key and has the 16-round Feistel structure.

SEEDは、128ビットの鍵をサポートし、16段のFeistel構造を有しています。

2.3. Weak Keys

2.3. 弱い鍵

At the time this document was written, there were no known weak keys for SEED.

この文書が書かれた時点では、SEEDのための既知の弱いキーがありませんでした。

2.4. Block Size and Padding

2.4. ブロックサイズとパディング

SEED uses a block size of 16 octets (128 bits).

SEEDは、16個のオクテット（128ビット）のブロックサイズを使用します。

Padding is required by SEED to maintain a 16-octet (128-bit) blocksize. Padding MUST be added, as specified in [ESP], such that the data to be encrypted (which includes the ESP Pad Length and Next Header fields) has a length that is a multiple of 16 octets.

パディングは、16オクテット（128ビット）のブロックサイズを維持するためにSEEDによって必要とされます。 [ESP]で指定されるようにパディングが追加されなければならない、（ESPパッド長と次ヘッダフィールドを含む）データを暗号化するようには16オクテットの倍数である長さを有しています。

Because of the algorithm specific padding requirement, no additional padding is required to ensure that the ciphertext terminates on a 4- octet boundary (i.e., maintaining a 16-octet blocksize guarantees that the ESP Pad Length and Next Header fields will be right aligned within a 4-octet word). Additional padding MAY be included, as specified in [ESP], as long as the 16-octet blocksize is maintained.

そのため、アルゴリズム特定のパディングの要件のため、追加のパディングが暗号文（すなわち、16オクテットのブロックサイズの保証を維持するESPパッドの長さと次ヘッダフィールドは右内で整列されることを、4-オクテット境界で終わることを保証するために必要とされません4オクテットワード）。 [ESP]で指定されるように、追加のパディングがあれば、16オクテットのブロックサイズが維持されるように、含まれてもよいです。

2.5. Performance

2.5. 演奏

Performance figures of SEED are available at http://www.kisa.or.kr/seed/seed_eng.html

SEEDのパフォーマンス数値はhttp://www.kisa.or.kr/seed/seed_eng.htmlで入手できます。

3. ESP Payload

3. ESPペイロード

The ESP Payload is made up of the Initialization Vector(IV) of 16 octets followed by the encrypted payload. Thus, the payload field, as defined in [ESP], is broken down according to the following diagram:

ESPペイロードは、暗号化されたペイロードが続く16オクテットの初期化ベクトル（IV）で構成されています。したがって、[ESP]で定義されるようにペイロードフィールドは、以下の図に従って分解されます。

      +---------------+---------------+---------------+---------------+
      |                                                               |
      +               Initialization Vector (16 octets)               +
      |                                                               |
      +---------------+---------------+---------------+---------------+
      |                                                               |
      ~ Encrypted Payload (variable length, a multiple of 16 octets)  ~
      |                                                               |
      +---------------------------------------------------------------+

The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random and MUST be unpredictable.

IVフィールドが使用されている暗号アルゴリズムのブロックサイズと同じサイズでなければなりません。 IVはランダムに選択されなければならないと予測不可能でなければなりません。

Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped or re-ordered in transit.

各データグラムにIVを含むことは、それぞれの復号化は、いくつかのデータグラムを落としたり輸送中に再注文された場合でも、データグラムを実行することができる受信ことを保証します。

To avoid CBC encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-hamming distance source for IVs.

異なるパケットの非常に似通った平文ブロックのCBC暗号化を避けるために、実装は、カウンターやのIVのための他の低ハミング距離ソースを使用してはなりません。

4. Test Vectors

4.テストベクトル

The first 2 test cases test SEED-CBC encryption. Each test case includes key, the plaintext, and the resulting ciphertext. All data are hexadecimal numbers (not prefixed by "0x").

最初の2つのテストケースは、SEED-CBC暗号化をテストします。各テストケースは、鍵、平文、得られた暗号文を含みます。すべてのデータは16進数（「0xの」で始まるではない）です。

The last 4 test cases illustrate sample ESP packets using SEED-CBC for encryption. All data are hexadecimal numbers (not prefixed by "0x").

最後の4のテストケースは、暗号化にSEED-CBCを使用してサンプルESPパケットを示しています。すべてのデータは16進数（「0xの」で始まるではない）です。

Case #1 : Encrypting 32 bytes (2 blocks) using SEED-CBC with 128-bit key Key : ed2401ad 22fa2559 91bafdb0 1fefd697 IV : 93eb149f 92c9905b ae5cd34d a06c3c8e PlainText : b40d7003 d9b6904b 35622750 c91a2457 5bb9a632 364aa26e 3ac0cf3a 9c9d0dcb CipherText : f072c5b1 a0588c10 5af8301a dcd91dd0 67f68221 55304bf3 aad75ceb 44341c25

ケース＃1：128ビット鍵KEYとSEED-CBCを使用して、32バイト（2ブロック）を暗号化は：22fa2559 91bafdb0 1fefd697 IVをed2401ad：93eb149f 92c9905b ae5cd34d a06c3c8e平文：b40d7003 d9b6904b 35622750 c91a2457 5bb9a632 364aa26e 3ac0cf3a 9c9d0dcb暗号文：f072c5b1 a0588c10 5af8301a dcd91dd0 67f68221 55304bf3 aad75ceb 44341c25

Case #2 : Encrypting 64 bytes (4 blocks) using SEED-CBC with 128-bit key Key : 88e34f8f 081779f1 e9f39437 0ad40589 IV : 268d66a7 35a81a81 6fbad9fa 36162501 PlainText : d76d0d18 327ec562 b15e6bc3 65ac0c0f 8d41e0bb 938568ae ebfd92ed 1affa096 394d20fc 5277ddfc 4de8b0fc e1eb2b93 d4ae40ef 4768c613 b50b8942 f7d4b9b3 CipherText : a293eae9 d9aebfac 37ba714b d774e427 e8b706d7 e7d9a097 228639e0 b62b3b34 ced11609 cef2abaa ec2edf97 9308f379 c31527a8 267783e5 cba35389 82b48d06

ケース＃2：081779f1 e9f39437 0ad40589 IV 88e34f8f：268d66a7 35a81a81 6fbad9fa 36162501平文：d76d0d18 327ec562 b15e6bc3 65ac0c0f 8d41e0bb 938568ae ebfd92ed 1affa096 394d20fc 5277ddfc 4de8b0fc e1eb2b93 d4ae40ef 4768c613 b50b8942 f7d4b9b3 128ビット鍵KEYとSEED-CBCを使用して64バイト（4つのブロック）暗号化暗号文：a293eae9 d9aebfac 37ba714b d774e427 e8b706d7 e7d9a097 228639e0 b62b3b34 ced11609 cef2abaa ec2edf97 9308f379 c31527a8 267783e5 cba35389 82b48d06

Case #3 : Sample transport-mode ESP packet (ping 192.168.123.100) Key : 90d382b4 10eeba7a d938c46c ec1a82bf SPI : 4321 Source address : 192.168.123.3 Destination address : 192.168.123.100 Sequence number : 1 IV : e96e8c08 ab465763 fd098d45 dd3ff893

ケース＃3：サンプルトランスポートモードESPパケット（pingを192.168.123.100）キー：90d382b4 10eeba7a d938c46cのec1a82bf SPI：4321ソースアドレス：192.168.123.3送信先アドレス：192.168.123.100シーケンス番号：1 IV：e96e8c08 ab465763 fd098d45 dd3ff893

Original packet : IP header (20 bytes) : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 Data (64 bytes) : 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

元のパケット：IPヘッダー（20バイト）：45000054 08f20000 4001f9fe c0a87b03 c0a87b64データ（64バイト）：08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 20212223 24252627 18191a1b 1c1d1e1f 28292a2b 2c2d2e2f 30313233 34353637

Augment data with : Padding : 01020304 05060708 090a0b0c 0d0e Pad length : 0e Next header : 01 (ICMP)

パディング：01020304 05060708 090a0b0c 0d0eパッド長を有するデータを増強0E次ヘッダ：01（ICMP）

Pre-encryption Data with padding, pad length and next header(80 bytes): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01

パディング、パッドの長さと次のヘッダ（80バイト）で予め暗号化データ：08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 20212223 24252627 18191a1b 1c1d1e1f 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01

Post-encryption packet with SPI, Sequence number, IV : IP Header : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 SPI/Seq # : 00004321 00000001 IV : e96e8c08 ab465763 fd098d45 dd3ff893 Encrypted Data (80 bytes) : e7ebaa03 cf45ef09 021b3011 b40d3769 be96ebae cd4222f6 b6f84ce5 b2d5cdd1 60eb6b0e 5a47d16a 501a4d10 7b2d7cc8 ab86ba03 9a000972 66374fa8 f87ee0fb ef3805db faa144a2 334a34db 0b0f81ca

SPI、シーケンス番号、IVとポスト暗号化パケット：IPヘッダ：45000054 08f20000 4001f9fe c0a87b03のc0a87b64 SPI /配列番号：00004321 00000001 IV：e96e8c08 ab465763 fd098d45 dd3ff893暗号化データ（80バイト）：e7ebaa03 cf45ef09 021b3011 b40d3769 be96ebae cd4222f6 b6f84ce5 b2d5cdd1 60eb6b0e 5a47d16a 501a4d10 7b2d7cc8 ab86ba03 9a000972 66374fa8 f87ee0fb ef3805db faa144a2 334a34db 0b0f81ca

Case #4 : Sample transport-mode ESP packet (ping -p 77 -s 20 192.168.123.100) Key : 90d382b4 10eeba7a d938c46c ec1a82bf SPI : 4321 Source address : 192.168.123.3 Destination address : 192.168.123.100 Sequence number : 8 IV : 69d08df7 d203329d b093fc49 24e5bd80

ケース＃4：サンプルトランスポートモードESPパケット（pingの-p 77 -s 20 192.168.123.100）キー：90d382b4 10eeba7a d938c46cのec1a82bf SPI：4321ソースアドレス：192.168.123.3送信先アドレス：192.168.123.100シーケンス番号：8 IV：69d08df7 d203329d b093fc49 24e5bd80

Original packet: IP header (20 bytes) : 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64 Data (28 bytes) : 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

元のパケット：IPヘッダー（20バイト）：45000030 08fe0000 4001fa16データc0a87b64 c0a87b03（28バイト）：0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

Augment data with : Padding : 0102 Pad length : 02 Next header : 01 (ICMP)

パディング：でデータを増補0102パッドの長さ：02次ヘッダ：01（ICMP）

Pre-encryption Data with padding, pad length and next header(32 bytes): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201

0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201：パディング、パッドの長さと次のヘッダ（32バイト）で予め暗号化データ

Post-encryption packet with SPI, Sequence number, IV : IP header : 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI/Seq # : 00004321 00000008 IV : 69d08df7 d203329d b093fc49 24e5bd80 Encrypted Data (32 bytes) : b9ad6e19 e9a6a2fa 02569160 2c0af541 db0b0807 e1f660c7 3ae2700b 5bb5efd1

SPI、シーケンス番号、IVと後の暗号化パケット：IPヘッダ：4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI /配列番号：00004321 00000008 IV：69d08df7 d203329d b093fc49 24e5bd80暗号化データ（32バイト）：b9ad6e19 e9a6a2fa 02569160 2c0af541 db0b0807 e1f660c7 3ae2700b 5bb5efd1

Case #5 : Sample tunnel-mode ESP packet (ping 192.168.123.200) Key : 01234567 89abcdef 01234567 89abcdef SPI : 8765 Source address : 192.168.123.3 Destination address : 192.168.123.200 Sequence number : 2 IV : f4e76524 4f6407ad f13dc138 0f673f37

ケース＃5：サンプルトンネルモードESPパケット（pingを192.168.123.200）キー：01234567 89abcdef 01234567 89abcdef SPI：8765ソースアドレス：192.168.123.3送信先アドレス：192.168.123.200シーケンス番号：2 IV：f4e76524 4f6407ad f13dc138 0f673f37

Original packet : IP header (20 bytes) : 45000054 09040000 4001f988 c0a87b03 c0a87bc8 Data (64 bytes) : 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

元のパケット：IPヘッダー（20バイト）：450000540904万4001f988 c0a87b03 c0a87bc8データ（64バイト）：08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 20212223 24252627 18191a1b 1c1d1e1f 28292a2b 2c2d2e2f 30313233 34353637

Augment data with : Padding : 01020304 05060708 090a Pad length : 0a Next header : 04 (IP-in-IP)

パディング：01020304 05060708 090aパッド長を有するデータを増強0A次ヘッダ：04（IPインIP）

Pre-encryption Data with original IP header, padding, pad length and next header (96 bytes) : 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04

45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 10111213 090a0a04 0c0d0e0f：元のIPヘッダ、パディング、パッドの長さと次のヘッダ（96バイト）で予め暗号化データ

Post-encryption packet with SPI, Sequence number, IV : IP header : 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 SPI/Seq # : 00008765 00000002 IV : f4e76524 4f6407ad f13dc138 0f673f37 Encrypted Data (96 bytes): 2638aa7b 05e71b54 9348082b 67b47b26 c565aed4 737f0bcb 439c0f00 73e7913c 3c8a3e4f 5f7a5062 003b78ed 7ca54a08 c7ce047d 5bec14e4 8cba1005 32a12097 8d7f5503 204ef661 729b4ea1 ae6a9178 59a5caac 46e810bd 7875bd13 d6f57b3d

SPI、シーケンス番号、IVと後の暗号化パケット：IPヘッダ：4500008c0905万4032f91e c0a87b03 c0a87bc8 SPI /配列＃：00008765 00000002 IV：f4e76524 4f6407ad f13dc138 0f673f37暗号化データ（96バイト）：2638aa7b 05e71b54 9348082b 67b47b26 c565aed4 737f0bcb 439c0f00 73e7913c 3c8a3e4f 5f7a5062 003b78ed 7ca54a08 c7ce047d 5bec14e4 8cba1005 32a12097 8d7f5503 204ef661 729b4ea1 ae6a9178 59a5caac 46e810bd 7875bd13 d6f57b3d

Case #6 : Sample tunnel-mode ESP packet (ping -p ff -s 40 192.168.123.200) Key : 01234567 89abcdef 01234567 89abcdef SPI : 8765 Source address : 192.168.123.3 Destination address : 192.168.123.200 Sequence number : 5 IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22

ケース＃6：サンプルトンネルモードESPパケット（pingの-p FF -s 40 192.168.123.200）キー：01234567 89abcdef 01234567 89abcdef SPI：8765ソースアドレス：192.168.123.3送信先アドレス：192.168.123.200シーケンス番号：5 IV：85d47224 b5f3dd5d 2101d4ea 8dffab22

Original packet : IP header (20 bytes) : 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 Data (48 bytes) : 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

元のパケット：IPヘッダー（20バイト）：45000044 090c0000 4001f990 c0a87b03 c0a87bc8データ（48バイト）：0800d63c aa0a0200 c69c083d a3de0300 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

Augment data with : Padding : 01020304 05060708 090a Pad length : 0a Next header : 04 (IP-in-IP)

パディング：01020304 05060708 090aパッド長を有するデータを増強0A次ヘッダ：04（IPインIP）

Pre-encryption Data with original IP header, padding, pad length and next header (80 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 01020304 05060708 090a0a04

元のIPヘッダ、パディング、パッドの長さと次のヘッダ（80バイト）で予め暗号化データ：45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 01020304 05060708 090a0a04

Post-encryption packet with SPI, Sequence number, IV : IP header : 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI/Seq # : 00008765 00000005 IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22 Encrypted Data (80 bytes) : 311168e0 bc36ac4e 59802bd5 192c5734 8f3d29c8 90bab276 e9db4702 91f79ac7 79571929 c170f902 ffb2f08b d448f782 31671414 ff29b7e0 168e1c87 09ba2b67 a56e0fbc 4ff6a936 d859ed57 6c16ef1b

IPヘッダ：4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI /配列＃：00008765 00000005 IV：85d47224 b5f3dd5d 2101d4ea 8dffab22暗号化データ（80バイト）：311168e0 bc36ac4e 59802bd5 192c5734 8f3d29c8 90bab276 e9db4702 91f79ac7 79571929 c170f902 SPI、シーケンス番号、IVと後の暗号化パケットffb2f08b d448f782 31671414 ff29b7e0 168e1c87 09ba2b67 a56e0fbc 4ff6a936 d859ed57 6c16ef1b

5. Interaction with IKE

IKE 5.相互作用

This section describes the use of IKE [IKE] to establish IPsec ESP security associations (SAs) that employ SEED in CBC mode.

このセクションでは、CBCモードでSEEDを採用したIPsec ESPセキュリティアソシエーション（SA）を確立するために、IKE [IKE]の使用を記載しています。

5.1. Phase 1 Identifier

5.1. フェーズ1つの識別子

For Phase 1 negotiations, the object identifier of SEED-CBC is defined in [SEED].

フェーズ1つのネゴシエーションのために、SEED-CBCのオブジェクト識別子は、[SEED]で定義されています。

   algorithm OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410)
   kisa(200004) algorithm(1) }

   id-seedCBC OBJECT IDENTIFIER ::= { algorithm seedCBC(4) }

5.2. Phase 2 Identifier

5.2. フェーズ2の識別子

For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of (21) for ESP_SEED_CBC.

フェーズ2ネゴシエーションのために、IANAは、ESPはESP_SEED_CBCための識別子（21）を形質転換割り当てました。

5.3. Key Length Attribute

5.3. キーの長さ属性

Since the SEED supports 128-bit key lengths, the Key Length attribute is set with 128 bits.

SEEDは、128ビットの鍵長をサポートしているので、キーの長さ属性は、128ビットで設定されています。

5.4. Hash Algorithm Considerations

5.4. アルゴリズムの考慮事項をハッシュ

HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered of sufficient strength to serve both as IKE generators of 128-bit SEED keys and as ESP authenticators for SEED encryption using 128-bit keys.

HMAC-SHA-1 [HMAC-SHA]およびHMAC-MD5 [HMAC-MD5]は、現在、128ビットSEEDキーのIKE発生器として128ビットキーを使用してSEED暗号化のためのESPオーセンティケータの両方として機能するのに十分な強度を有すると考えられます。

6. Security Considerations

6.セキュリティの考慮事項

No security problem has been found on SEED. SEED is secure against all known attacks including Differential cryptanalysis, Linear cryptanalysis, and related key attacks. The best known attack is only an exhaustive search for the key (by [CRYPTREC]). For further security considerations, the reader is encouraged to read [CRYPTREC], [ISOSEED], and [SEED-EVAL].

いいえ、セキュリティの問題は、SEEDに見つかっていません。 SEEDは、差分解読法、線形解読法、および関連鍵攻撃を含むすべての既知の攻撃に対して安全です。最もよく知られた攻撃は、（[CRYPTREC]による）キーのための唯一の徹底的な検索です。さらに、セキュリティ問題のために、読者は[CRYPTREC]、[ISOSEED]、および[SEED-EVAL]を読み取ることが奨励されます。

7. IANA Considerations

7. IANAの考慮事項

IANA has assigned ESP Transform Identifier (21) to ESP_SEED_CBC.

IANAは、ESP割り当てESP_SEED_CBCに識別子（21）を形質転換しています。

8. Acknowledgments

8.謝辞

The authors want to thank Ph.D Haesuk Kim of Future Systems Inc. and Brian Kim of OULLIM Information Technology Inc. for providing expert advice on Test Vector examples.

著者は、テストベクトルの例に関する専門家のアドバイスを提供するためのフューチャー・システムズの博士HaesukキムとOULLIM情報技術（株）のブライアン・キムに感謝したいと思います。

9. References

9.参考文献

9.1. Normative References

9.1. 引用規格

[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.

[CBC]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。

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

[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。

[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。

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

[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[SEED] Park, J., Lee, S., Kim, J., and J. Lee, "The SEED Encryption Algorithm", RFC 4009, February 2005.

[SEED]パーク、J.、リー、S.、キム、J.、およびJ.リー、 "SEED暗号化アルゴリズム"、RFC 4009、2005年2月。

[TTASSEED] Telecommunications Technology Association (TTA), South Korea, "128-bit Symmetric Block Cipher (SEED)", TTAS.KO-12.0004, September, 1998 (In Korean) http://www.tta.or.kr/English/new/main/index.htm

[TTASSEED]電気通信技術協会（TTA）、韓国、 "128ビットの対称ブロック暗号（SEED）"、TTAS.KO-12.0004、1998年9月（韓国語で）http://www.tta.or.kr/英語/新/メイン/ index.htmを

9.2. Informative Reference

9.2. 参考文献

[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard(AES), November 2001. http://csrc.nist.gov/publications/fips/fips197/fips-197. {ps,pdf}

[AES] NIST、FIPSパブ197、「高度暗号化標準（AES）、2001年11月http://csrc.nist.gov/publications/fips/fips197/fips-197。{PS、PDF}

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

[ARCH]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。

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

[CRYPTO-S]シュナイアー、B.、 "応用暗号第二版"、John Wiley＆Sons、ニューヨーク、NY、1995、ISBN 0-471-12845-7。

[CRYPTREC] Information-technology Promotion Agency (IPA), Japan, CRYPTREC. "SEED Evaluation Report", February, 2002 http://www.kisa.or.kr/seed/seed_eng.html

[CRYPTREC]情報処理推進機構（IPA）、日本、CRYPTREC。 "SEED評価報告書"、2002年2月http://www.kisa.or.kr/seed/seed_eng.html

[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[HMAC-MD5] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-MD5-96の使用"、RFC 2403、1998年11月。

[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

[HMAC-SHA] Madson、C.およびR.グレン、 "ESPおよびAH内HMAC-SHA-1-96の使用"、RFC 2404、1998年11月。

[ISOSEED] ISO/IEC JTC 1/SC 27 N3979, "IT Security techniques - Encryption Algorithms - Part3 : Block ciphers", June 2004.

[ISOSEED] ISO / IEC JTC 1 / SC 27 N3979、 "ITセキュリティ技術 - 暗号化アルゴリズム - 第3部：ブロック暗号"、2004年6月。

[MODES] Symmetric Key Block Cipher Modes of Operation, http://www.nist.gov/modes/.

[MODES]の動作の対称鍵ブロック暗号モード、http://www.nist.gov/modes/。

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

[ROAD]セイヤー、R.、N. DoraswamyおよびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。

[SEED-EVAL] KISA, "Self Evaluation Report", http://www.kisa.or.kr/seed/data/Document_pdf/ SEED_Self_Evaluation.pdf"

[SEED-EVAL] KISA、 "自己評価報告書"、http://www.kisa.or.kr/seed/data/Document_pdf/ SEED_Self_Evaluation.pdf」

Authors' Address

著者の住所

Hyangjin Lee Korea Information Security Agency Phone: +82-2-405-5446 Fax : +82-2-405-5319 EMail : jiinii@kisa.or.kr

Hyangjinリー韓国情報セキュリティ庁電話：+ 82-2-405-5446ファックス：+ 82-2-405-5319 Eメール：jiinii@kisa.or.kr

Jaeho Yoon Korea Information Security Agency Phone: +82-2-405-5434 Fax : +82-2-405-5219 EMail : jhyoon@kisa.or.kr

Jaehoユン・韓国情報セキュリティ庁電話：+ 82-2-405-5434ファックス：+ 82-2-405-5219 Eメール：jhyoon@kisa.or.kr

Seoklae Lee Korea Information Security Agency Phone: +82-2-405-5230 Fax : +82-2-405-5219 EMail : sllee@kisa.or.kr

Seoklaeリー韓国情報セキュリティ庁電話：+ 82-2-405-5230ファックス：+ 82-2-405-5219 Eメール：sllee@kisa.or.kr

Jaeil Lee Korea Information Security Agency Phone: +82-2-405-5200 Fax : +82-2-405-5219 EMail: jilee@kisa.or.kr

Jaeilリー韓国情報セキュリティ庁電話：+ 82-2-405-5200ファックス：+ 82-2-405-5219 Eメール：jilee@kisa.or.kr

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2005）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。