RFC3537 日本語訳

Network Working Group                                          J. Schaad
Request for Comments: 3537                       Soaring Hawk Consulting
Category: Standards Track                                     R. Housley
                                                          Vigil Security
                                                                May 2003

Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: カテゴリに相談する3537年の高く昇っているタカ: 標準化過程R.Housley不寝番セキュリティ2003年5月

       Wrapping a Hashed Message Authentication Code (HMAC) key
           with a Triple-Data Encryption Standard (DES) Key
             or an Advanced Encryption Standard (AES) Key

Triple-データ暗号化規格(DES)キーかエー・イー・エス(AES)キーによって主要なHashedメッセージ立証コード(HMAC)を包装します。

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document defines two methods for wrapping an HMAC (Hashed
   Message Authentication Code) key.  The first method defined uses a
   Triple DES (Data Encryption Standard) key to encrypt the HMAC key.
   The second method defined uses an AES (Advanced Encryption Standard)
   key to encrypt the HMAC key.  One place that such an algorithm is
   used is for the Authenticated Data type in CMS (Cryptographic Message
   Syntax).

このドキュメントはHMAC(メッセージ立証コードを論じ尽くす)キーを包装するための2つの方法を定義します。 定義された最初の方法はHMACキーをコード化するために主要なTriple DES(データ暗号化規格)を使用します。 定義された2番目の方法はHMACキーをコード化するために主要なAES(エー・イー・エス)を使用します。 使用されるそのようなアルゴリズムがCMS(暗号のMessage Syntax)のAuthenticated Dataタイプのためのものである1つの場所。

1. Introduction

1. 序論

   Standard methods exist for encrypting a Triple-DES (3DES) content-
   encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES-
   WRAP], and for encrypting an AES CEK with an AES KEK [AES-WRAP].
   Triple-DES key wrap imposes parity restrictions, and in both
   instances there are restrictions on the size of the key being wrapped
   that make the encryption of HMAC [HMAC] keying material difficult.

標準方法は、Triple-DES(3DES)の満足している暗号化3DESの主要な暗号化によって主要な(CEK)キー(KEK)[3DES WRAP]をコード化して、AES KEK[AES-WRAP]と共にAES CEKをコード化するために存在しています。 三重のDESの主要な包装はパリティ制限を課します、そして、両方の例には、包装されるキーのサイズにおける材料を合わせるHMAC[HMAC]の暗号化を難しくする制限があります。

   This document specifies a mechanism for the encryption of an HMAC key
   of arbitrary length by a 3DES KEK or an AES KEK.

このドキュメントは3DES KEKかAES KEKによる任意の長さのHMACキーの暗号化にメカニズムを指定します。

