]> Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

Security Internet-Draft 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.

Introduction This document specifies the derivation of the content-encryption key for the Cryptographic Message Syntax (CMS) enveloped-data content type , the content-encryption key for the CMS encrypted-data content type , or the content-authenticated-encryption key for the authenticated-enveloped-data content type . The use of this mechanism provides protection against where the attacker manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier. Johannes Roth and Falko Strenzke presented such an attack at IETF 118 , where:

1. The attacker intercepts a CMS Authenticated-Enveloped-Data content that uses either AES-CCM or AES-GCM .
2. The attacker turns the intercepted content into a "garbage" CMS Enveloped-Data content that is composed of AES-CBC guess blocks.
3. The attacker sends the "garbage" message to the victim, and the victim reveals the result of the decryption with 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 three parts:

• Potential recipients include the object identifier for the use-cms-cek-hkdf-sha256 attribute (with no parameters) in S/MIME Capabilities to indicate support for this mitigation.
• As a flag to the recipient that this mitigation is being used, carry the use-cms-cek-hkdf-sha256 attribute in the unprotected attributes.
• Perform encryption with a derived content-encryption key or content-authenticated-encryption key:

ASN.1 CMS values are generated using ASN.1 , using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .

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 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 materiam (OKM) from input key material (IKM). HKDF is used with the SHA-256 hash function . The derivation includes the DER-encoded AlgoritmIdentifier as the optional info input value. If an attacker were to change the originator-provided AlgoritmIdentifier, then the recipient will derive a different content-encryption key or content-authenticated-encryption key. The CMS_CEK_HKDF_SHA256 function uses the HKDF-Extract and HKDF-Expand functions to derive the OKM from the IKM: 8160 THEN raise error salt = "The Cryptographic Message Syntax" PRK = HKDF-Extract(salt, IKM) OKM = HKDF-Expand(PRK, info, OKM_SIZE) ]]>

The use-cms-cek-hkdf-sha256 Attribute The use-cms-cek-hkdf-sha256 attribute specifies that the CMS_CEK_HKDF_SHA256 function defined in to derive the content-encryption key or the content-authenticated-encryption key. The use-cms-cek-hkdf-sha256 attribute MUST be a unprotected attribute or an unauthenticated attribute; it MUST NOT be an signed attribute, authenticated attribute, or protected attribute. The following object identifier identifies the use-cms-cek-hkdf-sha256 attribute: The use-cms-cek-hkdf-sha256 attribute values have ASN.1 type of NULL. Using the conventions from , the use-cms-cek-hkdf-sha256 attribute is defined as:

SMIMECapabilities Attribute Conventions The SMIMECapabilities Attribute is defined in . An S/MIME client announces the set of cryptographic functions it supports using the SMIMECapabilities attribute. If an S/MIME client is supports the mechanism in this document, the id-use-cms-cek-hkdf-sha256 OID SHOULD be included in the set of cryptographic functions. The parameter with this encoding MUST be absent. The encoding for id-use-cms-cek-hkdf-sha256, in hexadecimal, is:

Use of of HKDF with SHA-256 with CMS This section describe the originator and recipient processing to implement this mitigation for each of the CMS encrypting content types.

Enveloped-Data Content Type As specified in , the fourth step of constructing an Enveloped-data is: To implement this mitigation, the originator expands this step as follows:

