The ideal system that everyone is searching for – the silver bullet, is to
have top security automatically regardless of who you are sending to and what
product(s) they happen to be using. The reality is that many e-mail packages
are not themselves secure, and do not interoperate cleanly with anything but
their own products.
For the time being you are better off keeping your security outside of your
e-mail or word processing package, and exchanging attachments that are fully
protected and not relying upon any of the different systems that people are
using. That way you increase the security of the result and do not have to rely
on complex interactions between proprietary systems.
It may not be as elegant, but it will take you a lot further than relying on
a specific e-mail service and will give you, for the time being, a much more
For the last ten years or so we have become increasingly reliant on e-mail.
It is ubiquitous, and unlike real mail it can chase us from continent to continent
in seconds. For better or worse we now have the ability to conduct the next
worst thing to conversation, but in writing.
Of course, and despite all the advice, we treat this ability as if it were
the same as personal conversation. Private. Off the record. We also assume that
no-one else is going to be able to read it, and that it can’t ever get into
the wrong hands.
Slowly but surely we are finding out, the hard way, that, as in the words of
the song, “It ain’t necessarily so.” What we are doing is like sending picture
postcards through the mail. It appears that everyone from our e-mail administrator
to half the hacking community can pick up what we are doing, even off the internal
Enter the answer – secure e-mail (Se-mail?). Run it just like ordinary mail
but click on the secure button and you’re done. Shangri-La! But is it for real
or is it yet another of the IT pipe dreams?
Silver Bullet Syndrome
This is not a new disease. Far from it. This is a regular epidemic every time
someone goes near the IT security allergy. Somehow or other it seems obvious
to anyone that the immense complexity of the computer can be made safe and secure
by a single act (the laying on of hands perhaps?). Despite the fact that every
day experience teaches us how difficult it is to get a computer to anything
without us making a significant contribution, security is supposed to happen
without any thought or planning (even less than putting something in a brown
envelope rather than a see-through folder).
Manufacturers have been quick to recognize two things. The first has been that
they need to service their customers more so that they can charge more. The
second is that despite all the claims about standards in security, the cold
hard reality is that there are hardly any.
What, no standards?
Well, almost none. We have S/MIME (version 2 or 3?) to sort out how you might
sign and encrypt streams going from one e-mail client to another. That’s fine
except that you need ‘PKI’ standards sitting behind S/MIME to make it useful,
and there seem to be more of those than you can shake a stick at. This is a
case where there are so many different standards (and even more interpretations
of them) that in effect you have no standards.
If you want to think about standards in terms of manufacturer’s products (after
all, dominant suppliers and monopolies set standards of a kind) then the picture
is more like this. We have Outlook Express and Outlook (not the same thing even
if they are from the same stable) and HotMail. To that we must add Eudora, Lotus
Notes and AOL (Compuserve). We have an increasing number of web-mail products
such as Yahoo and Lycos, just in case the others weren’t enough. And we haven’t
yet begun to mention all the various brands of ‘secure’ mail that exist, including
PGP. Can you believe that all of these interoperate smoothly and seamlessly
with each other?
So we can conclude that standards are not yet in a position to help us.
Somewhere in the security debate, you lose, as we seem in danger of doing,
sight of what your objective actually is because the technology debate is so
much more confusing.
The objective for the user might be summarized as follows (borrowing from the
- to be certain what they send goes to the right person/place;
- to be certain that the right person/place can read the information;
- to be able to use signed information as proof to a court or other body;
- to stop the wrong people from reading personal and private
Some of these wishes are more difficult than others. Just as in the paper world,
you can’t stop anyone seeing the address on the outside of a letter, the same
is true of e-mail. If someone alters that address, it doesn’t go to the right
place, and if someone alters the return address (in many countries it is written
on the back of the envelope) the recipient may not know where it has come from
or it may not, if delivery fails, be returned to the correct sender.
We are familiar with the paper world and it has some benefits. You can usually
see if someone has already opened your mail. The Post Office can often cope
with wrong addressing and still get it to the right place. You believe that
the delivery service is going to behave in the way that you expect and you know
that a proof of delivery from them is accepted by the authorities.
E-mail is rather different. There is no way of telling who reads the mail unless
you take actual steps to make it impossible. The e-mail Post Office can’t cope
with any address errors whatsoever. It has no idea if any of the addresses on
the mail are correct and can’t tell if they have been altered. There is no plain
envelope to stop people reading the contents and it is possible for hackers,
government agencies and almost anyone else to read the mail. Proof of delivery
is worth the paper it is printed on.
An impossible dream?
No. E-mail can be made secure, but you have to take a few things into account.
The first thing to understand is that you can’t do much about the addresses,
or the subject line. Nothing about these can be made secure. Don’t ever believe
them when you read them.
Different systems may allow you to secure the message text of the e-mail, but
you have to be very certain what that security is, when it is added, when it
is removed, and how you would prove it had been secured afterwards. These are
fundamental to you if you are going to rely on the security mechanisms later
as proof that something happened.
The second thing to understand is that you can never (with current systems)
send anything secret to someone you don’t know. It’s not possible. You have
to have a ‘public key’ of theirs before it can be done. You can’t, with conventional
systems, send information to ‘anyone’ in a particular group, function or business.
You have to send to specific individuals.
The third thing to understand is that the protection that you apply to an e-mail
has to be something that the recipient can deal with. E-mail systems don’t currently
relate the keys used for information protection to the recipients of the e-mail,
and don’t know what algorithms the recipient is likely to have. This is because
there are far too many unnecessary choices forced onto users of these systems
and services (or set by administrators who are making choices based upon their
own prejudices rather than looking at usability). If you use something the recipient
can’t process you are wasting your time. But you can’t afford the time needed
to sort this kind of problem out.
Problem solving strategies
Most of the difficulties identified can be avoided by ignoring the e-mail systems
completely and concentrating instead on the information to be sent. This could
be anything – a Word document, a text file, some HTML, a graphic or even a video.
Whatever you do should not alter its content, and it should not be possible
to remove your security before the information is securely in the computer of
This means that your protection software is going to have to protect the file
in such a way that an attacker cannot remove the protection without you being
able to detect it. (That’s not the same as pretending a fake document is real.
Since much of the information you get is not protected, today you make value
judgments on what is ‘right’ based upon your own feelings, or you ‘phone the
sender and ask them to confirm what they actually sent. So removing the protection
and making subtle changes to documents that you might then believe is perfectly
The recipient is then in a position where their first step is to check the
authenticity of the file they have received. That avoids any possibility of
misunderstanding what is protected and what is not. The file is the thing that
is protected, and not other parts of the e-mail that may, or may not be correct.
Once the recipient has checked that the file is authentic they can go ahead
and use a copy of it that has had the protection removed. This is an essential
step, because they must not be able to alter, or add to, the file that they
received and still have it claim that it was ever authentic (unless, of course,
you have some system that maintains a copy of each different thing in the file,
protected by each person that has altered or added to it).
This approach may not seem as ‘elegant’ as having everything automated, but
it is a lot more secure, and prevents any mistakes or misunderstandings about
who has signed what, and therefore what can be relied upon.
About The Author
Steve Mathews has over 15 years information security experience and is
one of the authors of ISO/IEC 17799 and BS7799 part 2. He is a CLAS consultant
recognized by the UK national security agency CESG.