E-mail security has been a growing concern over the past few years. The average individual, who uses e-mail, naively believes that his e-mail is private and secure but he is wrong, as the electronic world is filled with snoopers who can access all types of data over the network. As the world goes digital, with more and more raw information about individuals available electronically, the need for security increases. Ubiquity and speed of e-mail have made it increasingly effective. So providing reliance over this medium has become an inevitable requirement.
The e-mails of today can be made secure by encrypting the content on an external medium and sending this as an attachment over the mail. But this increases the size of the mail and makes it inconvenient for the user. There are other systems that provide specific security and are strongly tied to the mail servers and browsers. Enter the answer—secure e-mail (Se-mail). Run it just like an ordinary mail but click on the secure button and you are done. Somehow 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).
Let us take an analogy that explains a typical e-mail scenario. Suppose a person is in a crowded room and spots a friend to whom he wants to convey an important message, but he does not want to yell. He writes a message on a paper-slip and asks the person next to him to pass it on, trusting no one will read it on its journey through dozens of hands—hands belonging to people he has never met. What are the odds that the person’s friend will be the only one to read the message intended for him or her alone? Untold number of people, including you and me, employ this useful aspect of network and Internet communication to exchange data and documents.
Whilst there are strong legal penalties that deter snooping in the traditional media, such as posted or courier mail, the sheer novelty of computer-aided communication has created gaps in the legal net, allowing for tampering and snooping on others’ e-mails or personal information. As the world goes digital, with more and more raw information about individuals available electronically, the need for security increases.
The major problems that ordinary e-mails suffer are data origin authentication and connectionless integrity apart from privacy. Which means that it is quite difficult with the ordinary e-mail to prove that the sender actually wrote the message, or that it has not been tampered with? Here, we will be discussing about the various challenges in e-mail security and try to find out the solution for the same. At the same time, we will discuss a few tips and tricks that can ensure e-mail security.
How e-mail works
Sending an e-mail message is like sending an ordinary letter (not a courier, registered letter or speed post). When you send a letter, you drop it off at your local post office. Your local post office looks at the address and figures out which regional post office the letter should go to. Then the regional post office looks at the address and finds out which local post office is closest to your recipient. Finally, the recipient’s local post office delivers your letter to its recipient.
Computers are like post offices, and the simple mail transport protocol (SMTP) is the procedure, rather a protocol which a post office uses to find out where to send the letter next in the process. Any program that sends an e-mail message uses SMTP protocol (default port 25) to deliver that message to the next ‘post office’ for relaying to its final destination.
Now, we have sent the mail using SMTP. What about retrieving the e-mail or reading the e-mail? Well for this, two common protocols are used, which are namely POP3 (post office protocol) (default port 110) and IMAP3 (Internet message access protocol) (default port 143). The working of e-mail is depicted in Fig. 1.
In today’s scenario, the objective for the user might be summarised as follows (borrowing from the paper world): 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 receipt as proof to a court or other body; to stop the wrong people from reading personal and private information. Some of these wishes are more difficult than others.
Just as in the paper world you cannot stop anyone from seeing the address on the letters’ envelope, the same is true for an e-mail. If someone alters that address, it does not go to the right place, and if someone alters the return address, 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. 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 cannot cope with any address errors whatsoever. It has no idea if any of the addresses on the mail are correct and cannot 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.
Most people send mail in two ways—with a web-based interface like Yahoo!, Gmail or Hotmail, or with an e-mail client program like Outlook or Eudora. When we send a message with an e-mail program on our personal computer (or cell phone or PDA), we have to specify a server so that our e-mail program knows where to send the message. This server is like our local post office. An e-mail program talks directly to the server using the computer protocol (language) known as SMTP. This is like dropping off a letter at the local post office.
When we use some tool on our personal computer for an Internet connection to communicate with a Web server, the language that the Internet connection uses is HTTP—hypertext transfer protocol. When we send our message with Web mail, the Web server contacts its SMTP server and sends our message to it.
To summarise, when we use the Web-based e-mail programs like Gmail (which is also a cloud service), the Web server already has the SMTP/POP3/IMAP3 address inserted. If we want to access other e-mail accounts maintained by any other e-mail server (term used for SMTP/POP3/IMAP3 server), it can be done using these Web-based services, by mentioning the specific e-mail server address. Let us see the security in both these cases.
In case of e-mail clients like Outlook or any other non-Web-based application, we can apply security on the message and send the e-mail. This kind of security is shown in Fig. 2. In case of Web-based scenario, we can have an SSL kind of environment between client and Web server, and SSL or some other kind of security between the Web server and the e-mail server. Between Web server and client, we can invoke SSL in the form of https://www.site.com. Here SSL, which runs at the transport layer (default port 443), takes care of all the communication being encrypted between client and Web server. Between Web server and e-mail server, we can have SSL-enabled SMTP in the form SMTPS, SSL-enabled POP3 in the form POP3S, SSL-enabled IMAP in the form IMAP3S or some other kind of security. It all depends upon the requirement and ease of usage. The above-mentioned scenarios are depicted in Fig. 2.
We have mentioned a phrase, ‘some other kind of security’ many a times above, but what does it mean? In the scenario of Web-based e-mail access, we can take S/MIME or MOSS as different security standards that can be used. Similarly, in the scenario of non-Web-based access, we can take PGP or PEM as different security standards. But MOSS and PEM are not much used these days for e-mail security.
Issues in e-mail security
E-mail can be made secure, but we have to take a few things into account. The first thing to understand is that we cannot do much about the addresses, or the subject line. Nothing about these can be made secure. Different systems may allow us to secure the message text of the e-mail, but we have to be very certain what that security is, when it is added, when it is removed and how we could prove it had been secured, afterwards. These are fundamental and important if we are going to rely on the security mechanisms later as proof that something happened.
The second thing to understand is that we can never (with current systems) send anything secret to someone we do not know. It is not possible. We have to have a ‘public key’ of theirs before it can be done. We cannot, with conventional systems, send information to ‘anyone’ in a particular group, function or business. We have to send to specific individuals.
The third thing to understand is that the protection that we apply to an e-mail has to be something that the recipient can deal with. E-mail systems do not currently relate the keys used for information protection to the recipients of the e-mail, and do not 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 we use something the recipient cannot process, we are wasting time. But we cannot afford the time needed to sort this kind of problem out.
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 we do should not alter its content, and it should not be possible to remove your security before the information reaches securely in the computer system of the recipient.
This means that the protection software is going to protect the file in such a way that an attacker cannot remove the protection without us being able to detect it. (That is not the same as pretending a fake document is real. Since much of the information we get is not protected, today we make value judgements on what is ‘right’ based upon our own feelings, or we ‘phone’ the sender and ask them to confirm what they actually sent. So removing the protection and making subtle changes to documents that we might then believe is perfectly feasible.) The recipient is then in a position where his/her first step is to check the authenticity of the file he/she has 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, he/she can go ahead and use a copy of it whose protection has been removed. This is an essential step, because he or she must not be able to alter, or add to, the file that they received and still claim that it was ever authentic (unless, of course, we have some system that maintains a copy of different things 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. Now let us see the various issues in e-mail security. Normally, two kinds of threats can be there in e-mail security, and these are:
Threats which can be there on the security of e-mail itself. These are the threats which can make an e-mail vulnerable. These threats are basically of five types. These are:
1. Loss of confidentiality. This threat arises due to lack of privacy of an e-mail, which occurs when an e-mail is sent over open networks. This threat can be removed by providing encryption over the message part. Such a message will not make any sense, even if read.
2. Loss of integrity. When an e-mail travels over a network, the body of the e-mail, which is the message part, can be altered in transit, resulting in the loss of integrity. This threat can be removed by creating a hash of the message at its origin and sending it along with the message. Hash of the message can be recalculated at the receiver’s end and matched to find out if any change has been made in the message over the network by any intruder, and thus in a way takes care of the integrity of the message.
3. Lack of data origin authentication. This threat occurs when a person who appears to have sent the e-mail is actually not the person to have sent the e-mail. This can be due to telnetting the SMTP server directly, sharing the e-mail passwords. This threat can be solved by using the concept of public key certificate, with the usage of public key and private key pair, with public key certificate from a certification authority (CA). We should also not allow direct telnetting to the e-mail server and restrict the common password for individual e-mail accounts.
Fig. 4 and Fig. 5 depict the problem of direct telnetting to the e-mail server and sending an e-mail, lacking data origin authentication. In Fig. 4, we are telnetting to an IP address (of the e-mail server) on port 25, which is the default port for SMTP. When writing mail from :< >, we have written [email protected] and sent to [email protected] Whilst retrieval of the e-mail, as shown in Fig. 5, we have telnetted to an IP address (of the e-mail server) on port 110 for the same. When logging on to Alice’s e-mail inbox, we see the mail to have arrived from [email protected] One important point to remember is that we have taken the example as [email protected] This address can be replaced with any other e-mail id and can create lots of problems.
4. Lack of non-repudiation. This threat arises when the receiver cannot trust the contents sent. There is also mistrust that the sender can deny having sent the e-mail.
5. Lack of notification of receipt. Similar to the above situation, there is a threat in which the sender can have a mistrust whether the receiver has received the e-mail or not. The message which was marked as sent may not have been sent.
The last two threats can be removed by the usage of digital signatures. A digital signature is an electronic means of authenticating an online identity. Along with the authentication, it takes care of the non-repudiation and ensures that an actual sender has sent the e-mail and the authentic receiver has received the e-mail. Digital signature is created when we encrypt the hash of the e-mail message with private key of the sender.
To add to this, we can make this scheme more powerful by encrypting the hash of the e-mail message with the private key of the sender and then again encrypting the result with the public key of the recipient. This ensures that only the receiver is able to read the e-mail and also makes it clear that only the sender has sent the e-mail. This scheme is also known as bidirectional hashing. A fully-secure e-mail can be sent by using the combination of hashing, encryption and digital signature. This scheme is shown in Fig. 6.
Threats to an organisation that arisse due to an e-mail.
These threats mainly include:
1. Disclosure of sensitive information. As we know, disclosure of information can be done quickly by e-mail compared to paper-based mail. The information can be quite sensitive/strategic or of proprietary nature. We do not want to get into the disclosure, whether the disclosure was deliberate (and malicious) or unintentional. Whatsoever it was, disclosure has happened. At the same time, we also have to take into account the fact that disclosure may be internal or external. By external we mean that an e-mail can cross the LAN limit into the Internet world. Such disclosures can lead to loss of information and can even cause loss of reputation of an organisation.
3. Exposure to denial of service attacks. Denial of service (DoS) is an attack which makes a system/individual unavailable to its intended users. Although the means to carry out, motives for, and targets of a DoS attack may vary, it generally consists of the concerted efforts of a person or persons to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely. Perpetrators of DoS attacks typically target sites or services hosted on high-profile Web servers such as banks, credit card payment gateways and even root name servers.
One common method of attack involves saturating the target (victim) machine with external communication requests, such that it cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. In general terms, DoS attacks are implemented by either forcing the targeted computer(s) to reset, or consuming its resources so that it can no longer provide its intended service, or obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately. These attacks can be in two ways:
(i) Exposure of systems to DoS attacks. E-mail server attached to network may be vulnerable to DoS attacks—more relevant with increasing dependence on e-mail as the communications tool. DoS on mail server may compromise other network services too.
(ii) Exposure of individuals to denial of service attacks. Mail bombing, excessive spam generally exposes an individual e-mail client to DoS attack. Individuals get so spammed by incoming e-mail that they stop reading it. We will deal with e-mail spam and e-mail authentication in the next part.
To be concluded in next part…
The author is working in ADRIN, Department of Space as Scientist ‘SF’ and involved in developing applications on network and data security