Link to home
Create AccountLog in
Avatar of moorooboorai
moorooboorai

asked on

Is there a way to store e-mail encrypted on a mailserver?

Hi,

In the process of setting up a proper mailserver solution, I am betting on qmail and dovecot for IMAP. A requirement has been set to do the utmost to keep mail traffic secure and encrypted. E-mail sending and receiving will be done using TLS/SSL. However, there doesn't seem to be any wrapper, patch or plug-in that will allow for encrypted storage of the e-mail that will be kept on the server.

The main idea behind this requirement originates from a 'trust no-one' stance taken towards e-mail management. So 'simply' encrypting the filesystems doesn't meet the requirement: any administrator with root access can read e-mails. Ideally the mail would be encrypted with a (very) strong user password so indeed only the user logging in would be able to decrypt/read his own mail messages.

Have any of you came accross the same requirements? Have you been able to meet this requirement? If so then how?

Anxious to learn your answers.
Avatar of yo_bee
yo_bee
Flag of United States of America image

Do you have a local or hosted e-mail server?
Avatar of moorooboorai
moorooboorai

ASKER

I am setting up the mail-server, so it's local to me.
ASKER CERTIFIED SOLUTION
Avatar of yo_bee
yo_bee
Flag of United States of America image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Thanks for the reply.
I'll have to look into the PGP Universal Server to see whether it makes a fit.

A rough sketch of how I think this should work out:

User A establishes a SSL session between his client and the mail-server.
User A sends an e-mail destined for user B.
User B has an account on the mail-server.
User B's mail has to be encrypted (no doubt by some qmail sidestep) with user B's strong password.

User B establishes a SSL session between his client and the mail-server.
User B authenticates.
The mailserver (dovecot in this case) decrypts the message and sends it to the client.
User B retrieves the message over the SSL session into his local mail-client.

So in this case the integrity (security) of the e-mail, once on user B's machine, is up to user B's security enforcement.

In this case there is no need for any client, whether sending or receiving, to have any additional plug-ins.
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
@Arnold:
Thanks for the heads up, but I am clear on the differences between TLS/SSL and PGP.

I don't want to burden any users with setting up PGP on their mail clients. I just want to ensure that a users' mail, once on the server, will be encrypted there. To be decrypted by his password only. In that case, when the server gets hacked and the messages exposed, the hacker still won't be able to explore the contents because they are unencrypted. (Or for that matter, substitute the hacker for anyone with root privileges). I am not looking for encryption of the message by the user himself. That's still up to him (or her) to do so.
You can not since there has to be a way for the users to exchange public keys.
If all the users are internal, and the only way they access the messages is via a web interface, you could approach what you want. i.e. configure the interface to always set the encrypt mode the problem deals with the handling of the message when there are several recipients.

The other option is the notification to a recipient just such saying you have a message and they have to use a web interface into which they login to view the message.

 
Yesterday I dawned on me that Google isn't always a man's best friend. Meaning: I had turned to Experts Exchange because Google'ing on this subject had run dry. However, when I yesterday queried the lists on the Dovecot site it actually turned out someone else had the same question. See this link and the answer by Dovecot's main author: http://dovecot.markmail.org/search/?q=dovecot+encrypt#query:dovecot%20encrypt+page:1+mid:khhe646k675x3yfd+state:results

It states there is no solution, but one could be contrived a la the zlib plugin. So there seems to be some hope. Thought it would be wise to share this information with you, as it may be triggering some alternate thoughts and answers on my question.
I clicked the link, but all I see is a Chart.
That's odd. when I click it it properly shows up (in Safari).
Anyway, if you surf to dovecot.markmail.org and then query for "dovecot encrypt" you should get there.
Scroll through the entries and stop at the one titled "[Dovecot] Plugin to encrypt mailboxes ?".
Its a IE 8 thing.
I look forward to reading this.
Here is the issue.  Which part of the message do you want to encrypt?
I.e. do you only want the stored message encrypted? i.e. your_usera sends an email to remote_userb.
Presumably the transport from your_usera to your server is secured via TLS/SSL.
The message itself is in clear plain text without regard to formatting i.e. HTML.
From your server to the destination the transport could be secure, but is more likely not.

