Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)
Extracted elements (23)
AES was selected over DES because it offers superior security, performance, efficiency, ease of implementation, and flexibility. Rijndael performs consistently well across hardware and software environments, has low memory requirements suited for constrained devices, and its operations are among the easiest to defend against power and timing attacks.
An S/MIME client SHOULD announce supported cryptographic functions using the SMIMECapabilities attribute, which MUST be signed. Algorithm OIDs SHOULD be logically separated by functional category and MUST be ordered by preference.
Compliant software MUST meet the requirements for constructing an encrypted-data content type stated in CMS Section 8. The EncryptedData encryptedContentInfo contentEncryptionAlgorithm field MUST specify a symmetric encryption algorithm, and implementations MUST support AES.
For AES key wrap OIDs, the parameters field MUST be absent. Implementations MUST support the CEK and KEK having the same length. If different lengths are supported, the KEK MUST be of equal or greater length than the CEK.
For KEKRecipientInfo, the keyEncryptionAlgorithm algorithm field MUST be one of the AES wrap OIDs, and the parameters field MUST be absent. The encryptedKey field MUST include the AES CEK wrapped using the previously distributed symmetric KEK.
For PasswordRecipientInfo, the RecipientInfo PasswordRecipientInfo CHOICE MUST be used when a password-derived KEK wraps the AES CEK. The keyEncryptionAlgorithm algorithm field MUST be one of the AES wrap OIDs and the parameters field MUST be absent.
If an S/MIME client is required to support symmetric encryption with AES, the SMIMECapabilities attribute MUST contain the AES OID in the symmetric algorithms category, and the parameter with this encoding MUST be absent.
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm field MUST specify a symmetric encryption algorithm. Implementations MUST support content encryption with AES, but implementations MAY support other algorithms as well.
The EnvelopedData keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm identifier. The originatorKey algorithm fields MUST contain the dh-public-number object identifier with absent parameters.
The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies RSAES-OAEP as the key transport algorithm for encrypting the CEK for the recipient.
The KeyTransRecipientInfo version MUST be either 0 or 2: version MUST be 0 if RecipientIdentifier is issuerAndSerialNumber, and MUST be 2 if RecipientIdentifier is subjectKeyIdentifier. The recipient's certificate MUST contain an RSA public key.
When key agreement is used, the RecipientInfo keyAgreeRecipientInfo CHOICE MUST be used. The KeyAgreeRecipient version MUST be 3. The originatorInfo field MUST be the originatorKey alternative containing the originator's ephemeral public key.
AES in CBC mode is defined for three key sizes: 128, 192, and 256 bits, identified by OIDs id-aes128-CBC, id-aes192-CBC, and id-aes256-CBC respectively. The AlgorithmIdentifier parameters field MUST be present and MUST contain a 16-byte AES-IV.
ES-DH/AES key derivation uses SHA-1 per RFC 2631 to generate the AES KEK from the shared secret ZZ, with a counter and key length encoded in the hash input. Multiple SHA-1 invocations with incrementing counter values are concatenated to reach the required key length (e.g., two invocations for AES-256).
Four key management techniques are supported for wrapping the AES CEK in enveloped-data: (1) Key Transport via recipient RSA public key, (2) Key Agreement via ES-DH or SS-DH, (3) Previously Distributed Symmetric KEK, and (4) Password Encryption via password-derived KEK.
S/MIME capability encodings for AES key sizes are defined: 128-bit (30 0B 06 09 60 86 48 01 65 03 04 01 02), 192-bit (30 0B 06 09 60 86 48 01 65 03 04 01 16), and 256-bit (30 0B 06 09 60 86 48 01 65 03 04 01 2A).
The AES key wrap algorithm (RFC 3394) encrypts one AES key in another AES key, producing output 64 bits longer than the input CEK as a checksum, using 6*n AES encryption/decryption operations where n is the number of 64-bit blocks in the CEK.
Three AES key wrap OIDs are defined: id-aes128-wrap ({ aes 5 }), id-aes192-wrap ({ aes 25 }), and id-aes256-wrap ({ aes 45 }). In all cases the parameters field MUST be absent; the OID conveys the KEK size but not the wrapped CEK size.
This document defines six OIDs in the ASN.1 module CMSAesRsaesOaep: three for AES-CBC content encryption (id-aes128-CBC, id-aes192-CBC, id-aes256-CBC) and three for AES key wrap (id-aes128-wrap, id-aes192-wrap, id-aes256-wrap), all under the NIST aes arc.
Mixing RSA-OAEP and RSA PKCS#1 v1.5 to transport the same CEK is inadvisable because an attacker can exploit the Bleichenbacher attack against the PKCS#1 v1.5 encrypted key even if OAEP is also present.
The generation of AES CEKs relies on random numbers; use of inadequate PRNGs can result in little or no security, as attackers may reproduce the PRNG state and search a small key space rather than brute-forcing the full key space. RFC 1750 guidance applies.
When wrapping a CEK with a KEK, the KEK MUST always be at least the same length as the CEK, because an attacker will target the weakest (shorter) key in a brute-force attack.
AES-IV is encoded as an OCTET STRING of exactly 16 bytes (SIZE(16)), used as the AlgorithmIdentifier parameter for all three AES-CBC OIDs (id-aes128-CBC, id-aes192-CBC, id-aes256-CBC).