crypto flaw in secure mail standards

From: Don Davis (dtdat_private)
Date: Fri Jun 22 2001 - 08:15:03 PDT

  • Next message: mu-b: "eXtremail Remote Format String ('s)"

    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ï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:
    http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps
    
    				- don davis, boston
    				  http://world.std.com/~dtd
    
    
    
    
    
    -
    



    This archive was generated by hypermail 2b30 : Fri Jun 22 2001 - 10:12:32 PDT