Secured Mail Through PGP Mail Gateway

Abstract – PGP Mail Gateway is a backend server which acts like a gateway for mail encryption and decryption with digital signature using industry standards available on open source environment. It is designed to be deployed even on an existing mail server or as a separate backend service where it will provide email security through GPG (open source version of PGP) encryption. Therefore this system will not route emails but will handle only email encryption and decryption. PGP Mail Gateway will serve the purpose of providing email security to a business entity which requires a low cost but highly secure solution with user interactivity kept at a minimum.

Keywords- PGPMG – PGP Mail Gateway, RFC – Request for Comments, Cryptography – is the practice and study of techniques for secure communication, Cypher text – text with cryptography applied on them , Encryption – turning plain text in to cypher text, Decryption, SMTP – Simple Mail Transfer Protocol. I. INTRODUCTION

Email is apparently the most popular mode of communication in the world. An email is considered an open postcard which traverses through internet where anyone can read it. Thus, it goes through an unprotected network before it reaches the destination. Several RFCs on enhancing the privacy of emails have been put forward by different groups in order to bring more secure platform to the user [1].

However, several cryptographic methods are available such as symmetric-key encryption, Caesar’s cipher and public key cryptography [2]. By using these methods several data encryption methods have been implemented.

A. Pretty Good Privacy (PGP)
This data encryption and decryption program is often used for signing, encrypting, decrypting texts, files, etc… PGP has both features of both conventional and public key cryptography. PGP follows the Open PGP standards (RFC 4880) for data encryption [3].

B. GNU Privacy Guard (GPG)
It is the alternative to PGP Suite. GPG is compliant with RFC 4880 which is the current IETF standards track specification of OpenPGP. GPG is a part of Free Software Foundation’s GNU software project.

C. Secure/Multipurpose Internet Mail Extensions (S/MIME)
This is a standard used for public key encryption and signing of MIME data. S/MIME provides authentication, message integrity and non-repudiation of origin using digital signatures and data security.

Even though these programs are available, people hardly use them with their email communications. Companies invest a lot in security and especially on their email system because their business process is highly dependent on emails.

Let’s consider the typical mail server system of an organization. Normally this is placed inside the De-Militarized Zone (DMZ) of the network. Emails passed within organizational network will not travel through internet. But when an email needs to be sent between two organizations of in different networks, it will travel through internet. When a user, who is using probably an email client such as Mozilla Thunderbird or Microsoft Outlook or Webmail, wants to send an email to the another person outside of the network it will be using internet as the communication mode. As a result, anyone with the right tools can view the email and will be able to change the passing message. Also the middle person can send modified messages to both sides. So there’s a question of authenticity, integrity and privacy. Without proper email security, organizations might have to face such situations [1].

As mentioned above, there are security measures such as PGP/GPG or S/MIME that can be adapted to the company security policy. But there’s another issue that a company has to face when introducing these methods to all the employees. It’s not easy to use PGP/GPG or S/MIME with a mail client and handling all the keys and certificates by themselves. This is another problem area as to why companies do not use these encryption and decryption programs.

PGPMG addresses these issues to bring a total enterprise level solution. Also at the time of initiating this project, it was learnt that Fossmart (Pvt.) Ltd. an organisation aimed at research and development of open source services and solutions, were identified such a need and intended to develop one as an add-on service for their already existing security framework. Thus, recognising this as an opportunity to collaborate with Fossmart in building the solution, this research was initiated.

II. METHODOLOGY

A. Scope and Requirements

The responsibility of handling sensitive information of an organization or an individual is no minute task. Therefore as discussed previously the scope of the research was more focused on what happens to an email once it is out there on an unprotected network outside the safety of a firewall, which for ease will loosely be referred to as the internet, rather than trying to provide a hundred per cent impenetrable email service.

Keeping with the above scope, as well as the industrial issues that tag along with providing such a solution, the following basic functions were derived to which the PGPMG will provide an enterprise level solution.

