Email encryption

[imported_Irse]

I need something that will encrypt emails and attachment. The receiver will need to unencrypt the email and attachment. New HIPAA requirements. Anything out there> Heard of Lockbin and Endinc. Are ther better alternatives? Hopefully free.

 

[Wolfpup]

I'd think you'd want to use something that implements Open-PGP. I think there's even a plug-in that supposedly does that for Gmail? And I've heard Apple's email program integrates Open PGP well, but I've never used email encryption.

 

[MrColin]

I like to use encrypted pdfs when I do tax work for people as it doesn't require special software/config for less sophisticated users on the receiving end. Getting every recipient to use OpenPGP and secure key distribution is a huge PITA.

With encrypted pdfs you just need to have a pre-shared password. I'm not sure if Adobe's latest Acrobat has gone to the cloudy SAS model, if so you might need to check if it complies with HIPPA. AFAIK zip files can be encrypted too.

Also, I believe the HIPPA crowd still likes to pretend that ssl is secure (its not). It's not too hard to create a ssl encrypted content server with all free software.

 

[secmail]

I need something that will encrypt emails and attachment. The receiver will need to unencrypt the email and attachment. New HIPAA requirements. Anything out there> Heard of Lockbin and Endinc. Are ther better alternatives? Hopefully free.

I created a new service you can access by http://www.internetsecmail.com It's for free right now and if the people will like it I will start charging a small yearly fees to cover the site maintenance. The idea is to encrypt the messages/attachments using the personal Encryption Password of the Sender and decrypt them using Personal Encryption Password of the Receiver. The passwords are set using SSL web interface and stored in an ecrypted form. Instead of using email addresses the Subscriber just defines his "member name" and this "member name" can be associated with muliple email addresses which are not shown to other members. The emails (as well as attachments) are sent by InternetSecMail server as encrypted PDF files. The Sender also receives the copy of the email he sent and can save it in his "native" mailbox. As soon as messsage been sent, the message and attachments are removed from server. I think this method of communication is safe and allows high level of confidentiality and content protection. Using this service you can safely send your medical results, fincance statements, your ideas you want to share only with limited number of people and other information you define as "confidential".

 

[smakme7757]

Also, I believe the HIPPA crowd still likes to pretend that ssl is secure (its not). It's not too hard to create a ssl encrypted content server with all free software.

I'm not sure I understand what you mean here?

If you mean that SSL is not secure because it can be implemented with open source code then you are sorely mistaken.

 

[Fallen Kell]

Getting every recipient to use OpenPGP and secure key distribution is a huge PITA.

OpenPGP doesn't use secure key distribution. It uses public key distribution. There is no need to transmit a secret/secure key. You simply need both parties to have created their own key pairs and send each other their public keys which can be done over the open internet (just be sure to create 4096 bit RSA keys (or larger)). Do NOT use DSA keys as the SHA1 hash has been compromised due to a weakness.

 

[Fallen Kell]

The passwords are set using SSL web interface and stored in an ecrypted form.

The problem here is that the private keys are outside the control of the users. Even if they are stored in encrypted form on your site, they are in a location that can be hacked/accessed by unknown parties entities. This means that anyone who has access to private keys could then decrypt the emails.

The only way your service could be secure is if the users simply upload their public keys to it, and then your client downloads the public keys of the recipients and encrypts the message. I still would not really trust it to be honest, as this has all the hallmarks of a system to seem to be secure but just a scam to collect personal/confidential information. It also doesn't help that this is your first post in these forums advertising a service that has a thin veil of security when it is wide open to inside attack.

 

[lxskllr]

The problem here is that the private keys are outside the control of the users. Even if they are stored in encrypted form on your site, they are in a location that can be hacked/accessed by unknown parties entities. This means that anyone who has access to private keys could then decrypt the emails.

The only way your service could be secure is if the users simply upload their public keys to it, and then your client downloads the public keys of the recipients and encrypts the message. I still would not really trust it to be honest, as this has all the hallmarks of a system to seem to be secure but just a scam to collect personal/confidential information. It also doesn't help that this is your first post in these forums advertising a service that has a thin veil of security when it is wide open to inside attack.

