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
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 <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-----
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 <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)
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.
participants (11)
-
ckey2＠eng.ua.edu -
David Mazieres -
david＠sternlight.com -
dlv＠bwalk.dm.com -
galactus＠stack.urc.tue.nl -
Guy Geens -
Jeffrey Goldberg -
Jiri Baum -
mdeindl＠vnet.ibm.com -
Philippe VIJGHEN -
Rich Graves