Status of This Memo

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.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9459.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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.¶

Table of Contents

1.Introduction

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 AuthenticatedEncryption with Associated Data (AEAD) algorithms[RFC5116], which provideboth confidentiality and integrity protection. However, there are situationswhere another mechanism, such as a digital signature, is used to provideintegrity. In these cases, an AEAD algorithm is not needed. The softwaremanifest being defined by the IETF SUIT WG[SUIT-MANIFEST] is oneexample where a digital signature is always present.¶

2.Conventions and Terminology

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.¶

3.AES Modes of Operation

NIST has defined several modes of operation for the Advanced EncryptionStandard[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).¶

Only AES Counter (AES-CTR) mode and AES Cipher Block Chaining (AES-CBC) arediscussed in this document.¶

4.AES Counter Mode

When AES-CTR is used as a COSE content encryption algorithm, theencryptor generates a unique value that is communicated to thedecryptor. This value is called an "Initialization Vector" (or "IV") in thisdocument. The same IV and AES key combinationMUST NOT be used morethan once. The encryptor can generate the IV in any manner that ensuresthe same IV value is not used more than once with the same AES key.¶

When using AES-CTR, each AES encrypt operation generates 128 bits of keystream. AES-CTR encryption is the XOR of the key stream with theplaintext. AES-CTR decryption is the XOR of the key stream with theciphertext. If the generated key stream is longer than the plaintext orciphertext, 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 has many properties that make it an attractive COSE content encryptionalgorithm. AES-CTR uses the AES block cipher to create a stream cipher. Datais encrypted and decrypted by XORing with the key stream produced by AES encrypting sequential IV block values, called "counter blocks", where:¶

• The first block of the key stream is the AES encryption of the IV.¶
• The second block of the key stream is the AES encryption of (IV + 1) mod 2¹²⁸.¶
• The third block ofthe key stream is the AES encryption of (IV + 2) mod 2¹²⁸, and so on.¶

AES-CTRis easy to implement, can be pipelined and parallelized, and supports key stream precomputation. Sending of the IV is the onlysource of expansion because the plaintext and ciphertext are the same size.¶

When used correctly, AES-CTR provides a high level of confidentiality.Unfortunately, AES-CTR is easy to use incorrectly. Being a streamcipher, reuse of the IV with the same key is catastrophic. An IVcollision immediately leaks information about the plaintext. Forthis reason, it is inappropriate to use AES-CTR with statickeys. Extraordinary measures would be needed to prevent reuse of anIV value with the static key across power cycles. To be safe,implementationsMUST use fresh keys with AES-CTR.¶

AES-CTR keys may be obtained either from a key structure or from a recipientstructure. Implementations encrypting and decryptingMUST validate that thekey type, key length, and algorithm are correct and appropriate for theentities involved.¶

With AES-CTR, it is trivial to use a valid ciphertext to forge other(valid to the decryptor) ciphertexts. Thus, it is equally catastrophic touse AES-CTR without a companion authentication and integritymechanism. ImplementationsMUST use AES-CTR in conjunction with anauthentication and integrity mechanism, such as a digital signature.¶

The instructions inSection 5.4 of [RFC9052] are followed for AES-CTR.Since AES-CTR cannot provide integrity protection for external additionalauthenticated data, the decryptorMUST ensure that no external additional authenticated data was supplied. SeeSection 6.¶

The 'protected' headerMUST be a zero-length byte string.¶

5.AES Cipher Block Chaining Mode

AES-CBC mode requires a 16-octet IV. Use of arandomly or pseudorandomly generated IV ensures that the encryption of thesame plaintext will yield different ciphertext.¶

AES-CBC performs an XOR of the IV with the first plaintext block before itis encrypted. For successive blocks, AES-CBC performs an XOR of the previousciphertext block with the current plaintext before it is encrypted.¶

AES-CBC requires padding of the plaintext; the padding algorithm specifiedinSection 6.3 of [RFC5652]MUST be used prior to encrypting theplaintext. This padding algorithm allows the decryptor to unambiguouslyremove the padding.¶

The simplicity of AES-CBC makes it an attractive COSE content encryptionalgorithm. The need to carry an IV and the need for padding lead to anincrease in the overhead (when compared to AES-CTR). AES-CBC is much saferfor use with static keys than AES-CTR. That said, as described in[RFC4107],the use of automated key management to generate fresh keys is greatlypreferred.¶

AES-CBC does not provide integrity protection. Thus, an attackercan introduce undetectable errors if AES-CBC is used without a companionauthentication and integrity mechanism. ImplementationsMUST use AES-CBCin conjunction with an authentication and integrity mechanism, such as adigital signature.¶

The instructions inSection 5.4 of [RFC9052] are followed for AES-CBC.Since AES-CBC cannot provide integrity protection for external additionalauthenticated data, the decryptorMUST ensure that no external additional authenticated data was supplied. SeeSection 6.¶

