SMS Vs Email Sender Authentication Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Short Message Service (SMS) and Electronic Mail (Email) are the most popular means of electronic communications today because of their ease of use and availability. Their usage continues with the growth of mobile phones [1] and the ubiquity of the internet. Unfortunately, like many electronic services, SMS and email have suffered several abuses, one of which is the faking of the sender identity. This poses a serious threat to the reliability of these services, because the identity of the sender is crucial in any communication. The email in particular is much more prone to this abuse than the SMS counterpart because of the inherent design issues.

Faking an Email Sender

The email was built on the Simple Mail Transfer Protocol (SMTP) with the objectives of transferring mails reliably and efficiently [2]. Like many of the early internet services, there were no security considerations which meant that it had no means of ensuring confidentiality, integrity, privacy and authentication.

A typical email message consists of an Envelope, a Header and a Body. The Envelope typically contains the HELO identity which is the Mail Transmitting Agent (MTA) sending the message, the MAIL FROM identity, the email address responsible for sending the email and acting as the delivery address for error responses. The Header contains other details of the message including the Subject, Sending date and other identities. Other important header information include the From identity which contains the address of the author of the message. The Sender identity is used to if the author of the message is not the actual sender of the message. The To identity serves as the address of the intended recipient.

These header identities are not required for message delivery but for the recipient to identify the author of the message. Because the email protocol does not provide for the verification of the author and sender information saved in the headers, they can be changed to reflect another email address, thereby deceiving the recipient. Also, the messages are transmitted through many intermediate servers in the clear which makes it easy for a malicious user to intercept and manipulate these header identities.

SMS Sender Authentication Mechanism

Unlike email, security was built into the Global System for Mobile Communications (GSM) protocol on which SMS rides from the onset. It was intended to provide anonymity, authentication, and confidentiality of user data and signalling information [3]. The authentication ensures that it is almost certain that the user is the one s/he claims to be. To achieve this, subscriber authentication is performed at each registration and before any service is performed. [4][5].

The mobile station (MS) consists of the Mobile Equipment (ME) and the SIM (Subscriber Identification Module) card. The SIM is a smart card that contains a unique identifier, IMSI and a Ki, an individual subscriber authentication key. The Ki is a 128-bit random number which is the root cryptographic key used for generating session keys and for user authentication. It is stored in the SIM and the Authentication Centre (AuC). The authentication process works though a challenge/response process involving the MS, AuC, HLR (Home Location Register) and MSC (Mobile Switching Centre)/VLR (Visitor Location Register). The AuC fetches the Ki from the HLR using the IMSI of the MS and using the A3 algorithm, Ki and a random number, R the AuC calculates an expected signed response, SResp from the MS. Secondly, using the A8 algorithm, Ki and R; it calculates another key, Kc. The Kc, SResp and the R are then delivered to the MSC/VLR. The MSC/VLR then sends the RAND to the MS. Since the MS has the Ki and can perform the A3 and A8 encryption algorithms, it calculates the Kc and the SResp. The MS then sends the SResp to the MSC/VLR which compares the value with the one it got from the AuC. If they match, the user is authenticated; otherwise access is denied [6]. All subsequent messages from the MS are recorded against the IMSI. This authentication mechanism makes it very difficult to fake the identity of another subscriber.

Some Proposed Solutions to Email Sender Authentication

Various solutions have been proposed to address the problem of the email sender authentication. Some of the approaches attempt to verify the address of the purported sending server while the others provide a more end-to-end authentication mechanisms or a combination of both.

Sender Policy Framework (SPF) and Sender ID

These protocols are designed to protect against the forgery of email sender identities either in the envelope or in the header. They verify that the sending mail server provided in the envelope is actually authorised to send mails on behalf of the domain. In SPF[7], the identities HELO and MAIL FROM are authenticated by comparing the sending mail server's IP address to the list of authorized sending IP addresses as published by the sender domain's owner in a DNS record "v=spf1". Sender ID[8] proposed by Microsoft works like the SPF except that it authenticates one of the header addresses using an algorithm Purported Responsible Address, PRA [9].

SPF and Sender ID require that every mail server has to publish the list of IP addresses that are authorized to send emails on behalf of its domain. The main disadvantage of this is that it will take a long time before all mail servers will adopt these approaches. Statistics [10] show that these methods have not been widely accepted. It also causes problems for users who legitimately want to use another domain to send emails without changing their addresses. Secondly, both approaches do not address the problem of cross-user or cross-domain forgery where users within the same domain can forge each others’ address.

Secure MIME (S/MIME)

S/MIME [11] works by signing and optionally encrypting the body of the message. It relies on public key certificates for the identification of senders, using the X.509 public key infrastructure (PKI). It is supported by most of the popular mail clients available. The issue with this solution is that every user has to buy a certificate from a certificate authority (CA), though this is a lot cheaper than that of required for a web server. The signature on the mail serves as an assurance to the receiver that the person with the signing certificate most likely authored the message content.

Pretty Good Privacy (PGP) / OpenPGP

PGP [12] has been adopted by the IETF as the de-facto standard for signing and encrypting text or any block of data. Under the name OpenPGP [13], it is flexible for use even with mail clients that do not have the capability to sign and encrypt messages. OpenPGP has been adapted to PGP/MIME to multi-part MIME messages in a similar way to S/MIME. The difference is in the management of keys in that PGP/MIME works with a public key web of trust instead of relying on a central CA. This implication here is that receivers cannot really verify the sender and just have to trust the key. The trust is usually established through personal contacts and public key verification.

DomainKeys Identified Mail (DKIM)

DKIM [14] combines the some of the features of the above protocols and hence it’s a hybrid. It ties the authenticity of the message content to the message's alleged sender identity. This means that in order for a message to be considered valid, its signature must be verified successfully and the domain of the sender in the header must also match that of the signing key. DKIM provides a cryptographic signature of multiple Internet Message Format header fields and the body of a message. A domain that is implementing this protocol must publish the public (domain) key corresponding to its private key in a DNS record. The key can then be used the mail receivers to check the authenticity of the message header and body with compared with the header sender identity.

Though S/MIME, PGP and DKIM are more effective than the SPF and Sender ID, they are still not as widely adopted as they should due to usability and other practical issues. There are issues around getting a certificate through a CA or web of trust. Also, many ordinary users may not create strong keys for use which may undermine the security. They are also CPU intensive and require the whole message to be received before the validity is determined and action taken.

Trusted Email System

Another proposal is the use of a hardware-based cryptographic functionality of Trusted Platform Module (TPM) and the Ephemerizer concept [15]. The TPM addresses the vulnerabilities of software based keys prone to PGP and S/MIME by storing the keys in a tamper-resistant hardware module while the Ephemerizer issues ephemeral keys which are used to encrypt emails and expire after a period of time. The disadvantage of this is that new TPM hardware has to be acquired to do this.


Due to the lack of security in the email protocol, it is very easy to fake the email sender. This is a lot more difficult with SMS due to strong security design built into GSM. SPF and Microsoft’s Sender ID are part solutions to the problem of email authentication. Only end-to-end solutions such as PGP, S/MIME and DKIM can provide adequate authentication. However, due to the complexity of creating certificates and usability, the adoption of these protocols is still quite low. A TPM-based solution would be the ideal for solving these problems but it will take a while before enough personal computers have the module and there are cost implications.