[要約] RFC 4309は、IPsec Encapsulating Security Payload（ESP）でAdvanced Encryption Standard（AES）CCMモードを使用するための仕様です。このRFCの目的は、IPsecにおけるAES CCMモードの使用に関するガイドラインを提供することです。
Network Working Group R. Housley
Request for Comments: 4309 Vigil Security
Category: Standards Track December 2005
Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
Advanced暗号化標準（AES）CCMモードを使用して、セキュリティペイロードをカプセル化する（ESP）
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity.
このドキュメントでは、CBC-MAC（CCM）モードを備えたカウンターでの高度な暗号化標準（AES）の使用について説明します。とコネクションのない完全性。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. AES CCM Mode ....................................................2
3. ESP Payload .....................................................4
3.1. Initialization Vector (IV) .................................4
3.2. Encrypted Payload ..........................................4
3.3. Authentication Data ........................................5
4. Nonce Format ....................................................5
5. AAD Construction ................................................6
6. Packet Expansion ................................................7
7. IKE Conventions .................................................7
7.1. Keying Material and Salt Values ............................7
7.2. Phase 1 Identifier .........................................8
7.3. Phase 2 Identifier .........................................8
7.4. Key Length Attribute .......................................8
8. Test Vectors ....................................................8
9. Security Considerations .........................................8
10. Design Rationale ...............................................9
11. IANA Considerations ...........................................11
12. Acknowledgements ..............................................11
13. References ....................................................11
13.1. Normative References .....................................11
13.2. Informative References ...................................12
The Advanced Encryption Standard (AES) [AES] is a block cipher, and it can be used in many different modes. This document describes the use of AES in CCM (Counter with CBC-MAC) mode (AES CCM), with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) [ESP] mechanism to provide confidentiality, data origin authentication, and connectionless integrity.
高度な暗号化標準（AES）[AES]はブロック暗号であり、多くの異なるモードで使用できます。このドキュメントでは、CCM（CBC-MACを備えたカウンター）モード（AES CCM）でのAEの使用について、明示的な初期化ベクトル（IV）を使用して、セキュリティペイロードをカプセル化するIPSEC（ESP）[ESP]メカニズム、データ原文を提供するメカニズムとして説明します。認証、およびコネクションレスの完全性。
This document does not provide an overview of IPsec. However, information about how the various components of IPsec and the way in which they collectively provide security services is available in [ARCH] and [ROAD].
このドキュメントでは、IPSECの概要は提供されていません。ただし、IPSECのさまざまなコンポーネントと、それらが集合的にセキュリティサービスを提供する方法に関する情報は、[Arch]および[Road]で利用可能です。
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 [STDWORDS].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[stdwords]で説明されていると解釈されます。
CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. In this specification, CCM is used with the AES [AES] block cipher.
CCMは、一般的なAuthenticate-and-Encryptブロック暗号モード[CCM]です。この仕様では、CCMはAES [AES]ブロック暗号で使用されます。
AES CCM has two parameters:
AES CCMには2つのパラメーターがあります。
M M indicates the size of the integrity check value (ICV). CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets; However, to maintain alignment and provide adequate security, only the values that are a multiple of four and are at least eight are permitted. Implementations MUST support M values of 8 octets and 16 octets, and implementations MAY support an M value of 12 octets.
M Mは、整合性チェック値（ICV）のサイズを示します。CCMは、4、6、8、10、12、14、および16のオクテットの値を定義します。ただし、アラインメントを維持し、適切なセキュリティを提供するために、4つの倍数で少なくとも8つの値のみが許可されています。実装は、8オクテットと16オクテットのM値をサポートする必要があり、実装は12オクテットのM値をサポートする場合があります。
L L indicates the size of the length field in octets. CCM defines values of L between 2 octets and 8 octets. This specification only supports L = 4. Implementations MUST support an L value of 4 octets, which accommodates a full Jumbogram [JUMBO]; however, the length includes all of the encrypted data, which also includes the ESP Padding, Pad Length, and Next Header fields.
L Lは、オクテットの長さフィールドのサイズを示します。CCMは、2オクテットと8オクテットの間のLの値を定義します。この仕様はL = 4のみをサポートします。実装は、4オクテットのL値をサポートする必要があります。ただし、長さには、ESPパディング、パッドの長さ、次のヘッダーフィールドも含まれる暗号化されたすべてのデータが含まれています。
There are four inputs to CCM originator processing:
CCMオリジナル処理には4つの入力があります。
key A single key is used to calculate the ICV using CBC-MAC and to perform payload encryption using counter mode. AES supports key sizes of 128 bits, 192 bits, and 256 bits. The default key
キー単一のキーは、CBC-MACを使用してICVを計算し、カウンターモードを使用してペイロード暗号化を実行するために使用されます。AESは、128ビット、192ビット、256ビットのキーサイズをサポートしています。デフォルトキー
size is 128 bits, and implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
サイズは128ビットで、実装はこのキーサイズをサポートする必要があります。実装は、192ビットと256ビットのキーサイズをサポートする場合があります。
nonce The size of the nonce depends on the value selected for the parameter L. It is 15-L octets. Implementations MUST support a nonce of 11 octets. The construction of the nonce is described in Section 4.
ノンセのサイズは、パラメーターLで選択された値に依存します。15-Lオクテットです。実装は、11オクテットの非CEをサポートする必要があります。NonCEの構築については、セクション4で説明しています。
payload The payload of the ESP packet. The payload MUST NOT be longer than 4,294,967,295 octets, which is the maximum size of a Jumbogram [JUMBO]; however, the ESP Padding, Pad Length, and Next Header fields are also part of the payload.
ESPパケットのペイロードをペイロードします。ペイロードは4,294,967,295オクテットを超えてはなりません。これは、ジャンボグラムの最大サイズです[ジャンボ]。ただし、ESPパディング、パッドの長さ、および次のヘッダーフィールドもペイロードの一部です。
AAD CCM provides data integrity and data origin authentication for some data outside the payload. CCM does not allow additional authenticated data (AAD) to be longer than 18,446,744,073,709,551,615 octets. The ICV is computed from the ESP header, Payload, and ESP trailer fields, which is significantly smaller than the CCM-imposed limit. The construction of the AAD described in Section 5.
AAD CCMは、ペイロード外の一部のデータに対してデータの整合性とデータ起源認証を提供します。CCMでは、追加の認証データ（AAD）が18,446,744,073,709,551,615オクテットを長くすることはできません。ICVは、ESPヘッダー、ペイロード、およびESPトレーラーフィールドから計算されます。これは、CCMが課した制限よりも大幅に小さいです。セクション5で説明されているAADの構築。
AES CCM requires the encryptor to generate a unique per-packet value and to communicate this value to the decryptor. This per-packet value is one of the component parts of the nonce, and it is referred to as the initialization vector (IV). The same IV and key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
AES CCMでは、暗号化業者が一意のパケットごとの値を生成し、この値を復号化者に伝える必要があります。このパケットごとの値は、NONCEのコンポーネント部分の1つであり、初期化ベクトル（IV）と呼ばれます。同じIVとキーの組み合わせを複数回使用してはなりません。暗号化業者は、一意性を保証するあらゆる方法でIVを生成できます。IV生成への一般的なアプローチには、各パケットおよび線形フィードバックシフトレジスタ（LFSR）のカウンターの増分が含まれます。
AES CCM employs counter mode for encryption. As with any stream cipher, reuse of the same IV value with the same key is catastrophic. An IV collision immediately leaks information about the plaintext in both packets. For this reason, it is inappropriate to use this CCM with statically configured keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES CCM. The Internet Key Exchange (IKE) [IKE] protocol or IKEv2 [IKEv2] can be used to establish fresh keys.
AES CCMは、暗号化にカウンターモードを採用しています。他のストリーム暗号と同様に、同じキーと同じIV値の再利用は壊滅的です。IVの衝突は、両方のパケットの平文に関する情報をすぐに漏らします。このため、静的に構成されたキーでこのCCMを使用することは不適切です。電源サイクル全体で静的キーを使用したIV値の再利用を防ぐには、並外れた測定が必要です。安全にするには、実装がAES CCMを備えた新鮮なキーを使用する必要があります。インターネットキーエクスチェンジ（IKE）[IKE]プロトコルまたはIKEV2 [IKEV2]を使用して、新しいキーを確立できます。
The ESP payload is composed of the IV followed by the ciphertext. The payload field, as defined in [ESP], is structured as shown in Figure 1.
ESPペイロードは、IVで構成され、その後のCiphertextが続きます。[ESP]で定義されているペイロードフィールドは、図1に示すように構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. ESP Payload Encrypted with AES CCM
図1. AES CCMで暗号化されたESPペイロード
The AES CCM IV field MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
AES CCM IVフィールドは8オクターでなければなりません。IVは、特定のキーに対して同じIV値が1回だけ使用されることを保証する方法で、暗号化業者によって選択される必要があります。暗号化業者は、一意性を保証するあらゆる方法でIVを生成できます。IV生成への一般的なアプローチには、各パケットおよび線形フィードバックシフトレジスタ（LFSR）のカウンターの増分が含まれます。
Including the IV in each packet ensures that the decryptor can generate the key stream needed for decryption, even when some datagrams are lost or reordered.
各パケットにIVを含めることで、一部のデータグラムが紛失または再注文された場合でも、復号化に必要なキーストリームを復号化できることが保証されます。
The encrypted payload contains the ciphertext.
暗号化されたペイロードには、ciphertextが含まれています。
AES CCM mode does not require plaintext padding. However, ESP does require padding to 32-bit word-align the authentication data. The Padding, Pad Length, and Next Header fields MUST be concatenated with the plaintext before performing encryption, as described in [ESP]. When padding is required, it MUST be generated and checked in accordance with the conventions specified in [ESP].
AES CCMモードでは、プレーンテキストパディングは必要ありません。ただし、ESPでは、認証データを32ビットワードアライに合わせてパディングが必要です。[ESP]で説明されているように、暗号化を実行する前に、パディング、パッドの長さ、および次のヘッダーフィールドをプレーンテキストと連結する必要があります。パディングが必要な場合は、[ESP]で指定された規則に従って生成され、チェックインする必要があります。
AES CCM provides an encrypted ICV. The ICV provided by CCM is carried in the Authentication Data fields without further encryption. Implementations MUST support ICV sizes of 8 octets and 16 octets. Implementations MAY also support ICV 12 octets.
AES CCMは暗号化されたICVを提供します。CCMから提供されるICVは、さらに暗号化することなく認証データフィールドに運ばれます。実装は、8オクテットと16オクテットのICVサイズをサポートする必要があります。実装は、ICV 12オクテットをサポートする場合があります。
Each packet conveys the IV that is necessary to construct the sequence of counter blocks used by counter mode to generate the key stream. The AES counter block is 16 octets. One octet is used for the CCM Flags, and 4 octets are used for the block counter, as specified by the CCM L parameter. The remaining octets are the nonce. These octets occupy the second through the twelfth octets in the counter block. Figure 2 shows the format of the nonce.
各パケットは、カウンターモードで使用されるカウンターブロックのシーケンスを構築してキーストリームを生成するために必要なIVを伝えます。AESカウンターブロックは16オクテットです。CCMフラグには1つのオクテットが使用され、CCM Lパラメーターで指定されているように、ブロックカウンターには4オクテットが使用されます。残りのオクテットはnonceです。これらのオクテットは、カウンターブロックの2番目のオクテットから12番目のオクテットを占めています。図2は、ノンセの形式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Nonce Format
図2.ノンセ形式
The components of the nonce are as follows:
ノンセのコンポーネントは次のとおりです。
Salt The salt field is 24 bits. As the name implies, it contains an unpredictable value. It MUST be assigned at the beginning of the security association. The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.
塩塩フィールドは24ビットです。名前が示すように、予測不可能な値が含まれています。セキュリティ協会の開始時に割り当てる必要があります。塩の値は秘密である必要はありませんが、セキュリティ協会の開始前に予測可能であってはなりません。
Initialization Vector The IV field is 64 bits. As described in Section 3.1, the IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key.
初期化ベクターIVフィールドは64ビットです。セクション3.1で説明されているように、IVは、特定のキーに対して同じIV値が一度だけ使用されることを保証する方法で、暗号化業者によって選択されなければなりません。
This construction permits each packet to consist of up to:
この構造により、各パケットは以下で構成されます。
2^32 blocks = 4,294,967,296 blocks = 68,719,476,736 octets
2^32ブロック= 4,294,967,296ブロック= 68,719,476,736オクテット
This construction provides more key stream for each packet than is needed to handle any IPv6 Jumbogram [JUMBO].
この構造は、IPv6ジャンボグラム[ジャンボ]を処理するために必要なものよりも、各パケットの重要なストリームを提供します。
The data integrity and data origin authentication for the Security Parameters Index (SPI) and (Extended) Sequence Number fields is provided without encrypting them. Two formats are defined: one for 32-bit sequence numbers and one for 64-bit extended sequence numbers. The format with 32-bit sequence numbers is shown in Figure 3, and the format with 64-bit extended sequence numbers is shown in Figure 4.
セキュリティパラメーターインデックス（SPI）および（拡張）シーケンス番号フィールドのデータの整合性とデータ起源認証は、それらを暗号化せずに提供されます。2つの形式が定義されています。1つは32ビットシーケンス番号、もう1つは64ビットの拡張シーケンス番号です。32ビットシーケンス番号の形式を図3に示し、64ビットの拡張シーケンス番号を持つ形式を図4に示します。
Sequence Numbers are conveyed canonical network byte order. Extended Sequence Numbers are conveyed canonical network byte order, placing the high-order 32 bits first and the low-order 32 bits second. Canonical network byte order is fully described in RFC 791, Appendix B.
シーケンス番号は、正規のネットワークバイト順序で伝達されます。拡張されたシーケンス番号は、標準的なネットワークバイトの順序で伝達され、高次の32ビットを最初に配置し、低次の32ビットを2番目に配置します。標準的なネットワークバイト順序は、RFC 791、付録Bで完全に説明されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. AAD Format with 32-bit Sequence Number
図3. 32ビットシーケンス番号のAAD形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. AAD Format with 64-bit Extended Sequence Number
図4. 64ビットの拡張シーケンス番号を持つAAD形式
The initialization vector (IV) and the integrity check value (ICV) are the only sources of packet expansion. The IV always adds 8 octets to the front of the payload. The ICV is added at the end of the payload, and the CCM parameter M determines the size of the ICV. Implementations MUST support M values of 8 octets and 16 octets, and implementations MAY also support an M value of 12 octets.
初期化ベクトル（IV）と整合性チェック値（ICV）は、パケット拡張の唯一のソースです。IVは、常にペイロードの前面に8オクテットを追加します。ICVはペイロードの最後に追加され、CCMパラメーターMはICVのサイズを決定します。実装は、8オクテットと16オクテットのM値をサポートする必要があり、実装は12オクテットのM値もサポートする場合があります。
This section describes the conventions used to generate keying material and salt values for use with AES CCM using the Internet Key Exchange (IKE) [IKE] protocol. The identifiers and attributes needed to negotiate a security association that uses AES CCM are also defined.
このセクションでは、インターネットキーエクスチェンジ（IKE）[IKE]プロトコルを使用して、AES CCMで使用するキーイング材料と塩値を生成するために使用される規則について説明します。AES CCMを使用するセキュリティ協会をネゴシエートするために必要な識別子と属性も定義されています。
As previously described, implementations MUST use fresh keys with AES CCM. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable salt value for use in the nonce from IKE. Note that this convention provides a salt value that is secret as well as unpredictable.
前述のように、実装はAES CCMを備えた新鮮なキーを使用する必要があります。Ikeは、新鮮な鍵を確立するために使用できます。このセクションでは、IKEの非CEで使用する予測不可能な塩値を取得するための慣習について説明します。この条約は、予測不可能であると同時に秘密の塩値を提供していることに注意してください。
IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, called KEYMAT. Keying material is extracted from the output string without regard to boundaries.
Ikeは、擬似ランダム関数（PRF）を使用してキーイング材料を導き出します。PRFは、keymatと呼ばれる任意のサイズのキーイング材料を導き出すために繰り返し使用されます。キーイング材料は、境界に関係なく出力文字列から抽出されます。
The size of KEYMAT MUST be three octets longer than is needed for the associated AES key. The keying material is used as follows:
キーマットのサイズは、関連するAESキーに必要なものよりも3オクテット長でなければなりません。キーイング材料は次のように使用されます。
AES CCM with a 128-bit key The KEYMAT requested for each AES CCM key is 19 octets. The first 16 octets are the 128-bit AES key, and the remaining three octets are used as the salt value in the counter block.
128ビットキー付きAES CCM各AES CCMキーに対してキーマットが要求したのは19オクテットです。最初の16個のオクテットは128ビットAESキーで、残りの3個のオクテットはカウンターブロックの塩値として使用されます。
AES CCM with a 192-bit key The KEYMAT requested for each AES CCM key is 27 octets. The first 24 octets are the 192-bit AES key, and the remaining three octets are used as the salt value in the counter block.
192ビットキー付きAES CCM各AES CCMキーに対してキーマットが要求したのは27オクテットです。最初の24個のオクテットは192ビットAESキーであり、残りの3つのオクテットはカウンターブロックの塩値として使用されます。
AES CCM with a 256-bit key The KEYMAT requested for each AES CCM key is 35 octets. The first 32 octets are the 256-bit AES key, and the remaining three octets are used as the salt value in the counter block.
256ビットキー付きAES CCM各AES CCMキーに対してキーマットが要求したのは35オクテットです。最初の32個のオクテットは256ビットAESキーであり、残りの3つのオクテットはカウンターブロックの塩値として使用されます。
This document does not specify the conventions for using AES CCM for IKE Phase 1 negotiations. For AES CCM to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned.
このドキュメントでは、IKEフェーズ1交渉にAES CCMを使用するための規則を指定していません。この方法でAES CCMを使用するには、個別の仕様が必要であり、暗号化アルゴリズム識別子を割り当てる必要があります。
For IKE Phase 2 negotiations, IANA has assigned three ESP Transform Identifiers for AES CCM with an explicit IV:
IKEフェーズ2の交渉では、IANAはAES CCMの3つのESP変換識別子を明示的なIVで割り当てました。
14 for AES CCM with an 8-octet ICV; 15 for AES CCM with a 12-octet ICV; and 16 for AES CCM with a 16-octet ICV.
8オクテットのICVを備えたAES CCMの場合。12オクテットのICVを備えたAES CCMの場合。16オクテットのICVを備えたAES CCMの16。
Because the AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length attribute MUST have a value of 128, 192, or 256.
AESは3つのキー長をサポートするため、IKEフェーズ2エクスチェンジ[DOI]でキー長属性を指定する必要があります。キー長属性の値は、128、192、または256の値を持っている必要があります。
Section 8 of [CCM] provides test vectors that will assist implementers with AES CCM mode.
[CCM]のセクション8では、AES CCMモードで実装者を支援するテストベクトルを提供します。
AES CCM employs counter (CTR) mode for confidentiality. If a counter value is ever used for more that one packet with the same key, then the same key stream will be used to encrypt both packets, and the confidentiality guarantees are voided.
AES CCMは、機密性のためにカウンター（CTR）モードを採用しています。カウンター値が同じキーを持つ1つのパケットよりも多くの場合に使用される場合、同じキーストリームを使用して両方のパケットを暗号化し、機密性の保証が無効になります。
What happens if the encryptor XORs the same key stream with two different packet plaintexts? Suppose two packets are defined by two plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are encrypted with key stream K1, K2, K3. The two corresponding ciphertexts are:
暗号化業者が2つの異なるパケットプレーンテキストを備えた同じキーストリームをXorするとどうなりますか？2つのパケットが2つのプレーンテキストバイトシーケンスP1、P2、P3、Q1、Q2、Q3で定義され、両方がキーストリームK1、K2、K3で暗号化されているとします。対応する2つの暗号文は次のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1 XOR K1）、（P2 XOR K2）、（P3 XOR K3）
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
（Q1 XOR K1）、（Q2 XOR K2）、（Q3 XOR K3）
If both of these two ciphertext streams are exposed to an attacker, then a catastrophic failure of confidentiality results, because:
これらの2つの暗号文の両方が攻撃者にさらされている場合、機密性の壊滅的な失敗の結果は次のとおりです。
(P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
(P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
(P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3
Once the attacker obtains the two plaintexts XORed together, it is relatively straightforward to separate them. Thus, using any stream cipher, including AES CTR, to encrypt two plaintexts under the same key stream leaks the plaintext.
攻撃者が2つのプレーンテキストを一緒に取得すると、それらを分離するのは比較的簡単です。したがって、AES CTRを含むストリーム暗号を使用して、同じキーストリームの下で2つのプレーンテキストを暗号化すると、プレーンテキストが漏れます。
Therefore, AES CCM should not be used with statically configured keys. Extraordinary measures would be needed to prevent the reuse of a counter block value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES CCM. The IKE [IKE] protocol can be used to establish fresh keys.
したがって、AES CCMは、静的に構成されたキーでは使用しないでください。パワーサイクル全体の静的キーを使用したカウンターブロック値の再利用を防ぐには、並外れた測定が必要です。安全にするには、実装がAES CCMを備えた新鮮なキーを使用する必要があります。IKE [IKE]プロトコルを使用して、新鮮なキーを確立できます。
When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows. If a different mechanism is used to establish fresh keys, one that
IKEが2つのピアエンティティ間で新鮮なキーを確立するために使用される場合、2つのトラフィックフロー用に個別のキーが確立されます。新鮮なキーを確立するために別のメカニズムを使用している場合、
establishes only a single key to encrypt packets, then there is a high probability that the peers will select the same IV values for some packets. Thus, to avoid counter block collisions, ESP implementations that permit use of the same key for encrypting and decrypting packets with the same peer MUST ensure that the two peers assign different salt values to the security association (SA).
パケットを暗号化するための単一のキーのみを確立すると、ピアが一部のパケットで同じIV値を選択する可能性が高くなります。したがって、カウンターブロックの衝突を避けるために、同じキーを暗号化および復号化するために同じキーを使用することを許可するESP実装は、同じピアでパケットを復号化する必要があります。
Regardless of the mode used, AES with a 128-bit key is vulnerable to the birthday attack after 2^64 blocks are encrypted with a single key. Since ESP with Extended Sequence Numbers allows for up to 2^64 packets in a single SA, there is real potential for more than 2^64 blocks to be encrypted with one key. Implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key, or implementations SHOULD make use of the longer AES key sizes. Note that ESP with 32-bit Sequence Numbers will not exceed 2^64 blocks even if all of the packets are maximum-length Jumbograms.
使用するモードに関係なく、128ビットキーを持つAESは、2^64ブロックが単一のキーで暗号化された後、誕生日攻撃に対して脆弱です。拡張されたシーケンス番号を備えたESPは、単一のSAで最大2^64パケットを可能にするため、1つのキーで2^64を超えるブロックを暗号化する実際の可能性があります。実装は、2^64ブロックが同じキーで暗号化される前に、新しいキーを生成する必要があります。または、実装はより長いAESキーサイズを利用する必要があります。すべてのパケットが最大長さのジャンボグラムであっても、32ビットシーケンス番号のESPは2^64ブロックを超えないことに注意してください。
In the development of this specification, the use of the ESP sequence number field instead of an explicit IV field was considered. This section documents the rationale for the selection of an explicit IV. This selection is not a cryptographic security issue, as either approach will prevent counter block collisions.
この仕様の開発では、明示的なIVフィールドの代わりにESPシーケンス番号フィールドの使用が考慮されました。このセクションでは、明示的なIVの選択の根拠を文書化します。どちらのアプローチもカウンターブロックの衝突を防ぐため、この選択は暗号化のセキュリティの問題ではありません。
The use of the explicit IV does not dictate the manner that the encryptor uses to assign the per-packet value in the counter block. This is desirable for several reasons.
明示的なIVの使用は、暗号化業者がカウンターブロックにパケットごとの値を割り当てるために使用する方法を決定しません。これはいくつかの理由で望ましいです。
1. Only the encryptor can ensure that the value is not used for more than one packet, so there is no advantage to selecting a mechanism that allows the decryptor to determine whether counter block values collide. Damage from the collision is done, whether the decryptor detects it or not.
1. 暗号化業者のみが、値が複数のパケットに使用されないことを保証できるため、復号化者がカウンターブロック値が衝突するかどうかを判断できるメカニズムを選択する利点はありません。decryptorがそれを検出するかどうかにかかわらず、衝突による損傷は行われます。
2. The use of explicit IVs allows adders, LFSRs, and any other technique that meets the time budget of the encryptor, so long as the technique results in a unique value for each packet. Adders are simple and straightforward to implement, but due to carries, they do not execute in constant time. LFSRs offer an alternative that executes in constant time.
2. 明示的なIVを使用することで、各パケットのユニークな値になる限り、暗号化者の時間予算を満たす追加者、LFSR、およびその他の手法が可能になります。加算器は実装するのが簡単で簡単ですが、キャリーのために、一定の時間では実行されません。LFSRは、一定の時間で実行される代替品を提供します。
3. Complexity is in control of the implementer. Furthermore, the decision made by the implementer of the encryptor does not make the decryptor more (or less) complex.
3. 複雑さは実装者を制御しています。さらに、暗号化業者の実装者によって下された決定は、復号化者をより複雑にするものではありません。
4. The assignment of the per-packet counter block value needs to be inside the assurance boundary. Some implementations assign the sequence number inside the assurance boundary, but others do not. A sequence number collision does not have the dire consequences, but, as described in Section 6, a collision in counter block values has disastrous consequences.
4. パケットごとのカウンターブロック値の割り当ては、保証境界内にある必要があります。いくつかの実装は、保証境界内にシーケンス番号を割り当てますが、他のものはそうではありません。シーケンス数の衝突には悲惨な結果はありませんが、セクション6で説明されているように、カウンターブロック値の衝突は悲惨な結果をもたらします。
5. Using the sequence number as the IV is possible in those architectures where the sequence number assignment is performed within the assurance boundary. In this situation, the sequence number and the IV field will contain the same value.
5. シーケンス番号を保証境界内で実行されるアーキテクチャでは、IVとしてシーケンス番号を使用することが可能です。この状況では、シーケンス番号とIVフィールドには同じ値が含まれます。
6. By decoupling the IV and the sequence number, architectures where the sequence number assignment is performed outside the assurance boundary are accommodated.
6. IVとシーケンス番号を切り離すことにより、保証境界の外でシーケンス番号割り当てが実行されるアーキテクチャが収容されます。
The use of an explicit IV field directly follows from the decoupling of the sequence number and the per-packet counter block value. The additional overhead (64 bits for the IV field) is acceptable. This overhead is significantly less overhead associated with Cipher Block Chaining (CBC) mode. As normally employed, CBC requires a full block for the IV and, on average, half of a block for padding. AES CCM confidentiality processing with an explicit IV has about one-third of the overhead as AES CBC, and the overhead is constant for each packet.
明示的なIVフィールドの使用は、シーケンス番号とパケットごとのカウンターブロック値のデカップリングから直接続きます。追加のオーバーヘッド（IVフィールドの64ビット）は許容されます。このオーバーヘッドは、暗号ブロックチェーン（CBC）モードに関連するオーバーヘッドが大幅に少ないです。通常使用されているように、CBCはIVの完全なブロックを必要とし、平均してパディングのブロックの半分を必要とします。明示的なIVでのAES CCMの機密保持処理は、オーバーヘッドの約3分の1をAES CBCとして持ち、各パケットのオーバーヘッドは一定です。
IANA has assigned three ESP transform numbers for use with AES CCM with an explicit IV:
IANAは、AES CCMで使用するための3つのESP変換番号を明示的なIVで割り当てました。
14 for AES CCM with an 8-octet ICV; 15 for AES CCM with a 12-octet ICV; and 16 for AES CCM with a 16-octet ICV.
8オクテットのICVを備えたAES CCMの場合。12オクテットのICVを備えたAES CCMの場合。16オクテットのICVを備えたAES CCMの16。
Doug Whiting and Niels Ferguson worked with me to develop CCM mode. We developed CCM mode as part of the IEEE 802.11i security effort. One of the most attractive aspects of CCM mode is that it is unencumbered by patents. I acknowledge the companies that supported the development of an unencumbered authenticated encryption mode (in alphabetical order):
Doug WhitingとNiels Fergusonは私と協力してCCMモードを開発しました。IEEE 802.11iセキュリティの取り組みの一部としてCCMモードを開発しました。CCMモードの最も魅力的な側面の1つは、特許によって妨げられていないことです。妨げられていない認証された暗号化モードの開発をサポートした企業（アルファベット順）を認めます。
Hifn Intersil MacFergus RSA Security
HIFN Intersil MacFergus RSAセキュリティ
Also, I thank Tero Kivinen for his comprehensive review of this document.
また、この文書の包括的なレビューをしてくれたTero Kivinenに感謝します。
This section provides normative and informative references.
このセクションでは、規範的で有益な参照を提供します。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001.
[AES] Nist、Fips Pub 197、「Advanced Encryption Standard（AES）」、2001年11月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[doi] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent、S。、「セキュリティペイロードをカプセル化するIP（ESP）」、RFC 4303、2005年12月。
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[CCM] Whiting、D.、Housley、R。、およびN. Ferguson、「Counter with CBC-MAC（CCM）」、RFC 3610、2003年9月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[stdwords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Arch] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[Road] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[JUMBO] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[ジャンボ]ボーマン、D。、ディアリング、S。、およびR.ヒンデン、「IPv6ジャンボグラム」、RFC 2675、1999年8月。
Author's Address
著者の連絡先
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。