CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC

Status of This Memo

This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 February 2023.¶

Copyright Notice

Copyright (c) 2022 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) [RFC8152] syntax. Encryption with COSE today uses Authenticated Encryption with Associated Data (AEAD) [RFC5116] algorithms, 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 [I-D.ietf-suit-manifest] is one example 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 five modes of operation for Advanced Encryption Standard (AES) [AES]. AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The AES has a block size of 128 bits (16 octets).¶

NIST has defined several modes of operation for use with AES [MODES]. Each of these modes has different characteristics. The five modes are: ECB (Electronic Code Book), CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter).¶

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

4. AES Counter Mode

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 (IV) in this document. 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.¶

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 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 counter block values. AES-CTR is easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation. While the IV must be communicated, 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 stream cipher, reuse of the IV with the same key is catastrophic. An IV collision immediately leaks information about the plaintext in both uses of AES-CTR. For this reason, it is inappropriate to use this mode of operation 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.¶

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

5. AES Cipher Block Chaining Mode

AES-CBC mode requires an 16 octet Initialization Vector (IV). Use of a randomly generated IV ensures that the encryption of the same plaintext will yield different ciphertext.¶

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 previous ciphertext block with the current plaintext before it is encrypted.¶

AES-CBC will require padding; 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.¶

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

6. IANA Considerations

IANA is requested to register six COSE algorithm identifiers for AES-CTR and AES-CBC in the COSE Algorithms Registry [IANA].¶

The information for the six COSE algorithm identifiers is provided in Section 4.1 and Section 5.1. Also, for all six entries, the "Capabilities" column should contain "[kty]", the "Change Controller" column should contain "IESG", and the "Reference" column should contain a reference to this document.¶

Ideally, the six values will be assigned in the -65534 to -261 range.¶

7. Security Considerations

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 before reaching this limit.¶

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

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 that one plaintext with the same key, then the same key stream will be used to encrypt both plaintexts, and the confidentiality guarantees are voided.¶

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

   (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:¶

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

Therefore, it is inappropriate to use AES-CTR with static keys. Extraordinary measures would be needed to prevent reuse of a counter block value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR.¶

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 his own choosing. The ciphertext is:¶

   (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 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)

Accordingly, implementations MUST use of AES-CTR in conjunction with an authentication and integrity mechanism, such as a digital signature.¶

AES-CBC does not provide integrity protection. Thus, an attacker can introduce undetectable errors if AES-CBC is used without a companion authentication mechanism. Accordingly, implementations MUST use of AES-CBC in conjunction with an authentication and integrity mechanism, such as a digital signature.¶

8. Acknowledgements

Many thanks to David Brown for raising the need for non-AEAD algorithms to support the SUIT manifest.¶

Authors' Addresses