Agreed. I also question the use of SSL. The encryption can be broken using forged keys. As you said, any encryption that isn't done on the client machine can't be trusted. Even if the intention is 100% pure, flaws can compromise the encryption, and it won't be generally known without review.

 

[smakme7757]

I would just rather use PGP than that service. If the other person isn't willing to setup PGP or S/MIME then the information isn't that important and you can just send encrypted PDF files (Using AES, not the simple PDF locking mechanism).

If the information is that important and the other party isn't willing to put the time in to secure the communications then they should loose their job to be frank lol.

 

[secmail]

There is no "public" or "private" keys there. The technology is different. The user assigns the password to himself (like you use in online banking or PayPal) ans use this password for opening the encrypted PDF file. The password itself is stored in Server, but in encrypted form and without the possibility to break it from outside. The private key to read the password is used only by application and it stored in safe place out of web server access path. You can try it.

 

[secmail]

The PGP is not supported by any client and the "free" PDF encryption is not easy as well for averege user.
The mehod I developed is "universal", client independent and easy to use.

 

[secmail]

First of all I don't collect any personal information except the name, email and origin (which can be extracted also from incoming IP address). And both (email and name) are totally hidden from other users. That's right that I'm trying to "advertise" this service, but for advertising I have other ways and in this forum I just trying to collect professional opinions...
You can try and register yourself. My member name is secmail. I don't see any way to break in or to use "false identity" to read the message, but may be I'm wrong...
Any way, I appreciate your comments.

 

[Savatar]

First of all I don't collect any personal information except the name, email and origin (which can be extracted also from incoming IP address). And both (email and name) are totally hidden from other users. That's right that I'm trying to "advertise" this service, but for advertising I have other ways and in this forum I just trying to collect professional opinions...
You can try and register yourself. My member name is secmail. I don't see any way to break in or to use "false identity" to read the message, but may be I'm wrong...
Any way, I appreciate your comments.

Never use PDF attachments if you can avoid it... they are not secure since malicious information inside PDF files can be used to execute code. Many users use Adobe Acrobat viewer, which is known to have had several vulnerabilities throughout the years, and is still among the top three methods that malware spreads via third-party plugins/programs.

My email provider won't even let me receive PDF files for this reason... and, I suspect, many other email providers will remove those attachments automatically as well. That is one of the primary things that would deter me from using this service.

The Registeration Confirmation Code has been sent
to you by email as encrypted PDF file.
Please open this file using your Personal Encryption
Password, enter into this field

 

[secmail]

