[要約] RFC 9459 は、COSEでAES-CTRとAES-CBCを使用するための規約を定めており、CBORデータ形式を使用して基本的なセキュリティサービスを提供することを目的としています。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9459 Vigil Security
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 September 2023
The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with COSE.
簡潔なバイナリオブジェクト表現（CBOR）データ形式は、小さなコードサイズと小さなメッセージサイズに合わせて設計されています。CBORオブジェクトの署名と暗号化（COSE）は、CBORデータ形式を使用して基本的なセキュリティサービスを提供するためにRFC 9052で指定されています。このドキュメントは、AES-CTRおよびAES-CBCをCOSEでコンテンツ暗号化アルゴリズムとして使用するための規則を指定します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9459.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9459で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Terminology
3. AES Modes of Operation
4. AES Counter Mode
4.1. AES-CTR COSE Key
4.2. AES-CTR COSE Algorithm Identifiers
5. AES Cipher Block Chaining Mode
5.1. AES-CBC COSE Key
5.2. AES-CBC COSE Algorithm Identifiers
6. Implementation Considerations
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with the CBOR Object Signing and Encryption (COSE) [RFC9052] syntax. Today, encryption with COSE uses Authenticated Encryption with Associated Data (AEAD) algorithms [RFC5116], which provide both confidentiality and integrity protection. However, there are situations where another mechanism, such as a digital signature, is used to provide integrity. In these cases, an AEAD algorithm is not needed. The software manifest being defined by the IETF SUIT WG [SUIT-MANIFEST] is one example where a digital signature is always present.
このドキュメントは、AES-CTRおよびAES-CBCをCBORオブジェクトの署名および暗号化（COSE）[RFC9052]構文を使用したコンテンツ暗号化アルゴリズムとして使用するための規則を指定します。今日、COSEによる暗号化は、関連するデータ（AEAD）アルゴリズム[RFC5116]を使用した認証された暗号化を使用しており、機密性と整合性保護の両方を提供します。ただし、デジタル署名などの別のメカニズムが整合性を提供するために使用される状況があります。これらの場合、AEADアルゴリズムは必要ありません。IETFスーツWG [スーツマニフェスト]によって定義されているソフトウェアマニフェストは、デジタル署名が常に存在する一例です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
NIST has defined several modes of operation for the Advanced Encryption Standard [AES] [MODES]. AES supports three key sizes: 128 bits, 192 bits, and 256 bits. AES has a block size of 128 bits (16 octets). Each of these modes has different characteristics. The modes include: CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter).
NISTは、高度な暗号化標準[AES] [モード]のいくつかの動作モードを定義しています。AESは、128ビット、192ビット、256ビットの3つのキーサイズをサポートしています。AESのブロックサイズは128ビット（16オクテット）です。これらの各モードには異なる特性があります。モードには、CBC（Cipherブロックチェーン）、CFB（Cipherフィードバック）、OFB（出力フィードバック）、およびCTR（カウンター）が含まれます。
Only AES Counter (AES-CTR) mode and AES Cipher Block Chaining (AES-CBC) are discussed in this document.
このドキュメントでは、AESカウンター（AES-CTR）モードとAES暗号ブロックチェーン（AES-CBC）のみについて説明します。
When AES-CTR is used as a COSE content encryption algorithm, the encryptor generates a unique value that is communicated to the decryptor. This value is called an "Initialization Vector" (or "IV") in this document. The same IV and AES key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures the same IV value is not used more than once with the same AES key.
AES-CTRがCOSEコンテンツ暗号化アルゴリズムとして使用される場合、暗号化業者は、復号化装置に伝達される一意の値を生成します。この値は、このドキュメントの「初期化ベクトル」（または「IV」）と呼ばれます。同じIVとAESキーの組み合わせを複数回使用してはなりません。暗号化業者は、同じAESキーを使用して同じIV値が複数回使用されないことを保証するあらゆる方法でIVを生成できます。
When using AES-CTR, each AES encrypt operation generates 128 bits of key stream. AES-CTR encryption is the XOR of the key stream with the plaintext. AES-CTR decryption is the XOR of the key stream with the ciphertext. If the generated key stream is longer than the plaintext or ciphertext, the extra key stream bits are simply discarded. For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size.
AES-CTRを使用する場合、各AES暗号操作は128ビットのキーストリームを生成します。AES-CTR暗号化は、プレーンテキストを備えたキーストリームのXORです。AES-CTR復号化は、暗号文を備えたキーストリームのXORです。生成されたキーストリームがPlantextまたはciphertextよりも長い場合、追加のキーストリームビットは単に破棄されます。このため、AES-CTRでは、プレーンテキストをブロックサイズの倍数にパッドでパッドにする必要はありません。
AES-CTR has many properties that make it an attractive COSE content encryption algorithm. AES-CTR uses the AES block cipher to create a stream cipher. Data is encrypted and decrypted by XORing with the key stream produced by AES encrypting sequential IV block values, called "counter blocks", where:
AES-CTRには、魅力的なCOSEコンテンツ暗号化アルゴリズムになる多くのプロパティがあります。AES-CTRは、AESブロック暗号を使用してストリーム暗号を作成します。データは、「カウンターブロック」と呼ばれるシーケンシャルIVブロック値を暗号化するAESによって生成されるキーストリームでXoringによって暗号化および復号化されます。
* The first block of the key stream is the AES encryption of the IV.
* キーストリームの最初のブロックは、IVのAES暗号化です。
* The second block of the key stream is the AES encryption of (IV + 1) mod 2^128.
* キーストリームの2番目のブロックは、（iv 1）mod 2^128のAES暗号化です。
* The third block of the key stream is the AES encryption of (IV + 2) mod 2^128, and so on.
* キーストリームの3番目のブロックは、（IV 2）mod 2^128などのAES暗号化です。
AES-CTR is easy to implement, can be pipelined and parallelized, and supports key stream precomputation. Sending of the IV is the only source of expansion because the plaintext and ciphertext are the same size.
AES-CTRは実装が簡単で、パイプライン化および並列化でき、キーストリームの事前計算をサポートします。Plantextとciphertextが同じサイズであるため、IVの送信は唯一の拡張ソースです。
When used correctly, AES-CTR provides a high level of confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. Being a stream cipher, reuse of the IV with the same key is catastrophic. An IV collision immediately leaks information about the plaintext. For this reason, it is inappropriate to use AES-CTR with static 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-CTR.
正しく使用すると、AES-CTRは高レベルの機密性を提供します。残念ながら、AES-CTRは誤って使いやすいです。ストリーム暗号であるため、同じキーでIVを再利用することは壊滅的です。IVの衝突は、すぐに平文に関する情報を漏らします。このため、静的キーでAES-CTRを使用することは不適切です。電源サイクル全体で静的キーを使用したIV値の再利用を防ぐには、並外れた測定が必要です。安全にするには、実装がAES-CTRを備えた新鮮なキーを使用する必要があります。
AES-CTR keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
AES-CTRキーは、キー構造または受信者構造のいずれかから取得できます。実装の暗号化と復号化は、関連するエンティティにとってキータイプ、キー長、およびアルゴリズムが正しく適切であることを検証する必要があります。
With AES-CTR, it is trivial to use a valid ciphertext to forge other (valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to use AES-CTR without a companion authentication and integrity mechanism. Implementations MUST use AES-CTR in conjunction with an authentication and integrity mechanism, such as a digital signature.
AES-CTRを使用すると、有効な暗号文を使用して他の（DeCryptorに有効な）暗号文を偽造することは簡単です。したがって、コンパニオン認証と整合性メカニズムなしでAES-CTRを使用することも同様に壊滅的です。実装は、デジタル署名などの認証と整合性メカニズムと組み合わせてAES-CTRを使用する必要があります。
The instructions in Section 5.4 of [RFC9052] are followed for AES-CTR. Since AES-CTR cannot provide integrity protection for external additional authenticated data, the decryptor MUST ensure that no external additional authenticated data was supplied. See Section 6.
[RFC9052]のセクション5.4の指示には、AES-CTRが続きます。AES-CTRは、外部の追加の認証データに対して整合性保護を提供できないため、復号が外部の追加の認証データが提供されないようにする必要があります。セクション6を参照してください。
The 'protected' header MUST be a zero-length byte string.
「保護された」ヘッダーは、ゼロ長バイト文字列でなければなりません。
When using a COSE key for the AES-CTR algorithm, the following checks are made:
AES-CTRアルゴリズムにCOSEキーを使用する場合、次のチェックが行われます。
* The 'kty' field MUST be present, and it MUST be 'Symmetric'.
* 「kty」フィールドが存在する必要があり、「対称」でなければなりません。
* If the 'alg' field is present, it MUST match the AES-CTR algorithm being used.
* 「アルグ」フィールドが存在する場合、使用されているAES-CTRアルゴリズムと一致する必要があります。
* If the 'key_ops' field is present, it MUST include 'encrypt' when encrypting.
* 「key_ops」フィールドが存在する場合、暗号化時に「暗号化」を含める必要があります。
* If the 'key_ops' field is present, it MUST include 'decrypt' when decrypting.
* 「key_ops」フィールドが存在する場合、復号化するときは「復号化」を含める必要があります。
The following table defines the COSE AES-CTR algorithm values. Note that these algorithms are being registered as "Deprecated" to avoid accidental use without a companion integrity protection mechanism.
次の表は、COSE AES-CTRアルゴリズム値を定義しています。これらのアルゴリズムは、コンパニオンインテグリティ保護メカニズムなしで偶発的な使用を避けるために「非推奨」として登録されていることに注意してください。
+=========+========+==========+=============+=============+
| Name | Value | Key Size | Description | Recommended |
+=========+========+==========+=============+=============+
| A128CTR | -65534 | 128 | AES-CTR w/ | Deprecated |
| | | | 128-bit key | |
+---------+--------+----------+-------------+-------------+
| A192CTR | -65533 | 192 | AES-CTR w/ | Deprecated |
| | | | 192-bit key | |
+---------+--------+----------+-------------+-------------+
| A256CTR | -65532 | 256 | AES-CTR w/ | Deprecated |
| | | | 256-bit key | |
+---------+--------+----------+-------------+-------------+
Table 1
AES-CBC mode requires a 16-octet IV. Use of a randomly or pseudorandomly generated IV ensures that the encryption of the same plaintext will yield different ciphertext.
AES-CBCモードには16オクテットIVが必要です。ランダムまたは擬似ランダムに生成されたIVを使用すると、同じプレーンテキストの暗号化が異なる暗号文を生成することが保証されます。
AES-CBC performs an XOR of the IV with the first plaintext block before it is encrypted. For successive blocks, AES-CBC performs an XOR of the previous ciphertext block with the current plaintext before it is encrypted.
AES-CBCは、暗号化される前に、最初の平文ブロックでIVのXORを実行します。連続したブロックの場合、AES-CBCは、暗号化される前に現在のプレーンテキストを使用して、前の暗号文ブロックのXORを実行します。
AES-CBC requires padding of the plaintext; the padding algorithm specified in Section 6.3 of [RFC5652] MUST be used prior to encrypting the plaintext. This padding algorithm allows the decryptor to unambiguously remove the padding.
AES-CBCには、平文のパディングが必要です。[RFC5652]のセクション6.3で指定されているパディングアルゴリズムは、平文を暗号化する前に使用する必要があります。このパディングアルゴリズムにより、復号化装置はパディングを明確に除去できます。
The simplicity of AES-CBC makes it an attractive COSE content encryption algorithm. The need to carry an IV and the need for padding lead to an increase in the overhead (when compared to AES-CTR). AES-CBC is much safer for use with static keys than AES-CTR. That said, as described in [RFC4107], the use of automated key management to generate fresh keys is greatly preferred.
AES-CBCのシンプルさにより、魅力的なCOSEコンテンツ暗号化アルゴリズムになります。IVを運ぶ必要性とパディングの必要性は、オーバーヘッドの増加につながります（AES-CTRと比較して）。AES-CBCは、AES-CTRよりも静的キーで使用する方がはるかに安全です。とはいえ、[RFC4107]で説明されているように、自動化されたキー管理を使用して新鮮なキーを生成することが非常に好まれます。
AES-CBC does not provide integrity protection. Thus, an attacker can introduce undetectable errors if AES-CBC is used without a companion authentication and integrity mechanism. Implementations MUST use AES-CBC in conjunction with an authentication and integrity mechanism, such as a digital signature.
AES-CBCは整合性保護を提供しません。したがって、攻撃者は、コンパニオン認証と整合性メカニズムなしでAES-CBCが使用される場合、検出不能なエラーを導入できます。実装は、デジタル署名などの認証と整合性メカニズムと組み合わせてAES-CBCを使用する必要があります。
The instructions in Section 5.4 of [RFC9052] are followed for AES-CBC. Since AES-CBC cannot provide integrity protection for external additional authenticated data, the decryptor MUST ensure that no external additional authenticated data was supplied. See Section 6.
[RFC9052]のセクション5.4の指示に従って、AES-CBCについて続きます。AES-CBCは、外部の追加の認証データに対して整合性保護を提供できないため、復号が外部の追加の認証データが提供されないようにする必要があります。セクション6を参照してください。
The 'protected' header MUST be a zero-length byte string.
「保護された」ヘッダーは、ゼロ長バイト文字列でなければなりません。
When using a COSE key for the AES-CBC algorithm, the following checks are made:
AES-CBCアルゴリズムにCOSEキーを使用する場合、次のチェックが行われます。
* The 'kty' field MUST be present, and it MUST be 'Symmetric'.
* 「kty」フィールドが存在する必要があり、「対称」でなければなりません。
* If the 'alg' field is present, it MUST match the AES-CBC algorithm being used.
* 「アルグ」フィールドが存在する場合、使用されているAES-CBCアルゴリズムと一致する必要があります。
* If the 'key_ops' field is present, it MUST include 'encrypt' when encrypting.
* 「key_ops」フィールドが存在する場合、暗号化時に「暗号化」を含める必要があります。
* If the 'key_ops' field is present, it MUST include 'decrypt' when decrypting.
* 「key_ops」フィールドが存在する場合、復号化するときは「復号化」を含める必要があります。
The following table defines the COSE AES-CBC algorithm values. Note that these algorithms are being registered as "Deprecated" to avoid accidental use without a companion integrity protection mechanism.
次の表は、COSE AES-CBCアルゴリズム値を定義しています。これらのアルゴリズムは、コンパニオンインテグリティ保護メカニズムなしで偶発的な使用を避けるために「非推奨」として登録されていることに注意してください。
+=========+========+==========+=============+=============+
| Name | Value | Key Size | Description | Recommended |
+=========+========+==========+=============+=============+
| A128CBC | -65531 | 128 | AES-CBC w/ | Deprecated |
| | | | 128-bit key | |
+---------+--------+----------+-------------+-------------+
| A192CBC | -65530 | 192 | AES-CBC w/ | Deprecated |
| | | | 192-bit key | |
+---------+--------+----------+-------------+-------------+
| A256CBC | -65529 | 256 | AES-CBC w/ | Deprecated |
| | | | 256-bit key | |
+---------+--------+----------+-------------+-------------+
Table 2
COSE libraries that support either AES-CTR or AES-CBC and accept Additional Authenticated Data (AAD) as input MUST return an error if one of these non-AEAD content encryption algorithms is selected. This ensures that a caller does not expect the AAD to be protected when the cryptographic algorithm is unable to do so.
AES-CTRまたはAES-CBCのいずれかをサポートし、入力として追加の認証データ（AAD）を受け入れるCOSEライブラリは、これらの非AEADコンテンツ暗号化アルゴリズムのいずれかが選択されている場合、エラーを返す必要があります。これにより、暗号化アルゴリズムがそうすることができない場合、発信者がAADが保護されることを期待しないことが保証されます。
IANA has registered six COSE algorithm identifiers for AES-CTR and AES-CBC in the "COSE Algorithms" registry [IANA-COSE].
IANAは、「COSEアルゴリズム」レジストリ[IANA-COSE]にAES-CTRおよびAES-CBCの6つのCOSEアルゴリズム識別子を登録しています。
The information for the six COSE algorithm identifiers is provided in Sections 4.2 and 5.2. Also, for all six entries, the "Capabilities" column contains "[kty]", the "Change Controller" column contains "IETF", and the "Reference" column contains a reference to this document.
6つのCOSEアルゴリズム識別子の情報は、セクション4.2および5.2に記載されています。また、6つのエントリすべてについて、「機能」列には「[kty]」が含まれ、「Change Controller」列には「IETF」が含まれ、「参照」列にはこのドキュメントへの参照が含まれています。
This document specifies AES-CTR and AES-CBC for COSE, which are not AEAD ciphers. The use of the ciphers is limited to special use cases, such as firmware encryption, where integrity and authentication is provided by another mechanism.
このドキュメントは、COSE用のAES-CTRとAES-CBCを指定していますが、これは暗号ではありません。暗号の使用は、別のメカニズムによって完全性と認証が提供されるファームウェア暗号化などの特別なユースケースに限定されています。
Since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Implementations should change the key before reaching this limit.
AESのブロックサイズは128ビットサイズであるため、使用されているモードに関係なく、AES暗号化によって生成される暗号文は、2^64ブロックが単一のキーで暗号化された後、ランダム値と区別できます。実装は、この制限に達する前にキーを変更する必要があります。
To avoid cross-protocol concerns, implementations MUST NOT use the same keying material with more than one mode. For example, the same keying material must not be used with AES-CTR and AES-CBC.
プロトコル間の懸念を回避するために、実装は複数のモードで同じキーイング素材を使用してはなりません。たとえば、同じキーイング材料をAES-CTRおよびAES-CBCで使用しないでください。
There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES-CTR and AES-CBC is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks.
すべてのブロック暗号モードに対してかなり一般的な事前計算攻撃があり、キーに対する中間攻撃を可能にします。これらの攻撃では、既知のプレーンテキストおよび既知のキーに関連付けられた暗号文の巨大なテーブルの作成と検索が必要です。メモリとプロセッサのリソースが事前計算攻撃に利用できると仮定すると、AES-CTRとAES-CBCの理論的強度は2^（n/2）ビットに制限されます。ここで、nはキー内のビット数です。長いキーを使用することは、事前計算攻撃に対する最良の対策です。
When used properly, AES-CTR mode provides strong confidentiality. Unfortunately, it is very easy to misuse this counter mode. If counter block values are ever used for more than one plaintext with the same key, then the same key stream will be used to encrypt both plaintexts, and the confidentiality guarantees are voided.
適切に使用すると、AES-CTRモードは強力な機密性を提供します。残念ながら、このカウンターモードを誤用するのは非常に簡単です。カウンターブロック値が同じキーを持つ複数のプレーンテキストに使用される場合、同じキーストリームを使用して両方のプレーンテキストを暗号化し、機密性の保証が無効になります。
What happens if the encryptor XORs the same key stream with two different plaintexts? Suppose two plaintext octet sequences P1, P2, P3 and Q1, Q2, Q3 are both encrypted with key stream K1, K2, K3. The two corresponding ciphertexts are:
暗号化者が2つの異なるプレーンテキストを備えた同じキーストリームをXorした場合はどうなりますか？2つのプレーンテキストオクテットシーケンスP1、P2、P3、Q1、Q2、Q3が両方ともキーストリームK1、K2、K3で暗号化されているとします。対応する2つの暗号文は次のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 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, since:
これらの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つのプレーンテキストを暗号化すると、プレーンテキストが漏れます。
Data forgery is trivial with AES-CTR mode. The demonstration of this attack is similar to the key stream reuse discussion above. If a known plaintext octet sequence P1, P2, P3 is encrypted with key stream K1, K2, K3, then the attacker can replace the plaintext with one of its own choosing. The ciphertext is:
データ偽造は、AES-CTRモードで些細なことです。この攻撃のデモンストレーションは、上記のキーストリーム再利用の議論に似ています。既知のプレーンテキストオクテットシーケンスP1、P2、P3がキーストリームK1、K2、K3で暗号化されている場合、攻撃者はプレーンテキストを独自の選択の1つに置き換えることができます。ciphertextは次のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
The attacker simply XORs a selected sequence Q1, Q2, Q3 with the ciphertext to obtain:
攻撃者は、選択したシーケンスQ1、Q2、Q3をXARSでXORSするだけで、取得します。
(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
Which is the same as:
これは次と同じです。
((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)
Decryption of the attacker-generated ciphertext will yield exactly what the attacker intended:
攻撃者が生成した暗号文の復号化は、攻撃者が意図したものを正確に生成します。
(Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)
AES-CBC does not provide integrity protection. Thus, an attacker can introduce undetectable errors if AES-CBC is used without a companion authentication mechanism.
AES-CBCは整合性保護を提供しません。したがって、攻撃者は、コンパニオン認証メカニズムなしでAES-CBCが使用される場合、検出不能なエラーを導入できます。
If an attacker is able to strip the authentication and integrity mechanism, then the attacker can replace it with one of their own creation, even without knowing the plaintext. The usual defense against such an attack is an Authenticated Encryption with Associated Data (AEAD) algorithm [RFC5116]. Of course, neither AES-CTR nor AES-CBC is an AEAD. Thus, an implementation should provide integrity protection for the 'kid' field to prevent undetected stripping of the authentication and integrity mechanism; this prevents an attacker from altering the 'kid' to trick the recipient into using a different key.
攻撃者が認証と整合性のメカニズムを剥奪できる場合、攻撃者は、プレーンテキストを知らなくても、自分の作成の1つに置き換えることができます。このような攻撃に対する通常の防御は、関連するデータ（AEAD）アルゴリズム[RFC5116]を使用した認証された暗号化です。もちろん、AES-CTRもAES-CBCもAEADではありません。したがって、実装は、認証と完全性メカニズムの検出されない剥離を防ぐために、「KID」分野に完全性保護を提供する必要があります。これにより、攻撃者が「子供」を変更して、受信者が別のキーを使用してだましてしまうのを防ぎます。
With AES-CBC mode, implementers should perform integrity checks prior to decryption to avoid padding oracle vulnerabilities [Vaudenay].
AES-CBCモードを使用すると、実装者は復号化の前に整合性チェックを実行して、Oracleの脆弱性[Vaudenay]をパディングしないようにする必要があります。
With the assignment of COSE algorithm identifiers for AES-CTR and AES-CBC in the COSE Algorithms Registry, an attacker can replace the COSE algorithm identifiers with one of these identifiers. Then, the attacker might be able to manipulate the ciphertext to learn some of the plaintext or extract the keying material used for authentication and integrity.
COSEアルゴリズムレジストリにおけるAES-CTRおよびAES-CBCのCOSEアルゴリズム識別子の割り当てにより、攻撃者はCOSEアルゴリズム識別子をこれらの識別子のいずれかに置き換えることができます。次に、攻撃者は暗号文を操作して、平文の一部を学習したり、認証と整合性に使用されるキーイング素材を抽出できる場合があります。
Since AES-CCM [RFC3610] and AES-GCM [GCMMODE] use AES-CTR for encryption, an attacker can switch the algorithm identifier to AES-CTR and then strip the authentication tag to bypass the authentication and integrity, allowing the attacker to manipulate the ciphertext.
AES-CCM [RFC3610]およびAES-GCM [GCMMODE]を使用してAES-CTRを暗号化に使用するため、攻撃者はアルゴリズム識別子をAES-CTRに切り替えてから認証タグを剥がして認証と整合性をバイパスでき、攻撃者が操作できるようになります。暗号文。
An attacker can switch the algorithm identifier from AES-GCM to AES-CBC, guessing 16 bytes of plaintext at a time, and see if the recipient accepts the padding. Padding oracle vulnerabilities are discussed further in [Vaudenay].
攻撃者は、アルゴリズム識別子をAES-GCMからAES-CBCに切り替えて、一度に16バイトのプレーンテキストを推測し、受信者がパディングを受け入れるかどうかを確認できます。パディングオラクルの脆弱性については、[Vaudenay]でさらに説明しています。
[AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", NIST FIPS 197,
DOI 10.6028/NIST.FIPS.197-upd1, May 2023,
<https://doi.org/10.6028/NIST.FIPS.197-upd1>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques", NIST Special
Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December
2001, <https://doi.org/10.6028/NIST.SP.800-38A>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[GCMMODE] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
November 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.
[IANA-COSE]
IANA, "CBOR Object Signing and Encryption (COSE)",
<https://www.iana.org/assignments/cose>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <https://www.rfc-editor.org/info/rfc3610>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[SUIT-MANIFEST]
Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and
Ø. Rønningstad, "A Concise Binary Object Representation
(CBOR)-based Serialization Format for the Software Updates
for Internet of Things (SUIT) Manifest", Work in Progress,
Internet-Draft, draft-ietf-suit-manifest-22, 27 February
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
suit-manifest-22>.
[Vaudenay] Vaudenay, S., "Security Flaws Induced by CBC Padding --
Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002,
2002, <https://www.iacr.org/cryptodb/archive/2002/
EUROCRYPT/2850/2850.pdf>.
Many thanks to David Brown for raising the need for non-AEAD algorithms to support encryption within the SUIT manifest. Many thanks to Ilari Liusvaara, Scott Arciszewski, John Preuß Mattsson, Laurence Lundblade, Paul Wouters, Roman Danyliw, Sophie Schmieg, Stephen Farrell, Carsten Bormann, Scott Fluhrer, Brendan Moran, and John Scudder for the review and thoughtful comments.
スーツマニフェスト内の暗号化をサポートするために非AEADアルゴリズムの必要性を高めてくれたDavid Brownに感謝します。Ilari Liusvaara、Scott Arciszewski、JohnPreußmattsson、Laurence Lundblade、Paul Wouters、Roman Danyw、Sophie Schmieg、Stephen Farrell、Carsten Bormann、Scott Flurer、Brendan Moran、John Scudderのレビューと思慮深いコメントに感謝します。
Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
Hannes Tschofenig
Email: hannes.tschofenig@gmx.net