1. Outgoing Mail Security
Send emails securely through the internet to the intended recipient and certify that the email was from the original sender. 2. Incoming Mail Authentication and Decryption
Receive emails securely and check whether the email was from the actual sender that it claims to be from as well as decipher any encrypted information. 3. Configure System
Allow an administrator to specify how the system should handle email security and do basic configurations. 4. Manage Security Information
Allow administrator or individual users to manage their security information such as keys and certificates and even publish them. 5. Analyse and Maintain the System
Allow administrator to view the status of the PGPMG and carry out maintenance operations on the system

From the above, the latter two are mainly for advanced users who wish to be more proactive and involved in how the security of their email is managed. For those who really want to reap the benefits of the PGPMG system, as an automated solution which will practically take care of security protocols by itself, only the system configuration needs to be done and only upon installation, unless security protocols change within the organisation later on. Simply said the goal was to cater to both these audiences when finding a solution to the said problem.

B. Security Model of the System

The expected functionalities of the system also bring up an age old question to mind, “Who will guard the guardians?” Instead of applying a fully insulated system which handles email security by itself, when providing with such flexibility of accessing and handling security information it poses another new set of threats to the problem already at hand. Therefore when approaching towards the solution being provided through the PGPMG the following security levels were also sought to be addressed as explained concisely in Figure 1: System Security Model below.

Figure 1: System Security Model

The security model above illustrates the vulnerability of each module or section of the application in order of vulnerability to external threats. The proposed solutions (within parenthesis) for each area have been concluded according to the findings during this project. These will be further elaborated during discussions on each module’s implementation.

C. Research Questions and Literature Survey

A very thorough literature survey was required in order to understand the implementation requirements of such a system. At times the feasibility of the solution was under question with the knowledge that other such products were failed in the industry [4], however the initial survey lead to final three questions, • Is it possible to develop the system using totally open source software? • Is it achievable to be developed in a modularized architecture? • Can Perl deliver better results than Ruby?

From the beginning the solution was posed challenging to be developed using Open Source technologies, but the literature survey revealed that much of the research had been done separately although there wasn’t a totally integrated solution apart from a few proprietary products [3].

The modularisation of the product was a must since the team had to work with different technologies and a pure Object Oriented approach was not possible in this case, as most open source languages and protocols only supported a structured approach. The analysis on the constructs and abilities of each language allowed separating independent tasks to be carried out by each language and the development of interface modules to support interoperability. The final module design which was implemented is shown below in Figure 2.

Figure 2: System Components

Since the development team was somewhat familiar with Perl and several readily available libraries which had to be customised for convenience were available, the decision on Perl or Ruby was fairly easy. However, its security and benefit for the solution had to later be revised in order to provide a hybrid solution incorporating both languages.

D. Module Implementation

Once the design phase was complete including the component structure and the database design each module was inspected carefully for its detailed functionality and protocol to be followed for better architecture as a program and overall to ensure that the security requirements are in fact met. 1) Server Environment

The environment setup was very important from the early stages since the final deployment of the product will be all inclusive Open SUSE 11.3 distribution with the PGPMG as an inbuilt application. The server environment contained three main parts

External Mail Recipient – The external email server or computer with email client application on the other side of the internet where incoming mails will originate and outgoing mails will finally be received

DNS Server – This is the server that routes emails from the internet to the internal Mail Transfer Agent (MTA) and vice versa using MX (Mail Exchange) entries in its configuration. This is also external to the server on which the application runs. Local Server – This is the server on which the PGPMG application is deployed, along with its own internal MTA and supporting services. It is assumed that this server will lie within the previously mentioned DMZ and is configured to minimize vulnerability to direct threats in the best way possible.

Since the research is based on the local server it is important to focus on each module and how each was implemented.

2) The Internal MTA

Its basic function is to route all external and internal emails to the PGPMG on one designated port and receive emails from the PGPMG and route it to an external or internal receiver. (Here external and internal refers to the perspective of the Local Server’s Network)

Figure 3: Mail Routing Setup