Schaad & Housley            Standards Track                     [Page 1]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[1ページ]RFC3537HMAC

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [STDWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[STDWORDS]で説明されるように本書では解釈されることであるべきです。

2. HMAC Key Guidelines

2. HMACの主要なガイドライン

   [HMAC] suggests that the key be at least as long as the output (L) of
   the hash function being used.  When keys longer than the block size
   of the hash algorithm are used, they are hashed and the resulting
   hash value is used.  Using keys much longer than L provides no
   security benefit, unless the random function used to create the key
   has low entropy output.

[HMAC]は、キーが使用されるハッシュ関数の出力(L)と少なくとも同じくらい長いと示唆します。 細切れ肉料理アルゴリズムのブロック・サイズより長いキーが使用されているとき、それらは論じ尽くされます、そして、結果として起こるハッシュ値は使用されています。 キーを作成するのに使用される確率関数が低いエントロピー出力を持っていない場合、Lがセキュリティ利益を全く提供しないよりはるかに長い間、キーを使用します。

3. HMAC Key Wrapping and Unwrapping with Triple-DES

3. HMACの主要なラッピングと三重のDESと共に開けること。

   This section specifies the algorithms for wrapping and unwrapping an
   HMAC key with a 3DES KEK [3DES].

このセクションは3DES KEK[3DES]によって主要なHMACを包装して、開けるためのアルゴリズムを指定します。

   The 3DES wrapping of HMAC keys is based on the algorithm defined in
   Section 3 of [3DES-WRAP].  The major differences are due to the fact
   that an HMAC key is of variable length and the HMAC key has no
   particular parity.

HMACキーの3DESラッピングは[3DES-WRAP]のセクション3で定義されたアルゴリズムに基づいています。 主要な違いはHMACキーが可変長のものであり、HMACキーにはどんな特別の同等もないという事実のためです。

   In the algorithm description, "a || b" is used to represent 'a'
   concatenated with 'b'.

アルゴリズム記述、「a」で|| 「b」は、'b'で連結された'a'を表すのに使用されます。

3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key

3.1 三重のDES主要な暗号化キーによって主要なHMACを包装すること。

   This algorithm encrypts an HMAC key with a 3DES KEK.  The algorithm
   is:

このアルゴリズムは3DES KEKによって主要なHMACをコード化します。 アルゴリズムは以下の通りです。

   1.  Let the HMAC key be called KEY, and let the length of KEY in
       octets be called LENGTH.  LENGTH is a single octet.

1. HMACキーをKEYと呼ばせてください、そして、八重奏における、KEYの長さをLENGTHと呼ばせてください。 LENGTHはただ一つの八重奏です。

   2.  Let LKEY = LENGTH || KEY.

2. LKEYに長さと等しくしいさせてください。|| 主要。

   3.  Let LKEYPAD = LKEY || PAD.  If the length of LKEY is a multiple
       of 8, the PAD has a length of zero.  If the length of LKEY is not
       a multiple of 8, then PAD contains the fewest number of random
       octets to make the length of LKEYPAD a multiple of 8.

3. LKEYPADにLKEYと等しくしいさせてください。|| そっと歩いてください。 LKEYの長さが8の倍数であるなら、PADには、ゼロの長さがあります。 LKEYの長さが8の倍数でないなら、PADはLKEYPADの長さを8の倍数にする最も数数の無作為の八重奏を含んでいます。

   4.  Compute an 8 octet key checksum value on LKEYPAD as described in
       Section 2 of [3DES-WRAP], call the result ICV.

4. [3DES-WRAP]のセクション2で説明されるようにLKEYPADで8の八重奏の主要なチェックサム価値を計算してください、そして、ICVに結果に電話をしてください。

   5.  Let LKEYPADICV = LKEYPAD || ICV.

5. LKEYPADICVにLKEYPADと等しくしいさせてください。|| ICV。

   6.  Generate 8 octets at random, call the result IV.

6. 8つの八重奏を無作為に発生させてください、そして、結果IVに電話をしてください。

Schaad & Housley            Standards Track                     [Page 2]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[2ページ]RFC3537HMAC

   7.  Encrypt LKEYPADICV in CBC mode using the 3DES KEK.  Use the
       random value generated in the previous step as the initialization
       vector (IV).  Call the ciphertext TEMP1.

7. 3DES KEKを使用して、CBCモードでLKEYPADICVをコード化してください。 初期化ベクトル(IV)として前のステップで発生する無作為の値を使用してください。 TEMP1に暗号文に電話をしてください。

   8.  Let TEMP2 = IV || TEMP1.

8. TEMP2にIVと等しくしいさせてください。|| TEMP1。

   9.  Reverse the order of the octets in TEMP2.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP3.

9. TEMP2での八重奏の注文を逆にしてください。 すなわち、最も重要な(最初に)八重奏は最も重要でない(最後)八重奏などで交換されます。 TEMP3に結果に電話をしてください。

   10. Encrypt TEMP3 in CBC mode using the 3DES KEK.  Use an
       initialization vector (IV) of 0x4adda22c79e82105.

10. 3DES KEKを使用して、CBCモードでTEMP3をコード化してください。 0x4adda22c79e82105の初期化ベクトル(IV)を使用してください。

   Note:  When the same HMAC key is wrapped in different 3DES KEKs, a
   fresh initialization vector (IV) must be generated for each
   invocation of the HMAC key wrap algorithm (step 6).

以下に注意してください。 同じHMACキーが異なった3DES KEKsで包装されるとき、新鮮な初期化ベクトル(IV)はHMACの主要な包装アルゴリズム(ステップ6)の各実施のために発生しなければなりません。

3.2  Unwrapping an HMAC Key with a Triple-DES Key-Encryption Key

3.2 三重のDES主要な暗号化キーによって主要なHMACを開けること。

   This algorithm decrypts an HMAC key using a 3DES KEK.  The algorithm
   is:

このアルゴリズムは、3DES KEKを使用することでHMACキーを解読します。 アルゴリズムは以下の通りです。

   1.  If the wrapped key is not a multiple of 8 octets, then error.

1. 包装されたキーが8つの八重奏の倍数でないなら、そして、誤りです。

   2.  Decrypt the wrapped key in CBC mode using the 3DES KEK.  Use an
       initialization vector (IV) of 0x4adda22c79e82105.  Call the
       output TEMP3.

2. 3DES KEKを使用して、CBCモードで包装されたキーを解読してください。 0x4adda22c79e82105の初期化ベクトル(IV)を使用してください。 TEMP3に出力に電話をしてください。

   3.  Reverse the order of the octets in TEMP3.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP2.

3. TEMP3での八重奏の注文を逆にしてください。 すなわち、最も重要な(最初に)八重奏は最も重要でない(最後)八重奏などで交換されます。 TEMP2に結果に電話をしてください。

   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
       significant (first) 8 octets, and TEMP1 is composed of the
       remaining octets.

4. IVとTEMP1にTEMP2を分解してください。 IVは最も重要な(最初に)8つの八重奏です、そして、TEMP1は残っている八重奏で構成されます。

   5.  Decrypt TEMP1 in CBC mode using the 3DES KEK.  Use the IV value
       from the previous step as the initialization vector.  Call the
       plaintext LKEYPADICV.

5. 3DES KEKを使用して、CBCモードでTEMP1を解読してください。 初期化ベクトルとして前のステップからIV値を使用してください。 LKEYPADICVに平文に電話をしてください。

   6.  Decompose the LKEYPADICV into LKEYPAD, and ICV.  ICV is the least
       significant (last) 8 octets.  LKEYPAD is composed of the
       remaining octets.

6. LKEYPAD、およびICVにLKEYPADICVを分解してください。 ICVは最も重要でない(最後)8つの八重奏です。 LKEYPADは残っている八重奏で構成されます。

   7.  Compute an 8 octet key checksum value on LKEYPAD as described in
       Section 2 of [3DES-WRAP].  If the computed key checksum value
       does not match the decrypted key checksum value, ICV, then error.

7. [3DES-WRAP]のセクション2で説明されるようにLKEYPADで8の八重奏の主要なチェックサム価値を計算してください。 計算された主要なチェックサム値が解読された主要なチェックサム値、ICVに合っていないなら、そして、誤りです。

Schaad & Housley            Standards Track                     [Page 3]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[3ページ]RFC3537HMAC

   8.  Decompose the LKEYPAD into LENGTH, KEY, and PAD.  LENGTH is the
       most significant (first) octet.  KEY is the following LENGTH of
       octets.  PAD is the remaining octets, if any.

8. 長さ、キー、およびパッドにLKEYPADを分解してください。 LENGTHは最も重要な(最初に)八重奏です。 KEYは八重奏の以下のLENGTHです。 PADはもしあれば残っている八重奏です。

   9.  If the length of PAD is more than 7 octets, then error.

9. PADの長さが7つ以上の八重奏であるなら、そして、誤りです。

   10. Use KEY as an HMAC key.

10. HMACキーとしてKEYを使用してください。

3.3 HMAC Key Wrap with Triple-DES Algorithm Identifier

3.3 三重のDESアルゴリズム識別子があるHMACの主要な包装

   Some security protocols employ ASN.1 [X.208-88, X.209-88], and these
   protocols employ algorithm identifiers to name cryptographic
   algorithms.  To support these protocols, the HMAC Key Wrap with
   Triple-DES algorithm has been assigned the following algorithm
   identifier:

いくつかのセキュリティプロトコルがASN.1[X.208-88、X.209-88]を使います、そして、これらのプロトコルは暗号アルゴリズムを命名するのにアルゴリズム識別子を使います。これらのプロトコルをサポートするために、以下のアルゴリズム識別子をTriple-DESアルゴリズムがあるHMAC Key Wrapに割り当ててあります:

      id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
          smime(16) alg(3) 11 }

