rfc9459.original   rfc9459.txt 
COSE R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9459 Vigil Security
Intended status: Standards Track H. Tschofenig Category: Standards Track H. Tschofenig
Expires: 26 November 2023 Arm Limited ISSN: 2070-1721 September 2023
25 May 2023
CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC
draft-ietf-cose-aes-ctr-and-cbc-06
Abstract Abstract
The Concise Binary Object Representation (CBOR) data format is The Concise Binary Object Representation (CBOR) data format is
designed for small code size and small message size. CBOR Object designed for small code size and small message size. CBOR Object
Signing and Encryption (COSE) is specified in RFC 9052 to provide Signing and Encryption (COSE) is specified in RFC 9052 to provide
basic security services using the CBOR data format. This document basic security services using the CBOR data format. This document
specifies the conventions for using AES-CTR and AES-CBC as Content specifies the conventions for using AES-CTR and AES-CBC as content
Encryption algorithms with COSE. encryption algorithms with COSE.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 26 November 2023. 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.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology
3. AES Modes of Operation . . . . . . . . . . . . . . . . . . . 3 3. AES Modes of Operation
4. AES Counter Mode . . . . . . . . . . . . . . . . . . . . . . 3 4. AES Counter Mode
4.1. AES-CTR COSE Key . . . . . . . . . . . . . . . . . . . . 4 4.1. AES-CTR COSE Key
4.2. AES-CTR COSE Algorithm Identifiers . . . . . . . . . . . 5 4.2. AES-CTR COSE Algorithm Identifiers
5. AES Cipher Block Chaining Mode . . . . . . . . . . . . . . . 5 5. AES Cipher Block Chaining Mode
5.1. AES-CBC COSE Key . . . . . . . . . . . . . . . . . . . . 6 5.1. AES-CBC COSE Key
5.2. AES-CBC COSE Algoritm Identifiers . . . . . . . . . . . . 6 5.2. AES-CBC COSE Algorithm Identifiers
6. Implementation Considerations . . . . . . . . . . . . . . . . 7 6. Implementation Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
This document specifies the conventions for using AES-CTR and AES-CBC This document specifies the conventions for using AES-CTR and AES-CBC
as Content Encryption algorithms with the CBOR Object Signing and as content encryption algorithms with the CBOR Object Signing and
Encryption (COSE) [RFC9052] syntax. Encryption with COSE today uses Encryption (COSE) [RFC9052] syntax. Today, encryption with COSE uses
Authenticated Encryption with Associated Data (AEAD) [RFC5116] Authenticated Encryption with Associated Data (AEAD) algorithms
algorithms, which provide both confidentiality and integrity [RFC5116], which provide both confidentiality and integrity
protection. However, there are situations where another mechanism, protection. However, there are situations where another mechanism,
such as a digital signature, is used to provide integrity. In these such as a digital signature, is used to provide integrity. In these
cases, an AEAD algorithm is not needed. The software manifest being cases, an AEAD algorithm is not needed. The software manifest being
defined by the IETF SUIT WG [I-D.ietf-suit-manifest] is one example defined by the IETF SUIT WG [SUIT-MANIFEST] is one example where a
where a digital signature is always present. digital signature is always present.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. AES Modes of Operation 3. AES Modes of Operation
NIST has defined several modes of operation for Advanced Encryption NIST has defined several modes of operation for the Advanced
Standard (AES) [AES] [MODES]. AES supports three key sizes: 128 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 bits, 192 bits, and 256 bits. AES has a block size of 128 bits (16
octets). Each of these modes has different characteristics. The octets). Each of these modes has different characteristics. The
modes include: CBC (Cipher Block Chaining), CFB (Cipher FeedBack), modes include: CBC (Cipher Block Chaining), CFB (Cipher FeedBack),
OFB (Output FeedBack), and CTR (Counter). OFB (Output FeedBack), and CTR (Counter).
Only AES Counter mode (AES-CTR) and AES Cipher Block Chaining (AES- Only AES Counter (AES-CTR) mode and AES Cipher Block Chaining (AES-
CBC) are discussed in this document. CBC) are discussed in this document.
4. AES Counter Mode 4. AES Counter Mode
When AES-CTR is used as a COSE Content Encryption algorithm, the When AES-CTR is used as a COSE content encryption algorithm, the
encryptor generates a unique value that is communicated to the encryptor generates a unique value that is communicated to the
decryptor. This value is called an initialization vector (IV) in decryptor. This value is called an "Initialization Vector" (or "IV")
this document. The same IV and AES key combination MUST NOT be used in this document. The same IV and AES key combination MUST NOT be
more than once. The encryptor can generate the IV in any manner that used more than once. The encryptor can generate the IV in any manner
ensures the same IV value is not used more than once with the same that ensures the same IV value is not used more than once with the
AES key. same AES key.
When using AES-CTR, each AES encrypt operation generates 128 bits of 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 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 plaintext. AES-CTR decryption is the XOR of the key stream with the
ciphertext. If the generated key stream is longer than the plaintext ciphertext. If the generated key stream is longer than the plaintext
or ciphertext, the extra key stream bits are simply discarded. For 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 this reason, AES-CTR does not require the plaintext to be padded to a
multiple of the block size. multiple of the block size.
AES-CTR has many properties that make it an attractive COSE Content AES-CTR has many properties that make it an attractive COSE content
Encryption algorithm. AES-CTR uses the AES block cipher to create a encryption algorithm. AES-CTR uses the AES block cipher to create a
stream cipher. Data is encrypted and decrypted by XORing with the stream cipher. Data is encrypted and decrypted by XORing with the
key stream produced by AES encrypting sequential IV block values, key stream produced by AES encrypting sequential IV block values,
called counter blocks. The first block of the key stream is the AES called "counter blocks", where:
encryption of the IV, the second block of the key stream is the AES
encryption of (IV + 1) mod 2^128, the third block of the key stream * The first block of the key stream is the AES encryption of the IV.
is the AES encryption of (IV + 2) mod 2^128, and so on. AES-CTR is
easy to implement, and AES-CTR can be pipelined and parallelized. * The second block of the key stream is the AES encryption of (IV +
AES-CTR also supports key stream precomputation. Sending of the IV 1) mod 2^128.
is the only source of expansion because the plaintext and ciphertext
are the same size. * The third block of the key stream is the AES encryption of (IV +
2) mod 2^128, and so on.
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.
When used correctly, AES-CTR provides a high level of When used correctly, AES-CTR provides a high level of
confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. confidentiality. Unfortunately, AES-CTR is easy to use incorrectly.
Being a stream cipher, reuse of the IV with the same key is Being a stream cipher, reuse of the IV with the same key is
catastrophic. An IV collision immediately leaks information about catastrophic. An IV collision immediately leaks information about
the plaintext. For this reason, it is inappropriate to use AES-CTR the plaintext. For this reason, it is inappropriate to use AES-CTR
with static keys. Extraordinary measures would be needed to prevent with static keys. Extraordinary measures would be needed to prevent
reuse of an IV value with the static key across power cycles. To be reuse of an IV value with the static key across power cycles. To be
safe, implementations MUST use fresh keys with AES-CTR. safe, implementations MUST use fresh keys with AES-CTR.
skipping to change at page 4, line 44 skipping to change at line 163
catastrophic to use AES-CTR without a companion authentication and catastrophic to use AES-CTR without a companion authentication and
integrity mechanism. Implementations MUST use AES-CTR in conjunction integrity mechanism. Implementations MUST use AES-CTR in conjunction
with an authentication and integrity mechanism, such as a digital with an authentication and integrity mechanism, such as a digital
signature. signature.
The instructions in Section 5.4 of [RFC9052] are followed for AES- The instructions in Section 5.4 of [RFC9052] are followed for AES-
CTR. Since AES-CTR cannot provide integrity protection for external CTR. Since AES-CTR cannot provide integrity protection for external
additional authenticated data, the decryptor MUST ensure that no additional authenticated data, the decryptor MUST ensure that no
external additional authenticated data was supplied. See Section 6. external additional authenticated data was supplied. See Section 6.
The 'protected' header MUST be a zero-length byte string.
4.1. AES-CTR COSE Key 4.1. AES-CTR COSE Key
When using a COSE key for the AES-CTR algorithm, the following checks When using a COSE key for the AES-CTR algorithm, the following checks
are made: are made:
* The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
* If the 'alg' field is present, it MUST match the AES-CTR algorithm * If the 'alg' field is present, it MUST match the AES-CTR algorithm
being used. being used.
* If the 'key_ops' field is present, it MUST include 'encrypt' when * If the 'key_ops' field is present, it MUST include 'encrypt' when
encrypting. encrypting.
* If the 'key_ops' field is present, it MUST include 'decrypt' when * If the 'key_ops' field is present, it MUST include 'decrypt' when
decrypting. decrypting.
In addition, the 'protected' header parameters encoded value MUST be
a zero-length byte string.
4.2. AES-CTR COSE Algorithm Identifiers 4.2. AES-CTR COSE Algorithm Identifiers
The following table defines the COSE AES-CTR algorithm values. Note The following table defines the COSE AES-CTR algorithm values. Note
that these algorithms are being registered as "Deprecated" to avoid that these algorithms are being registered as "Deprecated" to avoid
accidental use without a companion integrity protection mechanism. accidental use without a companion integrity protection mechanism.
+=========+=======+==========+========================+=============+ +=========+========+==========+=============+=============+
| Name | Value | Key Size | Description | Recommended | | Name | Value | Key Size | Description | Recommended |
+=========+=======+==========+========================+=============+ +=========+========+==========+=============+=============+
| A128CTR | TBD1 | 128 | AES-CTR w/ | Deprecated | | A128CTR | -65534 | 128 | AES-CTR w/ | Deprecated |
| | | | 128-bit key | | | | | | 128-bit key | |
+---------+-------+----------+------------------------+-------------+ +---------+--------+----------+-------------+-------------+
| A192CTR | TBD2 | 192 | AES-CTR w/ | Deprecated | | A192CTR | -65533 | 192 | AES-CTR w/ | Deprecated |
| | | | 192-bit key | | | | | | 192-bit key | |
+---------+-------+----------+------------------------+-------------+ +---------+--------+----------+-------------+-------------+
| A256CTR | TBD3 | 256 | AES-CTR w/ | Deprecated | | A256CTR | -65532 | 256 | AES-CTR w/ | Deprecated |
| | | | 256-bit key | | | | | | 256-bit key | |
+---------+-------+----------+------------------------+-------------+ +---------+--------+----------+-------------+-------------+
Table 1 Table 1
5. AES Cipher Block Chaining Mode 5. AES Cipher Block Chaining Mode
AES-CBC mode requires an 16 octet Initialization Vector (IV). Use of AES-CBC mode requires a 16-octet IV. Use of a randomly or
a randomly or pseudo-randomly generated IV ensures that the pseudorandomly generated IV ensures that the encryption of the same
encryption of the same plaintext will yield different ciphertext. plaintext will yield different ciphertext.
AES-CBC performs an XOR of the IV with the first plaintext block AES-CBC performs an XOR of the IV with the first plaintext block
before it is encrypted. For successive blocks, AES-CBC performs an before it is encrypted. For successive blocks, AES-CBC performs an
XOR of previous ciphertext block with the current plaintext before it XOR of the previous ciphertext block with the current plaintext
is encrypted. before it is encrypted.
AES-CBC requires padding of the plaintext; the padding algorithm AES-CBC requires padding of the plaintext; the padding algorithm
specified in Section 6.3 of [RFC5652] MUST be used prior to specified in Section 6.3 of [RFC5652] MUST be used prior to
encrypting the plaintext. This padding algorithm allows the encrypting the plaintext. This padding algorithm allows the
decryptor to unambiguously remove the padding. decryptor to unambiguously remove the padding.
The simplicity of AES-CBC makes it an attractive COSE Content The simplicity of AES-CBC makes it an attractive COSE content
Encryption algorithm. The need to carry an IV and the need for encryption algorithm. The need to carry an IV and the need for
padding lead to an increase in the overhead (when compared to AES- 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. 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 That said, as described in [RFC4107], the use of automated key
management to generate fresh keys is greatly preferred. management to generate fresh keys is greatly preferred.
AES-CBC does not provide integrity protection. Thus, an attacker can AES-CBC does not provide integrity protection. Thus, an attacker can
introduce undetectable errors if AES-CBC is used without a companion introduce undetectable errors if AES-CBC is used without a companion
authentication and integrity mechanism. Implementations MUST use authentication and integrity mechanism. Implementations MUST use
AES-CBC in conjunction with an authentication and integrity AES-CBC in conjunction with an authentication and integrity
mechanism, such as a digital signature. mechanism, such as a digital signature.
The instructions in Section 5.4 of [RFC9052] are followed for AES- The instructions in Section 5.4 of [RFC9052] are followed for AES-
CBC. Since AES-CBC cannot provide integrity protection for external CBC. Since AES-CBC cannot provide integrity protection for external
additional authenticated data, the decryptor MUST ensure that no additional authenticated data, the decryptor MUST ensure that no
external additional authenticated data was supplied. See Section 6. external additional authenticated data was supplied. See Section 6.
The 'protected' header MUST be a zero-length byte string.
5.1. AES-CBC COSE Key 5.1. AES-CBC COSE Key
When using a COSE key for the AES-CBC algorithm, the following checks When using a COSE key for the AES-CBC algorithm, the following checks
are made: are made:
* The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
* If the 'alg' field is present, it MUST match the AES-CBC algorithm * If the 'alg' field is present, it MUST match the AES-CBC algorithm
being used. being used.
* If the 'key_ops' field is present, it MUST include 'encrypt' when * If the 'key_ops' field is present, it MUST include 'encrypt' when
encrypting. encrypting.
* If the 'key_ops' field is present, it MUST include 'decrypt' when * If the 'key_ops' field is present, it MUST include 'decrypt' when
decrypting. decrypting.
In addition, the 'protected' header parameters encoded value MUST be 5.2. AES-CBC COSE Algorithm Identifiers
a zero-length byte string.
5.2. AES-CBC COSE Algoritm Identifiers
The following table defines the COSE AES-CBC algorithm values. Note The following table defines the COSE AES-CBC algorithm values. Note
that these algorithms are being registered as "Deprecated" to avoid that these algorithms are being registered as "Deprecated" to avoid
accidental use without a companion integrity protection mechanism. accidental use without a companion integrity protection mechanism.
+=========+=======+==========+========================+=============+ +=========+========+==========+=============+=============+
| Name | Value | Key Size | Description | Recommended | | Name | Value | Key Size | Description | Recommended |
+=========+=======+==========+========================+=============+ +=========+========+==========+=============+=============+
| A128CBC | TBD4 | 128 | AES-CBC w/ | Deprecated | | A128CBC | -65531 | 128 | AES-CBC w/ | Deprecated |
| | | | 128-bit key | | | | | | 128-bit key | |
+---------+-------+----------+------------------------+-------------+ +---------+--------+----------+-------------+-------------+
| A192CBC | TBD5 | 192 | AES-CBC w/ | Deprecated | | A192CBC | -65530 | 192 | AES-CBC w/ | Deprecated |
| | | | 192-bit key | | | | | | 192-bit key | |
+---------+-------+----------+------------------------+-------------+ +---------+--------+----------+-------------+-------------+
| A256CBC | TBD6 | 256 | AES-CBC w/ | Deprecated | | A256CBC | -65529 | 256 | AES-CBC w/ | Deprecated |
| | | | 256-bit key | | | | | | 256-bit key | |
+---------+-------+----------+------------------------+-------------+ +---------+--------+----------+-------------+-------------+
Table 2 Table 2
6. Implementation Considerations 6. Implementation Considerations
COSE libraries that support either AES-CTR or AES-CBC and accept COSE libraries that support either AES-CTR or AES-CBC and accept
Additional Authenticated Data (AAD) as input MUST return an error if Additional Authenticated Data (AAD) as input MUST return an error if
one of these non-AEAD content encryption algorithm is selected. This one of these non-AEAD content encryption algorithms is selected.
ensures that a caller does not expect the AAD to be protected when This ensures that a caller does not expect the AAD to be protected
the cryptographic algorithm is unable to do so. when the cryptographic algorithm is unable to do so.
7. IANA Considerations 7. IANA Considerations
IANA is requested to register six COSE algorithm identifiers for AES- IANA has registered six COSE algorithm identifiers for AES-CTR and
CTR and AES-CBC in the COSE Algorithms Registry [IANA]. AES-CBC in the "COSE Algorithms" registry [IANA-COSE].
The information for the six COSE algorithm identifiers is provided in The information for the six COSE algorithm identifiers is provided in
Section 4.2 and Section 5.2. Also, for all six entries, the Sections 4.2 and 5.2. Also, for all six entries, the "Capabilities"
"Capabilities" column should contain "[kty]", the "Change Controller" column contains "[kty]", the "Change Controller" column contains
column should contain "IESG", and the "Reference" column should "IETF", and the "Reference" column contains a reference to this
contain a reference to this document. document.
Ideally, the six values will be assigned in the -65534 to -261 range.
8. Security Considerations 8. Security Considerations
This document specifies AES-CTR and AES-CBC for COSE, which are not This document specifies AES-CTR and AES-CBC for COSE, which are not
authenticated encryption with additional data (AEAD) ciphers. The AEAD ciphers. The use of the ciphers is limited to special use
use of the ciphers is limited to special use cases where integrity cases, such as firmware encryption, where integrity and
and authentication is provided by another mechanism, such as firmware authentication is provided by another mechanism.
encryption.
Since AES has a 128-bit block size, regardless of the mode employed, Since AES has a 128-bit block size, regardless of the mode employed,
the ciphertext generated by AES encryption becomes distinguishable the ciphertext generated by AES encryption becomes distinguishable
from random values after 2^64 blocks are encrypted with a single key. from random values after 2^64 blocks are encrypted with a single key.
Implementations should change the key before reaching this limit. Implementations should change the key before reaching this limit.
To avoid cross-protocol concerns, implementations MUST NOT use the To avoid cross-protocol concerns, implementations MUST NOT use the
same keying material with more than one mode. For example, the same same keying material with more than one mode. For example, the same
keying material must not be used with AES-CTR and AES-CBC. keying material must not be used with AES-CTR and AES-CBC.
There are fairly generic precomputation attacks against all block There are fairly generic precomputation attacks against all block
cipher modes that allow a meet-in-the-middle attack against the key. cipher modes that allow a meet-in-the-middle attack against the key.
These attacks require the creation and searching of huge tables of These attacks require the creation and searching of huge tables of
ciphertext associated with known plaintext and known keys. Assuming ciphertext associated with known plaintext and known keys. Assuming
that the memory and processor resources are available for a that the memory and processor resources are available for a
precomputation attack, then the theoretical strength of AES-CTR and precomputation attack, then the theoretical strength of AES-CTR and
AES-CBC are limited to 2^(n/2) bits, where n is the number of bits in 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 the key. The use of long keys is the best countermeasure to
precomputation attacks. precomputation attacks.
When used properly, AES-CTR mode provides strong confidentiality. When used properly, AES-CTR mode provides strong confidentiality.
Unfortunately, it is very easy to misuse this counter mode. If Unfortunately, it is very easy to misuse this counter mode. If
counter block values are ever used for more than one plaintext with 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 the same key, then the same key stream will be used to encrypt both
plaintexts, and the confidentiality guarantees are voided. plaintexts, and the confidentiality guarantees are voided.
What happens if the encryptor XORs the same key stream with two What happens if the encryptor XORs the same key stream with two
skipping to change at page 8, line 50 skipping to change at line 351
Once the attacker obtains the two plaintexts XORed together, it is Once the attacker obtains the two plaintexts XORed together, it is
relatively straightforward to separate them. Thus, using any stream relatively straightforward to separate them. Thus, using any stream
cipher, including AES-CTR, to encrypt two plaintexts under the same cipher, including AES-CTR, to encrypt two plaintexts under the same
key stream leaks the plaintext. key stream leaks the plaintext.
Data forgery is trivial with AES-CTR mode. The demonstration of this Data forgery is trivial with AES-CTR mode. The demonstration of this
attack is similar to the key stream reuse discussion above. If a attack is similar to the key stream reuse discussion above. If a
known plaintext octet sequence P1, P2, P3 is encrypted with key known plaintext octet sequence P1, P2, P3 is encrypted with key
stream K1, K2, K3, then the attacker can replace the plaintext with stream K1, K2, K3, then the attacker can replace the plaintext with
one of his own choosing. The ciphertext is: one of its own choosing. The ciphertext is:
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3) (P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
The attacker simply XORs a selected sequence Q1, Q2, Q3 with the The attacker simply XORs a selected sequence Q1, Q2, Q3 with the
ciphertext to obtain: ciphertext to obtain:
(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3)) (Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
Which is the same as: Which is the same as:
skipping to change at page 9, line 27 skipping to change at line 377
(Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3) (Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)
AES-CBC does not provide integrity protection. Thus, an attacker can AES-CBC does not provide integrity protection. Thus, an attacker can
introduce undetectable errors if AES-CBC is used without a companion introduce undetectable errors if AES-CBC is used without a companion
authentication mechanism. authentication mechanism.
If an attacker is able to strip the authentication and integrity If an attacker is able to strip the authentication and integrity
mechanism, then the attacker can replace it with one of their own mechanism, then the attacker can replace it with one of their own
creation, even without knowing the plaintext. The usual defense creation, even without knowing the plaintext. The usual defense
against such an attack is an Authenticated Encryption with Associated against such an attack is an Authenticated Encryption with Associated
Data (AEAD) [RFC5116] algorithm. Of course, neither AES-CTR nor AES- Data (AEAD) algorithm [RFC5116]. Of course, neither AES-CTR nor AES-
CBC is an AEAD. Thus, an implementation should provide integrity CBC is an AEAD. Thus, an implementation should provide integrity
protection for the kid field to prevent undetected stripping of the protection for the 'kid' field to prevent undetected stripping of the
authentication and integrity mechanism; this prevents an attacker authentication and integrity mechanism; this prevents an attacker
from altering the kid to trick the recipient into using a different from altering the 'kid' to trick the recipient into using a different
key. key.
With AES-CBC mode, implementers should perform integrity checks prior With AES-CBC mode, implementers should perform integrity checks prior
to decryption to avoid padding oracle vulnerabilities [Vaudenay]. to decryption to avoid padding oracle vulnerabilities [Vaudenay].
With the assignment of COSE algorithm identifiers for AES-CTR and With the assignment of COSE algorithm identifiers for AES-CTR and
AES-CBC in the COSE Algorithms Registry, an attacker can replace the AES-CBC in the COSE Algorithms Registry, an attacker can replace the
COSE algorithm identifiers with one of these identifiers. Then, the COSE algorithm identifiers with one of these identifiers. Then, the
attacker might be able to manipulate the ciphertext to learn some of attacker might be able to manipulate the ciphertext to learn some of
the plaintext or extract the keying material used for authentication the plaintext or extract the keying material used for authentication
and integrity. and integrity.
Since AES-CCM [RFC3610] and AES-GCM [GCMMODE] use AES-CTR for Since AES-CCM [RFC3610] and AES-GCM [GCMMODE] use AES-CTR for
encryption, an attacker can switch the algorithm identifier to AES- encryption, an attacker can switch the algorithm identifier to AES-
CTR, and then strip the authentication tag to bypass the CTR and then strip the authentication tag to bypass the
authentication and integrity, allowing the attacker to manipulate the authentication and integrity, allowing the attacker to manipulate the
ciphertext. ciphertext.
An attacker can switch the algorithm identifier from AES-GCM to AES- An attacker can switch the algorithm identifier from AES-GCM to AES-
CBC, guess of 16 bytes of plaintext at a time, and checking each CBC, guessing 16 bytes of plaintext at a time, and see if the
guess with padding oracle as discussed above. recipient accepts the padding. Padding oracle vulnerabilities are
discussed further in [Vaudenay].
9. Acknowledgements
Many thanks to David Brown for raising the need for non-AEAD
algorithms to support encryption within the SUIT manifest. Many
thanks to David Brown, Ilari Liusvaara, Scott Arciszewski, John Preuß
Mattsson, Laurence Lundblade, Paul Wouters, Roman Danyliw, and John
Scudder for the review and thoughtful comments.
10. References 9. References
10.1. Normative References 9.1. Normative References
[AES] National Institute of Standards and Technology (NIST), [AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS "Advanced Encryption Standard (AES)", NIST FIPS 197,
Publication 197, November 2001. 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 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques", NIST Special Operation: Methods and Techniques", NIST Special
Publication 800-38A, December 2001. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>. June 2005, <https://www.rfc-editor.org/info/rfc4107>.
skipping to change at page 10, line 47 skipping to change at line 441
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>. <https://www.rfc-editor.org/info/rfc9052>.
10.2. Informative References 9.2. Informative References
[GCMMODE] Dworkin, M., "Recommendation for Block Cipher Modes of [GCMMODE] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, November 2007. Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
November 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.
[I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and
O. 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>.
[IANA] "IANA Registry for CBOR Object Signing and Encryption [IANA-COSE]
(COSE)", n.d., IANA, "CBOR Object Signing and Encryption (COSE)",
<https://www.iana.org/assignments/cose/cose.xhtml>. <https://www.iana.org/assignments/cose>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <https://www.rfc-editor.org/info/rfc3610>. 2003, <https://www.rfc-editor.org/info/rfc3610>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[Vaudenay] Vaudenay, S., "Security Flaws Induced by CBC Padding [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, Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002,
2002, <https://www.iacr.org/cryptodb/archive/2002/ 2002, <https://www.iacr.org/cryptodb/archive/2002/
EUROCRYPT/2850/2850.pdf>. EUROCRYPT/2850/2850.pdf>.
Acknowledgements
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.
Authors' Addresses Authors' Addresses
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
Email: housley@vigilsec.com Email: housley@vigilsec.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Email: hannes.tschofenig@gmx.net
Email: hannes.tschofenig@arm.com
 End of changes. 46 change blocks. 
158 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.48.