Secure e-mail protocols

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.

1 Introduction

Electronic mail or e-mail has become an essential communication tool these days. E-mail has become an integral part of the way we conduct our online business and personal lives. In terms of e-commerce, e-mail is the foundation of the technology. Most of the e-mail systems are vulnerable to a number of security attacks. The sender is not able to make sure that whether the receiver receives the e-mail or not. Similarly the receiver is not able to determine whether the e-mail is from the actual sender or not. We send the e-mail through open channel and there are many chances of eavesdropping and modify the content of the e-mail by the attacker. E-mail systems transfer not only text but also graphics, pictures animations, electronic documents, voice and financial transactions via internet. In order for e-mail to be used for important communications, some notions of certified delivery must be there for users. A certified e-mail protocol must possess the following security properties:

  • Alice ( the sender) must have sum way of proving that Bob ( the receiver) received the mail, if bob later try to deny it.
  • Bob must have some way of proving that Alice did not send the mail , if Alice later try to claim that she did.

A Certified E-mail Protocol

Alice wishes to send Bob a certified message. Bob wants to receive a certified message. A Protocol is needed for this exchange i.e. we have to build a protocol to allow Alice to be able to prove to an arbiter that Bob has received her message if and only if he did receive it [1].

Let M be the message, K a key, Ek an encryption method using K and some standard symmetric cipher [ NBS77, LMM91, Sch 94 ] , and H a message digest.

  • Alice chooses a random key, K and sends the encrypted message Ek(m) to Bob.
  • Bob returns a digitally signed message to Alice with form: I would like Alice to publish the key for the Ek- encrypted message, whose digest is H(Ek(M)), by date T at location X. -/s/Bob
  • Alice publishes the pair H(Ek(M)), K in X on or before date T.
  • Bob retrieves the key and decrypts the message.

If Alice is called upon to prove that Bob received the e-mail, she presents her copies of M, K, Ek(M), and Bob's signed message from step (b). Also she presents the public record of her publishing them in step (c) in accordance with Bob's request. The arbiter confirms that Ek(M) is correct and conforms to what was published in step (c), and also that the publication was in accordance to Bob's request in step (b). If Bob is called upon to prove that Alice did not send him the e-mail, he challenges Alice to present the body of evidence listed above. If she cannot, the arbiter has no choice but to believe Bob.

Analysis of The Protocol

The protocol is secure against cheating attempts by either Alice or Bob:

  1. If Bob refuses to comply in step (b) mentioned above or gives an unreasonable date or location, then he does not receive the key for the encrypted message and hence does not receive the message.
  2. I f Alice refuses to comply in step (c) and claims that Bob has received the message when he does not , then Bob can show that Alice did not publish the key by calling upon the public records of location X. This is conceptually equivalent to Alice not sending the message but then claiming she had.
  3. If Bob refuses to comply in step (d), then he loses because he has claimed that he will comply in step (b). This is conceptually equivalent of Bob's accepting and signing for the certified mail but refusing to open it.

Security Properties

The protocol has a few properties [1] which are worth explicitly noting.

  1. The signed message of step (b) must make clear how and when to retrieve the key and how to retrieve the key and how to use it to decrypt the message. This prevents Bob from claiming that Alice has waited unduly in publishing the key.
  2. Bob may wish to include with his message of step (b) a description of what he expects from the contents of decrypted message. By doing so, Bob greatly reduces Alice's ability to deliver bogus information.
  3. So long as neither Alice or Bob attempt to cheat, their identities need never be revealed to a third party i.e , this whole protocol could be conducted anonymously , through anonymous remailers.
  4. This method does not offer privacy in that an eavesdropper has access to both Ek(M) and K. If privacy is required, the exchange at steps (a) and (b) should be conducted using a method providing adequate privacy.
  5. Alice must retain a copy of T, K, and Bob's key request message for as long as she wishes to be able to prove receipt. This is equivalent to Alice keeping a copy of the certified e-mail receipt.

It should be noted that if Alice has a reliable connection to the public channel, we can render the protocol optimistic by adding between steps (b) and (c):

  • Alice gives Bob K directly
  • Bob gives Alice a receipt for k

If Bob gives Alice the receipt for K, she need not publish as required by step (C) , thus reducing network traffic. If Bob fails to give Alice the receipt , Alice may continue with step (c).

Trusted Mail Gateway

E- mail systems are vulnerable to a number of security risks. In an e- mail exchange process, receiving party cannot be certain that the e-mail is from the actual sender and sending party is not able to make sure that the intended recipient has received e-mail. E-mail is always vulnerable to eavesdropping since it is delivered with other Internet traffic over the same transport device. Malicious content in e-mail might enter user host through e-mail client. Spam mails fill user's mailboxes and create unnecessary network traffic. All these result in loss of information, unavailability of network services and misuse of computing resources. As a result, secured and trusted e-mail delivery is required. Trusted Mail Gateway [2] provides a solution for security problems in e-mail delivery. The Trusted Mail Gateway offers domain security. It is compatible with existing-mail clients and domain e-mail servers. It generates S/MIME digital signatures and performs S/MIME encryption on behalf of the domain using secret key Cryptography Message Syntax (CMS) data to provide origin authenticity, integrity and confidentiality. It applies anti-virus control and protection, spam filtering and content check to both incoming mails to domain and outgoing mails from the domain to prevent attacks against availability. It also provides intra-domain security. It keeps e-mail messages in corresponding mailboxes as encrypted messages. Trusted Mail Gateway processes all the mails passing through and records processing results in database as notary information. Moreover, it establishes trust relations with other registered trusted domains and exchanges notary information with them via a secure channel.

