Computer and Data Security

Jonathan Calazan

CMPT 495

Computer and Data Security

December 20, 2005

EMAIL SECURITY

I. Introduction

Email is now a part of our everyday lives. Pretty much anyone who has access to the internet has an email account. Email is an easy and efficient way to communicate. Many businesses today rely on email to communicate with their customers. But is email secure? While you may already know that email is not secure, you might not realize how insecure it really is. Millions of emails are sent everyday, and many of those people sending these emails are not aware that these emails can be intercepted, misdelivered, read, and even modified by unauthorized individuals.

The good news is that there are ways we can protect email messages we send. Using encryption and digital signatures, we can prevent many of the major security threats to email. Secure messaging schemes, such as Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME), are now becoming easier to implement with many commercial email clients being integrated with them or can be extended with plug-ins to implement them [6]. Unfortunately, many email users have never even heard of these schemes, do not know how to use them, or just do not bother with them because they require a little bit of more work to implement.

This paper will serve as a guide to understanding how email works, the structure of an email message, the threats to email, and how to protect email messages.

II. How Email Works

If you have ever set up an email account using an email client, such as Microsoft Outlook, you have probably seen the terms “Incoming mail server” and “Outgoing mail server.” These mail servers are computers that pass your email messages to other mail servers, where people who connect to those mail servers can receive them.

Figure 1. Sending and receiving emails [11].

Looking at Figure 1, the man connects to a mail server (green computer) and sends his email. This mail server (green computer) then forwards that email to another mail server (purple computer). The woman then connects to that mail server (purple computer) and receives the email the man sent her. The “Incoming mail server” is the server where you connect to to retrieve your emails. The “Outgoing mail server” is the mail server that you connect to to send your email messages. To receive an email, you must have an account on a mail server. This is similar to having an address to receive letters [11]. To send an email, all you need is an Internet connection and the address of an outgoing mail server. Some outgoing servers will require the users to authenticate themselves before they can use that server, but there are many servers out there that would allow you to send emails without authentication (also known as “open-relay servers”). The standard protocol that is used for sending emails is called the Simple Mail Transfer Protocol (SMTP). All email servers communicate to each other using SMTP [3].

III. Email Message Structure

An email message consists of a header. The email header contains information about who the message was sent from, the recipient(s), and the mail servers the message visited [1]. Most email programs for reading emails will hide many of the email header fields by default, but they usually have an option to display the headers (for example, in Microsoft Outlook, right-clicking on an email and choosing “Option” will display the email header). Below is an example of an email message showing the header [1]:

From Fri Aug 18 15:10:01 2000
Received: from bham.ac.uk by isdux1.bham.ac.uk (8.8.8/1.1.8.2/14Aug95-0452PM)
id PAA0000016479; Fri, 18 Aug 2000 15:10:00 +0100 (BST)
Received: from majordom by bham.ac.uk with local (Exim 3.16 #3)
id 13PmpO-0000XU-00
for ; Fri, 18 Aug 2000 15:08:58 +0100
Received: from majordom by bham.ac.uk with local (Exim 3.16 #3)
id 13PmpN-0000XK-00
for ; Fri, 18 Aug 2000 15:08:57 +0100
Received: from isdugp.bham.ac.uk ([147.188.128.15] helo=isdux1.bham.ac.uk)
by bham.ac.uk with esmtp (Exim 3.16 #3)
id 13PmpM-0000XA-00; Fri, 18 Aug 2000 15:08:56 +0100
Received: by isdux1.bham.ac.uk (8.8.8/1.1.8.2/14Aug95-0452PM)
id PAA0000009231; Fri, 18 Aug 2000 15:09:56 +0100 (BST)
Message-Id: <>
Subject: Netscape vulnerability fix
To:
Date: Fri, 18 Aug 2000 15:09:56 +0100 (BST)
From: Chris Bayliss <>
Reply-To:
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender:
Precedence: bulk
Status: RO

Netscape have released a new version of Netscape Communicator (4.75) which is not subject to the Java vulnerability announced preciously on this list.
If you use a vulnerable version of Netscape (version 4.0 - 4.74) it is
recommended that you upgrade.

Chris Bayliss
Information Services

The Received: field tells us the route the email has taken, which servers has handled it, and the times it was handled [1].

The Date: field gives us the date and time the message was sent including the time zone [1].

The From: field gives us information about the sender. The part in angle brackets is a real electronic mail address. This field may be user settable, so may not reflect the true sender. In this case, it shows the original sender of the message [1].

The Sender: field, again, gives us information about the sender. This is inserted by some systems if the actual sender is different from the text in the From: field. This makes email more difficult to forge, although this too can be set by the sender. There are other uses for a sender field. In the example above, the sender is set to the list owner by the mailing list system. This allows error messages to be returned to the list owner rather than the original sender of the message [1].

The To: field tells us the recipient of the message. This may be a list or an individual. However it may bear no relation to the person that the email is delivered to. Mail systems used a different mechanism for determining the recipient of a message [1].

The Cc: field gives us the email addresses of the recipients who will receive a copy of the message [1].

The Subject: field gives us the subject of the message as specified by the sender [1].

The Message-id: is a unique system generated id. This can sometimes be useful in fault tracing if multiple copies of a message have been received [1].

The Reply-to: field contains the email address where any reply should be sent to (in preference to any electronic mail address in the From: field if present). This may be inserted by the sender, usually when they want replies to go to a central address rather than the address of the system they are using. It is also inserted automatically by some systems [1].

X-Mailer: Any field beginning with X can be inserted by a mail system for any purpose [1].

IV. Threats to Email

There are many threats to email. One of them is message interception and eavesdropping. Emails are sent in clear text over the Internet. For example, if you’re connected to a wireless network that is not secured and you send an email, someone can sniff out the packets and be able to read what you sent. Also, when you send an email, as I explained earlier, your emails are saved on a mail server until you retrieve them (or until your email client tells the mail server to delete the messages, but the messages can also be backed up by the mail server, of course). This means that anyone who has Administrator access to the mail server can read your messages. It is even said that government agencies all over the world are reading emails via automated scans [9].

Another threat is sending false messages. It is very easy to create a message to make it look like that it came from someone other than who they are actually from [3]. You can just simply edit the Return Address field and type in anything there, send it, and it will appear in the From field when the recipient receives the message. The reason this is possible is because SMTP servers do not check for sender authenticity. The cartoon below is an example of this threat.

Figure 2. Example of a false message threat.

Other threats include message content modification (again, when your message is in transit anyone with Administrator access to the system can modify your message), denial of message transmission (sender can deny having sent the message), and message replay [7].

V. Requirements and Solutions

According to Charles and Shari Pfleeger, a secure email system must ensure that the message is not exposed en route to the receiver (message confidentiality), what the receiver sees is what was sent (message integrity), the receiver is confident who the sender was (sender authenticity), and the sender cannot deny having sent the message (nonrepudiation) [7]. The use of digital signatures and encryption satisfies these requirements.

A digital signature is a protocol that produces the same effect as a real signature: it is a mark that only the sender can make, but other people can easily recognize as belonging to the sender [7]. It is used to confirm agreement to a message, just like a real signature. Using a digital signature assures the authenticity and nonrepudiability of the sender [7]. A digital signature also assures the integrity of the message because of a hash function called a message integrity check (MIC) in the digital signature [7].

Public key encryption systems are usually applied to digital signatures [7]. Two keys are used: a public key and a private key. The private key can encrypt and decrypt the signature. The public key can be used to decrypt, but it cannot be used to encrypt, only the private key can encrypt. Most of the time when someone sends a digital signature, it comes with the corresponding public key. It does not matter who has access to the public key because it is only used for decrypting the signature. This method works for verifying the identity of the sender because the public key can only decrypt the message that corresponds to the private key that was used to encrypt the message. If the public key failed to decrypt the message, then you know that the message did not come from who it claimed it came from.

Now, for the confidentiality problem, this is solved with encryption. The message is encrypted with the recipient’s public key and decrypted with the corresponding private key (for asymmetric encryption). If someone intercepts the message, unless that person has access to the recipient’s private key, the message would not make any sense to him/her. Below is an example of what an encrypted message looks like.

Figure 3. Encrypted message example.

Two popular examples of secure email systems that provide digital signatures and encryption are Secure Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP).

VI. Secure Multipurpose Internet Mail Extensions (S/MIME)

S/MIME was developed by RSA Data Security, Inc. It is the Internet standard for secure email attachments [7]. Today, support for S/MIME is integrated into many email clients, such as Microsoft Outlook and Outlook Express, Netscape Communicator, and Lotus Notes [2]. Because of this, S/MIME is likely to dominate the secure email market in the future [7].

S/MIME encourages users to obtain a Digital Certificate from a reliable Certification Authority (CA), such as VeriSign, Thawte, Equifax, and VISA, to ensure that the name on each certificate really belongs to the entity that controls the certificate’s matching private key [2]. This could be a complex process and usually involves payment. VeriSign Inc., for example, sells a simple certificate called a “Class-1 Digital ID” for $14.95 that expires after a year [2]. There are also CAs that give away free “personal email certificates” such as Thawte Consulting Ltd. (www.thawte.com) [2].

Obtaining a free Digital Certificate from Thawte wasn’t that difficult. All you have to do is go to their website and click on the link that says “Click here for you free Personal Email Certificate now!”, and answer a few pages of questions. They will also send you emails to the email address you provided and one of them gives you a confirmation code that you must enter on their website to confirm that you in fact have access to that email address. Once that is done you can download your free Digital Certificate and import it to your email client. This Digital Certificate, however, only contains your email address and not your full name. If you want your full name on the certificate, you must provide them with more information, such as a passport number, driver’s license number, or social security number. If you know a Certified Public Accountant, a Bank Manager, or a Practicing Attorney, they can also sign for you to get your identity trusted so your full name will appear on the certificate. Below is an example of a Digital Certificate issued by Thawte.

Figure 4. Digital Certificate.

You can see from Figure 4 that next to the Issued To: field, all it says is “Thawte Freemail Member” and not my full name. The reason for this is because they have not verified my identity, only my email address. I can still send digitally signed messages, but all it confirms is that the email actually came from that email address. Figure 5 shows an example of a signed Microsoft Outlook email message.