A weakness in PGP signatures, and a suggested solution (long)

I've been engaged in a lively debate with a few members of the cypherpunks
mailing list about forgeries that are hard to repudiate even if PGP signatures
are used. One of the participants suggested that I post a summary to
alt.privacy.pgp and sci.crypt, which is just what I'm doing.

(My apologies to the mail.cypherpunks readers who already saw much of
this once.)

I'll illustrate the problem with several scenarios of forgeries.
(It's funny that earlier today I was showing a friend how easy it is to
post forgeries. She seemed suitably impressed. :)

Scenario 1:

Bob once sent Carol an e-mail that looked like this:

-----------------------------------------------------------------------
From: Bob@boxb
To: Carol@boxc
Date: 25 Dec 1965
Subject: Carol, we're history
Message-ID: <111@boxb>

----BEGIN PGP SIGNED MESSAGE----

I no longer wish to go out with you. Merry Christmas!

----BEGIN PGP SIGNATURE----
Version 2.6.2

12341234...

----END PGP SIGNATURE----

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

Carol can forge an e-mail to Alice that looks like this:

-----------------------------------------------------------------------
From: Bob@boxb
To: Alice@boxa
Date: 25 Dec 1995
Subject: Alice, we're history
Message-ID: <222@bobb>

----BEGIN PGP SIGNED MESSAGE----

I no longer wish to go out with you. Merry Christmas!

----BEGIN PGP SIGNATURE----
Version 2.6.2

12341234...

----END PGP SIGNATURE----

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

We assume that it's easy for Carol to forge the RFC 822 headers to make it look
like the e-mail came from Bob. That's why many of us use digital signatures.

The signed portion of Bob's original e-mail did not state that the message is
addressed to Carol (e.g., "Dear Carol"). Alice will probably verify that the
signature matches Bob's private key and assume that the e-mail is authentic and
has been sent to her by Bob. To repudiate the e-mail, Bob might have to point
out that the "Received:" headers differ from his usual e-mails, without relying
on PGP. In fact, the presense of his verifiable signature would create more of
a presumption of authenticity of Alice's part.

Scenario 2:

Bob sends the same e-mail as above to Carol. David, a rogue sysadmin, gets
a copy of the e-mail, forges the same e-mail as above to Alice.

Scenario 3:

Bob sends a signed e-mail to Alice. Alice sees it in her newsfeed, forges a
Usenet article, makes it look like it came from Bob, and includes the body of
Bob's e-mail as the body of the Usenet forgery. Usenet forgeries are easy.

Again, if the signed text happens to be suitable, then Bob will have difficulty
repudiating the forgery. He won't not be able to use the PGP signature, which
will in fact verify. Hopefully, he'll be able to point out that the RFC 1036
Path: header is different from his usual header (which may not be the case).
Many Usenet readers would be unconvinced and Bob's reputation would be damaged.

Scenario 4:

Bob posts a signed Usenet article to alt.sex. Alice forges a usenet article in
Bob's name to misc.kids, recycilng the signed body, which would probably be
considered inappropriate for misc.kids. Same result as #3.

Scenario 5:

Bob posts a signed Usenet article to some innocuous newsgroup. Alice reposts
the same body in a forgery in Bob's name. The forgery can be cross-posted to
numerous "inappropriate" newsgroups ("velveeta"), or multi-posted ("spam").
Certain rogue self-apponited net.cops forge cancels for all copies of Bob's
article, including the original. (They are a bigger menace than the forgers :)

(As several people know, I have been a victim of some of the above-described
kinds of forgeries.)

I think the underlying problem is that the way PGP signatures are used by most
people, they validate a text, but allow it to be quoted out of context in an
e-mail or Usenet forgery.

I suggest to the kind folks working on PGP 3 that there should be a standard
protocol to include within the signed portion the information on when and for
whom this text is written: i.e. the list of e-mail recipients and/or Usenet
newsgroups, which could be easily compared with the RFC 822/1036 headers of an
e-mail/Usenet article. Perhaps there could be a new option for PGP to look
_outside_ the signed block and match the headers with what's inside the block.
For example, suppose the signature block says: this text was written by
alice@zog.org, posted to alt.sex and alt.sex.banal and e-mailed to
bob@masons.com. Suppose PGP is asked to check the signature in a file that
purports to be a e-mail or a Usenet article and has some headers before the
signed portion. If there is a list of To: recipients, and it includes someone
other than the recipients listed within the signed block; or if there is a
Newsgroups: header, and it includes newsgroups not listed within the signed
portion; then the input is bogus. For compatibility with the existing software,
if the signed block doesn't include this info, then this checking should't be
done, of course.