イド-alg-HMACwith3DESwrap物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)11をメンバーと同じくらい具体化させます。

   The AlgorithmIdentifier parameter field MUST be NULL.

AlgorithmIdentifierパラメタ分野はNULLであるに違いありません。

3.4 HMAC Key Wrap with Triple-DES Test Vector

3.4 三重のDESテストベクトルがあるHMACの主要な包装

   KEK          :  5840df6e 29b02af1
                :  ab493b70 5bf16ea1
                :  ae8338f4 dcc176a8

KEK: 5840df6e 29b02af1: ab493b70 5bf16ea1: ae8338f4 dcc176a8

   HMAC_KEY     :  c37b7e64 92584340
                :  bed12207 80894115
                :  5068f738

HMAC_キー: c37b7e64 92584340: bed12207 80894115: 5068f738

   IV           :  050d8c79 e0d56b75

IV: 050d8c79 e0d56b75

   PAD          :  38be62

以下を水増ししてください。 38be62

   ICV          :  1f363a31 cdaa9037

ICV: 1f363a31 cdaa9037

   LKEYPADICV   :  14c37b7e 64925843
                :  40bed122 07808941
                :  155068f7 38be62fe
                :  1f363a31 cdaa9037

LKEYPADICV: 14c37b7e64925843: 40bed122 07808941: 155068f7 38be62fe: 1f363a31 cdaa9037

   TEMP1        :  157a8210 f432836b
                :  a618b096 475c864b
                :  6612969c dfa445b1
                :  5646bd00 500b2cc1

