]> University of Applied Sciences Bonn-Rhein-Sieg

Hannes.Tschofenig@gmx.net https://www.h-brs.de

Security COSE COSE AEAD Downgrade Attack This document specifies the derivation of the content-encryption key in CBOR Object Signing and Encryption (COSE). This mechanism protects against attacks where an attacker manipulates the content-encryption algorithm identifier. Status information for this document may be found at . Discussion of this document takes place on the COSE Working Group mailing list (), which is archived at . Subscribe at .

Introduction This document specifies the derivation of the content-encryption key for COSE. The use of this mechanism provides protection against where the attacker manipulates the content-encryption algorithm identifier. This attack has been demonstrated against CMS and the mitigation can be found in . This attack is generic and can apply to other protocols with similar characteristics, such as COSE. However, the attack requires several preconditions: The attacker intercepts a COSE Encrypt payload that uses either AES-CCM or AES-GCM . The attacker converts the intercepted content into a "garbage" COSE Encrypt payload composed of AES-CBC guess blocks. The attacker sends the "garbage" message to the victim, who then reveals the result of the decryption to the attacker. If any of the transformed plaintext blocks match the guess for that block, then the attacker learns the plaintext for that block. With highly structured messages, one block can reveal the only sensitive part of the original message. This attack is thwarted if the encryption key depends upon the delivery of the unmodified algorithm identifier. The mitigation for this attack has two parts: Potential recipients include a new parameter, cek-hkdf, in the outermost protected header of the COSE_Encrypt payload to indicate support for this mitigation. This parameter MUST use the value true. Perform encryption with a derived content-encryption key or content-authenticated-encryption key. The new CEK' is the result of deriving a CEK. This key derivation uses the alg parameter found in the outermost COSE_Encrypt header.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Use of of HKDF with SHA-256 to Derive Encryption Keys The mitigation uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) to derive output keying material (OKM) from input key material (IKM). HKDF is used with the SHA-256 hash function . If an attacker were to change the originator-provided COSE_Encrypt algorithm identifier then the recipient will derive a different content-encryption key. The CEK_HKDF function uses the HKDF-Extract and HKDF- Expand functions to derive the OKM from the IKM:

The output OKM is calculated as follows:

8160 THEN raise error salt = "CBOR Object Signing and Encryption" PRK = HKDF-Extract(salt, IKM) OKM = HKDF-Expand(PRK, alg, OKM_SIZE) ]]>

Security Considerations This mitigation always uses HKDF with SHA-256. One KDF algorithm was selected to avoid the need for negotiation. In the future, if a weakness is found in the KDF algorithm, a new attribute will need to be assigned for use with an alternative KDF algorithm. If the attacker removes the cek-hkdf header parameter from the COSE_Encrypt header prior to delivery to the recipient, then the recipient will not attempt to derive CEK', which will deny the recipient access to the content, but will not assist the attacker in recovering the plaintext content. If the attacker changes the value of the COSE_Encrypt alg parameter prior to delivery to the recipient, then the recipient will derive a different CEK', which will not assist the attacker in recovering the plaintext content. Providing the algorithm identifer as an input to the key derivation function is sufficient to mitigate the attack described in , but this mitigation includes both the object identifier and the parameters to protect against some yet-to-be-discovered attack that only manipulates the parameters. Implementations MUST protect the content-encryption keys, this includes the CEK and CEK'. Compromise of a content-encryption key may result in disclosure of the associated encrypted content. Compromise of a content-authenticated-encryption key may result in disclosure of the associated encrypted content or allow modification of the authenticated content and the additional authenticated data (AAD). Implementations MUST randomly generate content-encryption keys and content-authenticated-encryption keys. Content key distribution methods are described in Section 8.5 of and in Section 6 of . These algorithms define derivation and protection of content-encryption keys.

IANA Considerations IANA is requested to add a new header parameter to the "COSE Common Header Parameters" established with .

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. National Institute of Standards and Technology (NIST) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Vigil Security, LLC This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS). The use of this mechanism provides protection against where the attacker manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier. MTG AG MTG AG

Acknowledgments The author would like to thank Russ Housley and Ken Takayama for their feedback. The content of this document re-uses from the work done by Russ and applies it to COSE.