After I posted the above suggestion to cypherpunks, one very respected member
of that list informed me that "the security multiparts standard (RFC 1848)
includes a provision for signing the headers as well as the body of a message.
The security multiparts can be used with PGP, and there is even an Internet
Draft for it (draft-elkins-pem-pgp-02.txt), but there is not yet consensus for
adopting this as a standard on the pgp-mime mailing list."

I hope my examples will convince some that present practice of signing pieces
of text which can be quoted out of context in a forgery is just not enough.

We need to have an easy way to sign the headers without resorting to mine.

---

Dr. Dimitri Vulis
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

An easy short-term partial solution would be to modify mailcrypt, bap, or
whatever front end you use to automatically put the current date and (a
shortened form of) the To: or Newsgroups: header into the PGP signature
Comments: line. 

-rich

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 12 Jan 1996, Rich Graves wrote:

> Date: Fri, 12 JAN 1996 02:04:13 -0800 
> From: Rich Graves <llurch@Networking.Stanford.EDU>
> Newgroups: netcraft.cypherpunks, alt.security.pgp, sci.crypt,
>     mail.cypherpunks
> Subject: Re: A weakness in PGP signatures, and a suggested solution (long) 
> 
> An easy short-term partial solution would be to modify mailcrypt, bap, or
> whatever front end you use to automatically put the current date and (a
> shortened form of) the To: or Newsgroups: header into the PGP signature
> Comments: line. 
> 
> -rich

PGP totally ignores the Comment: line. How do you think this helps?
(Note: references are signed with the rest of the message ;-)

Guy Geens <guy.geens@elis.rug.ac.be>: Ph.D. student at ELIS -- TFCG / IMEC 
Atypical civil engineer -- And proud of it!
Home Page: http://www.elis.rug.ac.be/ELISgroups/tfcg/staff/gg.html 
finger ggeens@elis.rug.ac.be for PGP public keys (or use keyserver) 


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQBVAwUBMPZFaXwHoCha5QR1AQG/0wH/XmSC8y6/IKk3kuDYFTOCVvU6+j+Zlu0B
XpssrtwG3Fhck0CyJhYLzpqfw2D5wj8lL/SLsilmd8fVLo//jLUmSw==
=8xTy
-----END PGP SIGNATURE-----

> From: Rich Graves <llurch@Networking.Stanford.EDU>
> Newsgroups: netcraft.cypherpunks,alt.security.pgp,sci.crypt,mail.cypherpunks
> Date: Fri, 12 Jan 1996 02:04:13 -0800
> 
> An easy short-term partial solution would be to modify mailcrypt, bap, or
> whatever front end you use to automatically put the current date and (a
> shortened form of) the To: or Newsgroups: header into the PGP signature
> Comments: line. 

Well, I'm not much of an elisp hacker so I resorted to using perl, but
here's what I have.  This doesn't address the issue of automatically
verifying the headers in a message, but at least the headers are in
the message so that you can manually verify things when there may be a
problem.

David

--
#!/usr/local/bin/perl
#
# Put Header In Sig.
# This script copies mail headers into the body of a message
# before signing, so that your signed messages cannot be taken
# out of context.
#
# To use with mailcrypt, put something like the following in your
# .emacs file:
#
# (defun put-header-in-sig ()
#   (call-process-region
#    (point-min) (point-max)
#    "~/bin/phis"
#    nil
#    (current-buffer)
#    nil))
# (add-hook 'mc-pre-signature-hook 'put-header-in-sig)


while (<>) {
    last if /^--/;
    $header .= $_ unless /^(BCC|FCC):/;
    $date = 1 if /^Date:/i;
}

exit 0 unless $_;

$header = "Date: " . `date` . $header unless $date;
print $header, "\n";

while (<>) {}

-----BEGIN PGP SIGNED MESSAGE-----