TEMP1: 157a8210 f432836b: a618b096 475c864b: 6612969c dfa445b1: 5646bd00 500b2cc1

Schaad & Housley            Standards Track                     [Page 4]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[4ページ]RFC3537HMAC

   TEMP3        :  c12c0b50 00bd4656
                :  b145a4df 9c961266
                :  4b865c47 96b018a6
                :  6b8332f4 10827a15
                :  756bd5e0 798c0d05

TEMP3: c12c0b50 00bd4656: b145a4df 9c961266: 4b865c47 96b018a6: 6b8332f4 10827a15: 756bd5e0 798c0d05

   Wrapped Key  :  0f1d715d 75a0aaf6
                :  6f02e371 c08b79e2
                :  a1253dc4 3040136b
                :  dc161118 601f2863
                :  e2929b3b dd17697c

キーを包装します: 0f1d715d 75a0aaf6: 6f02e371 c08b79e2: a1253dc4 3040136b: dc161118 601f2863: e2929b3b dd17697c

4. HMAC Key Wrapping and Unwrapping with AES

4. HMACの主要なラッピングとAESと共に開けること。

   This section specifies the algorithms for wrapping and unwrapping an
   HMAC key with an AES KEK [AES-WRAP].

このセクションはAES KEK[AES-WRAP]によって主要なHMACを包装して、開けるためのアルゴリズムを指定します。

   The AES wrapping of HMAC keys is based on the algorithm defined in
   [AES-WRAP].  The major difference is inclusion of padding due to the
   fact that the length of an HMAC key may not be a multiple of 64 bits.

