Why encrypting emails isn’t as simple as it sounds

The quality of protected communications matters – a lot. If the sent material is highly sensitive and the legislation and/or policy demands high security, opportunistic encryption might not be enough. For organizations, deciding what email encryption solution to use is often not so simple and, generally speaking, there is no single correct answer.

Here we will discuss the different options and if a combination of encryption methods might be the answer.

Why organizations need encryption

Encrypting an email message ensures that unauthorized parties cannot read it. For any party without proper authorization, the message will appear indecipherable.

For organizations, message confidentiality is crucial to stop potentially sensitive information from reaching prying eyes. Also, they should be able to confirm the integrity of the message and the sender’s identity – without this, spoofed messages can be sent.

The basis of confidential communication over email is that both sender and recipient have secured their respective local systems, by hardening the host OS, employing client security, EDR, XDR and so forth.

Different options have different benefits and challenges

Best-effort opportunistic encryption methods such as Outlook Message Encryption (OME) and various third-party solutions (email encryption gateways, plugins and similar) have the benefit of being easy to use. They can also be transparently integrated into email programs (such as Outlook Message Encryption), and make it easy to contact new people, with no need for prior key exchange – if the message is sent to a user who doesn’t run the same system, a portal for opening the message is typically placed in view.

Additionally, they can often be integrated into the outgoing email server with rules to enforce encryption automatically, depending on set rules such as automated encryption for certain attachments, for example.

There is, however, the possibility of an unauthorized party decrypting the message if they gain access to it first. This poses a real threat as the email communication itself is not guaranteed to be encrypted due to the email delivery process being reliant on STARTTLS and similar opportunistic encryption schemes. This can be mitigated by adding 2FA, such as via SMS PIN code which can help improve security (of course, the recipient’s cell phone number must be known when sending). And in many situations, it is important to also identify the sender’s identity reliably: After all, if anyone can send messages, how can you differentiate a genuine sender from an imposter?

Full encryption methods such as S/MIME and PGP/GPG enable complete confidentiality where only the recipient can decrypt the email message due to the possibility of verifying the sender’s identity. However, several issues arise when using this method. There is a need for key management where keys need to be distributed, swapped, and kept up to date. There is also limited support as the recipient often needs to use the same solution as the sender.

Only a certain subset of contacts typically use this solution, leading to the need to use multiple solutions depending on the recipient(s). This also requires extra effort to determine which solution can be used for the specific recipient and if the solution is secure enough for the material being sent. This can lead to a complicated user interface with different, confusing options like “sign only” or “sign and encrypt”. It becomes quite easy to end up choosing the wrong option, or worse, forgetting to use the encryption at all (since it usually must be selected specifically).

Recently Google started offering option to use S/MIME with Gmail as “E2EE” or “client-side encryption”. This option is currently in beta testing and only available for limited audiences. This however is a significant development as it might result in wider adoption of S/MIME encryption, especially if made available for free Gmail tiers.

The threat model decides

What is the best solution? S/MIME or PGP/GPG may seem like attractive solutions, but challenges in key management and difficulty in training people to use them could lead to poor adoption. Some less secure solutions could be used for most communication, while the more secure solutions, such as S/MIME or GPG/PGP, could be used for other recipients.

The users that need to use the more secure solutions must be instructed on identifying when the more secure method is needed and how to use the solution properly (such as key management and practice sending and receiving encrypted email). Ultimately the demands of the specific organization and use cases determine the solutions that might be needed.