Mandatory email verification
Greetings: Is anyone aware of a way to modify sendmail to require a verified digital signature for all mail sent? This subject came up after a discussion of the possible repercussions of forged email through port 25. Even a good PGP user can't use manual encryption on a message-by- message basis as a defense for false mail attribution. For example, someone forges a defamatory message and signs your name to it. The recipient brings it to public attention and you try to claim "it doesn't have my PGP sig, therefore I didn't send it". The obvious counter is that you purposely failed to sign it to preserve your plausible deniability. The only way this would work is if the system you're on won't accept mail unless accompanied by a digital signature, which would allow the user to claim innocence if it wasn't his sig. The mailer would also have to check the sig to ensure that it belongs to an authorized user on the system to prevent people from creating one-time keys just to appease the mailer and prevent their real sig from being used. Running this version of "SIGmail" (<-- note flashy new marketing name) on your system would seem to be a reasonable defense against claims of false attribution. Has anyone done any work along these lines? Is there an obvious fault with a system which would operate in this manner? Please don't misconstrue this as an attack on anon mail, which obviously needs to be preserved. What I'm interested in avoiding is mail forged with another user's name. All that's required to do a convincing job now is an account on the user's home system and some knowledge of ESMTP. Seems to me like this is a potential disaster waiting to happen. Maybe the H.E.A.T. crew can solve this one . . . Fabio, we need you! =D.C. Williams <dcwill@ee.unr.edu>
From: "Dr. D.C. Williams" <dcwill@ee.unr.edu>
Is anyone aware of a way to modify sendmail to require a verified digital signature for all mail sent?
This would be very difficult to do in the short-term because of the current problems of few PKCAs and the relatively poor intergration of signatures into current mail user agents. But, rather than providing user-keyed authentication, it should be possible for you to set up your sendmail so that you could prove that an _outgoing_ message did or did not originate at your site (e.g. rather than verify userx sent it you can say with reasonable certainty that userx@my.domain sent that message.) Create a public key pair for the mail system. Messages being sent out are given a signature based upon the user who sent the message (the person who invoked sendmail...), so if someone tried to forge mail that had the appearance of coming from your site you would be able to at least show that it was not actually sent from the @foo.bar mail system. It is not too difficult to push the system a little further and be able to show that if the message does have such a signature then either the user did send the message or the originating system was hacked. A few more quick hacks would let someone send a mail message to the site given on the From line and have it check the signature and report back on whether or not the message was obviously forged or if it has the right sending signatures. Such a system would only take a few hours of hacking to get operational, and users would not be significantly inconvenienced by it's operation and would only need to query it if they wanted to check the validity of a message... jim
Its my understanding that to be truly useful on multi-user systems, digital signatures require some user input (eg, PGP requires entering a pass phrase). Sendmail could be hacked easily enough to append signatures and to even ask the user for the requisite pass phrase-- or sendmail can append the signature automagically, using an environment variable (yuch, just a touch insecure?) or some other method (a root-owned and executed shell script). The first method, having sendmail ask the user for the pass phrase, is most secure, but also the most inconvienent. For instance, at our site, we have several distributed workstations. We send numerous mail messages to each other every day, and signing each one would be a real pain. To prevent this sendmail could be hacked to only require signatures on mail messages addressed outside the domain. This still leaves us back at the original problem-- one of us could flame the boss and then deny the authenticity of the message because it lacked our signature. The automagic method is frightfully insecure. Creating an environment variable transparently requires that the pass phrase be physically located on the system, instead of the user's mind. (I wouldn't want to ask users to slip in their "pass phrase" disk every morning when they log on). There is also a question of trust-- a dishonest sysadm could easily break this method. The dishonest sysadm could also easily break a shell script method, as could anyone who got the root password. Jim McCoy pointed out aptly that the hack could be done quickly, but, laying technical issues aside, do we really want our computers signing our mail for us (what about messages to anonymous remailers-- a digital signature defeats that in short order)? That's the real question. -- Doug Shapter dps@kafka.atinc.com finger dps@kryten.atinc.com for PGP public key
From: dps@kafka.atinc.com (Doug Shapter)
Its my understanding that to be truly useful on multi-user systems, digital signatures require some user input (eg, PGP requires entering a pass phrase).
Not really. The system I was sketching out would not require the user to enter any information at all, the sendmail daemon would handle everything and have the key for that mail server held internally. The purpose would not be to say that "User X" did or did not sign a message, but to say _with reasonable assurance_ that the message either came from someone logged in as userx@foo.com (there are other alternatives, like the mail server being hacked, etc.) The purpose of such a system would not be to link mail messages to any real person or identity, but to link it to an account on the sending host (and mostly to link it to the sending host.) Thus someone who just did a telnet to port 25 and forged off a mail message would not be able to generate the necessary site signature to pull off the charade unless they managed to actually hack _into_ the mail server. Bouncing messages off a smtp port would no longer be enough to work. In actual practice the keys would not need to be monstrously huge and one could probably get by with a public key small enough to fit into a TXT record in the DNS system. It would be easier to break in to the system than crack a 512 bit key... The mail system would not be signing the messages for you, it would just do a hash of a few choice lines from the header and sign those with the mail system key. It would not try to say that any particular person sent a mail message but would instead say "to the best of my knowledge this message came from my system and was sent by someone accessing account userx" and no more. This would probably be enough to cut mail forgery through smtp by 90% among sites using the system. jim
automagically, using an environment variable (yuch, just a touch insecure?) or some other method (a root-owned and executed shell script).
I'm now working on a system (internal to each machine) which checks any mail to be sent for a signature (affixed by a mail front-end or by the user if he prefers to use the raw mail interface). This sig is produced by a key created my the system administrator solely for the purpose of verifying mail authenticity - any user who wants more security is still free to generate a separate key pair for encryption purposes. All that would be required is to sign the cyphertext with the "mail key" after encryption with whatever other key(s) the user wished to use. The mail sig has to be the last signature affixed to the message if it's to be stripped before sending (see below). The problem of key pass phrases is one I hadn't thought of yet. Remember that the "mail key" pair is not intended for any purpose beyond mail authentication. What if the private keys are stored in separate directories with rwx permissions for the individual user only? The keyring could be accessed by a mail program run by that user but not by anyone else (except uid 0), which is as secure as any UNIX system can hope for. Remember that uid 0 made the keys in the first place! The script which adds the sig wouldn't need a unique passphrase to sign with the "mail key". Of course, users' own private keys used for encryption would be protected in whatever manner they see fit, although (as beaten to death in another thread) keeping private keys on public machines is often a risky proposition. Once the system has verified that the mail submitted for transmittal does indeed have a valid sig, the sig could be stripped before sending. This would have absolutely no impact on other systems' mail, because all of the "sig, verify, strip" processes are confined to the user's machine. In fact, the mail recipient wouldn't even know this had occurred, ensuring proper use with remailers. All this system does is provide some reasonable protection for users against mail forgery originating from their own machine. My experiments with port 25 show that a telnet connection from a remote machine to port 25 causes the remote machine's address to appear in the ESMTP headers. However, mail sent from a local connection to port 25 can't be readily distinguished from mail sent via "normal" mail programs (mail, elm, pine, etc.). On the systems I've examined, I can enter a user's login through port 25 and sendmail will affix his real identity from /etc/passwd just as though that user had sent the mail. For instance, a user can forge mail from root on their own machine. I don't know about you, but that's something that concerns me. It's entirely possible that someone impersonating root could send email to a user to change his password as a "system test", giving the bad guy access to someone else's account. Admittedly, this is a pretty benign example, but the potential for real damage is there. It might well be that I'm overly concerned with something that really isn't a problem. However, the more I think about possible acts of "e-terrorism" which can be caused by convincingly forged email, the more concerned I become. If everybody knew how insecure mail really is and afforded it the proper amount of suspicion and distrust, this wouldn't be much of a problem (I don't know anybody who believes that "for a good time, call 555-XXXX" messages written in bathroom stalls were put there by the person who belongs to that phone number). However, I sense that many well meaning but largely uninformed people seem to think that email is secure, private, and inviolable. Given that level of trust, the possible consequences which might flow from convincingly forged email are significant. It's probably easier to fix the mail than attempt to educate the public, although I might well be wrong in that assessment. =D.C. Williams <dcwill@ee.unr.edu>
All this system does is provide some reasonable protection for users against mail forgery originating from their own machine. My experiments with port 25 show that a telnet connection from a remote machine to port 25 causes the remote machine's address to appear in the ESMTP headers. However, mail sent from a local connection to port 25 can't be readily distinguished from mail sent via "normal" mail programs (mail, elm, pine, etc.). On the systems I've examined, I can enter a user's login through port 25 and sendmail will affix his real identity from /etc/passwd just as though that user had sent the mail. For instance, a user can forge mail from root on their own machine. I don't know about you, but that's something that concerns me. It's entirely possible that someone impersonating root could send email to a user to change his password as a "system test", giving the bad guy access to someone else's account. Admittedly, this is a pretty benign example, but the potential for real damage is there.
The last time I hacked a mailer (elm 2.4 to be specific) I seem to remember that it invoced sendmail as a process rather than connecting to it via port 25 to send mail. It would seem that one could hack sendmail so as not to accept non sendmail connections to port 25 from the local machine (it clearly knows from the socket info structures who is connected on the other end of the socket) or perhaps to refuse to accept user id from a port 25 connection on the local machine (instead indicating the origen of the mail as user "sendmail25" or something similar). The later approach could be refined by adding a header line to the mail indicating it came from port 25 rather than rejecting it - then all you would have to do is make sure that the legitimate mailers were configured to invoke sendmail as a process rather than via port 25, and the appearence of the warning header line would be a red flag that something irregular happened in the creation of the mail. It might be necessary to hack the permanent sendmail process listening on port 25 to accept mail from other spawned sendmail processes via a memory to memory transfer (most unixes support this these days) or via some other port than 25, or with an additional step of passing the process id so it could check the UID of the process sending it the mail to authenticate the sender. [I am writing this in a typically airheaded manner this afternoon without looking at the sendmail source I have on the machine so I am a little vague about how sendmail spawned talks to sendmail permanent to send mail, but whatever technique is used here ought to be subject to a pass the process ID or pass a magic cookie (hash of process ID and sendmail version perhaps?) and the process id approach]. Thus one need not bother with message signing at all, or if one wanted to use it, could use it only to authenticate one sendmail process on your local machine to another.
D. C. Williams writes:
Is anyone aware of a way to modify sendmail to require a verified digital signature for all mail sent?...
Has anyone done any work along these lines? Is there an obvious fault with a system which would operate in this manner?
I think that changing "sendmail" to do this would have lots of repercussions. Many services send mail automatically, and most of them aren't equipped to do digital signatures. | GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5@tivoli.com> | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |
DC Williams writes: | Is anyone aware of a way to modify sendmail to require a verified digital | signature for all mail sent? This subject came up after a discussion | of the possible repercussions of forged email through port 25. | Even a good PGP user can't use manual encryption on a message-by- | message basis as a defense for false mail attribution. For example, | someone forges a defamatory message and signs your name to it. The | recipient brings it to public attention and you try to claim "it doesn't | have my PGP sig, therefore I didn't send it". The obvious counter is that | you purposely failed to sign it to preserve your plausible deniability. | The only way this would work is if the system you're on won't accept | mail unless accompanied by a digital signature, which would allow the | user to claim innocence if it wasn't his sig. The mailer would also have | to check the sig to ensure that it belongs to an authorized user on the | system to prevent people from creating one-time keys just to appease the | mailer and prevent their real sig from being used. Running this version | of "SIGmail" (<-- note flashy new marketing name) on your system would | seem to be a reasonable defense against claims of false attribution. | | Has anyone done any work along these lines? Is there an obvious fault | with a system which would operate in this manner? Design areas to be worked out: Will the system drop such mail silently, or return it to the sender? Will the messages returned to sender be signed by the mail system? If so, will they contain any reference to the message sent? How will you protect the keys used for signing? If the 'bounce' messages aren't signed, a great way to generate flamage would be to send messages to the user claiming that his recent mail was not properly signed, causing him to send another copy, annoying the hell out of all the recipeints. I'd like to close this message by saying that mandatory signing is not a good idea. People will generate a low security key, and leave it totally unsecured. The way most folks with a clue deal with forged mail is they see the writing style is different, the person is advocating a new & different position, or the mail is just random flammage. Most folks regularly disregard this sort of thing as children playing with a new toy. Requiring the use of signatures for all mail is silly. Adam
participants (6)
-
Adam Shostack -
Dave Emery -
dps＠kafka.atinc.com -
Dr. D.C. Williams -
m5＠vail.tivoli.com -
mccoy＠io.com