HMACキーのAESラッピングは[AES-WRAP]で定義されたアルゴリズムに基づいています。 主要な違いはHMACキーの長さが64ビットの倍数でないかもしれないという事実のためそっと歩く包含です。

   In the algorithm description, "a || b" is used to represent 'a'
   concatenated with 'b'.

アルゴリズム記述、「a」で|| 「b」は、'b'で連結された'a'を表すのに使用されます。

4.1 Wrapping an HMAC Key with an AES Key-Encryption Key

4.1 AES主要な暗号化キーによって主要なHMACを包装すること。

   This algorithm encrypts an HMAC key with an AES KEK.  The algorithm
   is:

このアルゴリズムはAES KEKによって主要なHMACをコード化します。 アルゴリズムは以下の通りです。

   1.  Let the HMAC key be called KEY, and let the length of KEY in
       octets be called LENGTH.  LENGTH is a single octet.

1. HMACキーをKEYと呼ばせてください、そして、八重奏における、KEYの長さをLENGTHと呼ばせてください。 LENGTHはただ一つの八重奏です。

   2.  Let LKEY = LENGTH || KEY.

2. LKEYに長さと等しくしいさせてください。|| 主要。

   3.  Let LKEYPAD = LKEY || PAD.  If the length of LKEY is a multiple
       of 8, the PAD has a length of zero.  If the length of LKEY is not
       a multiple of 8, then PAD contains the fewest number of random
       octets to make the length of LKEYPAD a multiple of 8.

3. LKEYPADにLKEYと等しくしいさせてください。|| そっと歩いてください。 LKEYの長さが8の倍数であるなら、PADには、ゼロの長さがあります。 LKEYの長さが8の倍数でないなら、PADはLKEYPADの長さを8の倍数にする最も数数の無作為の八重奏を含んでいます。

   4.  Encrypt LKEYPAD using the AES key wrap algorithm specified in
       section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption
       key.  The result is 8 octets longer than LKEYPAD.

4. .1セクション2.2[AES-WRAP]で指定されたAESの主要な包装アルゴリズムを使用して、LKEYPADをコード化してください、暗号化キーとしてAES KEKを使用して。 LKEYPADより八重奏長い間、結果は8です。

Schaad & Housley            Standards Track                     [Page 5]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[5ページ]RFC3537HMAC

4.2  Unwrapping an HMAC Key with an AES Key

4.2 AESキーによって主要なHMACを開けること。

   The AES key unwrap algorithm decrypts an HMAC key using an AES KEK.
   The AES key unwrap algorithm is:

AESキーは開けられます。アルゴリズムは、HMACがキーであるとAES KEKを使用することで解読します。 AESキーは開けられます。アルゴリズムは以下の通りです。

   1.  If the wrapped key is not a multiple of 8 octets, then error.

1. 包装されたキーが8つの八重奏の倍数でないなら、そして、誤りです。

   2.  Decrypt the wrapped key using the AES key unwrap algorithm
       specified in section 2.2.2 of [AES-WRAP], using the AES KEK as
       the decryption key.  If the unwrap algorithm internal integrity
       check fails, then error, otherwise call the result LKEYPAD.

2. .2セクション2.2[AES-WRAP]で指定されたアルゴリズムを開けて、復号化キーとしてAES KEKを使用することでAESキーを使用して、包装されたキーを解読してください。 内部の保全チェックが失敗するアルゴリズム、当時の誤りを開けてください。さもなければ、LKEYPADに結果に電話をしてください。

   3.  Decompose the LKEYPAD into LENGTH, KEY, and PAD.  LENGTH is the
       most significant (first) octet.  KEY is the following LENGTH of
       octets.  PAD is the remaining octets, if any.

3. 長さ、キー、およびパッドにLKEYPADを分解してください。 LENGTHは最も重要な(最初に)八重奏です。 KEYは八重奏の以下のLENGTHです。 PADはもしあれば残っている八重奏です。

   4.  If the length of PAD is more than 7 octets, then error.

