RFC 9459

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

📅 published September 2023, from ietf

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

Okay bestie, here's the title block tea ☕ RFC 9459 is titled "CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC." It came out of the Internet Engineering Task Force (IETF), it's a Standards Track document, and it's dated September 2023. The ISSN is 2070-1721. The authors are R. Housley (Vigil Security) and H. Tschofenig 🦋 The title block doesn't list anything this RFC obsoletes or updates, so no drama there 🌸

Abstract 🫶

The Concise Binary Object Representation (CBOR) data format is built for small code size and small message size, which is so iconic 🧚 COSE (CBOR Object Signing and Encryption) is specified in RFC 9052 and gives you basic security services using CBOR. This doc is all about the rules for using AES-CTR and AES-CBC as content encryption algorithms with COSE 🔐

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 at https://www.rfc-editor.org/info/rfc9459.

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

1. Introduction 🌈

Okay so this doc sets the conventions for using AES-CTR and AES-CBC as content encryption algorithms with the CBOR Object Signing and Encryption (COSE) [RFC9052] syntax. Right now, COSE encryption uses Authenticated Encryption with Associated Data (AEAD) algorithms [RFC5116], which give you both confidentiality and integrity protection 💅 But there are situations where something else, like a digital signature, handles integrity. In those cases you don't need an AEAD algorithm. The software manifest being defined by the IETF SUIT WG [SUIT-MANIFEST] is one example where a digital signature is always present 🔥

2. Conventions and Terminology 📖

Here's the boilerplate that decides which key words count as requirements. Read it closely, it matters:

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 Encryption Standard [AES] [MODES]. AES comes in three key sizes: 128 bits, 192 bits, and 256 bits. AES has a block size of 128 bits (16 octets). Each mode has its own characteristics, and 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) are discussed in this document ✨

4. AES Counter Mode 💫

When AES-CTR is used as a COSE content encryption algorithm, the encryptor makes a unique value that gets 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 makes sure the same IV value is never used more than once with the same AES key.

Here's how the encryption works. Each AES encrypt operation generates 128 bits of key stream. AES-CTR encryption is the XOR of the key stream with the plaintext, and 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 just thrown away. That's why AES-CTR doesn't need the plaintext padded to a multiple of the block size 🍓

AES-CTR has a lot going for it as a COSE content encryption algorithm. It uses the AES block cipher to make a stream cipher. Data gets encrypted and decrypted by XORing with the key stream, which is made by AES encrypting sequential IV block values called "counter blocks":

  • 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^128.
  • 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 the IV is the only source of expansion, because the plaintext and ciphertext are the same size 🦋

When it's used correctly, AES-CTR gives a high level of confidentiality. BUT it's super easy to use incorrectly, so pay attention bestie 😭 Because it's a stream cipher, reusing an 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. You'd need extraordinary measures to stop an IV value from being reused with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR 🔑

AES-CTR keys can 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 🧐

With AES-CTR, it's trivial to take a valid ciphertext and use it to forge other ciphertexts that are still valid to the decryptor. So it's just as 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 🛡️

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 👀

The 'protected' header MUST be a zero-length byte string.

4.1. AES-CTR COSE Key 🗝️

When you use a COSE key for the AES-CTR algorithm, these checks happen:

  • The 'kty' field MUST be present, and it MUST be 'Symmetric'.
  • If the 'alg' field is present, it MUST match the AES-CTR algorithm being used.
  • If the 'key_ops' field is present, it MUST include 'encrypt' when encrypting.
  • If the 'key_ops' field is present, it MUST include 'decrypt' when decrypting.

4.2. AES-CTR COSE Algorithm Identifiers 🏷️

The table below defines the COSE AES-CTR algorithm values. These algorithms are being registered as "Deprecated" so nobody uses them by accident without a companion integrity protection mechanism. Not gonna lie, that's a big deal 💀

        +=========+========+==========+=============+=============+
        | 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

5. AES Cipher Block Chaining Mode 🌸

AES-CBC mode requires a 16-octet IV. Using a randomly or pseudorandomly generated IV makes sure that encrypting the same plaintext gives you different ciphertext, which is the vibe 💖

AES-CBC XORs the IV with the first plaintext block before it's encrypted. For each block after that, AES-CBC XORs the previous ciphertext block with the current plaintext before encrypting it ✨

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 lets the decryptor remove the padding without any ambiguity 🎯

The simplicity of AES-CBC makes it an attractive COSE content encryption algorithm. Carrying an IV and adding padding does add overhead compared to AES-CTR. AES-CBC is much safer for use with static keys than AES-CTR. That said, as described in [RFC4107], using automated key management to generate fresh keys is greatly preferred 🔁

AES-CBC does not provide integrity protection. So an attacker can slip in 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 🛡️

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 👀

The 'protected' header MUST be a zero-length byte string.

5.1. AES-CBC COSE Key 🗝️

When you use a COSE key for the AES-CBC algorithm, these checks happen:

  • The 'kty' field MUST be present, and it MUST be 'Symmetric'.
  • If the 'alg' field is present, it MUST match the AES-CBC algorithm being used.
  • If the 'key_ops' field is present, it MUST include 'encrypt' when encrypting.
  • If the 'key_ops' field is present, it MUST include 'decrypt' when decrypting.