The PGPMG will listen on port 2525 (under default configurations) while the Internal MTA which is a Postfix server is configured to send all incoming mail on port 25 to the listening 2525. The MTA is also configured to forward all emails on port 1056 to port 25. PGPMG will push emails out of port 1056 once it is done dealing with the email. Hence, loop avoidance is maintained. Also referring back to the Security Model (Figure 1), there lies a risk of intrusion for the configurations which are kept under highly privileged user access (i.e. root only).

3) MTA Interface

This module was implemented as a ruby program which executes an SMTP service listening on port 2525 for mail from the Internal MTA. This also connects with the DB Interface to check the administration settings applied to the incoming email. Based on these configurations it will do one of the following:

1. Forward mail back to the MTA
2. Forward mail to the GPG Interface for encryption
3. Forward mail to the GPG Interface for decryption

If the configurations are set to “Encrypt All” outgoing mails (from Local Network) will follow option 2. If a keyword is specified it will be inspected in the subject content of the email and based on that will take option 1 or 2. If it is an incoming mail and requires decryption or authentication it will take option 3. If not to be decrypted all other mail will take option 1.

Concerning security, the MTA Interface cannot be accessed by anyone. The emails it handles will be dumped as secure files and are separated as “ones to encrypt” and “decrypt”. These will only be accessible to this application component and the GPG Interface. Once an email reaches this point no physical user or other application will have privileges for the files or its content.

4) GPG Interface

Purely implemented as a collection of Perl and Shell scripts and libraries this component will take what ever secure files dumped by the MTA Interface and will check for the sender or recipients email information (depending whether to encrypt or decrypt) in the local database via the DB Interface. If user information as well as security key information is found it will continue encryption/decryption. If this information is not found then it will look through a standard list of online public key servers and continue in the case of encryption. If still not found the interface will try to generate keys for that user and encrypt. All generated keys will be certified by the PGPMG using RSA (Rivest, Shamir and Adleman – Founders) certificates. This process is done for all email users which go via the system in order to reduce online searching time and increase performance.

However there is a downside to this, especially in the decryption phase. If an email fails to decrypt that means the server either has a fake email, a wrong key file or the user has externally revoked their key. In this case an email is sent to the recipient and the mail is sent to the Main module for handling. From the security aspect this module is one of the most risky areas of the system since it deals not only with data of a single email but also the security information of users. Therefore no component will be able to access this module and its configurations unless via the Main module.

5) Main Module

The main function of this module is to decide which users actually need Admin Portal accounts, which users need to be informed via email of errors in the encryption decryption process. All scheduled operations also run via this module and such operations have been configured using CRON jobs. It also interacts with the DB Interface to update user changes and run any diagnostic operations on the PGPMG.

6) DB (Database) Interface and Database

From the design phase the database was quite time consuming since the lack of knowledge on what information should or should not be stored or more to the fact that it was unknown what information was there for storing. Once a slight understanding was gained through the literature survey a least data redundant solution was proposed and implemented in MySQL. Following several amendments during developments to the main objective regarding the database was to thoroughly document each change and make sure that each developer adhered to the required security standards as this was the component with the highest risk along side the application itself (Figure 1).

The DB Interface implemented in Perl is the only module which interacts with the database apart from the Admin Portal. It is a form of encapsulating the database fields to the external modules for better security as well as program structure. Also this interface has its own library of the data fields that are highly risky and should be encrypted each time data is stored or retrieved. It follows Blowfish and CBC (Cipher Block Chaining) for encrypting data in the database. Therefore the security concerns highlighted in the Security Model have also been handled.

7) Admin Portal and Browser Security

This is the next open window to external threats other than the MTA Interface and therefore is highly vulnerable. However it properly manages user privileges (assigned by the Main module). The admin portal implemented in PHP (Personal Home Pages) will focus on admin functions, maintenance functions and monitoring activities for the system as well as for the individual users.