Now remote_userb replies.
The message is now on your server in the your_usera's mailbox.

Now you want the mbox style encrypted or the message within encrypted.

The issue deals with when the user accesses the mail server to read their email, you would have an added step in the POP/IMAP account that will feed the encrypted data to an external process that will decrypt the message prior to passing it to the user.
A similar process will need to be used when the message is received and prior to it being stored such that you only encrypt the contents and the header sender/recipient/subject/date.

Are you thinking of having a system generated encryption key for each user stored someplace on the local server etc.


The question I still have is to what end?  

Providing a user A Identity S/MIME X509 type certficate or limit the user's access to their email to a web interface where you can handle/setup the gpg, x509 type of certificates, but the user must still handle the exchange/import of public certificates from recipients to which they would want to encrypt the email message.

@Arnold:
Your reply has some elements in common with the sketch I made of how things should work.
The message will be sent using an TLS/SSL encrypted session.
Indeed, "within" that session, the message would still be plain text.
But, as soon as the message gets processed by the mailserver - dropped by the MTA to Dovecot, that is - it should get encrypted with the receiving user's strong password. So the step would be to encourage and enforce mailbox users to pick strong passwords. The step would not be to even require them to also setup a PGP enabled mail-client.

Maybe think of it like this: I have to account for the responsibility any webhoster would have regarding the guaranteed privacy of it's clients email stored on it's servers. (Whether clients supersede that policy by - much applauded - PGP-alike additions to their mail-traffic, is entirely up to them.) Having email encrypted gives me the ability to ensure to any external auditor/accountant that message integrity has been preserved and no prying eyes have been able to read what's no theirs to read.
The problem is that during the receipt/processing of the email your MTA/MDA has no access to nor information about the user's password.

Lets try it this way. You are perhaps familiar with the Document Courier. Provided the Courier Firm checks backgrounds etc of the people they employ, the actual set of documents are still vulnerable to those employees. i.e. one of them suddenly decides to peer through them. If the sender provides an armored case to be carries, this is the only the sender can ensure that the only part that will access the data are the designated recipient.

You seem to be going on the premise of the courier provides a pair of keys to their user.
The courier takes the open secured case to the sender, gets the documents places them into the secured case and locks the case.  Now only the recipient using the key can open and access the documents. Note that to open the case you still needs the recipient's key.

Presumably your user can change passwords.  Presumably than you would need to keep track of the passwords or whenever the user changes their password, you would have to decrypt all the messages using the old password and reencrypt them all using the new one.
Or you would have to maintain all the prior user's passwords somewhere such that when the user tries to access a message, your process will .... to decrypt each one.

Email is not a secure mode of communication which is why PGP, S/MIME, etc. were introduced.

The alternative is you create virtualserver that would listen on differnet IPs and deliver to segmented data location such that etc.  The system's administrators will still be able to peek.

Alternatively, you could look into using a database backend as the storage of the data.


@Arnold:
Thanks for your elaborate answers and persistence on this topic.

The courier analogy fits like this: the courier would be carrying a case that's property of the receiver. Furthermore it has a drop-in only entry. (Like banks have for retail shops: an external vault where you can only drop cash-money, irreversible.) The key to the case is only carried by the receiver, hence the ownership.

As far as changing passwords, that would apparently indeed require re-encryption of pending messages. (Decrypt using old password, re-encrypt using new password.) But then other solutions could be thought up. Including ones where passwords would be kept historically. Although this is only top off my hat. But feasible at least. But this is diverting the essence of my question, so I think we should not elaborate further on this.

Personally, I like the suggestion of using a database as a storage back-end. At least it would allow me to set up a more sophisticated segregation/separation of duties. Meaning, the DBA's would have to conspire with the system administrator to gain access to the database contents. Meaning, again, the database contents would be encrypted using a key read-only from OS parts, accessible by system administrators only.

