Fwd: crypto flaw in secure mail standards

Ingo Kl÷cker ingo.kloecker@epost.de
Sat Jun 23 15:56:01 2001

Hash: SHA1

The following message was forwarded to the KMail mailing list. Now I 
wonder if the second scenario is possible with PGP/GnuPG, i.e. is it 
possible to extract the clear signed message(+signature packet) from an 
encrypted&signed message and then re-encrypt the clear signed message 
with another key? Or is it only possible to extract the original 
message (without the signature packet)?

- ----------  Forwarded Message  ----------
Subject: crypto flaw in secure mail standards
Date: Fri, 22 Jun 2001 10:15:03 -0500
From: Don Davis <dtd@world.std.com>
To: bugtraq@securityfocus.com

All current secure-mail standards specify, as their "high-
security" option, a weak use of the public-key sign and encrypt
operations.  On Thursday the 28th of this month, I'll present
my findings and my proposed repairs of the protocols, at the
Usenix Technical Conference here in Boston:

Don Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS,
PEM, PGP, and XML."  To appear in Proc. Usenix Tech. Conf. 2001,
Boston.  June 25-30, 2001.

A short summary:  All current secure-mail standards have a
significant cryptographic flaw.  There are several standard
ways to send and read secure e-mail.  The most well-known
secure mail systems are PGP and S/MIME.  All current public-
key-based secure-mail standards have this flaw.  Here are some
examples of the flaw in action:

Suppose Alice and Bob are business partners, and are setting
up a deal together.  Suppose Alice decides to call off the
deal, so she sends Bob a secure-mail message: "The deal is off."
Then Bob can get even with Alice:

  * Bob waits until Alice has a new deal in the works
    with Charlle;
  * Bob can abuse the secure e-mail protocol to re-encrypt
    and resend Alice's message to Charlie;
  * When Charlie receives Alice's message, he'll believe
    that the mail-security features guarantee that Alice
    sent the message to Charlie.
  * Charlie abandons his deal with Alice.

Suppose instead that Alice & Bob are coworkers.  Alice uses
secure e-mail to send Bob her sensitive company-internal
sales plan.  Bob decides to get his rival Alice fired:

  * Bob abuses the secure e-mail protocol to re-encrypt and
    resend Alice's sales-plan, with her digital signature,
    to a rival company's salesman Charlie.
  * Charlie brags openly about getting the sales plan from
    Alice.  When he's accused in court of stealing the plan,
    Charlie presents Alice's secure e-mail as evidence of
    his innocence.

Surprisingly, standards-compliant secure-mail clients will
not detect these attacks.

- ----------------------------------------------------------
   Simple Sign & Encrypt, by itself, is not very secure.
Cryptographers know this well, but application programmers
and standards authors still tend to put too much trust
in simple Sign-and-Encrypt.  In fact, every secure e-mail
protocol, old and new, has codified na´ve Sign & Encrypt
as acceptable security practice.  S/MIME, PKCS#7, PGP,
OpenPGP, PEM, and MOSS all suffer from this flaw.
Similarly, the secure document protocols PKCS#7, XML-
Signature, and XML-Encryption suffer from the same flaw.
Na´ve Sign & Encrypt appears only in file-security and
mail-security applications, but this narrow scope is
becoming more important to the rapidly-growing class
of commercial users. With file- and mail-encryption
seeing widespread use, and with flawed encryption in
play,  we can expect widespread exposures.

In this paper, we analyze the na´ve Sign & Encrypt flaw,
we review the defective sign/encrypt standards, and we
describe a comprehensive set of simple repairs.  The
various repairs all have a common feature:  when signing
and encryption are combined, the inner crypto layer must
somehow depend on the outer layer, so as to reveal any
tampering with the outer layer.

- ----------------------------

Once I've presented the paper, I'll make this link live:

				- don davis, boston

- -

- -------------------------------------------------------
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org