In article <Pine.ULT.3.91.960112020051.6769E-100000@Networking.Stanford.EDU>,
Rich Graves <llurch@Networking.Stanford.EDU> wrote:
> An easy short-term partial solution would be to modify mailcrypt, bap, or
> whatever front end you use to automatically put the current date and (a
> shortened form of) the To: or Newsgroups: header into the PGP signature
> Comments: line. 

That line can be clipped off by everyone, without even so much as a peep
from PGP.  Perhaps a better solution would be to copy the To:  and
Newsgroups: headers into the body of the message?

Galactus

- -- 
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
E-mail: galactus@stack.urc.tue.nl - Please PGP encrypt your mail if you can.
Finger galactus@turtle.stack.urc.tue.nl for public key (key ID 0x416A1A35).
Anonymity and privacy page: <http://www.stack.urc.tue.nl/~galactus/remailers/>


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAgUBMPbYTDyeOyxBaho1AQGtvAQA2bVrvx7Argv/MjjA7cOGpJNzV0AGg96J
PvOsknNKfUj9n/gRLDNlGeL+j8wcdpgpdv1h2udmL582nv1T6r/m1ZI6wxedDUvk
eGt+KpNKijXuTdXRTvdVV/Wxahk2/3TgoA0U40CZmm1s1Ckk506T1dkGkt19UsvO
/5sBQ/eKUhY=
=S/aM
-----END PGP SIGNATURE-----

In article <199601030407.UAA12551@comsec.com>, dlv@bwalk.dm.com (Dr.
Dimitri Vulis) wrote:

>I've been engaged in a lively debate with a few members of the cypherpunks
>mailing list about forgeries that are hard to repudiate even if PGP signatures
>are used. One of the participants suggested that I post a summary to
>alt.privacy.pgp and sci.crypt, which is just what I'm doing.

<long comment that signed messages don't include the headers, omitted>

Although I do not disagree with the poster, and it may be useful to
include headers in the encryption (though care must be taken in verifying
them if the routing process adds anything), the lesson here is really a
different and important one than the writer's idea of encrypting headers.

It is that signed messages en clair are a)unencrypted to a specific
recipient, b) anyone may "validate" such a message, and c) "BEGIN PGP
SIGNED MESSAGE" and
"END PGP SIGNATURE" mean exactly what they say--only the delimited matter
is authenticated. Thus if one is writing to Carol to break off a
relationship, one had better include "Dear Carol" in the message text, and
if you are in relationship with more than one Carol, or expect to be, the
date and other particularizing info as well.

By the way, if Bob is sending unencrypted e-mail to Carol about the
details of their relationship for reasons other than public witness, he
has more than spoofed headers to worry about. It's his own head, er, that
needs scrutiny. :-)

David

-----BEGIN PGP SIGNED MESSAGE-----

[I am posting this to exactly the same groups that the original was posted
 to.  If someone feels that the distribution should be more limited please
 restrict the follow-ups.  I have also mailed a copy to the original 
 poster.]

On Wed, 27 Dec 1995, Dr. Dimitri Vulis wrote:

> Bob once sent Carol an e-mail that looked like this:
> 
> -----------------------------------------------------------------------
> From: Bob@boxb
> To: Carol@boxc
> Date: 25 Dec 1965
> Subject: Carol, we're history
> Message-ID: <111@boxb>
> 
> ----BEGIN PGP SIGNED MESSAGE----
> 
> I no longer wish to go out with you. Merry Christmas!
> 
> ----BEGIN PGP SIGNATURE----
> Version 2.6.2
> 
> 12341234...
> 
> ----END PGP SIGNATURE----
> 
> -----------------------------------------------------------------------
> 
> Carol can forge an e-mail to Alice that looks like this:
> 
> -----------------------------------------------------------------------
> From: Bob@boxb
> To: Alice@boxa
> Date: 25 Dec 1995
> Subject: Alice, we're history
> Message-ID: <222@bobb>
> 
> ----BEGIN PGP SIGNED MESSAGE----
> 
> I no longer wish to go out with you. Merry Christmas!
> 
> ----BEGIN PGP SIGNATURE----
> Version 2.6.2
> 
> 12341234...
> 
> ----END PGP SIGNATURE----

I have omitted the other scenarios for reasons of space.  All of
them are based on the fact that information about the intended
recipient (including newsgroup) is not part of the information signed.

I proposal is made for a mechanism to have some header information
signed as well.

I don't think that such a thing needs to be build into pgp, but might
be included in pgp/MUA interfaces.