All transactions between the Admin Portal and the Database will also be encrypted using Blowfish and CBC (Cipher Block Chaining) while page to page post back information including sessions will be encrypted using SSL (Secure Socket Language). There for the Admin portal will only be accessible by using “https” in the browser. However, the Portal has only currently been self certified and many browsers will pop warnings of certification fraud, which maybe ignored for this release of the application. User login authentication is a must and when ever security information such as key file uploading or revoking occurs the user’s passphrase is also authenticated. Sensitive data has also been centralised to the database, which is least accessible from the outside. Also there is no registration to the Admin Portal and user accounts will be made according to the policy configurations made by the administrative user.

8) GPG Libraries

Perl libraries have been used along with the standard GPG release that comes along with Open SUSE 11.3. There is no major hazard in this area as it is a reference to the GPG protocol, but it is also kept under strict user privileges.

9) Deployment Manager

This module is basically the documentation and reference table of the services and repositories used to develop the system. If these dependencies are not properly managed the final deployment package will have issues when being implemented. With the hope of fully automating this process the dependency managed Open SUSE 11.3 operating system itself was compiled as a single application server deployable.

III. RESULTS AND DISCUSSIONS

A. Evidence

Firstly, setting up the mail server is one of the important sections of the project as it is the platform to develop the PGP Mail Gateway. The proper DNS system with two mail servers on two different networks with proper routing will give a proper testing environment to the system development.

Next, encrypting and decrypting a normal text file using GPG libraries and functions using command line arguments. This research was successful in encrypting and decrypting a file using GPG and managing the user’s public and private keys with Revocation certificate. This is the initial step of understanding GPG in Linux environment and the step by step process in creation of Public-Private Keys with Revocation certificates. This project uses Perl libraries and functions to achieve the task. Finally, creating the database and connecting with the GPG system, was done to develop the fully functional system.

Under the above mentioned envirment the system was tested with 100 test cases and the system proved to be accurate for 85%. There were few cases of failures due to network status and also decryptions of the mail headers. However under ideal setup the system worked at an acceptable level. Furter improvements are needed to be done to ensure 100% accuracy of the complete mail message.

B. Discussion

The overall picture of developing such a system had enlightened the project team on how difficult it is to develop the system and why there are fewer projects on this domain. This needs a lot of man hours and a sound knowledge on both PGP and Linux/Unix environment. The project team had to face this challenge within the given time line and considers the work carried out during that time line as an achievement.

IV. CONCLUSION AND FUTURE WORK

Email privacy has been a critical factor in the globe as it appears to be the most popular mode of communication and vulnerable too as it can be viewed by a third party and can even modify the original message. Several standards and methods have been developed but they are slow in being adopted. Also only few projects are there on this domain especially on open source environment.

PGP Mail Gateway will provide mail encryption and decryption facilities using the standards available in the industry. Other than that the focus of the research is to provide an architecture independent system that can suit any organizational requirement to protect the content of their emails.

This document has addressed the research area and the findings gathered in depth. The project team has taken up this project with all confidence to deliver the system meeting the customer requirements and expectations and has achieved up to the client expectations within the given short period of time. There’s a lot to be developed for it to be the best solution in open source world.

REFERENCES

1] M.Brinkers, “Why You Should Encrypt Your Email”, djigzo.com, para.3, Jan. 14, 2011. [online]. Available: http://www.djigzo.com/. [Accessed Feb. 22, 2011].

2] Network Associates, “How PGP Works”, pgpi.org, 1990-1999, [online]. Available: http://www.pgpi.org/doc/pgpintro/. [Accessed Feb. 19, 2011].

3] Admin, “PGP Universal Gateway Email”, Symantec.com, para.1, 1995-2011, [online]. Available: http://www.symantec.com/business/universal-gateway-email. [Accessed Feb. 25, 2011].

4] Admin, “Z1 SecureMail Gateway”, freshmeat.net, para.1, Feb. 03, 2011. [online]. Available: http://freshmeat.net/projects/z1securemailgateway/. [Accessed Feb. 22, 2011].

5] M.T.Rose and D.Storm, “Secure E-Mail: Problems, Standards, and Prospects”, The Internet Protocol Journal, vol. 2, no. 1, 19, March 1999. [online]. Available: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_2-1/secure_email.html. [Accessed Feb. 20, 2011].