Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS)

In recent years, there has been a substantial amount of research on quantum computers -- machines that exploit quantum mechanical phenomena to solve mathematical problems that are difficult or intractable for conventional computers. If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptosystems currently in use. This would seriously compromise the confidentiality and integrity of digital communications on the Internet and elsewhere. Under such a threat model, the current key encapsulation mechanisms would be vulnerable. Post-quantum key encapsulation mechanisms (PQ-KEM) are being developed in order to provide secure key establishment against an adversary with access to a quantum computer. As the National Institute of Standards and Technology (NIST) is still in the process of selecting the new post-quantum cryptographic algorithms that are secure against both quantum and classical computers, the purpose of this document is to propose a generic "algorithm-agnostic" solution to protect in confidentiality the CMS envelopped-data content against the quantum threat : the KEM-TRANS mechanism. This mechanism could thus be used with any key encapsulation mechanism, including post-quantum KEMs or hybrid KEMs.

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. The following terms are used in this document: BER: Basic Encoding Rules (BER) as defined in . DER: Distinguished Encoding Rules as defined in .

In the Envelopped-Data Content section of , two levels of encryptions are defined for CMS: the Content-encryption process which protects the data thanks to a symmetric algorithm used with a content encryption key (CEK); the Key-encryption process which protects this CEK thanks to a key transport mechanism. One of the typical use case of the CMS Envelopped-Data Content is to randomly generate a CEK, encrypt the data with a symmetric algorithm using this CEK and individually send the CEK to several recipients. In this scenario the CEK must be protected individually to the different recipients. To achieve this scenario with KEM primitives, it is necessary to define a new key transport mechanism that will fulfil the following requirements: the Key Transport Mechanism SHALL be secure againt quantum computers. the Key Transport Mechanism SHALL take the Content-Encryption Key (CEK) as input. According to NIST, a KEM encapsulation algorithm generates a random secret and a ciphertext from which the recipient can extract the shared secret, meaning that a KEM can not be used straightforward as a key transport mechanism in the CMS "multi-recipients" context. The KEM-TRANS mechanism defined in this document aims to turn a KEM into a key transport scheme allowing the sender to distribute a randomly generated key to several recipients. The KEM-TRANS Key transport mechanism described in the following section fulfils the requirements listed above and is an adaptation of the RSA-KEM algorithm previously specified in .

The KEM Key Transport Mechanism (KEM-TRANS) is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient. With this type of mechanism, a sender encrypts the keying data using the recipient's public key to obtain encrypted keying data. The recipient can then decrypt the encrypted keying data using his private key to recover the plaintext keying data.

The KEM-TRANS mechanism has the following underlying components: KEM, a Key Encapsulation Mechanism; KDF, a Key Derivation Function, which derives keying data of a specified length from a shared secret value; WRAP, a symmetric key-wrapping scheme, which encrypts keying Data using a key-encrypting key (KEK).

A KEM is cryptographic algorithm consisting of three functions : a key generation function KEM.keygen taking as input a security level and returning a key pair (private key and the associated public key) for this security level. an encapsulation function KEM.encaps taking a public key as input and returning a random session key and a ciphertext that is an encapsulation of the session key. a decaspulation function KEM.decaps taking as input a private key and a ciphertext and returning a session key.

A key derivation function (KDF) is a cryptographic function that derives one or more secret keys from a secret value using a pseudorandom function. KDFs can be used to stretch keys into longer keys or to obtain keys of a required format.

A wrapping algorithm is a symmetric algorithm protecting data in confidentiality and integrity. It is especially designed to transport key material. the WRAP algorithm consists of two functions : a wrapping function Wrap taking a wrapping key and a plaintext key as input and returning a wrapped key. a decaspulation function Unwrap taking as input a wrapping key and a wraped key and returning the plaintext key. In the following, kekLen denotes the length in bytes of the wrapping key for the underlying symmetric key-wrapping scheme. In this scheme, the length of the keying data to be transported MUST be among the lengths supported by the underlying symmetric key-wrapping scheme. Usage and formatting of the keying data is outside the scope of this algorithm. With some key derivation functions, it is possible to include other information besides the shared secret value in the input to the function. Also, with some symmetric key-wrapping schemes, it is possible to associate a label with the keying data. Such uses are outside the scope of this document, as they are not directly supported by CMS.

The KEM-TRANS mechanism described in the next sections assumes that the recipient has previously generated a key pair (recipPrivKey and recipPubKey) and has distributed this public key to the sender. The protocols and mechanisms by which the key pair is securely generated and the public key is securely distributed are out of the scope of this document.

Let recipPubKey be the recipient's public key, and let K be the keying data to be transported. The sender performs the following operations: Generate a shared secret SS and the associated ciphertext CT thanks to the KEM encaspulation function and the recipient's public key recipPubKey: (SS, CT) = KEM.encaps(recipPubKey) Derive a key-encrypting key KEK of length kekLen bytes from the shared secret SS using the underlying key derivation function: KEK = KDF(SS, kekLen) Wrap the keying data K with the key-encrypting key KEK using the underlying key-wrapping scheme to obtain wrapped keying data WK of length wrappedKekLen: WK = Wrap(KEK, K) Concatenate the wrapped keying data WK of length wrappedKekLen and the ciphertext CT to obtain the encrypted keying data EK: EK = (WK || CT) Output the encrypted keying data EK.

