Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)
Extracted elements (19)
A PRF intermediate step (deriving separate MAC-K and CEK-K from a master_secret) is required so that any rollback attack—removing the outer MAC and rewriting the envelope to plain EnvelopedData—will result in decryption failure rather than silently succeeding.
Encrypt-and-authenticate is chosen over authenticate-and-encrypt because it is the more secure option, as extensively analysed in the literature (Krawczyk's 'The Order of Encryption and Authentication').
If there is ambiguity over which MAC key size to use, it is RECOMMENDED that the size be specified explicitly in the macAlgorithm AlgorithmIdentifier or defined in an RFC, because de facto standard key sizes vary by algorithm (e.g., HMAC-SHA1 uses 160 bits, AES-based MACs use the AES key size).
MAC-authenticated encryption is introduced for CMS to address the gap between user expectations (that encryption implies integrity) and the reality that unauthenticated encryption provides none. This mirrors the encrypt-and-authenticate pattern already established in IPsec, SSL/TLS, and SSH.
PBKDF2 is chosen as the default PRF because it is already used in CMS, making it the most natural candidate. A future universal PRF (e.g., HKDF) can be substituted by specifying it in the prfAlgorithm field.
The ContentEncryptionAlgorithmIdentifier is MACed as encoded (without re-coding to DER) to protect it alongside the encrypted content; otherwise an attacker could manipulate encryption parameters (e.g., the IV) to alter decryption results without triggering a MAC failure.
Two fixed key sizes (128 and 256 bits) are provided rather than a user-selectable parameter to accommodate real-world demand for AES-256 alongside AES-128, while avoiding unnecessary complexity from arbitrary key lengths.
The resulting encrypt-and-authenticate processing is a combination of the existing CMS content types EncryptedData and AuthenticatedData, allowing implementation using existing code without introducing new content-processing mechanisms.
An S/MIME client SHOULD announce support for MAC-authenticated encryption via the SMIMECapabilities attribute, which MUST contain the authEnc128 and/or authEnc256 OID with algorithm parameters ABSENT.
As a guideline for authors specifying PRFs other than PBKDF2, any additional parameters such as salts, tags, and identification strings SHOULD be set to empty strings, and any iteration count SHOULD be set to one.
When PBKDF2 is used as a PRF other than the default, the PBKDF2-params 'salt' parameter MUST be an empty (zero-length) string and the 'iterationCount' parameter MUST be one, since these values are not used in the PRF process.
The authEnc pseudo-algorithm is defined with two OIDs—id-alg-authEnc-128 (1 2 840 113549 1 9 16 3 15) and id-alg-authEnc-256 (1 2 840 113549 1 9 16 3 16)—conveying 128 or 256 bits of master keying material respectively.
The MAC algorithm key is derived as MAC-K := PRF(master_secret, "authentication", 1) and the encryption key as Enc-K := PRF(master_secret, "encryption", 1), both with a single iteration.
The MAC covers the EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier concatenated with the encrypted content, and optionally the authenticated attributes: MAC(contentEncrAlgoID || encrypt(content) || authAttr).
This document registers two algorithm identifiers (id-alg-authEnc-128 and id-alg-authEnc-256) in the S/MIME Working Group arc delegated by RSA: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0).
An implementation that treats missing non-payload trailing data as non-fatal allows an attacker to truncate the message before the MAC value, defeating authentication. Any data-formatting problem such as truncated or missing trailing data MUST be treated as a MAC verification failure.
Because AuthEnvData's primary transformation is encryption rather than authentication, an implementation may output decrypted data before reaching and verifying the trailing MAC value. If data is prematurely returned to the user and the MAC later fails, the user may have already acted on tainted data.
Recommended mitigations for premature data release: buffer the entire message and verify the MAC before decryption; if streaming is required, break messages into smaller atomically-verifiable chunks; otherwise clearly signal authentication failure to the caller and invalidate any previously returned data.
The AuthEncParams structure is an ASN.1 SEQUENCE containing: prfAlgorithm (DEFAULT PBKDF2), encAlgorithm (AlgorithmIdentifier for the encryption algorithm), and macAlgorithm (AlgorithmIdentifier for the MAC algorithm).