The Trusted Mail Gateway provides domains with e-mail confidentiality, origin authentication, message content integrity, traffic logging, anti-virus protection, notary mechanisms and content filtering. Incoming messages are written into users' mailboxes as encrypted e- mails. All public key usage including signature verification is based on public key certificates. Both incoming and outgoing e-mails could be checked by anti- virus software component of The Trusted Mail Gateway. Content filtering could also be applied to incoming and outgoing e- mails' content by using pre defined text patterns. Security policies and control information are exchanged between the Trusted Mail Gateway over the internet. Security functionality of Trusted Mail Gateway is based on world-wide standards. It accomplishes confidentiality, integrity, non- repudiation and authentication tasks by employing Public Key Infrastructure (PKI). PKI includes secret key cryptography, public key cryptography, digital signatures and X509 public key certificates[2]. Security services employed in domain security including digital signatures and encryption are based on Secure/ Multipurpose Internet Mail Extensions (S/MIME). Trusted Mail Gateway holds information about clients' actions on their mailboxes, e- mails, access times and traffic logs in relational database. Domain users do not need to be aware of the existence of the Trusted Mail Gateway and its add- on functions. Domain users shall only recognize the Trusted Mail Gateway as their ordinary mail server.

System Architecture

The Trusted Mail Gateway architecturally connects the users' mail clients and the e- mail server. The clients connect to the gateway, instead of the actual mail server of the domain for sending and receiving mails. The Gateway then handles the necessary communication with the mail server, and makes the necessary checks and changes to the mails on their way. The mails coming from other domains are first received by the gateway and then passed to the actual mail server. This architecture is depicted below:

The functionality of the system is described below:

  • Traffic logging and notary mechanisms: The gateway logs all or selected parts of the mail traffic of the domain it serves. The local administrator can use the logs to inform sender domain's gateway about the delivery status of a mail, as well as to answer queries.
  • Anti-virus check: All mails passing from the gateway are checked for viruses. Virus alerts are logged, and infected mails are stopped.
  • Anti-spam check: The gateway does not let mails with spam characteristics to pass. Such mails are logged and blocked.
  • Domain security using S/MIME: The gateway can generate S/MIME signatures and performs S/MIME encryption on behalf of the domain, using X509 certificates issued for the gateway and other domains' gateways.
  • Content filtering: The gateway can be configured to block mails that contain pre-defined text patterns or attachments with specific file types.
  • Communication with other gateways: Security policies and control information are exchanged among the gateways via secure protocol.
  • Local CA (Certificate Authority): The gateway employs a local CA module in order to issue X509 certificates to clients and to itself. Those certificates are only valid in the domain. They are used to produce signatures, signature verification and encryption purposes in the domain.
  • Intra-domain S/MIME: As an advanced feature, in domains with existing PKI systems, the gateway may use clients' x509 certificates to verify personal signatures on outgoing mails, and encrypt incoming mails. This feature is employed to provide end-to-end security.
  • User Account Management: The gateway relates X509 certificates issued by local CA with client mail accounts. The gateway notifies local CA to issue a new certificate for a new client and informs local CA to revoke a client certificate if the client account is disabled.

The Trusted Mail Gateway handles security of an e-mail in such a way that end to end security is composed of three stages:

  1. Security of the e-mail between originating client and the originating domain's Trusted Mail Gateway,
  2. Security of the e-mail between originating and destination domain's Trusted Mail Gateways and,
  3. Security of the e-mail between the destination domain's Trusted Mail Gateway and the recipient of the e- mail.

Following figure depicts the end to end security property of Trusted Mail Gateway that consist of three stages, thick lines represent the e-mail traffic secured by two peer Trusted Mail Gateways.

E-mail Protocol for E-mail Transmissions on Mobile Equipment

