|
|
Email is increasingly being used for criminal purposes. Apart from the sheer nuisance value of spam, many people ask for confidential information under the pretext of being somebody else. Even the banks go along with dubious security practices.
What can be done? The obvious thing is to use the methods that are available. In the context of email, that means providing incontrovertible proof that the message really comes from you. Difficult? No, not at all. I do it with nearly every message I send. Why only “nearly” every message? See below.
The basics of proving who you are involve public-key encryption and a digital signature. In brief, public key encryption relies on two keys: one known only to you, and one available to anybody who is interested. The digital signature is encrypted with the private key, something only I can do. It can be decrypted with the public key by anybody who cares to check it. If it decrypts correctly, it must have been encrypted by me.
But how does that prove that I have written the text? Simple: the signature encrypts a digested form of the text. You can create the same digested form and use the public key to confirm that the signature decrypts to the same digest. If it does, then the text, as it appears, must come from me. If somebody modifies the text, the signature will no longer validate.
“Traditional” email, defined by RFC 822, is simply a collection of text lines. It doesn't provide a way to distinguish between the text and the signature; for that you need MIME. The structure of a message includes two attachments: the text body and the signature. The result looks like this in text form:
The text starting with Content-Type: text/plain; charset=us-ascii and ending with “See complete headers” is what's left of the real mail message that I truncated for this example, and the text starting with Content-Type: application/pgp-signature and ending with -----END PGP SIGNATURE----- is the signature. The lines with --CRj9LSjXOCc6Ii+Z are used by MIME to recognize the attachment boundaries.
A MUA like mutt shows the relationship like this:
|
This shows two top-level attachments: the first (numbered 1) is of type multipart/signed, and the other (4) is plain text (the footers added by the mailing list software which resent this message). The multipart/signed attachment, in turn, contains two attachments: the text (2) and the signature (3). MIME messages may contain an optional description, which is almost never of any use. We'll see below how Microsoft thinks they're important.
A GUI-based MUA typically shows much less information. Here's an example from Microsoft “Outlook”:
My best guess here is that the two named attachments are the signature (attachment 3 in the mutt list) and the footer (attachment 4), and that the text attachment isn't mentioned; it's displayed instead. It doesn't say what type the attachments are; it seems that Microsoft ignores the MIME Content-type: information and goes by a fake file name in the description with magic in the extension, so it gives the attachments names like ATT00004.dat and ATT00007.txt. This is not only completely unnecessary and can cause all kinds of confusion, as I have discovered: it's also downright dangerous, since it ignores the real content of the attachment.
Note in passing that this MUA deliberately mutilates the text: the text in grey reads “Extra line breaks in this message were removed”. By so doing it violates the RFCs, which state that attachments of type text/plain should be displayed without modification.
Various software performs this functionality. I use GPG (GNU Privacy guard), along with the mutt MUA, but it would clearly be useless if you had to use the same software that I do. The verification should be independent of the way you access your mail, but unfortunately Microsoft does not seem to understand the concept of security, and I don't know any way of verification using Microsoft software. If you know one, please let me know.
Clearly it's a good idea to sign your email, especially since good software makes it trivial to do so. The only disadvantage is that people with second-rate mail user agents can't easily confirm that the signature is correct, but that doesn't make it wrong to put the signature there. So why don't I do it with all messages?
There are four reasons:
Some mailing list software doesn't like MIME, and will refuse messages with any kind of MIME attachment. Nowadays this is quite uncommon.
Microsoft “Outlook” and “Internet Explorer” both find the text attachment, but make a complete mess of the signature, scaring people into thinking that it's a security breach and making them think they're going to compromise their system:
|
Microsoft “Outlook Express” makes it so difficult for the user to know what's going on that they frequently think there is no message at all:
|
The text is the footer text from the mailing list. In many cases, there's no text at all. The only clue that there's anything else is the “paper clip” icon on the right. If you click on that, it'll show the attachments, and you can select them:
|
Once again we see these silly magic names. This is the same issue that “Outlook” has, causing it to make the preposterous claims in the previous section. It's worth noting, though, that the attachments aren't the same ones that “Outlook” reported, as you can see by the size. The first one is the text, which wasn't reported by “Outlook”.
Some companies have such a limited grasp of security concepts that they refuse to accept digitally signed messages. eBay thinks that they encourage identity theft. It's difficult to fathom the confusion that could lead to such a conclusion, but it's happened to me.
So Microsoft's mail software doesn't handle digital signatures. What does Microsoft recommend instead? Their Security Response Center publishes... a PGP key for signing mail, and they use it:
The original message looks completely normal, and the only evidence of typical Microsoft mutilation was in the 298 character long footer “Unsubscribe” line, which has probably been added automatically. It's a good thing it is signed, or it would be easy to come to the conclusion that it was a fake based on the format. It's difficult to understand this contradiction. My best guess is that the people in Microsoft's Security Response Center understand the issues and do the right thing, but they haven't convinced the rest of the company yet.
Greg's home page | Greg's diary | Greg's photos | Copyright |