4. PADの長さが7つ以上の八重奏であるなら、そして、誤りです。

   5.  Use KEY as an HMAC key.

5. HMACキーとしてKEYを使用してください。

4.3 HMAC Key Wrap with AES Algorithm Identifier

4.3 AESアルゴリズム識別子があるHMACの主要な包装

   Some security protocols employ ASN.1 [X.208-88, X.209-88], and these
   protocols employ algorithm identifiers to name cryptographic
   algorithms.  To support these protocols, the HMAC Key Wrap with AES
   algorithm has been assigned the following algorithm identifier:

いくつかのセキュリティプロトコルがASN.1[X.208-88、X.209-88]を使います、そして、これらのプロトコルは暗号アルゴリズムを命名するのにアルゴリズム識別子を使います。これらのプロトコルをサポートするために、以下のアルゴリズム識別子をAESアルゴリズムがあるHMAC Key Wrapに割り当ててあります:

      id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
          smime(16) alg(3) 12 }

イド-alg-HMACwithAESwrap物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)12をメンバーと同じくらい具体化させます。

   The AlgorithmIdentifier parameter field MUST be NULL.

AlgorithmIdentifierパラメタ分野はNULLであるに違いありません。

4.4 HMAC Key Wrap with AES Test Vector

4.4 AESテストベクトルがあるHMACの主要な包装

   KEK          :  5840df6e 29b02af1
                :  ab493b70 5bf16ea1
                :  ae8338f4 dcc176a8

KEK: 5840df6e 29b02af1: ab493b70 5bf16ea1: ae8338f4 dcc176a8

   HMAC_KEY     :  c37b7e64 92584340
                :  bed12207 80894115
                :  5068f738

HMAC_キー: c37b7e64 92584340: bed12207 80894115: 5068f738

   PAD          :  050d8c

以下を水増ししてください。 050d8c

   LKEYPAD      :  14c37b7e 64925843
                :  40bed122 07808941
                :  155068f7 38050d8c

LKEYPAD: 14c37b7e64925843: 40bed122 07808941: 155068f7 38050d8c

Schaad & Housley            Standards Track                     [Page 6]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[6ページ]RFC3537HMAC

   Wrapped Key  :  9fa0c146 5291ea6d
                :  b55360c6 cb95123c
                :  d47b38cc e84dd804
                :  fbcec5e3 75c3cb13

キーを包装します: 9fa0c146 5291ea6d: b55360c6 cb95123c: d47b38cc e84dd804: fbcec5e3 75c3cb13

5. Security Considerations

5. セキュリティ問題

   Implementations must protect the key-encryption key (KEK).
   Compromise of the KEK may result in the disclosure of all HMAC keys
   that have been wrapped with the KEK, which may lead to loss of data
   integrity protection.

実現は主要な暗号化キー(KEK)を保護しなければなりません。 KEKの妥協はデータの喪失保全保護に通じるかもしれないKEKと共に包装されたすべてのHMACキーの公開をもたらすかもしれません。

   The use of these key wrap functions provide confidentiality and data
   integrity, but they do not necessarily provide data origination
   authentication.  Anyone possessing the KEK can create a message that
   passes the integrity check.  If data origination authentication is
   also desired, then the KEK distribution mechanism must provide data
   origin authentication of the KEK.  Alternatively, a digital signature
   may be used.

これらの主要な包装機能の使用は秘密性とデータ保全を提供しますが、それらは必ず入力データ作成認証を提供するというわけではありません。 KEKを所有しているだれでも保全チェックを通過するメッセージを作成できます。 また、入力データ作成認証が望まれているなら、KEK分配メカニズムはKEKのデータ起源認証を提供しなければなりません。 あるいはまた、デジタル署名は使用されるかもしれません。

   Implementations must randomly generate initialization vectors (IVs)
   and padding.  The generation of quality random numbers is difficult.