I also think that the crucial lesson here is to take the analogy to
signature on paper more seriously.  Imagine that paper documents were
reproducible in a way that made the original indistinguishable from
copies.  Under search circumstances you would never sign something like:

   I agree to give you my house plus $30,000 in exchange for your house.
                                            (signature)

For the same reasons that you would never sign something like that (without
specifying the individuals and the properties in question), you shouldn't
sign an electronic when the interpretation of the document is a function
of whose hands its in.  As with the paper document, you would never
rely on its interpretation depending on the name on the envelope, you
shouldn't rely on the headers.

As for the recipient, the signature determines responsibility for the
signed portion, but not for the act of sending the document.

The only difference between paper and E-docs is that with paper there
is a distinction between the original and copies.

The lesson is not so much that we should change pgp, but that we should
pay very careful attention to what we sign. 

- -jeff

Jeffrey Goldberg                +44 (0)1234 750 111 x 2826
 Cranfield Computer Centre      FAX         751 814
 J.Goldberg@Cranfield.ac.uk     http://WWW.Cranfield.ac.uk/public/cc/cc047/
      "An `alternative paradigm' is the first refuge of the incompetent" --LM


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Comment: Processed by mkpgp, a Pine/PGP interface.

iQCVAgUBMPQNUBu6nIqxqP+5AQGHxgQAunhff6dV0eCXuVe6w+t0KWELlfjx3Iu4
SrKKo/DB+yWYDn+UVsFPyqvG64qmBxSaLLT95S3rbJEPklpRteN2+8Z94O5PxvL4
Q0OfGSX7oPN2Hwl3hkbjhwLWMpogcxfg6yle1SsqMCTMj3t8RAdmWD8DAQ9fEVzK
JdSdEXoc37s=
=21Kt
-----END PGP SIGNATURE-----

>>>>> Christopher R Key <ckey2@eng.ua.edu> writes:

 > First of all, if the recipient is a newsgroup, why
 > would that particular information need to be part of the signed
 > information?

E.g. if I post some Emacs-worshipping to alt.religion.emacs --- fine.
But if someone forwards this to some serious comp.editor group, maybe
some people don't understand the jokes...

Only one example why it can be neccessarry to include the context
(e.g. the recipient) into the signature.


 > If you post to a newsgroup a message that is only
 > signed (as opposed to encrypted also), then you are obviously not
 > worried about who reads it.

The question is not if I care who reads it.  The question is in which
context (i.e. in which newsgroup) someone reads it.

 > The signature is only a method of
 > proving that the important text (message) is unchanged and intact,
 > and that the person who it is supposed to be from is the same who
 > signed it.

Probably many people don't make this destinction between the message
and the context.  And additionally: I can only proove that someone
forwarded my message to a wrong context, when the context is signed,
too.

Sure, I can include context-information manually, but when we want as
many people as possible using strong-crypto, it should be as
fool-proof as possible.

Therefore I think it would be a good idea to include the context into
the signature.



 > Secondly, if you are sending email to some one and sign it using
 > pgp, wouldn't that person need pgp to prove that in fact you did
 > sign it?  Then it can be reasonable that if that person has pgp to
 > prove the signature, that person has pgp to decrypt mail sent to
 > them.  Simply sign you message and encrypt it using that person's
 > public key.
{SNIP}

Then the receipient decrypts the message, encrypts it under another
person's public-key and forwards it to them.  And so the context has
changed, while my signature is still valid.....


Have a nice day!

Michael Deindl
--


DISCLAIMER: My oppinions are my own, not those of my employer IBM.

You are right but the question is: what do you want to sign/encipher,
the message body or the whole message exchange?

We thinked about this when we developed a piece of software
for the European Space Agency which is called EDIDOC server 
(Electronic Data Interchange of Documents).

In our case, SMTP header signing was anyway not acceptable
because we needed to support various communication means.

I won't go into too much details but EDIDOC is acting as 
a central server for information exchange with value added as:
- a clearing house
- security gateway
- communication gateway
- a gateway at document format level
- groupware aspects

Roughly,
- a clearing house:
	everything exchange is logged in the server db

- security gateway
	...this requires of course trusting of the server
	but people with different security packages can send/receive
	 "secured message" (signature, enciphering) to/from
	the server without worrying of the recipient/originator
	configuration. Only the server public key need to be known
	by the partners.

