[要約] RFC 5649は、Advanced Encryption Standard (AES) Key Wrap with Padding Algorithmに関する技術文書です。このRFCは、AES Key Wrapアルゴリズム（RFC 3394で定義）を拡張し、鍵の長さが64ビットの倍数でない場合にも対応できるようにパディングを導入します。この拡張により、さまざまな長さの鍵を安全にラップ（暗号化）およびアンラップ（復号）することが可能になります。主に鍵管理の文脈で利用され、異なるシステム間での鍵の安全な交換をサポートします。関連するRFCには、AES Key Wrapの基本を定義するRFC 3394があります。
Network Working Group R. Housley
Request for Comments: 5649 Vigil Security
Category: Informational M. Dworkin
NIST
August 2009
Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
パディングアルゴリズムを用いたAESキーラップ
Abstract
概要
This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped.
このドキュメントは、RFC 3394で指定されたAESキーラップアルゴリズムで使用するパディング規約を規定しています。この規約により、ラップされる鍵の長さが64ビットの倍数でなければならないという要件がなくなり、実用的な任意の長さの鍵をラップできるようになります。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供するものです。いかなる種類のインターネット標準も規定しません。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンス通知
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。このドキュメントに関する権利と制限が説明されていますので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストを含める必要があり、BSDライセンスに記載されているように保証なしで提供されます。
Management of cryptographic keys often leads to situations where one symmetric key is used to encrypt and integrity-protect another key, which can be either a symmetric key or an asymmetric key. The operation is often called key wrapping.
暗号鍵の管理においては、ある対称鍵を使用して別の鍵（対称鍵または非対称鍵）を暗号化し、完全性を保護するという状況が頻繁に発生します。この操作は、しばしばキーラッピングと呼ばれます。
This document specifies an extension of the Advanced Encryption Standard (AES) Key Wrap algorithm [AES-KW1, AES-KW2]. Without this extension, the input to the AES Key Wrap algorithm, called the key data, must be a sequence of two or more 64-bit blocks.
このドキュメントは、高度な暗号化標準（AES）キーラップアルゴリズム[AES-KW1、AES-KW2]の拡張を指定しています。この拡張機能がなければ、キーデータと呼ばれるAESキーラップアルゴリズムへの入力は、2つ以上の64ビットブロックのシーケンスでなければなりません。
The AES Key Wrap with Padding algorithm can be used to wrap a key of any practical size with an AES key. The AES key-encryption key (KEK) must be 128, 192, or 256 bits. The input key data may be as short as one octet, which will result in an output of two 64-bit blocks (or 16 octets). Although the AES Key Wrap algorithm does not place a maximum bound on the size of the key data that can be wrapped, this extension does so. The use of a 32-bit fixed field to carry the octet length of the key data bounds the size of the input at 2^32 octets. Most systems will have other factors that limit the practical size of key data to much less than 2^32 octets.
パディングアルゴリズムを用いたAESキーラップを使用すると、AES鍵を使用して実用的な任意のサイズの鍵をラップすることができます。AES鍵暗号化鍵（KEK）は、128、192、または256ビットでなければなりません。入力キーデータは最短で1オクテットの場合があり、その結果、2つの64ビットブロック（または16オクテット）の出力が得られます。AESキーラップアルゴリズムは、ラップできるキーデータのサイズに上限を設けていませんが、この拡張では上限を設けています。キーデータのオクテット長を格納するために32ビットの固定フィールドを使用するため、入力サイズの上限は2^32オクテットになります。ほとんどのシステムでは、鍵データの実用的なサイズを2^32オクテットよりもはるかに小さく制限する他の要因があります。
A message length indicator (MLI) is defined as part of an "Alternative Initial Value" in keeping with the statement in Section 2.2.3.2 of [AES-KW1], which says:
メッセージ長インジケーター（MLI）は、[AES-KW1]のセクション2.2.3.2の以下の記述に従い、「代替初期値」の一部として定義されます。
Also, if the key data is not just an AES key, it may not always be a multiple of 64 bits. Alternative definitions of the initial value can be used to address such problems.
また、キーデータが単なるAES鍵ではない場合、それは必ずしも64ビットの倍数であるとは限りません。初期値の代替定義を使用して、そのような問題に対処できます。
The following notation is used in the algorithm descriptions:
次の表記は、アルゴリズムの説明で使用されます。
MSB(j, W) Return the most significant j bits of W
LSB(j, W) Return the least significant j bits of W
ENC(K, B) AES Encrypt the 128-bit block B using key K
DEC(K, B) AES Decrypt the 128-bit block B using key K
V1 | V2 Concatenate V1 and V2
K The key-encryption key
m The number of octets in the key data
n The number of 64-bit blocks in the padded key data
Q[i] The ith plaintext octet in the key data
P[i] The ith 64-bit plaintext block in the padded key data
C[i] The ith 64-bit ciphertext data block
A The 64-bit integrity check register
The Alternative Initial Value (AIV) required by this specification is a 32-bit constant concatenated to a 32-bit MLI. The constant is (in hexadecimal) A65959A6 and occupies the high-order half of the AIV. Note that this differs from the high order 32 bits of the default IV in Section 2.2.3.1 of [AES-KW1], so there is no ambiguity between the two. The 32-bit MLI, which occupies the low-order half of the AIV, is an unsigned binary integer equal to the octet length of the plaintext key data, in network order -- that is, with the most significant octet first. When the MLI is not a multiple of 8, the key data is padded on the right with the least number of octets sufficient to make the resulting octet length a multiple of 8. The value of each padding octet shall be 0 (eight binary zeros).
この仕様に必要な代替初期値（AIV）は、32ビットMLIに連結された32ビット定数です。定数は（16進数で）A65959A6であり、AIVの上位半分を占めています。これは、[AES-KW1]のセクション2.2.3.1のデフォルトIVの上位32ビットとは異なるため、2つの間にあいまいさはありません。AIVの下位半分を占める32ビットMLIは、平文鍵データのオクテット長に等しい符号なしバイナリ整数であり、ネットワークオーダー（つまり、最上位オクテットが先頭）です。MLIが8の倍数でない場合、鍵データは、結果のオクテット長を8の倍数にするのに十分な最小数のオクテットで右側にパディングされます。各パディングオクテットの値は0（8個のバイナリゼロ）でなければなりません。
Notice that for a given number of 64-bit plaintext blocks, there are only eight values of MLI that can have that outcome. For example, the only MLI values that are valid with four 64-bit plaintext blocks are 32 (with no padding octets), 31 (with one padding octet), 30, 29, 28, 27, 26, and 25 (with seven padding octets). When the unwrapping process specified below yields n 64-bit blocks of output data and an AIV, the eight valid values for the MLI are 8*n, (8*n)-1, ..., and (8*n)-7. Therefore, integrity checking of the AIV, which is contained in a 64-bit register called A, requires the following steps:
特定の数の64ビット平文ブロックに対して、その結果になり得るMLIの値は8つしかないことに注意してください。たとえば、4つの64ビット平文ブロックで有効なMLI値は32（パディングオクテットなし）、31（1つのパディングオクテット）、30、29、28、27、26、および25（7つのパディングオクテット）です。以下に指定されたアンラッピングプロセスが出力データの n 個の 64ビットブロックとAIVを生成する場合、MLIの8つの有効な値は 8*n, (8*n)-1, ..., および (8*n)-7 です。したがって、Aと呼ばれる64ビットレジスタに含まれるAIVの整合性チェックには、次の手順が必要です。
1) Check that MSB(32,A) = A65959A6.
1) MSB(32,A) = A65959A6 であることを確認してください。
2) Check that 8*(n-1) < LSB(32,A) <= 8*n. If so, let MLI = LSB(32,A).
2) 8*(n-1) < LSB(32,A) <= 8*n を確認してください。その場合、MLI = LSB(32,A) とします。
3) Let b = (8*n)-MLI, and then check that the rightmost b octets of the output data are zero.
3) b = (8*n)-MLI とし、出力データの右端の b オクテットがゼロであることを確認してください。
If all three checks pass, then the AIV is valid. If any of the checks fail, then the AIV is invalid and the unwrapping operation must return an error.
3つのチェックすべてが合格した場合、AIVは有効です。チェックのいずれかが失敗した場合、AIVは無効であり、アンラップ操作はエラーを返す必要があります。
The AES Key Wrap with Padding algorithm consists of a wrapping process and an unwrapping process, both based on the AES codebook [AES]. It provides an extension to the AES Key Wrap algorithm [AES-KW1, AES-KW2] that eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits. The next two sections specify the wrapping and unwrapping processes, called the extended key wrapping process and the extended key unwrapping process, respectively. These names distinguish these processes from the ones specified in [AES-KW1] and [AES-KW2].
パディングアルゴリズムを用いたAESキーラップは、AESコードブック[AES]に基づいて、ラッピングプロセスとアンラッピングプロセスで構成されています。これは、AESキーラップアルゴリズム[AES-KW1、AES-KW2]の拡張を提供し、キーの長さが64ビットの倍数であるという要件を排除します。次の2つのセクションでは、それぞれ拡張キーラッピングプロセス、拡張キーアンラッピングプロセスと呼ばれるラッピングおよびアンラッピングプロセスを規定します。これらの名前は、これらのプロセスを[AES-KW1]および[AES-KW2]で指定されたプロセスと区別するためのものです。
The inputs to the extended key wrapping process are the KEK and the plaintext to be wrapped. The plaintext consists of between one and 2^32 octets, containing the key data being wrapped. The key wrapping process is described below.
拡張キーラッピングプロセスへの入力は、KEKとラップされる平文です。平文は1〜2^32オクテットで構成され、ラップされる鍵データを含みます。キーラッピングプロセスについては、以下に説明します。
Inputs: Plaintext, m octets {Q[1], Q[2], ..., Q[m]}, and Key, K (the KEK). Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.
入力：平文、m オクテット {Q[1], Q[2], ..., Q[m]}、および 鍵、K（KEK）。出力：暗号文、(n+1) 個の 64ビット値 {C[0], C[1], ..., C[n]}。
1) Append padding
1) パディングの追加
If m is not a multiple of 8, pad the plaintext octet string on the right with octets {Q[m+1], ..., Q[r]} of zeros, where r is the smallest multiple of 8 that is greater than m. If m is a multiple of 8, then there is no padding, and r = m.
mが8の倍数でない場合、平文オクテット列の右側をゼロのオクテット {Q[m+1], ..., Q[r]} でパディングします。ここで、rはmより大きい8の最小倍数です。mが8の倍数の場合、パディングはなく、r = m となります。
Set n = r/8, which is the same as CEILING(m/8).
n = r/8 を設定します。これは CEILING(m/8) と同じです。
For i = 1, ..., n j = 8*(i-1) P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8].
i = 1, ..., n に対して、j = 8*(i-1)、P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8] とします。
2) Wrapping
2) ラッピング (Wrapping)
If the padded plaintext contains exactly eight octets, then prepend the AIV as defined in Section 3 above to P[1] and encrypt the resulting 128-bit block using AES in ECB mode [Modes] with key K (the KEK). In this case, the output is two 64-bit blocks C[0] and C[1]:
パディングされた平文がちょうど8オクテットの場合、上記のセクション3で定義されているAIVをP[1]の前に付加し、キーK（KEK）を使用してECBモード[Modes]のAESで結果の128ビットブロックを暗号化します。この場合、出力は2つの64ビットブロックC[0]とC[1]になります。
C[0] | C[1] = ENC(K, A | P[1]).
C[0] | C[1] = ENC(K, A | P[1])。
Otherwise, apply the wrapping process specified in Section 2.2.1 of [AES-KW2] to the padded plaintext {P[1], ..., P[n]} with K (the KEK) and the AIV as defined in Section 3 above as the initial value. The result is n+1 64-bit blocks {C[0], C[1], ..., C[n]}.
それ以外の場合は、[AES-KW2]のセクション2.2.1で指定されたラッピングプロセスを、K（KEK）と、初期値として上記のセクション3で定義されたAIVを使用して、パディングされた平文 {P[1], ..., P[n]} に適用します。結果は n+1 個の 64ビットブロック {C[0], C[1], ..., C[n]} です。
The inputs to the extended key unwrapping process are the KEK and (n+1) 64-bit ciphertext blocks consisting of a previously wrapped key. If the ciphertext is a validly wrapped key, then the unwrapping process returns n 64-bit blocks of padded plaintext, which are then mapped in this extension to m octets of decrypted key data, as indicated by the MLI embedded in the AIV.
拡張されたキーアンラッピングプロセスへの入力は、以前にラップされたキーで構成されるKEKおよび(n+1)個の64ビット暗号文ブロックです。暗号文が有効にラップされたキーである場合、アンラッピングプロセスは n 個の 64ビットブロックのパディングされた平文を返します。これは、この拡張において、AIVに埋め込まれたMLIで示されるように、m オクテットの復号された鍵データにマッピングされます。
Inputs: Ciphertext, (n+1) 64-bit blocks {C[0], C[1], ..., C[n]}, and Key, K (the KEK). Outputs: Plaintext, m octets {Q[1], Q[2], ..., Q[m]}, or an error.
入力：暗号文、(n+1) 個の 64ビットブロック {C[0], C[1], ..., C[n]}、および 鍵、K（KEK）。出力：平文、m オクテット {Q[1], Q[2], ..., Q[m]}、またはエラー。
1) Key unwrapping
1) キーアンラッピング (Key unwrapping)
When n is one (n=1), the ciphertext contains exactly two 64-bit blocks (C[0] and C[1]), and they are decrypted as a single AES block using AES in ECB mode [Modes] with K (the KEK) to recover the AIV and the padded plaintext key:
nが1（n=1）の場合、暗号文にはちょうど2つの64ビットブロック（C[0]とC[1]）が含まれ、K（KEK）を使用してECBモード[Modes]のAESで単一のAESブロックとして復号化され、AIVとパディングされた平文鍵が復元されます：
A | P[1] = DEC(K, C[0] | C[1]).
A | P[1] = DEC(K, C[0] | C[1])。
Otherwise, apply Steps 1 and 2 of the unwrapping process specified in Section 2.2.2 of [AES-KW2] to the n+1 64-bit ciphertext blocks, {C[0], C[1], ..., C[n]}, and to the KEK, K. Define the padded plaintext blocks, {P[1], ..., P[n]}, as specified in Step 3 of that process, with A[0] as the A value. Note that checking "If A[0] is an appropriate value" is slightly delayed to Step 2 below since the padded plaintext is needed to perform this verification when the AIV is used.
それ以外の場合は、[AES-KW2]のセクション2.2.2で指定されているアンラッププロセスの手順1と2を、n+1 個の 64ビット暗号文ブロック {C[0], C[1], ..., C[n]} および KEK、K に適用します。そのプロセスのステップ3で指定されているように、パディングされた平文ブロック {P[1], ..., P[n]} を定義し、A[0] を A の値とします。「A[0]が適切な値かどうか」の確認は、AIVが使用される場合にこの検証を実行するためにパディングされた平文が必要になるため、以下のステップ2までわずかに先送りされることに注意してください。
2) AIV verification
2) AIV検証 (AIV verification)
Perform the three checks described in Section 3 above on the padded plaintext and the A value. If any of the checks fail, then return an error.
上記のセクション3で説明されている3つのチェックをパディングされた平文とA値で実行します。チェックのいずれかが失敗した場合は、エラーを返します。
3) Remove padding
3) パディングの削除 (Remove padding)
Let m = the MLI value extracted from A.
m = Aから抽出されたMLI値 とします。
Let P = P[1] | P[2] | ... | P[n].
P = P[1] | P[2] | ... | P[n] とします。
For i = 1, ... , m Q[i] = LSB(8, MSB(8*i, P))
i = 1, ... , m に対して Q[i] = LSB(8, MSB(8*i, P))
Some security protocols employ ASN.1 [X.680] and employ algorithm identifiers to name cryptographic algorithms. To support these protocols, the AES Key Wrap with Padding algorithm has been assigned the following algorithm identifiers, one for each AES KEK size. The AES Key Wrap (without padding) algorithm identifiers are also included here for convenience.
一部のセキュリティプロトコルは、ASN.1 [X.680]を採用し、暗号化アルゴリズムに名前を付けるためにアルゴリズム識別子を使用しています。これらのプロトコルをサポートするために、パディングアルゴリズムを使用したAESキーラップには、各AES KEKサイズに1つのアルゴリズム識別子が割り当てられています。AESキーラップ（パディングなし）アルゴリズム識別子も、便宜上ここに含まれています。
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 1 }
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 }
In all cases, the AlgorithmIdentifier parameter field MUST be absent.
いずれの場合も、AlgorithmIdentifierパラメータフィールドは存在してはなりません（MUST be absent）。
The examples in this section were generated using the index-based implementation of the AES Key Wrap algorithm along with the padding approach specified in Section 4 of this document. All values are shown in hexadecimal.
このセクションの例は、このドキュメントのセクション4で指定されたパディングアプローチとともに、AESキーラップアルゴリズムのインデックスベースの実装を使用して生成されました。すべての値は16進数で表示されます。
The first example wraps 20 octets of key data with a 192-bit KEK.
最初の例は、192ビットのKEKで20オクテットの鍵データをラップします。
KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8
KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8
Key : c37b7e6492584340 bed1220780894115 5068f738
Key : c37b7e6492584340 bed1220780894115 5068f738
Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a : 5f54f373fa543b6a
Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a : 5f54f373fa543b6a
The second example wraps 7 octets of key data with a 192-bit KEK.
2番目の例は、192ビットのKEKで7オクテットの鍵データをラップします。
KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8
KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8
Key : 466f7250617369
Key : 466f7250617369
Wrap : afbeb0f07dfbf541 9200f2ccb50bb24f
Wrap : afbeb0f07dfbf541 9200f2ccb50bb24f
Implementations must protect the key-encryption key (KEK). Compromise of the KEK may result in the disclosure of all keys that have been wrapped with the KEK, which may lead to the compromise of all traffic protected with those wrapped keys.
実装では、鍵暗号化鍵（KEK）を保護する必要があります。KEKが侵害されると、KEKでラップされたすべての鍵が漏洩する可能性があり、それらのラップされた鍵で保護されているすべてのトラフィックの侵害につながる可能性があります。
The KEK must be at least as good as the keying material it is protecting.
KEKは、少なくともそれが保護している鍵素材と同じくらい強力でなければなりません。
If the KEK and wrapped key are associated with different cryptographic algorithms, the effective security provided to data protected with the wrapped key is determined by the weaker of the two algorithms. If, for example, data is encrypted with 128-bit AES and that AES key is wrapped with a 256-bit AES key, then at most 128 bits of protection is provided to the data. If, for another example, a 128-bit AES key is used to wrap a 4096-bit RSA private key, then at most 128 bits of protection is provided to any data that depends on that private key. Thus, implementers must ensure that key-encryption algorithms are at least as strong as other cryptographic algorithms employed in an overall system.
KEKとラップキーが異なる暗号化アルゴリズムに関連付けられている場合、ラップされたキーで保護されているデータに提供される実効的なセキュリティは、2つのアルゴリズムのうち弱い方によって決定されます。たとえば、データが128ビットAESで暗号化され、そのAESキーが256ビットAESキーでラップされている場合、最大128ビットの保護がデータに提供されます。別の例では、128ビットAESキーを使用して4096ビットRSA秘密キーをラップする場合、その秘密キーに依存するデータに最大128ビットの保護が提供されます。したがって、実装者は、キー暗号化アルゴリズムが少なくともシステム全体で採用されている他の暗号化アルゴリズムと同じくらい強力であることを確認する必要があります。
The AES Key Wrap and the AES Key Wrap with Padding algorithms use different constants in the initial value. The use of different values ensures that the recipient of padded key data cannot successfully unwrap it as unpadded key data, or vice versa. This remains true when the key data is wrapped using the AES Key Wrap with Padding algorithm but no padding is needed.
AESキーラップとパディング付きAESキーラップは、初期値に異なる定数を使用します。異なる値を使用することで、パディングされた鍵データの受信者が、パディングされていない鍵データとして正常にアンラップできないこと（およびその逆）が保証されます。これは、パディング付きAESキーラップアルゴリズムを使用して鍵データをラップする際に、パディングが不要な場合でも同様です。
The AES Key Wrap with Padding algorithm provides almost the same amount of integrity protection as the AES Key Wrap algorithm.
パディングアルゴリズムを使用したAESキーラップは、AESキーラップアルゴリズムとほぼ同じ量の整合性保護を提供します。
A previous padding technique was specified for wrapping Hashed Message Authentication Code (HMAC) keys with AES [OLD-KW]. The technique in this document is more general; the technique in this document is not limited to wrapping HMAC keys.
ハッシュメッセージ認証コード（HMAC）鍵をAES [OLD-KW]でラップするために、以前のパディング技術が規定されていました。このドキュメントの手法はより一般的であり、HMAC鍵のラッピングに限定されません。
In the design of some high assurance cryptographic modules, it is desirable to segregate cryptographic keying material from other data. The use of a specific cryptographic mechanism solely for the protection of cryptographic keying material can assist in this goal. The AES Key Wrap and the AES Key Wrap with Padding are such mechanisms. System designers should not use these algorithms to encrypt anything other than cryptographic keying material.
いくつかの高保証暗号モジュールの設計では、暗号鍵素材を他のデータから分離することが望ましいとされています。暗号鍵素材の保護のためだけに特定の暗号化メカニズムを使用することは、この目標の達成に役立ちます。AESキーラップおよびパディング付きAESキーラップは、そのようなメカニズムです。システム設計者は、これらのアルゴリズムを使用して、暗号鍵素材以外のものを暗号化すべきではありません。
[AES] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), 26 November 2001.
[AES]国立標準技術研究所、FIPS Pub 197：Advanced Encryption Standard（AES）、2001年11月26日。
[AES-KW1] National Institute of Standards and Technology, AES Key Wrap Specification, 17 November 2001. http://csrc.nist.gov/groups/ST/toolkit/documents/kms/ AES_key_wrap.pdf
[AES-KW1]国立標準技術研究所、AESキーラップ仕様、2001年11月17日。http://csrc.nist.gov/groups/ST/toolkit/documents/kms/ AES_key_wrap.pdf
[AES-KW2] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-KW2] Schaad, J. およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、2002年9月。
[Modes] Dworkin, M., "Recommendation for Block Cipher Modes of Operation -- Methods and Techniques", NIST Special Publication 800-38A, 2001.
[Modes] Dworkin, M.、「操作のブロックモードの推奨 - 方法と技術」、NIST Special Publication 800-38A、2001。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X.680] ITU-T推奨X.680（2002）|ISO/IEC 8824-1：2002、情報技術 - 抽象構文記法1（ASN.1）：基本表記の仕様。
[AES-CMS] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[AES-CMS] Schaad, J.、「暗号化メッセージ構文（CMS）の高度な暗号化標準（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[CMS-ASN] Schaad, J. and P. Hoffman, "New ASN.1 Modules for CMS and S/MIME", Work in Progress, August 2009.
[CMS-ASN] Schaad, J. およびP. Hoffman、「CMSおよびS/MIME用の新しいASN.1モジュール」、2009年8月、進行中の作業。
[OLD-KW] Schaad, J. and R. Housley, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, May 2003.
[OLD-KW] Schaad, J. および R. Housley、「トリプルデータ暗号化標準（DES）キーまたは高度な暗号化標準（AES）キーを備えたハッシュメッセージ認証コード（HMAC）キーをラッピング」、RFC 3537、2003年5月。
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002, Information Technology - Abstract Syntax Notation One: Information Object Specification.
[X.681] ITU-T推奨X.681（2002）|ISO/IEC 8824-2：2002、情報技術 - 抽象的構文表記1：情報オブジェクト仕様。
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002, Information Technology - Abstract Syntax Notation One: Constraint Specification.
[X.682] ITU-T推奨X.682（2002）|ISO/IEC 8824-3：2002、情報技術 - 抽象的構文表記1：制約仕様。
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications.
[X.683] ITU-T推奨X.683（2002）|ISO/IEC 8824-4：2002、情報技術 - 抽象的構文表記1：ASN.1仕様のパラメーター化。
Paul Timmel should be credited with the MLI and padding technique described in this document.
このドキュメントで説明されているMLIおよびパディング技術は、Paul Timmelによるものです。
This appendix includes two ASN.1 modules. The first one makes use of the 1988 syntax, and the second one makes use of the 2002 ASN.1 syntax.
この付録には、2つのASN.1モジュールが含まれています。最初のものは1988年の構文を使用し、2番目のものは2002年のASN.1構文を使用します。
Appendix A.1 provides the normative ASN.1 definitions for the algorithm identifiers included in this specification using ASN.1 as defined in [X.680] using the 1988 ASN.1 syntax.
付録A.1は、1988年のASN.1構文を使用し、[X.680]で定義されているASN.1を用いて、この仕様に含まれるアルゴリズム識別子の規範的なASN.1定義を提供します。
Appendix A.2 provides informative ASN.1 definitions for the algorithm identifiers included in this specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683] using the 2002 ASN.1 syntax. This appendix contains the same information as Appendix A.1; however, Appendix A.1 takes precedence in case of conflict. The content encryption and key wrap algorithm objects are defined in [CMS-ASN].
付録A.2は、2002年のASN.1構文を使用し、[X.680]、[X.681]、[X.682]、および[X.683]で定義されているASN.1を用いて、この仕様に含まれるアルゴリズム識別子の参考情報のASN.1定義を提供します。この付録には、付録A.1と同じ情報が含まれています。ただし、矛盾がある場合は付録A.1が優先されます。コンテンツ暗号化とキーラップアルゴリズムオブジェクトは、[CMS-ASN]で定義されています。
The id-aes128-wrap, id-aes192-wrap, and id-aes256-wrap algorithm identifiers are defined in [AES-CMS].
ID-aes128-wrap、id-aes192-wrap、およびid-aes256-wrapアルゴリズム識別子は、[AES-CMS]で定義されています。
AESKeyWrapWithPad-88 { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) 47 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
BEGIN
-- EXPORTS ALL --
- すべてエクスポート -
-- IMPORTS NONE --
- インポートなし -
-- AES information object identifiers --
-- AES情報オブジェクト識別子 --
aes OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithms(4) 1 }
-- AES Key Wrap With Padding Algorithm Identifiers are to be used -- with the Parameter field absent
-- パディングアルゴリズム識別子を使用したAESキーラップは、 -- パラメータフィールドなしで使用されます
id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 }
id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 }
id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 }
END
END
AESKeyWrapWithPad-02 { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) 48 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
BEGIN
-- EXPORTS ALL --
- すべてエクスポート -
IMPORTS
AlgorithmIdentifier{}, CONTENT-ENCRYPTION, KEY-WRAP, SMIME-CAPS
FROM AlgorithmInformation-2009 -- [CMS-ASN]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) };
AES-ContentEncryption CONTENT-ENCRYPTION ::= {
cea-aes128-wrap-pad |
cea-aes192-wrap-pad |
cea-aes256-wrap-pad,
... }
AES-KeyWrap KEY-WRAP ::= {
kwa-aes128-wrap-pad |
kwa-aes192-wrap-pad |
kwa-aes256-wrap-pad,
... }
SMimeCaps SMIME-CAPS ::= {
cea-aes128-wrap-pad.&smimeCaps |
cea-aes192-wrap-pad.&smimeCaps |
cea-aes256-wrap-pad.&smimeCaps |
kwa-aes128-wrap-pad.&smimeCaps |
kwa-aes192-wrap-pad.&smimeCaps |
kwa-aes256-wrap-pad.&smimeCaps,
... }
-- AES object identifier
-- AESオブジェクト識別子
aes OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithms(4) 1 }
-- Content Encryption Algorithms
- コンテンツ暗号化アルゴリズム
cea-aes128-wrap-pad CONTENT-ENCRYPTION ::= {
IDENTIFIER id-aes128-wrap-pad
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } }
cea-aes192-wrap-pad CONTENT-ENCRYPTION ::= {
IDENTIFIER id-aes192-wrap-pad
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } }
cea-aes256-wrap-pad CONTENT-ENCRYPTION ::= {
IDENTIFIER id-aes256-wrap-pad
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } }
-- Key Wrap Algorithms
- キーラップアルゴリズム
kwa-aes128-wrap-pad KEY-WRAP ::= {
IDENTIFIER id-aes128-wrap-pad
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } }
id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 }
kwa-aes192-wrap-pad KEY-WRAP ::= {
IDENTIFIER id-aes192-wrap-pad
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } }
id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 }
kwa-aes256-wrap-pad KEY-WRAP ::= {
IDENTIFIER id-aes256-wrap-pad
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } }
id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 }
END
END
Authors' Addresses
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com
Morris Dworkin National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 USA
Morris Dworkin National Institute of Standards and Technology 100 Bureau Drive、Mail Stop 8930 Gaithersburg、MD 20899-8930 USA
EMail: dworkin@nist.gov