Let recipPrivKey be the recipient's private key and let EK be the encrypted keying data. The recipient performs the following operations: Separate the encrypted keying data EK into wrapped keying data WK of length wrappedKekLen and a ciphertext CT : (WK || CT) = EK Decapsulate the ciphertext CT thanks to the KEM decaspulation function and the recipient's private key to retrieve the shared secret SS: SS = KEM.decaps(recipPrivKey, CT) If the decapsulation operation outputs an error, output "decryption error", and stop. Derive a key-encrypting key KEK of length kekLen bytes from the shared secret SS using the underlying key derivation function: KEK = KDF(SS, kekLen) Unwrap the wrapped keying data WK with the key-encrypting key KEK using the underlying key-wrapping scheme to recover the keying data K: K = Unwrap(KEK, WK) If the unwrapping operation outputs an error, output "decryption error", and stop. Output the keying data K.

The KEM Key Transport Mechanism MAY be employed for one or more recipients in the CMS enveloped-data content type (Section 6 of ), where the keying data processed by the mechanism is the CMS content-encryption key (CEK).

When the KEM Key Transport Mechanism is employed for a recipient, the RecipientInfo alternative for that recipient MUST be KeyTransRecipientInfo. The mechanism satisfies the KeyTransportRecipientInfo interface defined in RFC 5652 by taking in a Content Encryption Key (CEK) and a recipient public key, and encrypting the CEK for that recipient. The algorithm-specific fields of the KeyTransRecipientInfo value MUST have the following values: keyEncryptionAlgorithm.algorithm MUST be id-kem-trans (see Appendix A); keyEncryptionAlgorithm.parameters MUST be a value of type GenericHybridParameters (see Appendix A), identifying: the key encapsulation mechanism (id-kem); the key derivation function (id-kdf); the symmetric wrapping mechanism (id-wrap). encryptedKey MUST be the encrypted keying data output by the KEM-TRANS Mechanism, where the keying data is the content-encryption key (CEK).

The conventions specified in this section augment .

The intended application for the key MAY be indicated in the key usage certificate extension (see , Section 4.2.1.3). If the keyUsage extension is present in a certificate that conveys a public key with the id-kem object identifier as discussed above, then the key usage extension MUST contain only the value keyEncipherment digitalSignature, nonRepudiation, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly and decipherOnly SHOULD NOT be present. A key intended to be employed only with the KEM-TRANS Mechanism SHOULD NOT also be employed for data encryption. Good cryptographic practice employs a given key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security.

If the recipient wishes only to employ the KEM-TRANS Mechanism with a given public key, the recipient MUST identify the public key in the certificate using the id-kem object identifier.

, Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. When constructing a signedData object, compliant software MAY include the SMIMECapabilities signed attribute announcing that it supports the KEM Key Transport Mechanism. The SMIMECapability SEQUENCE representing the KEM Key Transport Mechanism MUST include the id-kem-trans object identifier in the capabilityID field and MUST include a GenericHybridParameters value in the parameters field identifying the components with which the mechanism is to be employed. The DER encoding of a SMIMECapability SEQUENCE is the same as the DER encoding of an AlgorithmIdentifier. Example DER encodings for typical sets of components are given in Appendix A.

Within the CMS, algorithms are identified by object identifiers (OIDs). With one exception, all of the OIDs used in this document were assigned in other IETF documents, in ISO/IEC standards documents, by the National Institute of Standards and Technology (NIST). The two exceptions are the ASN.1 module's identifier and id-kem-transport that are both assigned in this document.

This document incorporates contributions and comments from a large group of experts. The Editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past year in pursuit of this document:

We are grateful to all, including any contributors who may have been inadvertently omitted from this list. This document borrows text from similar documents, including those referenced below. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - .

The ASN.1 syntax for identifying the KEM Key Transport Mechanism is an extension of the syntax for the "generic hybrid cipher" in ANS X9.44 . The syntax for the scheme is given in Appendix A.1. The syntax for selected underlying components including those mentioned above is given in Appendix A.2.

The object identifier for the KEM Key Transport Mechanism is id-kem-trans, which is defined in this document as:

When id-kem-trans is used in an AlgorithmIdentifier, the parameters MUST employ the GenericHybridParameters syntax. The syntax for GenericHybridParameters is as follows:

The fields of type GenericHybridParameters have the following meanings: kem identifies the underlying key encapsulation mechanism (KEM). This can be any NIST KEM. kdf identifies the underlying key derivation function (KDF). This can be any KDF from . kdf can be equal to null if the key encaspulation mechanism outputs a shared secret SS of size kekLen. wrap identifies the underlying key wrapping mechanism (WRAP). This can be any wrapping mechanism from .

The KEM-TRANS Mechanism can support any NIST KEM, including post-quantum KEMs. The object identifier for KEM is (TBD)

The KEM-TRANS Mechanism can support any KDF from . The KDF can be bypassed if the key encaspulation mechanism outputs a shared secret SS of size kekLen. kdf is then equal to null.

The KEM-TRANS Mechanism can support any wrapping mechanism from .