- communication gateway:
	Various ways of transmitting the messages to/from the server
	depending of partner configuration.

	This means that although, as you pointed out, the envelope 
	must be secured itself it can not be the envelope
	specific to the communication method used (SMTP, X.400,...)
	-> usefull information can not be stored at the level
	   of the communication method header (ex. SMTP) but is 
	   included in the secured body (originator, destinator, 
	   timestamp, subject, ....)
	   Only the strict minimal information is included in the
	   SMTP, X.400, FTP, floppy, a.s.o. "headers".
	   Our envelope is structured according to a SGML DTD.

- a gateway at document format level
	Server is doing conformance checking of	documents and
	can even down-translate them based on the recipient
	settings (some will expect SGML, other ones EDIFACT, other
	ones ASCII, other partners WP, .... depending of the
	type of document)

- groupware aspects
	complex scenarios (as chain of approval, document review, ...)
	may be implemented at the server level


For more information, send an e-mail to edidoc-info@bim.be

ESA/ESRIN has some information at http://www.esrin.esa.it

BIM Engineering as a home page (http://www.bim.be) which should
"soon" include information about the server


Philippe VIJGHEN
BIM Engineering Europe

In article <Pine.ULT.3.91.960110182255.18692H-100000@xdm011>, Jeffrey Goldberg <cc047@Cranfield.ac.uk> says:

{SNIP}
>I have omitted the other scenarios for reasons of space.  All of
>them are based on the fact that information about the intended
>recipient (including newsgroup) is not part of the information signed.
>
>I proposal is made for a mechanism to have some header information
>signed as well.
>
{SUPER-SNIP}
First of all, if the recipient is a newsgroup, why would that particular
information need to be part of the signed information?  If you post to a
newsgroup a message that is only signed (as opposed to encrypted also), 
then you are obviously not worried about who reads it.  The signature is 
only a method of proving that the important text (message) is unchanged and
intact, and that the person who it is supposed to be from is the same who 
signed it.

Secondly, if you are sending email to some one and sign it using pgp, wouldn't
that person need pgp to prove that in fact you did sign it?  Then it can be
reasonable that if that person has pgp to prove the signature, that person has
pgp to decrypt mail sent to them.  Simply sign you message and encrypt it 
using that person's public key.  All of this (from what I remember reading)
is in the pgp manual, and is one of the key methods for using public key 
encryption.

So if all that needs be done to a message to insure that the appropriate 
person reads it is encrypt it using their public key, why does pgp (or one
of the pgp interfaces) need to be changed to include header information?  
I think it just includes more well already.  "If it ain't broke, don't fix
it."

"That's all Ah've got to say about that."

-----BEGIN PGP SIGNED MESSAGE-----

Hello ckey2@eng.ua.edu (Christopher R. Key)
  and cypherpunks@toad.com
 
> In article <Pine.ULT.3.91.960110182255.18692H-100000@xdm011>, Jeffrey Goldberg <cc047@Cranfield.ac.uk> says:
...
> First of all, if the recipient is a newsgroup, why would that particular
> information need to be part of the signed information?  If you post to a
...

Somebody already pointed out an adult message being re-posted to a kidgroup.

...
> Secondly, if you are sending email to some one and sign it using pgp, wouldn't
> that person need pgp to prove that in fact you did sign it?  Then it can be
...
> So if all that needs be done to a message to insure that the appropriate 
> person reads it is encrypt it using their public key, why does pgp (or one
> of the pgp interfaces) need to be changed to include header information?  
...

But then the recipient has a PGP-signed message from you which
isn't encrypted (using pgp -d). That person could then impersonate
you. Eg Alice the jilted lover could resend the goodbye message
with forged headers to Bob's new girlfriend to get back at him.

What a sentence. Here it is again, hopefully understandable:

Bob->Alice
  From:Bob; Encrypted(Signed("We're through",Bob),Alice)

Alice does pgp -d, leaving her with Signed("We're through",Bob)

Alice->Carol
  From:Bob; Encrypted(Signed("We're through",Bob),Carol)

Later, when Bob gets another girlfriend,

Alice->Danielle
  From:Bob; Encrypted(Signed("We're through",Bob),Danielle)

Later still,

Alice->Eve
  From:Bob; Encrypted(Signed("We're through",Bob),Eve)