Re: crypto flaw in secure mail standards

[Florian Weimer <Florian.Weimer () RUS Uni-Stuttgart DE>]

Don Davis <dtd () world std com> 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.Weimer () RUS Uni-Stuttgart DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898