実現は初期化ベクトル(IVs)と詰め物を手当たりしだいに発生させなければなりません。 上質の乱数の世代は難しいです。

   RFC 1750 [RANDOM] offers important guidance in this area, and
   Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.

RFC1750[RANDOM]はこの領域で重要な指導を提供します、そして、FIPS Pub186[DSS]のAppendix3は1つの上質のPRNGのテクニックを提供します。

   The key wrap algorithms specified in this document have been reviewed
   for use with Triple-DES and AES, and have not been reviewed for use
   with other encryption algorithms.

本書では指定された主要な包装アルゴリズムは、使用のためにTriple-DESとAESと共に見直されて、使用のために他の暗号化アルゴリズムで見直されていません。

6. References

6. 参照

6.1  Normative References

6.1 標準の参照

   [3DES]      American National Standards Institute.  ANSI X9.52-1998,
               Triple Data Encryption Algorithm Modes of Operation.
               1998.

[3DES]American National Standards Institut。 ANSI X9.52-1998、データ暗号化アルゴリズム運転モードを3倍にしてください。 1998.

   [3DES-WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
               December 2001.

[3DES-包装]Housley、R.、「三重のDESとRC2の主要なラッピング」、RFC3217、2001年12月。

   [AES]       National Institute of Standards and Technology. FIPS Pub
               197: Advanced Encryption Standard (AES). 26 November
               2001.

[AES]米国商務省標準技術局。 FIPSパブ197: エー・イー・エス(AES)。 2001年11月26日。

   [AES-WRAP]  Schaad, J. and R. Housley, "Advanced Encryption Standard
               (AES) Key Wrap Algorithm", RFC 3394, September 2002.

[AES-包装] SchaadとJ.とR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、2002年9月。

Schaad & Housley            Standards Track                     [Page 7]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[7ページ]RFC3537HMAC

   [HMAC]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
               Hashing for Message Authentication", RFC 2104, February
               1997.

[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。

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

[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

6.2 Informative References

6.2 有益な参照

   [DSS]       National Institute of Standards and Technology. FIPS Pub
               186: Digital Signature Standard.  19 May 1994.

[DSS]米国商務省標準技術局。 FIPSパブ186: デジタル署名基準。 1994年5月19日。

   [RANDOM]    Eastlake 3rd, D., Crocker, S. and J. Schiller,
               "Randomness Recommendations for Security", RFC 1750,
               December 1994.

[無作為の] イーストレーク3番目とD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。

   [RFC2026]   Bradner, S., "The Internet Standards Process - Revision
               3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

   [X.208-88]  CCITT.  Recommendation X.208: Specification of Abstract
               Syntax Notation One (ASN.1).  1988.

[X.208-88]CCITT。 推薦X.208: 抽象構文記法1(ASN.1)の仕様。 1988.

   [X.209-88]  CCITT.  Recommendation X.209: Specification of Basic
               Encoding Rules for Abstract Syntax Notation One (ASN.1).
               1988.

[X.209-88]CCITT。 推薦X.209: 基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます。 1988.

7. Authors' Addresses

7. 作者のアドレス

   Jim Schaad
   Soaring Hawk Consulting

ジムSchaad Soaringはコンサルティングを襲います。

   EMail: jimsch@exmsft.com

メール: jimsch@exmsft.com

   Russell Housley
   Vigil Security
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

ラッセルHousley不寝番セキュリティ918は小山Driveヴァージニア20170ハーンドン(米国)を跳ばせます。

   EMail: housley@vigilsec.com

メール: housley@vigilsec.com

Schaad & Housley            Standards Track                     [Page 8]

RFC 3537                     HMAC Key Wrap                      May 2003

包装2003年5月に主要なSchaad&Housley標準化過程[8ページ]RFC3537HMAC

8. Full Copyright Statement

8. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

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

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

Schaad & Housley            Standards Track                     [Page 9]

Schaad&Housley標準化過程[9ページ]