Encryption Key Derivation in the COSE using HKDF with SHA-256

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

Copyright Notice

Copyright (c) 2024 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 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 [I-D.ietf-lamps-cms-cek-hkdf-sha256]. This attack is generic and can apply to other protocols with similar characteristics, such as COSE. However, the attack requires several preconditions:¶

1. The attacker intercepts a COSE Encrypt payload an changes the algorithm identifier to use the same underlying cipher with a different encryption mode, such as AES-GCM to AES-CBC.¶

2. The attacker converts the intercepted content into a "garbage" COSE Encrypt payload composed of AES-CBC guess blocks.¶

3. The attacker sends the "garbage" message to the victim, who then reveals the result of the decryption to the attacker.¶

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

CEK' = HKDF(CEK, COSE_Encrypt.alg)

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Updated Encryption Flow for each Content Key Distribution Method

This section describes the key distribution and encryption flows on sender side. Only the payload encryption process will be changed with the mitigation.¶

Some content key distribution methods generate encrypted CEK (eCEK) from randomly generated CEK. Figure 1 shows that each procedure is NOT changed by the mitigation.¶

Figure 2 shows that the mitigation layer is inserted just before the encrypting the plaintext payload. Note that Enc_structure is fed to encryption function (Encrypt) if the COSE_Encrypt.alg is an AEAD.¶

Then the sender creates COSE_Encrypt0 or COSE_Encrypt structure using these parameters if necessary.¶

• layer 0: The content encryption layer¶

  • protected or unprotected headers¶

    • content encryption algorithm id¶

    • its parameters such as IV¶

    • cek-hkdf = true¶

  • encrypted payload¶

• layer 1: The content key distribution layer¶

  • protected or unprotected headers¶

    • content key distribution method algorithm id¶

    • its parameters such as ephemeral key¶

    • kid¶

  • eCEK¶

TODO: provide an example binary (in appendix?)¶

4. Updated Decryption Flow for Each Content Key Distribution Method

This section describes the decryption flows on recipient side for each content key distribution method.¶

Figure 3 shows that the mitigation layer is inserted between the content key distribution methods and content decryption if the cek-hkdf parameter with true value locates in outer header. Note that Enc_structure is fed to decryption function (Decrypt) if the COSE_Encrypt.alg is an AEAD.¶

5. Use of of HKDF with SHA-256 to Derive Encryption Keys

The mitigation uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) [RFC5869] to derive output keying material (OKM) from input key material (IKM). HKDF is used with the SHA-256 hash function [FIPS180].¶

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

Inputs:
  IKM        Input keying material
  alg        COSE_Key algorithm identifier

Output:
  OKM      output keying material (same size as IKM)

The output OKM is calculated as follows:¶

  OKM_SIZE = len(IKM)
  IF OKM_SIZE > 8160 THEN raise error

  salt = "CBOR Object Signing and Encryption"
  PRK = HKDF-Extract(salt, IKM)

  OKM = HKDF-Expand(PRK, alg, OKM_SIZE)

6. 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 [RS2023], 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 [RFC9052] and in Section 6 of [RFC9053]. These algorithms define derivation and protection of content-encryption keys.¶

7. IANA Considerations

IANA is requested to add a new header parameter to the "COSE Common Header Parameters" established with [RFC9052].¶

+-----------+-------+--------------+-------------+------------------+
| Name      | Label | Value Type   | Value       | Description      |
|           |       |              | Registry    |                  |
+-----------+-------+--------------+-------------+------------------+
| cek-hkdf  | TBD   | bool         | N/A         | CEK-HKDF-SHA256  |
+-----------+-------+--------------+-------------+------------------+

Appendix A. Acknowledgments

Add your name here.¶

Authors' Addresses