Re: crypto flaw in secure mail standards

From: Florian Weimer (Florian.Weimerat_private-Stuttgart.DE)
Date: Sat Jun 23 2001 - 02:07:41 PDT

  • Next message: David Howe: "Re: crypto flaw in secure mail standards"

    Don Davis <dtdat_private> writes:
    
    > 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.
    
    This is a classic replay attack, but the protocol being attacked is
    not a computer protocol.  That's why you shouldn't sign generic
    statements such as 'The deal is off.' (or random insults without
    specific names, for another example) in the first place.
    
    With suitable user agents (e.g. mutt in conjuction with GnuPG),
    Charlie will notice that Alice has signed the message *before* the
    negotiations with Charlie have begun.
    
    > 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.
    
    Even here, the time difference between signing and sending could be an
    indication that someone is playing wrong.
    
    With OpenPGP, in both cases, the creation time information contained
    in the signature packet is protected by the digital signature, so Bob
    cannot change it before forwarding the message to Charlie.  As far as
    I recall, in the encryption packet, no encryption time is stored, so
    it's not possible for user agents to mistake the encryption time for
    the signature creation time.
    
    It is surprising that creation time information which is *not*
    provided by a trusted timestamping authority is sufficient to defeat
    such attacks or at least make them more complicated.
    
    > Surprisingly, standards-compliant secure-mail clients will
    > not detect these attacks.
    
    Have you looked at the OpenPGP/MIME specification draft?  It considers
    the flaw a feature.  PGP 2.x has an explicit command line option which
    permits to extract the data and signature from an encrypted message,
    so that the signature can still be verified.  There's a patch for
    GnuPG which implements completely transparent reencryption.
    
    Forwarding digitally signed messages even if you've received them
    encrypted can make sense.  Reencrypting mailing lists (with one list
    keys and individual subscriber keys) need this, and there are more
    applications to it.
    
    In short, I don't think this is a protocol flaw, it's just yet another
    misunderstanding of the meaning of a digital signature.  OpenPGP does
    not aim at preventing the receiver from leaking the transmitted
    message.  (For what it's worth, both the OpenPGP syntax and
    OpenPGP/MIME permit the sender to encrypt first and sign afterwards,
    but that's not the default with most implementations.)
    
    -- 
    Florian Weimer 	                  Florian.Weimerat_private-Stuttgart.DE
    University of Stuttgart           http://cert.uni-stuttgart.de/
    RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
    



    This archive was generated by hypermail 2b30 : Sun Jun 24 2001 - 08:50:30 PDT