Network Working Group R. Housley Request for Comments: 3217 RSA Laboratories 分類: 情報提供 2001年12月 3DES と RC2 のキーラッピング 本文書の位置づけ 本文書はインターネットコミュニティに情報を与えるものである. いかなる 種類のインターネット標準をも規定するものではない. 本文書の配布は 無制限である. 著作権表示 Copyright (C) The Internet Society (2001). All Rights Reserved. 要旨 本文書は 3DES キーを別の 3DES キーでラップするためのアルゴリズムおよび RC2 キーを別の RC2 キーでラップするためのアルゴリズムを定めるものである. これらのキーラップアルゴリズムは, 元は RFC 2630 の 12.6 項に書かれている. RFC 2630 でサポートされていたコンテキストを超えるコンテキストにおいて 有用であることがわかったため, 再度発表することとする. 1 序文 対称暗号鍵の管理においては, ある鍵がしばしば他の鍵の暗号化(もしくはラップ) に使われるという状況につながる. キーラップアルゴリズムは通常2つの シチュエーションで使用される.  まず最初のシチュエーションは, キー アグリーメントアルゴリズム (例えばDiffie-Hellman [DH-X9.42])によって 鍵暗号化鍵を1ペア生成し, コンテント暗号化鍵もしくはマルチキャスト鍵を 鍵暗号化鍵によって暗号化するのにキーラップアルゴリズムが使用されるもの である. 第二のシチュエーションでは, ローカルで生成されたストレージ鍵 暗号化鍵において, あるいは帯域外で配布された鍵暗号化鍵においてコンテント 暗号化鍵, マルチキャスト鍵, セッション鍵を暗号化するのにキーラップ アルゴリズムが使用される. 本文書では 3DES 鍵を別の 3DES 鍵 [3DES] でラップするアルゴリズムについて, また RC2 鍵を別の RC2 鍵でラップするアルゴリズムについて述べる. 3DES 鍵を 別の 3DES 鍵で暗号化するにはセクション 3 で述べられているアルゴリズムを 使用する. RC2 鍵を別の RC2 鍵で暗号化するにはセクション 4 で述べられている アルゴリズムを使用する. 両アルゴリズム共セクション 2 で述べられている キーチェックサムアルゴリズムに依存している. 3DES と RC2 コンテント 暗号化鍵は Cipher Block Chaining (CBC) モードで暗号化される. Housley 情報提供 [Page 1] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 本文書において, MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY の各キーワードは, Scott Bradner が[STDWORDS] で記述しているように解釈 されるべきである. 2 キーチェックサム キーチェックサムアルゴリズムは鍵の完全性チェック値を与えるために使用 される. このアルゴリズムは: 1. ラップされる鍵に対して 20 オクテットの SHA-1 [SHA1] メッセージ ダイジェストを計算する. 2. メッセージダイジェスト値のうち最も重要な(最初の) 8 オクテットをチェック サム値として使用する. 3 3DES 鍵ラッピングとアンラッピング このセクションでは 3DES 鍵を他の 3DES 鍵 [3DES] でラップ・アンラップする際に 使用されるアルゴリズムについて述べる. 2 キー 3DES および 3 キー 3DES 鍵の両方において同じラップアルゴリズムが 使用される. 2 キー 3DES 鍵がラップされる場合, 最初の DES 鍵と同じ値を 持った第三の鍵が生成される. したがって, ラップされた 3DES 鍵は必ず3つの DES 鍵を持つことになる. しかし, 2 キー 3DES 鍵を, 3つのユニークな DES 鍵 から成る 3 キー 3DES 鍵をラップするのに使用してはならない. 3.1 3DES 鍵ラップ 3DES 鍵ラップアルゴリズムは 3DES 鍵を 3DES 鍵暗号化鍵で暗号化する. 3DES 鍵 ラップアルゴリズムは: 1. ラップする 3 キー 3DES 鍵を構成するそれぞれの DES 鍵オクテットに奇数の パリティをセットする. この結果を CEK と呼ぶ. 2. 8 オクテットのチェックサム値を CEK に対してセクション 2 で述べたように 計算し, その結果を ICV と呼ぶ. 3. CEKICV = CEK || ICV とする. 4. 8 オクテットをランダムに生成し, この結果を IV と呼ぶ. 5. CEKICV を CBC モードで鍵暗号化鍵によって暗号化する. 前のステップで 生成したランダム値を初期化ベクトル (IV) として使用する. この結果を 暗号文 TEMP1 と呼ぶ. 6. TEMP2 = IV || TEMP1 とする. 7. TEMP2 のオクテットの順序を逆にする. つまり, 最も重要な (最初の) オクテットが最も重要でない (最後の) オクテットと交換される. 以下同様で ある. この結果を TEMP3 と呼ぶ. 8. TEMP3 を CBC モードで鍵暗号化鍵によって暗号化する. 初期化ベクトル (IV) として 0x4adda22c79e82105 を使用する. この暗号文の長さは 40 オクテット である. Housley 情報提供 [Page 2] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 注: 同じ 3 キー 3DES 鍵が異なる鍵暗号化鍵でラップされる場合, 新しい 初期化ベクトル (IV) がそれぞれの新しいキーラップアルゴリズムに対して生成 されなければならない. 3.2 3DES キーアンラップ 3DES キーアンラップアルゴリズムは 3DES 鍵暗号化鍵を使用して 3DES 鍵を復号 する. 3DES キーアンラップアルゴリズムは: 1. ラップされた鍵が 40 オクテットでなければエラーとなる. 2. 鍵暗号化鍵を使って CBC モードでラップされた鍵を復号する. 初期化ベクトル (IV) として 0x4adda22c79e82105 を使用する. アウトプットを TEMP3 と呼ぶ. 3. TEMP3 のオクテットの順序を逆にする. つまり, 最も重要な (最初の) オクテットが最も重要でない (最後の) オクテットと交換される. 以下同様で ある. この結果を TEMP2 と呼ぶ. 4. TEMP2 を IV と TEMP1 に分解する. IV は最も重要な(最初の) 8 オクテット で, TEMP1 は最も重要でない(最後の) 32 オクテットである. 5. TEMP1 を CBC モードで鍵暗号化鍵によって復号する. 前段階で得られた IV 値を初期化ベクトルとして使用する. この暗号文を CEKICV と呼ぶ. 6. CEKICV を CEK と ICV に分解する. CEK は最も重要な(最初の) 24オクテット であり, ICV は最も重要でない(最後の) 8 オクテットである. 7. 上記セクション2で述べたように CEK に対して 8 オクテットのキーチェック サム値を計算する. もし計算されたキーチェックサム値が復号されたキー チェックサム値, ICV と合わなければエラーとなる. 8. CEK を構成する DES 鍵のそれぞれの奇数パリティをチェックする. もし パリティが正しくなければエラーとなる. 9. CEK を 3DES 鍵として使用する. 3.3 3DES キーラップアルゴリズム識別子 いくつかのセキュリティプロトコルは ASN.1 [X.208-88, X.209-88] を採用して おり, これらのプロトコルは暗号化アルゴリズムに名前をつけるために アルゴリズム識別子を採用している. これらのアルゴリズムをサポートする ために, 3DES キーラップアルゴリズムは以下のアルゴリズム識別子を割り当て られた: id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } AlgorithmIdentifier パラメータフィールドは NULLでなければならない. Housley 情報提供 [Page 3] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 3.4 3DES キーラップ例 このセクションでは 3DES キーラップの例を挙げる. セクション 3.1 で名付け られたアイテムに対応する中間値は16進数表記されている. CEK: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 KEK: 255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838 251f ICV: 181b 7e96 86e0 4a4e CEKICV: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 181b 7e96 86e0 4a4e IV: 5dd4 cbfc 96f5 453b TEMP1: cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 973b 7a79 60f6 a44d cc5f 729d 8449 TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 973b 7a79 60f6 a44d cc5f 729d 8449 TEMP3: 4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4 2add 75c6 89a7 c1cf 3b45 f596 fccb d45d RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403 7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4 4 RC2 キーラッピングとアンラッピング このセクションでは RC2 鍵を他の RC2 鍵 [RC2] でラップ・アンラップする際に 使用されるアルゴリズムについて述べる. RC2 は可変長鍵をサポートする. RC2 の 128 ビット鍵が鍵暗号化鍵として使用 されなければならないが, ラップされる RC2 鍵はいかなる長さでもよい. 4.1 RC2 キーラップ RC2 キーラップアルゴリズムは RC2 鍵を RC2 鍵暗号化鍵で暗号化する. RC2 キーラップアルゴリズムは: 1. RC2 鍵を CEK と呼び, CEK のオクテット長を LENGTH と呼ぶ. LENGTH は 1 オクテットである. 2. LCEK = LENGTH || CEK とする. 3. LCEKPAD = LCEK || PAD とする. もし LCEK の長さが 8 の倍数ならば PAD の 長さは 0 である. もし LCEK の長さが 8 の倍数でなかったら, PAD には LCEKPAD の長さを 8 の倍数にするランダムなオクテットのうちの最小の数が 入る. 4. LCEKPAD に対してセクション 2 で述べたように 8 オクテットのキーチェック サム値を計算し, この結果を ICV と呼ぶ. 5. LCEKPADICV = LCEKPAD || ICV とする. 6. ランダムに 8 オクテットを生成し, その結果を IVと呼ぶ. 7. LCEKPADICV を CBC モードで鍵暗号化鍵によって暗号化する. 前のステップで 生成したランダム値を初期化ベクトル (IV) として使用するこの暗号文を TEMP1 と呼ぶ. Housley 情報提供 [Page 4] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 8. TEMP2 = IV || TEMP1 とする. 9. TEMP2 のオクテットの順序を逆にする. つまり, 最も重要な (最初の) オクテットが最も重要でない (最後の) オクテットと交換される. 以下同様 である. この結果を TEMP3 と呼ぶ. 10. TEMP3 を CBC モードで鍵暗号化鍵によって暗号化する. 初期化ベクトル (IV) として 0x4adda22c79e82105 を使用する. この暗号文の長さは 40 オクテットである. 注: 同じ RC2 鍵が別の鍵暗号化鍵でラップされる場合は, 新しい初期化 ベクトル (IV) がそれぞれのキーラップアルゴリズムのために生成され なければならない. 4.2 RC2 キーアンラップ RC2 キーアンラップアルゴリズムは RC2 鍵を RC2鍵暗号化鍵を使用して復号する. RC2 キーアンラップアルゴリズムは: 1. ラップされた鍵が 8 オクテットの倍数でない場合はエラーとなる. 2. ラップされた鍵暗号化鍵を使用して CBC モードで復号する. 初期化ベクトル (IV) として 0x4adda22c79e82105 を使用する. アウトプットを TEMP3 と呼ぶ. 3. TEMP3 のオクテットの順序を逆にする. つまり, 最も重要な (最初の) オクテットが最も重要でない (最後の) オクテットと交換される. 以下同様で ある. この結果を TEMP2 と呼ぶ. 4. TEMP2 を IV と TEMP1 に分解する. IV は最も重要な(最初の) 8 オクテット で, TEMP1 はその残りである. 5. TEMP1 を CBC モードで鍵暗号化鍵によって復号する. 前のステップで 得られた IV 値を初期化ベクトルとして使用する. この平文を LCEKPADICV と 呼ぶ. 6. LCEKPADICV を LCEKPAD と ICV に分解する. ICV は最も重要でない(最後の) 8 オクテットである. LCEKPAD はその残りのオクテットである. 7. LCEKPAD に対してセクション2で述べられたように 8 オクテットのキー チェックサム値を計算する. 計算されたキーチェックサム値が復号された キーチェックサム値 ICV と合わない場合はエラーとなる. 8. LCEKPAD を LENGTH, CEK, PAD に分解する.. LENGTH は最も重要な(最初の) オクテットである. CEK は それに続く LENGTH の長さのオクテットである. もしあればその残りのオクテットが PAD になる. 9. PAD の長さが 7 オクテット以上であればエラーとなる. 10. CEK を RC2 鍵として使用する. 4.3 RC2 キーラップアルゴリズム識別子 いくつかのセキュリティプロトコルは ASN.1 [X.208-88, X.209-88] を採用して おり, これらのプロトコルは暗号化アルゴリズムに名前をつけるために アルゴリズム識別子を採用している. これらのアルゴリズムをサポートする ために, RC2 キーラップアルゴリズムは以下のアルゴリズム識別子を割り当て られた: Housley 情報提供 [Page 5] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } AlgorithmIdentifier パラメータフィールドは RC2wrapParameter でなければ ならない: RC2wrapParameter ::= RC2ParameterVersion RC2ParameterVersion ::= INTEGER RC2 の有効キービット(キーサイズ) 32 ビット以上 256 ビット以下は RC2ParameterVersion でエンコードされる. 有効キービットのうち 40, 64, 128 ビットでは, rc2ParameterVersion はそれぞれ 160, 120, 58 ビット である. これらの値は単純に RC2 のキー長ではない. 値 160 に関しては 2 オクテット(00 A0) としてエンコードされなければならないことに 注意しなければならない. これは, 1 オクテット (A0) エンコーディングは 負数を表すからである. 4.4 RC2 キーラップ例 このセクションでは RC2 キーラップの例を挙げる. セクション 4.1 で名付け られたアイテムに対応する中間値は16進数表記されている. CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9 KEK: fd04 fd08 0607 07fb 0003 feff fd02 fe05 LENGTH: 10 LCEK: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9 PAD: 4845 cce7 fd12 50 LCEKPAD: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d948 45cc e7fd 1250 ICV: 0a6f f19f db40 4988 LCEKPADICV: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d948 45cc e7fd 1250 0a6f f19f db40 4988 IV: c7d9 0059 b29e 97f7 TEMP1: a01d a259 3793 1260 e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7 TEMP2: c7d9 0059 b29e 97f7 a01d a259 3793 1260 e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7 TEMP3: a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac b870 ce04 f555 8ce4 6012 9337 59a2 1da0 f797 9eb2 5900 d9c7 RESULT: 70e6 99fb 5701 f783 3330 fb71 e87c 85a4 20bd c99a f05d 22af 5a0e 48d3 5f31 3898 6cba afb4 b28d 4f35 Housley 情報提供 [Page 6] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 5 参考文献 [3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [DES] American National Standards Institute. ANSI X3.106, "American National Standard for Information Systems - Data Link Encryption". 1983. [DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994. [MODES] National Institute of Standards and Technology. FIPS Pub 81: DES Modes of Operation. 2 December 1980. [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RC2] Rivest, R., "A Description of the RC2 (r) Encryption Algorithm", RFC 2268, March 1998. [SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988. [X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988. Housley 情報提供 [Page 7] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 6 セキュリティに関する考察 導入に際しては鍵暗号化鍵を保護しなければならない. 鍵暗号化鍵が奪われると, その鍵暗号化鍵でラップされた鍵が全てさらされることにもなりかねず, その結果 それらの鍵で守られていた全てのトラフィックがさらされるかもしれない. 導入では, 初期化ベクトル(IV)とパディングをランダムに生成しなければ ならない. 高品質なランダムな数を生成することは難しい. RFC 1750 [RANDOM] においてこの分野における重要な案内が提供されているし, FIPS Pub 186 [DSS] の Appendix 3 では質の高い PRNG テクニックが提供されている. もし鍵暗号化鍵とラップされた鍵が別の対称暗号アルゴリズムで結び付けられて いるとしたら, ラップされた鍵によって暗号化されるデータが提供する セキュリティは2つのアルゴリズムの弱いほうで決定される. 例えばもしデータが 168 ビットの 3DES で暗号化され, その 3DES 鍵が 40 ビット RC2 鍵でラップ されているとしたら, たかだか 40 ビットの強度しか得られない. 40 ビット RC2 鍵の値を見つけ出せば, 3 DES が発見され, その 3DES 鍵によってコンテントが 復号される. したがって, 導入する人はコンテント暗号化アルゴリズムと同じ くらいかあるいはより強度の高い鍵暗号化アルゴリズムを保証しなければならない. 本文書で述べたこれらのキーラップアルゴリズムは, 3DES と RC2 を使用する ために確認たが, 他のアルゴリズムについては確認されていない. 同様に, CBC モード [MODES] を使用するキーラップアルゴリズムについては確認 したが, 他の暗号化モードの使用では確認していない. 7 謝辞 本文書は多くのプロフェッショナルの方々の貢献の結果である. IETF S/MIME ワーキンググループの全てのメンバーのhard workに感謝する. とりわけ, Carl Ellison, Peter Gutmann, Bob Jueneman, Don Johnson, Burt Kaliski, John Pawling, Jim Schaad には, アルゴリズムの定義とこの文書の執筆において サポートをしてくれたことに感謝する. 8 著者の連絡先 Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: rhousley@rsasecurity.com Housley 情報提供 [Page 8] RFC 3217 3DES と RC2 のキーラッピング 2001年12月 9 著作権表示全文 Copyright (C) The Internet Society (2001). 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. 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. Housley 情報提供 [Page 9]