A secure e-mail protocol is needed when a sender and a receiver exchange e- mails on insecure public networks like internet or mobile networks. Secure e- mail systems ensure that the content of e- mail is accessible only to the authorized recipients and the e- mail is not modified during transmission. Many users believe that the security of e- mails is guaranteed by a password login system. However the internet and mobile networks are more dangerous than the users believe and the password login system is insufficient to guarantee the security of e- mails. Forward secrecy is a security requirement of key exchange protocols which are cryptographic protocols. If forward secrecy is not provided in an e- mail protocol that uses short term keys, the previous e- mail messages will be disclosed when the long term keys of the parties are disclosed. In key exchange protocols, the forward secrecy can be achieved by the ephemeral Diffie- Hellman key exchange technique. However, it is difficult to use the simple and novel technique to a non-interactive protocols like e- mail protocols i.e. we cannot guarantee the recipient is always in the on line state. So designing an email protocol providing forward secrecy is not easy at all. To provide a reasonable level of security, an e- mail system such as PGP (Pretty Good Privacy) usually combines both symmetric and public-key crypto systems. The main idea is to encrypt the e- mail contents, using a symmetric encryption scheme with a short term key using a public key encryption scheme with the recipient's public key. That is, if designed correctly, the short term key can be decrypted and eventually the e- mail contents can be decrypted only by the recipient.

Now, a password based e- mail protocol, PAEP for M2M equipped with IC cards is presented [4]. Assume a user A is a sender and user B is a receiver, and SA and SB are the mobile mail server of A and B respectively.

PAEP consist of three phases:

  1. In the user's login phase, a user logs on his mobile mail server by using his password. In this phase the user and his mail server exchange a short term key using the shared password only without revealing any information about the password.
  2. In the sending phase of the sender A, A sends an encrypted mail for the recipient B to SA, and SA transmits the encrypted mail to SB. A and SA use the short term key established in the login phase for authentication.
  3. In the receiving phase of B, SB forwards the stored encrypted mail to B.

Login phase of A:

When A wants to log on SA , A and SA perform the following protocol:

  1. A chooses a random number x and sends ( A, XA = g1H(A||SA||PwA) . g2y mod p) to A.
  2. SA sends ( XSA = g1H(A||SA||PwA) . g2y mod p) to A.
  3. A computes kA = (XSA / g1H(A||SA||PwA))x mod p and sends tA = Mac.genKa (A||SA||XA||XSA) to SA.
  4. SA computes kA = (XA / g1H(A||SA||PwA))y mod p and sends tA = Mac.genKa (A||SA||XA||XSA) to A.
  5. [S] and [SA] If tA (tSA) is not a valid MAC tag, SA halts. Otherwise A and SA compute KA = H(A||SA||XA||XSA||kA).

Sending phase of A:

When A wants to securely send message M to B, A, SA and SB perform the following protocol:

  1. A sends (A,B) to SA.
  2. SA sends (A,B) to SB.
  3. SB recovers (B, g2Rb) from the list. SB sends (YB = g2rB , t1 = Mac.genKss ( B||A||SA||SB||YB) to SA.
  4. If t1 is valid, A sends ( YB , t2 = Mac.genkA (A||B||SA||YB||)) to A.
  5. If t2 is valid, A chooses a random number rA , computes YA = g2Ra and sk = H (A||B||YB||g2rArB). A sends t3 = Mac.genkA (A||B||SA||Z||YA)) to SA.
  6. . If t3 is valid, SA sends ( Z, YA) to SB.

Login Phase of B:

B and SB anonymously act as in the login phase of A.

Receiving phase of B:

  1. After B successfully logs on SA , B and SB compute KB. SB sends (A, Z, YA , t5 = Mac.genKb(SB||A||B||Z||YA)) to B.
  2. If t5 is valid , B computes sk using rB which is stored in IC chip of its mobile phone. B chooses a random number rB' replaces rB' for rB in its IC card. B sends (g2Rb', t6 = Mac.genkB(B||SB||g2Rb')) to SB.
  3. [SB] If t6 is valid , SB replaces ( B, g2Rb') for (B, g2rB) in the list.


In this paper, first a protocol allowing certified mail and an optimistic variation on this protocol was presented. These protocols minimize trust and complexity requirements on parties external to the two players. Secondly, the concept of Trusted Mail Gateway was presented which states the Trusted Mail Gateway records delivery and reception of all e- mails, sender and recipient data, peer domain name, security control results, delivery and reception time stamps with unique identifiers i.e. all events regarding to mail delivery process are under control. It is concluded that the Trusted Mail Gateway works with existing mail server and mail clients in the domain and it is efficient to set up and to spread domains that run Trusted Mail Gateway. This would be a great leap against mail security problems.


  1. Bruce Schneier, James Riordan, " A Certified E- mail Protocol", 14th Annual Computer Security Applications, Dec 1998.
  2. Erkut Sinan Ayla , Attila Ozgit, " An Architecture for End-to-End and Inter-Domain Trusted Mail Delivery Service", International Symposium on Computer Networks, June 2006.
  3. Hung-Min Sun, Bin-Tsan Hsieh, and Hsin-Jia Hwang. " Secure E-mail Protocols Providing Perfect Forward Secrecy", IEEE Communications Letters, Vol. 9, No 1, January 2005
  4. Jeong Ok Kwon, Ik Rae Jeong, " An Efficient Password-Based E-mail Protocol for Encrypted E-mail Transmissions on Mobile Equipment"
  5. Alexander W.Dent, "Flaws in an E-mail Protocol of Sun, Hsieh, and Hwang", IEEE Communications Letters, Vol. 9, No 8, August 2005.