Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)
Extracted elements (19)
AAD (additional authenticated data) is authenticated but not encrypted; in CMS authenticated-enveloped-data, authenticated attributes serve as the AAD. This allows header integrity protection without encrypting headers.
AES-GCM nonces need not have equal lengths, but 12-octet nonces are recommended because they can be processed more efficiently by the GCM algorithm (no hashing step required to derive the counter block).
For AES-CCM, the OCTET STRING encoding of GCMParameters requires the nonce to be a multiple of 8 bits, even though the GCM specification itself permits any length from 1 to 2^64 bits.
AES-CCM and AES-GCM do not require padding of plaintext or AAD inputs before invocation, simplifying interoperability with CMS implementations that lack padding logic.
For key management techniques beyond the four documented ones (see CMS Section 6.2.5), no assurance is given that automated key management requirements are met; designers must perform their own analysis before using such techniques with AES-CCM or AES-GCM.
For AES-CCM, L=8 is RECOMMENDED for the length field (yielding a 7-octet nonce), reflecting the normal CMS usage of a fresh content-authenticated-encryption key per content item.
For AES-CCM, the aes-ICVlen parameter MUST match the size in octets of the AuthEnvelopedData mac field. A length of 12 octets is RECOMMENDED.
For AES-CCM, the AlgorithmIdentifier parameters field MUST be present and must contain a CCMParameters structure with aes-nonce and aes-ICVlen fields.
For AES-GCM, the aes-ICVlen parameter MUST match the size in octets of the AuthEnvelopedData mac field. A nonce of 12 octets is RECOMMENDED for processing efficiency.
For AES-GCM, the AlgorithmIdentifier parameters field MUST be present and must contain a GCMParameters structure with aes-nonce and aes-ICVlen fields.
Implementations MUST use an automated key management system because reuse of an AES-CCM or AES-GCM nonce/key combination destroys security guarantees, making static key configurations extremely dangerous.
Within the scope of any authenticated-encryption key for AES-GCM, the nonce value MUST be unique. The set of nonce values used with any given key MUST NOT contain any duplicate values.
CMS authenticated-enveloped-data supports four key management techniques: Key Transport (content key encrypted in recipient's public key), Key Agreement (pairwise symmetric key via ECDH/DH), Symmetric Key-Encryption Keys (pre-distributed KEK), and Passwords (key derived from shared secret).
Six OIDs are defined: id-aes128-CCM ({aes 7}), id-aes192-CCM ({aes 27}), id-aes256-CCM ({aes 47}), id-aes128-GCM ({aes 6}), id-aes192-GCM ({aes 26}), id-aes256-GCM ({aes 46}), one per algorithm per key size.
Counter mode is vulnerable to misuse: if counter block values are reused with the same key, the same keystream encrypts two plaintexts, completely voiding confidentiality guarantees. The CMS AuthEnvelopedData structure and automated key management prevent this misuse.
Implementations must randomly generate content-authenticated-encryption keys using a cryptographically strong PRNG. Weak PRNGs allow an attacker to reproduce the key generation environment and search a small key space rather than brute-forcing the full space. RFC 4086 guidance applies.
Precomputation (meet-in-the-middle) attacks against counter mode limit theoretical strength to 2^(n/2) bits where n is the key length. Using long keys and unpredictable nonces significantly increases the table size an attacker must compute.
CCMParameters is an ASN.1 SEQUENCE containing aes-nonce (OCTET STRING of SIZE 7..13 octets) and aes-ICVlen (INTEGER with allowed values 4, 6, 8, 10, 12, 14, or 16, defaulting to 12).
GCMParameters is an ASN.1 SEQUENCE containing aes-nonce (OCTET STRING, recommended 12 octets) and aes-ICVlen (INTEGER with allowed values 12, 13, 14, 15, or 16, defaulting to 12).