The MyMail Secure Email Solution (cont'd)

Chapter 4: Architectural Implementations

Implementation

The preferred embodiment for implementing MyMail’s SES requires at least three groups of servers (where a group of servers consists of at least one or more computers), where each group of servers is dedicated to performing a single independent function.

The three independent functions are:

1. Email Database Host
2. Application Host
3. Paired Key Store

The server group performing the “Email Database Host” function requires at least one private network connection and no public Internet connections. The server group performing the “Application Host” function requires at least one public Internet connection and one private network connection. And the server group performing the “Paired Key Store” function requires at least one private network connection and no public Internet connections.

Alternatively a MyMail’s SES system or service can be configured using two groups of servers configured for the “Combined Application Database Host” function, and the “Paired Key Store” function. This implementation, although secure, is not as secure as the preferred embodiment implementation described above since the actual email message storage is on a server that is directly connected to the public Internet.

Figure 5: MyMail SES Architectural Implementation

Paired Key Store (PKS)

The PKS is housed on secure servers physically separated from the Email Database Host (EDH), Application Host (AH) and/or the Combined Application Database Host. The PKS stores each subscriber’s encryption key pairs in an encrypted MySQL database table. The PKS references the subscriber’s Public Encryption Key (PEK) and Private Decryption Key (PDK) pair using a 32-bit hash of the subscriber’s full email address. There are several functions of the PKS described below. The PKS is a Representational State Transfer “REST” web service with a command link interface. Access to the PKS is restricted to the source IP addresses of the Application Hosts with a valid 32-bit User ID and password pair. A call is made to retrieve a user’s PEK when new mail arrives and is encrypted from the SSL stream before storage. At login a call is made to retrieve a subscriber’s PDK when the user accesses their mail via Webmail or POP3.

Account Provisioning

Account Provisioning involves three processes:

1. Creating an unique email address (User ID) with secure storage for the new subscriber;
2. Generating a Public Encryption Key and Private Decryption Key pair;
3. Creating a subscriber file for the qmail Message Transfer Agent.

Each subscriber’s User ID is generated by taking the user’s name and desired or assigned domain name and running it through an ID inspection calculation to insure that the User ID is unique for the desired or assigned domain name prior to creation. For example if the User ID john.smith@MyMail .net already existed the subscriber would be given the option of selecting a known unique address such as: johnsmith@MyMail.net, john.smith01@MyMail.net or johnsmith123@MyMail.net, or of entering his own alternative address.

Generating each subscriber’s Public Encryption Key and Private Decryption Key pair involves the following steps:

1. Passing the subscriber’s User ID and Password to the Paired Key Store;
2. Taking said User ID and Password, and processing them through a hardware random number generated algorithm to create the Public Encryption Key;
3. Initiating a Key Signing Request from the Paired Key Store to the Key Signing Authority;
4. The Key Signing Authority signs the Key Signing Request using the Key Signing Authority’s Signing Key and Certificate, which results in the creation of the subscriber’s Private Decryption Key;
5. The Key Signing Authority returns the subscriber’s Private Decryption Key to the Paired Key Store, where it is encrypted using the User’s password.

Once the subscriber’s Public Encryption Key and Encrypted Private Decryption Key pair is created it is secured with a Dynamic Row Secret created by a hardware random number generated algorithm on the Paired Key Store. The Dynamic Row Secret is used to encrypt each subscriber’s Public Encryption Key and Encrypted Private Decryption Key pair, and is itself encrypted using the Paired Key Store’s Public Encryption Key.

After the subscriber’s Public Encryption Key, Encrypted Private Decryption Key and Encrypted Dynamic Row Secret have been created they are stored in a MySQL database on the Paired Key Store.

The last process of provisioning a subscriber’s account creates a file for the MyMail SES’s proprietary secure-qmail Message Transfer Agent.

Webmail Account Login Process (ALP)

1. Subscriber enters Email address and password at the login screen.
2. Application Host (AH) tests to see if domain is active
3. AH tests to see if account is active
4. AH tests to see if account has an active plan
5. Subscriber’s password is tested against the stored MD5 hash of their password
6. Subscriber’s session is initiated upon successful login
7. A $userid is calculated from the Subscriber’s login Email address
8. The Subscriber’s Private Decryption Key (PDK) is requested from the Paired Key Store (PKS) through a private SSL connection using the $userid and password.
   • PKS retrieves the Subscriber’s Public Encryption Key and Encrypted Private Decryption Key pair (“Key data”) and Subscriber’s Encrypted Dynamic Row Secret (eDRS) using the $userid
   • The Subscriber’s eDRS is decrypted using the PKS’ PDK
   • The Key data is decrypted using the DRS
   • The PDK is decrypted using the Subscriber’s password
   • The subscriber’s PDK is returned in PEM format
9. The subscriber’s PDK is stored in the session data.
10. Subscriber is redirect to the Inbox view

Mail Retrieval Process (MRP)

• Message retrieval request is executed on the AH
• The message data and DRS are retrieved from the mail database
• The encrypted DRS is base64 decoded
• The encrypted DRS is decrypted using the PDK
• The encrypted message data is base64 decoded
• The encrypted message data is decrypted using the DRS
• Inflate the message data using gzip compression
• The complete message data is now available to the requesting process

Mail Storage Process (MSP)

• New mail message arrives at AH
• $userid is calculated from the receipt’s Email address
• PEK is requested from the PKS using the $userid
  • PKS retrieves the Key data and Key data’s DRS using the $userid
  • The Key data’s DRS is decrypted using the PKS’ PDK
  • The Key data is decrypted using the DRS
  • The subscriber’s PEK is returned in PEM format
• Generate new DRS for the message
• Deflate the message data using gzip compression eliminate text patterns
• Encrypt the data of the message using the DRS
• Base64 encode the encrypted data
• Encrypt the DRS using the PEK
• Base64 encode the encrypted DRS
• Store message data and DRS in the mail database