Part 1 of 2 done 🎀 Next up: the algorithm identifiers for AES-CBC and everything after them ✨

5.2. AES-CBC COSE Algorithm Identifiers

Here's the lineup of COSE AES-CBC algorithm values 🎀. Heads up: these are registered as "Deprecated" so nobody uses them by accident without a companion integrity protection mechanism 😭.

     +=========+========+==========+=============+=============+
     | 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

6. Implementation Considerations 🧚

Okay, this one is a big deal 🔥. COSE libraries that support either AES-CTR or AES-CBC, and that accept Additional Authenticated Data (AAD) as input, MUST return an error if one of these non-AEAD content encryption algorithms gets selected. The reason is that it stops a caller from thinking the AAD is protected when the algorithm can't actually protect it 💀.

7. IANA Considerations 🌸

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

The details for those six identifiers live in Sections 4.2 and 5.2. For all six entries, the "Capabilities" column has "[kty]", the "Change Controller" column has "IETF", and the "Reference" column points back to this document ✨.

8. Security Considerations 💅

Okay, the security section is where things get seriously juicy, so buckle up 😭🔥.

This document specifies AES-CTR and AES-CBC for COSE, and neither one is an AEAD cipher. These ciphers are only meant for special use cases, like firmware encryption, where something else provides integrity and authentication 🫶.

AES has a 128-bit block size no matter which mode you use. That means the ciphertext starts looking distinguishable from random values once 2^64 blocks have been encrypted under a single key. Implementations should change the key before hitting that limit 🧠.

Now the main event 👑. 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 🙈.

There are pretty generic precomputation attacks against every block cipher mode that allow a meet-in-the-middle attack against the key 😵. These attacks need huge tables of ciphertext tied to known plaintext and known keys to be created and searched. If the memory and processor resources exist for a precomputation attack, 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. Long keys are the best countermeasure to precomputation attacks 🦋.

When it's used properly, AES-CTR mode gives strong confidentiality ✨. The problem is that it's super easy to misuse this counter mode 😭. If counter block values ever get used for more than one plaintext with the same key, then the same key stream encrypts both plaintexts, and the confidentiality guarantees are gone 💀.

So what happens if the encryptor XORs the same key stream with two different plaintexts? Say two plaintext octet sequences P1, P2, P3 and Q1, Q2, Q3 both get encrypted with key stream K1, K2, K3. The two ciphertexts look like this:

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

   (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)

If an attacker gets to see both of those ciphertext streams, confidentiality fails completely, because:

   (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 has the two plaintexts XORed together, it's pretty straightforward to pull them apart 🕵️‍♀️. So using any stream cipher, AES-CTR included, to encrypt two plaintexts under the same key stream leaks the plaintext 🚨.

Data forgery is trivial with AES-CTR mode 😱. The attack works like the key stream reuse one above. If a known plaintext octet sequence P1, P2, P3 gets encrypted with key stream K1, K2, K3, the attacker can swap the plaintext for one of their own choosing. The ciphertext is:

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

The attacker just XORs a chosen sequence Q1, Q2, Q3 into the ciphertext, which gives:

   (Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))

That's the same as:

   ((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)

When decrypted, the attacker's ciphertext gives back exactly what they wanted:

   (Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)
AES-CBC does not provide integrity protection 🚩. So if AES-CBC gets used without a companion authentication mechanism, an attacker can slip in undetectable errors.

If an attacker can strip the authentication and integrity mechanism, they can replace it with one of their own making, even without knowing the plaintext 😈. The usual defense against that sort of attack is an Authenticated Encryption with Associated Data (AEAD) algorithm [RFC5116]. Of course, neither AES-CTR nor AES-CBC is an AEAD 🙃. So an implementation should provide integrity protection for the 'kid' field, which prevents undetected stripping of the authentication and integrity mechanism. That also stops an attacker from changing the 'kid' to trick the recipient into using a different key 🔑.

With AES-CBC mode, implementers should perform integrity checks before decryption to avoid padding oracle vulnerabilities [Vaudenay] 🧁.

Once the COSE algorithm identifiers for AES-CTR and AES-CBC are in the COSE Algorithms Registry, an attacker can swap the COSE algorithm identifiers for one of these values. From there, 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 😭.

AES-CCM [RFC3610] and AES-GCM [GCMMODE] both use AES-CTR for encryption. So an attacker can switch the algorithm identifier to AES-CTR, strip the authentication tag to get around authentication and integrity, and then manipulate the ciphertext 🫠.

An attacker can also switch the algorithm identifier from AES-GCM to AES-CBC. They guess 16 bytes of plaintext at a time and check whether the recipient accepts the padding 👀. Padding oracle vulnerabilities are discussed further in [Vaudenay] 💜.

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgements 🫶

Huge thanks to David Brown for raising the need for non-AEAD algorithms to support encryption within the SUIT manifest 🙌. Thanks also 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 🎀

Russ Housley Vigil Security, LLC Email: housley@vigilsec.com

Hannes Tschofenig Email: hannes.tschofenig@gmx.net

📦 where this page comes from