• Include the use-cms-cek-hkdf-sha256 attribute in the UnprotectedAttributes.
• Derive the new content-encryption key (CEK') from the original content-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier:

• The content is encrypted with the new content-encryption key (CEK'). Content encryption may require that the content be padded to a multiple of some block size; see .

If the use-cms-cek-hkdf-sha256 attribute is present in the UnprotectedAttributes of an Enveloped-Data Content Type, then the recipient derives the new content-encryption key (CEK') as shown above, and uses it for decryption of the EncryptedContent. If the use-cms-cek-hkdf-sha256 attribute is not present in the UnprotectedAttributes, then the recipient uses the original content-encryption key (CEK) for decryption of the EncryptedContent.

Encrypted-Data Content Type As specified in , the content-encryption key is managed by other means. To implement this mitigation, the originator performs the following:

• Include the use-cms-cek-hkdf-sha256 attribute in the UnprotectedAttributes.
• Derive the new content-encryption key (CEK') from the original content-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier:

• The content is encrypted with the new content-encryption key (CEK'). Content encryption may require that the content be padded to a multiple of some block size; see .

If the use-cms-cek-hkdf-sha256 attribute is present in the UnprotectedAttributes of an Encrypted-Data Content Type, then the recipient derives the new content-encryption key (CEK') as shown above, and uses it for decryption of the EncryptedContent. If the use-cms-cek-hkdf-sha256 attribute is not present in the UnprotectedAttributes, then the recipient uses the original content-encryption key (CEK) for decryption of the EncryptedContent.

Authenticated-Enveloped-Data Content Type As specified in , the fifth step of constructing an Authenticated-Enveloped-Data is: To implement this mitigation, the originator expands this step as follows:

• Include the use-cms-cek-hkdf-sha256 attribute in the UnauthAttributes.
• Derive the new content-authenticated-encryption key (CEK') from the original content-authenticated-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier:

• The attributes collected in step 4 are authenticated and the CMS content is authenticated and encrypted with the new content-authenticated-encryption key (CEK'). If the authenticated encryption algorithm requires either the additional authenticated data (AAD) or the content to be padded to a multiple of some block size, then the padding is added as described in .

If the use-cms-cek-hkdf-sha256 attribute is present in the UnauthAttributes of an Enveloped-Data Content Type, then the recipient derives the new content-authenticated-encryption key (CEK') as shown above, and uses it for authenticated decryption of the EncryptedContent and the authentication of the AAD. If the use-cms-cek-hkdf-sha256 attribute is not present in the UnauthAttributes, then the recipient uses the original content-authenticated-encryption (CEK) for decryption and authentication of the EncryptedContent and the authentication of the AAD.

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 use-cms-cek-hkdf-sha256 attribute from the unprotected attributes or unauthenticated attributes, then the recipient will derive a different CEK', which will not assist the attacker in recovering the plaintext content. If the attacker changes the ContentEncryptionAlgorithmIdentifier, then the recipient will derive a different CEK', which will not assist the attacker in recovering the plaintext content. The AlgorithmIdentifier object identifier is sufficient to mitigate the attack described in , but this mitigation includes 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 and content-authenticated-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. Using an inadequate pseudo-random number generator (PRNG) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, and then searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. offers important guidance on this topic.

Privacy Considerations If the message-digest attribute is included in the AuthAttributes, then the attribute value will contain the unencrypted one-way hash value of the plaintext of the content. Disclosure of this hash value enables content tracking, and it can be used to determine if the plaintext matches one or more candidate contents. For these reasons, the AuthAttributes SHOULD NOT contain the message-digest attribute.

Operations Considerations CMS is often used to provide encryption in messaging environments, where various forms of unsolicited messages (such as spam and phishing) represent a significant volume of unwanted traffic. Mitigation strategies for unwanted message traffic involve analysis of message plaintext. When recipients accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since many mitigation strategies will be unable to access the message plaintext. Therefore, software that receives messages that have been encrypted using CMS ought to provide alternate mechanisms to handle the unwanted message traffic. One approach that does not require disclosure of keying material to a server is to reject or discard encrypted messages unless they purport to come from a member of a previously approve originator list.

IANA Considerations For the ASN.1 Module in the of this document, IANA is requested to assign an object identifier (OID) for the module identifier (TBD0) with a Description of "id-mod-CMS-CEK-HKDF-SHA256-2023". The OID for the module should be allocated in the "SMI Security for S/MIME Module Identifier" registry (1.2.840.113549.1.9.16.0). For the use-cms-cek-hkdf-sha256 attribute definition in of this document, IANA is requested to assign an object identifier (OID) (TBD1) with a Description of "id-aa-use-cms-cek-hkdf-sha256". The OID for the module should be allocated in the "SMI Security for
S/MIME Attributes" registry (1.2.840.113549.1.9.16.2).

Acknowledgements Thanks to Mike Ounsworth for his careful review and constructive comments.

References Normative References This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [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. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. National Institute of Standards and Technology (NIST) ITU-T ITU-T 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. Informative References Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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] The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. MTG AG MTG AG

ASN.1 Module This ASN.1 Module builds upon the conventions established in and . CMS-CEK-HKDF-SHA256-Module-2023 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-CMS-CEK-HKDF-SHA256-2023(TBD0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS ATTRIBUTE FROM PKIX-CommonTypes-2009 -- in [FRC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } SMIME-CAPS FROM AlgorithmInformation-2009 -- in [FRC5911] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ; -- -- use-CMS-CEK-HKDF-SHA256 Attribute -- UnprotectedAttrs ATTRIBUTE ::= { aa-useCMSCEKHKDFSHA256, ... } id-aa-use-cms-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { TBD1 } aa-useCMSCEKHKDFSHA256 ATTRIBUTE ::= { TYPE NULL IDENTIFIED BY id-aa-use-cms-cek-hkdf-sha256 } -- -- S/MIIME Capability for use-CMS-CEK-HKDF-SHA256 -- SMimeCaps SMIME-CAPS ::= { cap-useCMSCEKHKDFSHA256, ... } cap-useCMSCEKHKDFSHA256 SMIME-CAPS ::= { -- No value -- IDENTIFIED BY id-aa-use-cms-cek-hkdf-sha256 } END ]]>

CMS_CEK_HKDF_SHA256 Function Examples This appendix provides two test vectores for the CMS_CEK_HKDF_SHA256 function.

CMS_CEK_HKDF_SHA256 with AES-128-GCM This test vector uses includes an AlgorithmIdentifier for
AES-128-GCM.

CMS_CEK_HKDF_SHA256 with AES-128-CBC This test vector uses includes an AlgorithmIdentifier for
AES-128-CBC.