Daniel Brown <DBrown(_at_)certicom(_dot_)com> writes:
Presumably encrypt does not protect integrity, so, the attacker may be able
to change ciphertext to ciphertext', and further know that the corresponding
decryption plaintext' has some meaningful relationship to plaintext. Now the
attacker can compute hash(ciphertext') and if the encrypt function has
sufficiently poor integrity, the attacker can use this knowledge of MDC to
compute MDC' = encrypt(hash(ciphertext')).
The assumption is that they're using a 64- or 128-bit block cipher, so
something like RC4 would be a MUST NOT.
(In fact I don't know if RC4 has been used at all with CMS. That is, there's
nothing preventing its use, but even when RC4 was still popular what got used
in PKCS #7 was the block cipher RC2 and not the stream cipher RC4).
Even if S/MIME does not allow stream ciphers, they demonstrate that the
construction above presumes that the encrypt function must have some kind of
integrity properties. I'm not sure if AES-CBC, for example, has the
requisite integrity-protection property for the construction above.
Note that this isn't meant to be a high-integrity, provably-secure solution.
It's meant to be a low-effort fix for the problem that users expect CMS
encryption to exhibit a property that it doesn't currently have. I'd be
interested to see any real attacks on this, since it would mean OpenPGP's MDC
(which AFAIK has passed crypto scrutiny) would also be vulnerable.
An alternative construction may work, though:
MDC = MAC (ciphertext);
where MAC could be HMAC and the key would be the CEK, or a derivative
thereof.
This won't work, for the key-management reasons mentioned in my previous
message - crypto libraries and devices like smart cards and HSMs typically
implement hybrid encryption as "unwrap a CEK (e.g.for 3DES) with a private
key", but don't support "unwrap a CEK for 3DES and also feed it into a PRF to
suitably diversify it for use with HMAC". If it's an implementation where
keys can't leave the protected boundary, all you can get out of the unwrap is
a handle to a 3DES object, not even a key.
Admittedly, the alternative construction, however, might require more
implementation work than hash based construction, since some S/MIME
implementations may not have code for computing a MAC (unless they
implemented AuthenticatedData).
It's not the HMAC implementation that's the problem, it's that the key
management is impossible in some (many?) cases. There are a pile of kludges I
thought of (e.g. unwrap the 3DES key, then encrypt 128 bits of zeroes to get
an HMAC key, which gets around not having access to the CEK) but no matter how
you fiddle it it's an awful kludge, and I'm not sure that it doesn't
potentially introduce vulnerabilities of its own.
Peter.