Password-based Encryption for CMS
obsoleted by
Extracted elements (23)
A level of indirection is used in KeyEncryptionAlgorithmIdentifier so that alternative wrapping algorithms can be introduced without requiring structural changes to PasswordRecipientInfo. If the KEK algorithm were specified directly, any alternative would require a new structure.
Double wrapping is used to eliminate block collision attacks: with a 64-bit block cipher, after ~2^32 encryptions collisions between encrypted CEK blocks could allow an attacker who recovers one CEK to derive others. Double encryption makes every ciphertext bit depend on every plaintext bit.
Double wrapping requires no additional algorithm (e.g., no hash function), allowing implementation on constrained devices such as smart cards that typically support only a single block cipher and a single public-key algorithm.
No mechanism is provided to differentiate between multiple PasswordRecipientInfos for the same data (e.g., two passwords for one file), as there is insufficient existing practice to define such a mechanism; a future version may add an optional identification field.
PKCS #5 padding is not used when formatting the CEK block because the length of the data is already encoded explicitly in the length byte; padding is random and serves only to reach the required block-multiple length.
The two-stage design (password→KEK, KEK→CEK) is specified separately rather than wrapped into a single algorithm identifier as in PKCS #5v2, because the combined design is particular to that standard and may not apply to other key wrapping mechanisms.
Implementations may encounter PBKDF2 encoded with an alternative HMAC-SHA1 OID from the IPsec arc (1.3.6.1.5.5.8.1.2) with absent rather than NULL parameters, due to the inability to precisely specify PBKDF2 in 1988 ASN.1.
There is no requirement that the CEK algorithm match the KEK encryption algorithm, but care should be taken to ensure equivalent security levels; wrapping a Triple-DES key with an RC2/40 key results in a severe impedance mismatch in encryption strength.
After unwrapping, the CEK byte count must be within the valid range for the CEK algorithm and not exceed the wrapped key length; the bitwise complement of the check value must match the first three bytes of the CEK. Failure indicates an invalid KEK.
Conforming implementations MUST implement the id-alg-PWRI-KEK key wrap algorithm, and MUST include Triple-DES in CBC mode as a KEK encryption algorithm.
Conforming implementations MUST include PBKDF2 (RFC 2898) as a supported key derivation algorithm.
Implementations SHOULD NOT include keystream generator (KSG) ciphers such as RC4, or a block cipher in OFB mode, as KEK encryption algorithms. Block ciphers in ECB mode SHOULD NOT be included.
The version field of PasswordRecipientInfo MUST be set to 0.
Key unwrapping reverses the double encryption: (1) decrypt the nth ciphertext block using the (n-1)th block as IV, (2) decrypt blocks 1..n-1 using the decrypted nth block as IV, (3) decrypt the inner layer with the KEK and original IV.
Key wrapping is a two-pass process: (1) encrypt the formatted CEK block with the KEK using the specified IV, then (2) without resetting the IV (using the last ciphertext block as the IV), encrypt the result a second time. The output is the EncryptedKey.
PasswordRecipientInfo (pwri [3]) is added as a fourth CHOICE in RecipientInfo, alongside KeyTransRecipientInfo, KeyAgreeRecipientInfo, and KEKRecipientInfo. It provides password-based key wrapping for CMS.
The id-alg-PWRI-KEK algorithm identifier (OID 1.2.840.113549.1.9.16.3.9) identifies the key wrap algorithm. Its AlgorithmIdentifier parameters field specifies the underlying KEK encryption algorithm used within the wrap.
The id-alg-PWRI-KEK OID (1.2.840.113549.1.9.16.3.9) is assigned from the S/MIME Working Group arc contributed by RSA Security. No IANA action is required; additional algorithm OIDs are expected to come from advocates' own arcs.
The security of PasswordRecipientInfo when used with a password rests critically on the entropy of the user-selected password, which is typically low. Pass phrases are STRONGLY RECOMMENDED, though even pass phrases may be insufficient to protect 128-bit or higher CEKs.
The security of this recipient information type also rests on the security of the underlying mechanisms (RFC 2630 and PKCS5v2). The double-wrap prevents bit-flipping attacks and ensures that wrapping the same CEK with the same KEK produces a different EncryptedKey each time due to the IV.
PasswordRecipientInfo is a SEQUENCE containing: version (CMSVersion, always 0), keyDerivationAlgorithm ([0] OPTIONAL AlgorithmIdentifier), keyEncryptionAlgorithm (AlgorithmIdentifier), and encryptedKey (OCTET STRING).
PBKDF2-params is a SEQUENCE of: salt (OCTET STRING), iterationCount (INTEGER 1..MAX), optional keyLength (INTEGER 1..MAX), and prf (AlgorithmIdentifier, defaulting to id-hmacWithSHA1 with NULL parameters).
The formatted CEK block consists of: (1) a one-byte count of CEK bytes, (2) a three-byte check value (bitwise complement of first three CEK bytes), (3) the CEK itself, and (4) random padding to make the block a multiple of the KEK block length and at least two KEK cipher blocks long.