Thank you for comment!
That's correct but:
1. I tried to find some "universal" platform intdependent method without use of private/public keys.
The intention was to provide to the user ability to open encrypted message from any client
(Microsoft/Linux desktop or any mobile device having email client) and this "universal" tool is
acrobet reader.
2. The PDF email is created on the Server Side and does not contain any malware.
3. Several commercial vendors support similar solution (http://www.rpost.com/esecurity/pdf-conversion, https://www.privasphere.com/hp/index.php?id=202 ,http://www.djigzo.com/gateway.html and may be others).
4. I tried several email servers and no one of them prevented me from sending encrypted PDF file. Even if some server has such rule you can direct it to allow encrypted PDF files traffic from certain address.
5. One of the goals was to allow user not to disclose his actual address.

I just had no other solution to implement such "ulta secure" service....

Thanks again for comments

 

[Savatar]

Yeah, I understand the constraints. I have also been thinking about creating some secure messaging application ever since LavaBit went under. Unfortunately, after thinking about it, there doesn't seem like very much I could do. Most security-conscious users who demand 'ultra security' would understand how to get that security (using PGP over P2P methods to deliver the messages to avoid the metadata trail).

If you wanted more security 'in general' but still have it 'easy to use', you're naturally going to run into some problems.

Using something like the system you built as-is has at least two main problems as I see it:
1. First, and most importantly, using PDF loses the context of a 'message chain', since replying doesn't let you easily quote the previous text - and you can't see what the user said 3 messages ago. That's quite a loss of convenience for only a relatively minor gain in security. The average user today won't accept that loss in functionality, I would suspect.
2. Second, it requires users to have PDF readers installed. The average user is just going to install Acrobat Reader, which will likely only open them up to more vulnerabilities considering the state of it right now. I would strongly encourage users to stay away from Acrobat Reader, especially disable browser plug-ins for it, and view PDFs only when absolutely necessary.

So-called 'secure messaging portals' that I've seen require users to create an account to read their message and doesn't use email at all except to notify that you need to log on to see a new message (perhaps saying the account name that it's from). Naturally, this primarily relies on SSL and the user's browser. SSL itself isn't too bad to build a more secure messaging platform like this (vs general purpose email), but yes it has its fair share of vulnerabilities now and people have even been coerced into handing over SSL keys in extreme situations... so maybe it can't be considered 'ultra-secure' anymore either, unfortunately. I've looked into providing encryption with JavaScript alone ( something like jcryption here: http://www.jcryption.org/ ) and while it does help for form submission in general - it cannot be relied upon for a variety of reasons ( some are described here: http://www.matasano.com/articles/javascript-cryptography/ ). However, of course, this still has the 'single server' / middleman problem, where the server operators could get information about all the user's communications if they really wanted to or were coerced into doing so. The main thing you'd have to do to secure it more would be to make it decentralized.

The only easy thing I can think of to get around that is using something that is an offline application that handles the encryption parts - and then send the raw encrypted text so they can import it into the application... to be secure it would _require_ the user to maintain keys that the server knows nothing about. And then deliver the communication through different/decentralized channels. But, alas, that sounds really similar to PGP today...

So what is a good compromise for the average user? If you are designing this for them, to give them something a little more secure, I would think it needs to be as easy to use as possible... and people text a lot (I mean a LOT) on their silly phones... even though that is even less secure than email. So this would require mobile capabilities to address that for the average person as well. If you can deliver something akin to a secure messaging portal that works on phones and laptop alike, that's also decentralized an easy to use... I think something like that is what is needed to deliver what is needed in that space. But that's a tall order? Maybe something like XMPP could play a role.

It sounds do-able to me, and it would be an improvement over the current state of things, it's just a lot of work. Any thoughts on an approach like this?

 

[secmail]

Good point!
It's easy to implement the reply feature, but the whole point was not to keep the user messages inside the server. I can add it as a "feature" for user choice...
To be frank, I don't understand your preconception against PDF documents. Do you have any statistics about the harms caused by malicious PDF?
Look on https://www.bankfirstwestern.com/personal/online-estatements.asp and http://www.citibank.co.jp/en/banking/services/e-statement
Both banks send the encrypted PDF files to the customers (who wants to subscribe for this service). My company (which is "crazy" on security issues) does not prevent sending and receiving encrypted PDF files and I personally never harned not by PDF reader and not by PDF files...
But any way, thanks!
Your notes are very interesting and I will think about in this direction.
I'm sorry that you can't subscribe to my service. We could communicate "securely"....
By the way, the Foxit Reader is a more secured alternative for Acrobat Reader...

 

[Savatar]

Good point!
...
To be frank, I don't understand your preconception against PDF documents. Do you have any statistics about the harms caused by malicious PDF?
...
By the way, the Foxit Reader is a more secured alternative for Acrobat Reader...

Thanks, I have used FoxIt Reader when I need to view PDFs before, though I do still disable any web browser plugins.

Here are a couple references that show the most common attack vectors for Windows PC infection in 2012 and 2013:
http://www.av-test.org/en/news/news-single-view/artikel/adobe-java-make-windows-insecure/
http://www.securelist.com/en/analys...lletin_2012_The_overall_statistics_for_2012#4

Adobe PDF files came in #1 in 2013 as the most common method for compromising Windows systems, in a study carried out by AV Test. It came in #2 in a study carried out by Symantec in 2012.

By not installing or using these applications, or using alternatives with more secure settings and limiting their use to only where absolutely necessary, a user can go a long way towards protecting their systems. By requiring users to view a PDF file, the odds are that the average user will gravitate towards the most common solution (Acrobat Reader), and won't know how to disable the browser plug-in and disable javascript for it -- thereby potentially opening up their system to dangerous attacks.

 

[secmail]

Thanks.
It looks scary!
My development platform is linux/unix and I was not aware of all this nightmare around the Windows and PDF...
Actually I can change the format of the messages to 256 bit AES encrypted text files and provide my own open source safe "reader"...
Thanks again

 

[secmail]

Now I have full implementation of encrypted Text Files with ability to create "message chain" by subsequent replys..