The 'protected' headerMUST be a zero-length byte string.¶

6.Implementation Considerations

COSE libraries that support either AES-CTR or AES-CBC and acceptAdditional Authenticated Data (AAD) as inputMUST return anerror if one of these non-AEAD content encryption algorithms isselected. This ensures that a caller does not expect the AADto be protected when the cryptographic algorithm is unable to do so.¶

7.IANA Considerations

IANA has registered six COSE algorithm identifiers for AES-CTR andAES-CBC in the "COSE Algorithms" registry[IANA-COSE].¶

The information for the six COSE algorithm identifiers is provided inSections4.2 and5.2. Also, for all six entries, the"Capabilities" column contains "[kty]", the "Change Controller"column contains "IETF", and the "Reference" column containsa reference to this document.¶

8.Security Considerations

This document specifies AES-CTR and AES-CBC for COSE, which are notAEAD 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.¶

Since AES has a 128-bit block size, regardless of the modeemployed, the ciphertext generated by AES encryption becomesdistinguishable from random values after 2⁶⁴ blocks are encryptedwith a single key. Implementations should change the key beforereaching this limit.¶

To avoid cross-protocol concerns, implementationsMUST NOT use the samekeying material with more than one mode. For example, the same keyingmaterial must not be used with AES-CTR and AES-CBC.¶

There are fairly generic precomputation attacks against all block ciphermodes that allow a meet-in-the-middle attack against the key. These attacksrequire the creation and searching of huge tables of ciphertext associatedwith known plaintext and known keys. Assuming that the memory and processorresources are available for a precomputation attack, then the theoreticalstrength of AES-CTR and AES-CBC is limited to 2^(n/2) bits, where n is thenumber of bits in the key. The use of long keys is the best countermeasureto precomputation attacks.¶

When used properly, AES-CTR mode provides strong confidentiality. Unfortunately,it is very easy to misuse this counter mode. If counter block values are everused for more than one plaintext with the same key, then the same key streamwill be used to encrypt both plaintexts, and the confidentiality guarantees arevoided.¶

What happens if the encryptor XORs the same key stream with two differentplaintexts? Suppose two plaintext octet sequences P1, P2, P3 and Q1, Q2, Q3are both encrypted with key stream K1, K2, K3. The two correspondingciphertexts are:¶

   (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 acatastrophic failure of confidentiality results, since:¶

   (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 relativelystraightforward to separate them. Thus, using any stream cipher, includingAES-CTR, to encrypt two plaintexts under the same key stream leaks theplaintext.¶

Data forgery is trivial with AES-CTR mode. The demonstration of this attackis similar to the key stream reuse discussion above. If a known plaintextoctet sequence P1, P2, P3 is encrypted with key stream K1, K2, K3, then theattacker can replace the plaintext with one of its own choosing. Theciphertext is:¶

   (P1 XOR K1), (P2 XOR K2), (P3 XOR K3)

The attacker simply XORs a selected sequence Q1, Q2, Q3 with theciphertext to obtain:¶

   (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 whatthe attacker intended:¶

   (Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)

AES-CBC does not provide integrity protection. Thus, an attackercan introduce undetectable errors if AES-CBC is used without a companion authentication mechanism.¶

If an attacker is able to strip the authentication and integrity mechanism,then the attacker can replace it with one of their own creation, evenwithout knowing the plaintext. The usual defense against such an attack isan 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' fieldto prevent undetected stripping of the authentication and integritymechanism; this prevents an attacker from altering the 'kid' to trick therecipient into using a different key.¶

With AES-CBC mode, implementers should perform integrity checks prior todecryption to avoid padding oracle vulnerabilities[Vaudenay].¶

With the assignment of COSE algorithm identifiers for AES-CTR andAES-CBC in the COSE Algorithms Registry, an attacker can replace theCOSE algorithm identifiers with one of these identifiers. Then, theattacker might be able to manipulate the ciphertext to learn some of theplaintext or extract the keying material used for authentication andintegrity.¶

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 theauthentication tag to bypass the authentication and integrity, allowing the attacker to manipulate the ciphertext.¶

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 recipientaccepts the padding. Padding oracle vulnerabilities are discussedfurther in[Vaudenay].¶

Acknowledgements

Many thanks toDavid Brown for raising the need for non-AEAD algorithmsto support encryption within the SUIT manifest. Many thanks toIlari Liusvaara,Scott Arciszewski,John Preuß Mattsson,Laurence Lundblade,Paul Wouters,Roman Danyliw,Sophie Schmieg,Stephen Farrell,Carsten Bormann,Scott Fluhrer,Brendan Moran, andJohn Scudderfor the review and thoughtful comments.¶

Authors' Addresses