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.

Fig. 4: Problem of direct telnetting to the e-mail server and sending an e-mail
Fig. 4: Problem of direct telnetting to the e-mail server and sending an e-mail
Fig. 5: Spoofed e-mail sent, being viewed
Fig. 5: Spoofed e-mail sent, being viewed

3. Lack of data origin authentication.

SHARE YOUR THOUGHTS & COMMENTS

Please enter your comment!
Please enter your name here