What type of encrypted email is right for your enterprise?
Encrypted email describes email messages which have been encoded to prevent unauthorized access to their contents. Given the frequent number of targeted attacks and impersonations through email, forward-thinking enterprises have embraced encrypted email to prevent the leaking of their company’s IP.
However, there are many ways to send encrypted email messages over the internet. Not all these methods are equally secure. Many methods actually leave emails vulnerable to attack. This vulnerability is a result of the message being unencrypted at points along the message’s journey to the recipient.
In order to describe email as true ‘encrypted email’, only the sender and intended recipients should have the ability to read the message. The message should not be readable by the email provider or any intermediate party.
We will look at the relative strengths and weaknesses of each email encryption type to understand their strengths and weaknesses.
How does email encryption work?
The main methods for email encryption are:
- encrypting the email in transport (point-to-point encryption)
- encrypting at rest (on the client or server)
- encrypting through end-to-end encryption.
These methods work by encrypting data at various points on its path from the client to the server as well as to points afterwards. Without encryption, messages will stay in clear text throughout their journey.
What email encryption types are there?
Encrypting email messages during transmission
Some platforms use TLS (Transport Layer Security) to secure messages in transit. This standard ensures that the message is secure as it travels from an individual’s computer to the server. If the recipient’s email platform also uses TLS then the message will be encrypted between the sender’s email server and the recipient’s email server.
Challenges of TLS
TLS protects the message from potential “man-in-the-middle” attacks that might try to access the message while it is in transit. If the email platform only uses TLS to secure messages then messages are not secured on the sender’s computer, the server nor the recipient’s computer.
TLS is the default standard which providers such as Google and Microsoft use to enable encrypted email in Gmail and Outlook. For both networks however, both the sender and recipient must use TLS in order to create a secure connection. A such, if the recipient does not use TLS then messages will be delivered over non-secure connections.
Encryption at rest
To augment encryption in transit, some platforms might provide encryption at rest. Encrypted email that is secured at rest means the messages are secured on the storage medium. For most companies, this means the email is encrypted when not in use on the endpoints or on the server.
There are many commercially available options for encrypting data on the user’s hard drive. Most cloud providers such as Microsoft and Google will encrypt data at rest on their servers. The advantage of providing encryption-at-rest is that it can prevent an attacker from accessing information on a computer or from disks stolen from a data center.
The challenge of encryption at rest however for the server is that the storage providers frequently maintain the keys to the data in a centralized location. This means that the server can “see” the decrypted information. If the server can access the raw data, so can an attacker.
Encrypting email messages end-to-end with PGP and s/MIME
With end-to-end encryption, email messages are encrypted on the sender’s device with the recipient’s public key. Messages are decrypted on the recipient’s device by using their private key. No server or provider in between can ever decrypt the email and read it.
If one used end-to-end encryption, Gmail and Microsoft OMS would be unable to read an encrypted message because these providers would not have the recipient’s private key.
PGP and s/MIME are two traditional standards used to send secure end-to-end. Both protocols use a recipient’s public key to encrypt a message and use their private key to decrypt their message. The main difference between the two methods however is how public keys are distributed. s/MIME relies on a certificate authority (CA) to distribute keys where as PGP relies on a Web of Trust to distribute keys.
Problems with encrypting email messages end-to-end with PGP and s/MIME
While end-to-end encryption is the most secure method for securing email messages, PGP and s/MIME make the standard difficult for the enterprise to use. PGP in particular makes management of public keys extremely challenging for the end users. s/MIME makes management of certificates a challenging task for users.
Additionally, these two protocols also have security vulnerabilities that were discovered in the EFail attacks in mid-2018. In the EFail attacks, an attacker was able to inject code into the message that was then executed by the recipient when the email is read.
This attack was possible because the OpenPGP and S/MIME standards don’t require the recipient’s email to check that messages have not been tampered. Some implementations of OpenPGP implement Modification Detection Code (MDC) logic which blocks the exploits discussed. MDC code can detect the attacker’s modifications and prevents the email from decrypting and executing code.
With PGP, each individual must exchange their public key with everyone they wish to communicate with securely. There is no central repository for public keys. Additionally, if the user loses their device then they have to go through the process of exchanging their public key with all their correspondences all over again. Moreover, any email that was secured with their original keys cannot be decrypted. The loss of the user’s device means their private key is also lost.
Similarly, solutions that use s/MIME for encryption are also extremely challenging to use in the enterprise. While there is a central certificate authority that provides the public key, users are still unable to recreate private keys if they lose their devices. If a user loses their computer, s/MIME cannot recreate the information secured under the original public key.
End-to-end encryption redefined
While the standard of end-to-end encryption does provide strong encryption for email and files, its use in PGP and s/MIME is problematic. A much better and easier way to use end-to-end encryption is to enable centralized public key and certificate management by the server. This would eliminate the complications that PGP and s/MIME provide.
A strong implementation of end-to-end encryption would also ensure that if user devices were lost or stolen, devices could be re-keyed to enable users to regain access to their information. This addition would ensure that end-to-end encryption is actually useable for everyday business.
Conclusion
While email encryption might seem like a daunting task, an easy to use end-to-end encrypted email solution does exist. Encrypted email does not have to be something your organization tries to solve on its own. Instead, choose a provider that offers the gold standard for email encryption while eliminating friction for the user and enterprise.
The post What type of encrypted email is right for your enterprise? appeared first on PreVeil.
*** This is a Security Bloggers Network syndicated blog from PreVeil authored by Orlee Berlove. Read the original post at: https://www.preveil.com/blog/encrypted-email/
