Skip to main content

CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC
draft-ietf-cose-aes-ctr-and-cbc-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9459.
Authors Russ Housley , Hannes Tschofenig
Last updated 2022-11-08
Replaces draft-housley-cose-aes-ctr-and-cbc
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 9459 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-cose-aes-ctr-and-cbc-02
COSE                                                          R. Housley
Internet-Draft                                            Vigil Security
Intended status: Standards Track                           H. Tschofenig
Expires: 12 May 2023                                         Arm Limited
                                                         8 November 2022

     CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC
                   draft-ietf-cose-aes-ctr-and-cbc-02

Abstract

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

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 12 May 2023.

Copyright Notice

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

Housley & Tschofenig       Expires 12 May 2023                  [Page 1]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

   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
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   2
   3.  AES Modes of Operation  . . . . . . . . . . . . . . . . . . .   3
   4.  AES Counter Mode  . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  AES-CTR COSE Algoritm Identifiers . . . . . . . . . . . .   4
   5.  AES Cipher Block Chaining Mode  . . . . . . . . . . . . . . .   5
     5.1.  AES-CBC COSE Algoritm Identifiers . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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.

Housley & Tschofenig       Expires 12 May 2023                  [Page 2]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

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.  For example, the encryptor might generate the IV
   with a counter or a linear feedback shift register (LFSR).

   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 IV block values,
   which might be based on a counter or a LFSR.  AES-CTR is easy to
   implement, and AES-CTR can be pipelined and parallelized.  AES-CTR
   also 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
   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

Housley & Tschofenig       Expires 12 May 2023                  [Page 3]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

   inappropriate to use this 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.

   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.

4.1.  AES-CTR COSE Algoritm Identifiers

   When using a COSE key for the AES-CTR algorithm, the following checks
   are made:

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

   *  If the 'protected' field is present, it MUST be a zero-length byte
      string.

   Since AES-CTR cannot provide integrity protection for external
   additional authenticated data, the decryptor MUST ensure that no
   external additional authenticated data was supplied.

   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.

Housley & Tschofenig       Expires 12 May 2023                  [Page 4]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

   +=========+=======+==========+========================+=============+
   | Name    | Value | Key Size |      Description       | Recommended |
   +=========+=======+==========+========================+=============+
   | A128CTR |  TBD1 |   128    |       AES-CTR w/       |  Deprecated |
   |         |       |          |      128-bit key       |             |
   +---------+-------+----------+------------------------+-------------+
   | A192CTR |  TBD2 |   192    |       AES-CTR w/       |  Deprecated |
   |         |       |          |      192-bit key       |             |
   +---------+-------+----------+------------------------+-------------+
   | A256CTR |  TBD3 |   256    |       AES-CTR w/       |  Deprecated |
   |         |       |          |      256-bit key       |             |
   +---------+-------+----------+------------------------+-------------+

                                  Table 1

5.  AES Cipher Block Chaining Mode

   AES-CBC mode requires an 16 octet Initialization Vector (IV).  Use of
   a randomly or pseudo-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 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.

   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.

5.1.  AES-CBC COSE Algoritm Identifiers

   When using a COSE key for the AES-CBC algorithm, the following checks
   are made:

Housley & Tschofenig       Expires 12 May 2023                  [Page 5]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

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

   *  If the 'protected' field is present, it MUST be a zero-length byte
      string.

   Since AES-CTR cannot provide integrity protection for external
   additional authenticated data, the decryptor MUST ensure that no
   external additional authenticated data was supplied.

   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.

   +=========+=======+==========+========================+=============+
   | Name    | Value | Key Size |      Description       | Recommended |
   +=========+=======+==========+========================+=============+
   | A128CBC |  TBD4 |   128    |       AES-CBC w/       |  Deprecated |
   |         |       |          |      128-bit key       |             |
   +---------+-------+----------+------------------------+-------------+
   | A192CBC |  TBD5 |   192    |       AES-CBC w/       |  Deprecated |
   |         |       |          |      192-bit key       |             |
   +---------+-------+----------+------------------------+-------------+
   | A256CBC |  TBD6 |   256    |       AES-CBC w/       |  Deprecated |
   |         |       |          |      256-bit key       |             |
   +---------+-------+----------+------------------------+-------------+

                                  Table 2

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.

Housley & Tschofenig       Expires 12 May 2023                  [Page 6]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

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

7.  Security Considerations

   This document specifies AES-CTR and AES-GCM for COSE, which are not
   authenticated encryption with additional data (AEAD) ciphers.  The
   use of the ciphers is limited to special use cases where integrity
   and authentication is provided by another mechanism, such as firmware
   encryption.

   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.

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

   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:

Housley & Tschofenig       Expires 12 May 2023                  [Page 7]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

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

Housley & Tschofenig       Expires 12 May 2023                  [Page 8]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

   If an attacker is able to strip the authentication and integrity
   mechanism, then the attacker can replace it with their 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) [RFC5116] algorithm.  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
   the authentication and integrity mechanism; this prevents an attacker
   from altering the kid to trick the recipient into using a different
   key.

   With AES-CBC mode, implementers SHOULD perform integrity checks prior
   to decryption to avoid padding oracle vulnerabilities [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.

   Since AES-GCM uses AES-CTR for encryption, an attacker can switch the
   algorithm identifier from AES-GCM to AES-CTR, and then strip the
   authentication 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, guess of 16 bytes of plaintext at a time, and checking each
   guess with padding oracle as discussed above.

8.  Acknowledgements

   Many thanks to David Brown for raising the need for non-AEAD
   algorithms to support the SUIT manifest.  Many thanks to Ilari
   Liusvaara and Scott Arciszewski for the review and thoughtful
   comments.

9.  References

9.1.  Normative References

   [AES]      National Institute of Standards and Technology (NIST),
              "Advanced Encryption Standard (AES)", FIPS
              Publication 197, November 2001.

   [MODES]    Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Methods and Techniques", NIST Special
              Publication 800-38A, December 2001.

Housley & Tschofenig       Expires 12 May 2023                  [Page 9]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

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

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

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

9.2.  Informative References

   [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-20, 7 October
              2022, <https://www.ietf.org/archive/id/draft-ietf-suit-
              manifest-20.txt>.

   [IANA]     "IANA Registry for CBOR Object Signing and Encryption
              (COSE)", n.d.,
              <https://www.iana.org/assignments/cose/cose.xhtml>.

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

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

Authors' Addresses

Housley & Tschofenig       Expires 12 May 2023                 [Page 10]
Internet-Draft        AES-CTR and AES-CBC with COSE        November 2022

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

   Hannes Tschofenig
   Arm Limited
   Email: hannes.tschofenig@arm.com

Housley & Tschofenig       Expires 12 May 2023                 [Page 11]