So I guess this then would elaborate on my original question like: is there a way to store e-mail encrypted in a database backed back-end? Preferably any solutions would use any NoSQL database that supports storing 'document', like Riak from Basho, for instance.

Do you have any suggestions?
I'd leave the prior analogy with a minor item, either the courier has to maintain an inventory of such cases on hand, or has to go to the recipient to pickup the case and then to the sender for them to deposit the items, and then back to the recipient. What if the sender is in the farthest location from the recipient. The sender will call the recipient who would then ship them the Case, once the sender receives the case, places the documents and then ships it back.

I am unaware of such implementation.

using either, you are back to the same mechanism. i.e. the MTA to MDA to dovecot to a filer process that would use a key from a database for use by this user, encrypt the contents and save the file to disk.
When the user accesses the data via POP/IMAP or web interface, the service must first call on a decrypt process that would be passed the password the user provided to login to decrypt the message and then feed it back.  If the use is IMAP, it might be possible to get the message headers only without the need to decrypt each message unless the person wants to see the contents.

The complexity that you are getting involved in is without bounds.  Every item you think you resolve, twenty more popup that you did not consider.
Okay. Thanks so far.

Although the mentioned boundless complexity act as a proper red flag for me, I'm still not convinced this would be an unfeasable issue. The mentioned zlib plug-in for Dovecot should apparently be injected in the MTA/MDA/Dovecot pipeline similarly. Upon receipt a message needs compression, upon retrieval decompression. In this case compression/decompression would be substituted for encryption/decryption. Indeed a (symmetric) encryption key would have to be retrieved. One additional step in comparison with the zlib implementation.
If you go with PGP and have the e-mails process through Client -> PGP -> Mail Server -> Net  each user will get a certicate for encrypting and will encyrpt to that key for that user.  At that time the e-mail will be securily wrapped while in the server and the recipient will need a pubic key to decrypt.
With this method you can also add an additional key or ADK (Additional Decryption Key) to the server.  This key can only be generated by a standalone client like PGP Desktop. Once this key is imported the key is attached to every e-mail that meets encryption policies (i.e. Private, Confidential, certain domian...etc..).
For you to decrypt these items you will been PGP Desktop with the ADK import to allow you to decrypt with that key.
Yo_bee, you have the process reversed.  The recipient's private key is needed to decrypt, the recipient's public key is needed to encrypt the message for the recipient.

Going back to the courier example, you are effectively the cryptographer. You get the message you encrypt it based on the recipient. The recipient accesses their data, you decrypt it.

The problem with the add-on intermediery there is no place where this process could get direct feedback from the end user.
User -> email client ->NET ->POP server The exchange is user/password yes, here is the message. No, wrong username/password.  Similarly for IMAP.
This means that the decrypt stage as long as it is started, i.e. the login credentials were accepted, will have to identify as which user it is running, retrieve the private key and decrypt the message.
You would need to effectively replace the POP/IMAP of the mail server for your encrypt/decrypt to receive the users username/password combination.
If you PGP style key, you will have a database/table with public keys for encryption, a database/table with private keys for decryption and a database/table for the passphrase.

You could look at the encrypting Harddrives which will offer protection if the drive is removed from the system.

From what I can see is that you are adding overhead in a geometric scale.i.e. the more active the mail server, the more users you have the quicker the system will run out of resources.
If you are making pop3 available to the user, the messages existence on your system are fleeting. I.e. a user's email client checks for new email every 10,15,20 minutes.
Yes. You are right.  That was a mistake on my behalf.
The impact on resources is well understood and anticipated for. Security comes at a price (and impact).
The systems are already running on encrypted filesystems, so consequences of physical theft has been countered by that measure. But it still leaves the plain-text storage of mail messages. But these are all diverting from my original question and requirements.

So I guess the answer to my question would be there is no readily available solution to store e-mail encrypted, given the requirements I set. Do you agree?
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.