crypto flaw in secure mail standards

[Derek Atkins]

This is not a crypto flaw.  This is an engineering flaw.

First, the timestamp of the message is certainly encoded in the
signature.  This is protection against your first suggested attack.
The recipient, upon verifying the signature, notices that it was made,
e.g., two months previously.  Then one would have to wonder why a
two-month-old message was being sent.

The other obvious problem is that although the sender's identity is
encoded in the message's signature (as well as the time the signature
is purported to be made), the original intended recipient's are not
encoded within the signed portion of the message.  The simple fix
would be to include the appropriate mail headers withing the signed
portion of the message.  In particular, including the 'To' and 'Cc'
fields would immediately protect against both of these attacks.

The problem is not at all with the crypto.  The problem is with the
integration of the crypto with applications like e-mail.

Have a nice day,

-derek

Don Davis <dtd at world.std.com> writes:

> 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:
>   http://www.usenix.org/events/usenix01/usenix01.pdf
> 
> Citation:
> 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.
> 
> ----------------------------------------------------------
> Abstract
>    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=EFve 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=EFve 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=EFve 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:
> http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps
> 
> 				- don davis, boston
> 				  http://world.std.com/~dtd
> 
> 
> 
> 
> 
> -
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com