encryption in XML & in SMIME

this message follows up on discussions i had with ralph swick
and with joseph reagle, about adding privacy-encryption to
xml.  both joseph and ralph have suggested that i should
forward these comments to the new xml-encryption list.

					- don davis, boston

>At 3:06 PM -0400 7/26/00, Ralph R. Swick wrote:
> ... there is a little-recognized defect in PKCS7,
> SMIME, and CMS that makes each of them inappropriate
> for encryption purposes.
> The issue has to do with signing and encryption on the same
> text; there is no indication of the intended recipient.  You
> must put the intended recipients name in the body before you
> sign but since each of these systems considers the body to
> be opaque, the clients often forget to embed this additional
> information.
> Don's example was of a message signed with public key A
> and then encrypted with (the intended recipient's) public
> key B.  The current smime mail implementations, for example,
> do nothing to prevent the holder of the private key B from
> re-encrypting the signed message using public key C and
> forging message headers to make it appear that A intended
> the message to be viewed by C.

   the s/mime v3 msg spec (rfc 2633, sec 3.5,
"signing and encrypting") mentions this difficulty,
but doesn't acknowledge it as breakage.  the spec
suggests that either the implementation or the user
should should decide whether to sign first or to
encrypt first, according to the security needs of
the moment.  this suggestion is unrealistic; neither
software nor end-users are sophisticated enough to
make the security judgment.  nevertheless, some
s/mime email clients do offer users a menu choice
about whether to "sign & encrypt" or to "encrypt
& sign."

   this problem was first noted in a 1990 critique
of x.509 v1.  in a paper i wrote in 1996, i
discussed this problem as a persitent PKI protocol
error, and suggested that sign/wrap/sign is the only
correct solution.  since then, i've decided that it's
really a naming issue.  whether signing or encryption
is applied first, s/mime fails to duplicate the
security meaning of a symmetric-key ciphertext.
when B receives a symmetric-key ciphertext from A,
B assumes that:
   * A sent the message,
   * no-one else has seen the plaintext,
   * A intended B to receive the plaintext.

with s/mime, these assumptions can break down, because
the recipient may have to rely on the crypto layer to
_supply_ the target's or the intended recipient's names.
that is, the problem arises when:
   * the message plaintexts don't mention the
     sender's & target's names;
   * the sender's & target's names are important
     for understanding the message;
   * the target _assumes_ that the signer encrypted
     the message.

thus, signing and encrypting in either order can
be vulnerable in some cases:
   * if the message lacks the intended recipient's
     name (eg, "John loves you"), and is encrypted
     before signing, then the recipient B can re-encrypt
     the message for another recipient's eyes.  this
     attack misleads the new recipient C to suppose
     that the author A intended to send to C.  further,
     the new recipient C will assume that B has not
     seen the message.
   * if the message lacks the sender's name (eg,
     "here's my idea!"), and is signed before
     encrypting, then any eavesdropper can falsely
     claim authorship by replacing the sender's
     signature with the eavesdropper's own signature.

repair:  if the sender were obliged by the spec to
name the sender & recipient in his message-body,
then it wouldn't matter whwther signing or encryption
were applied first.  with either order, replacing the
outer layer of crypto would be evident, because the
outer layer's cert-name wouldn't match the message's
embedded names.

   i should emphasize that s/mime, cms, and pkcs#7
are OK for signing OR encrypting;  it's combining
the operations that's broken.  OTOH, i'll also
mention that s/mime & cms stipulate a broken mechanism
for handling MAC-keys.  i haven't looked at whether
pkcs#7 offers MACs (symmetric-key message
authentication codes).

   the bottom line:  i suggest that these standards are
not necessarily a good model to emulate, for adding crypto
to XML.

				- don davis, boston


Received on Monday, 28 August 2000 10:59:26 UTC