Why implementing end-to-end email encryption for NIS2 is a bad idea for your organization

NIS2 requires your organization to implement secure communications. Existing solutions like S/MIME and OpenPGP are not a fitting solution because, whilst they solve the secure communications requirement, they fall short in protecting your clients from security issues that may arise within your organization like viruses, malware and sharing restricted information.

“End-to-end encrypted email makes you compliant with NIS2? Unfortunately no!”

Surely implementing end-to-end encrypted email is for the best interest of your customers and makes you compliant with NIS2? Unfortunately no it isn’t and for that claim to stick we need to delve a little bit into the inner workings of end-to-end encrypted email solutions.

What is End-to-End Encryption?

First off let’s define the concept of end-to-end security, an often misrepresented term bandied about by suppliers. in a true end-to-end encryption scheme, the data is encrypted on the sender’s system or device, and only the intended recipient can decrypt it. There are two standardized methods for end-to-end encrypted email, it’s either S/MIME or OpenPGP. Both standards have been around for many decades and are widely implemented.

Challenges of S/MIME and OpenPGP

In both approaches the sender has a public key belonging to the recipient and uses this to encrypt the contents. The recipient has a private key and uses this to decrypt the contents. Only the recipient has this private key, it is the only party in the conversation that’s able to decrypt the email contents. Suppliers that use a web portal approach for secure email who claim they’re delivering end-to-end email encryption don’t comply with the abovementioned widely accepted definition of end-to-end encryption. Their solution might be secure (enough) but its certainly not end-to-end encryption.

So, what’s not to like about a mature and widely implemented standard for end-to-end email security? Actually, there are many challenges with S/MIME and OpenPGP, like the fact you have to have a public key of any recipient you want to communicate securely with. Which means that any recipient you’re communicating with must have enrolled for a private key and a certificate on their device. And the recipient must have provided their public key to you in advance of the actual communication. And this same recipient must replace their key set every year, because there’s an expiration date for these keys. Oh, and this same recipient must store all the previously issued keys in a safe place because if they lose them they can’t read the emails anymore that were encrypted with their old public key. Did I also mention that the recipient in question is a normal person, not an IT expert?

You can see the issue piling up, can’t you? Interestingly, this is not the pivotal argument why these solutions aren’t a good fit with your organization. That’s actually due to the core behavior of classic end-to-end encrypted solutions. What happens when you’re sending an end-to-end encrypted email? You must have the public key of the recipient as we already established earlier. Let’s assume you have that and you’re starting your email. As you finish the email you’re going to encrypt the email with the public key of the recipient. This works flawlessly as both S/MIME and OpenPGP have been around the block and the process is smooth. You now have an email message that’s fully encrypted with the recipient’s public key and you’re sending it out to the recipient. The recipient gets the email, decrypts it with the corresponding private key and the message is available in the clear.

Everybody is happy, right?

Wrong, you’re forgetting your troubled looking Security Officer who, though excited about the usage of end-to-end encrypted email, now finds out that the end-to-end encrypted email is bypassing all boundary protection mechanisms like your anti-virus / malware gateway and your data leakage prevention software. Which means you’re (still) not complying with NIS2.

“The solution you thought would protect your customers comes back and bites you in the behind”.

With a classic end-to-end encrypted email solution, you basically are creating messages that can’t be controlled, inspected or blocked by your border gateways. Because the content is fully encrypted there’s no way a control process can inspect the contents of the message. Any virus, malware or any communication with contents contrary to organizational security policy will fly right through your protection mechanisms, undetected, undeterred. This is where your NIS2 obligation fails, you are not protecting your clients, your customers against any internal security issue you may experience, they just propagate to your recipient without any way to stop it. The solution you thought would protect your customers comes back and bites you in the behind. Talk about a double-edged sword!

There are solutions available where you do the end-to-end encryption on your gateway, after you’ve done your anti-virus / malware and data leakage prevention scanning. That’s definitely possible but then it’s not end-to-end encryption anymore. And you still have all the other issues with key management as mentioned earlier. Bit of a catch-22, isn’t it? Damned if you do, damned if you don’t.

How to comply with NIS2 without blocking other mechanisms?

So how to resolve the issue, you want to comply with NIS2 and use e-mail encryption, but you also want to enforce control mechanisms on (malicious) email content which are also required by NIS2. A hybrid solution is your best bet, one that delivers email encrypted to your customers and also allows you to enforce anti-virus / malware and data leakage prevention measures. With such an approach you would need to transport the email from your IT environment to the secure email solution via an encrypted connection, rather than applying the encryption at the client level. By encrypting the connection to the secure email solution, you still have the ability to do content inspection either by inspecting the content before it hits your border gateway or by terminating the transport encryption at the border gateway and initiating a new encrypted connection to the secure email solution. Once the email arrives at the secure email solution it will apply message level encryption and deliver it to the recipient with an appropriate mechanism to decrypt the contents in the recipient’s client.

That sounds perfect but is this really a feasible solution?

The abovementioned approach forms the basis of SecuCypher, a hybrid secure email solution from SecuMailer that uses a combination of encrypted connections and message level encryption to deliver the best of both worlds.

“The recipient now has access to the decrypted contents of the email with a minimum of effort, all encryption/decryption processes take place automatically without any knowledge or expertise required from either sender or recipient.”

Our SaaS platform receives email from your organization over an encrypted TLS connection which allows you to apply any security control like anti-virus, malware or data leakage prevention to your outgoing email. Once we receive the email on our platform, we generate a strong (symmetric) key based on a master key you manage. The contents of your email, including any attachments, is encrypted with this derived key. Your encrypted email gets inserted into an attachment that contains your email content in a web page and all the encryption/decryption logic needed to show the embedded email to your intended recipient. The recipient receives the email, opens the attachment in the browser and gets asked for a means of authentication. As part of the 2FA authentication flow the browser generates a public/private key pair, sends the public key off to the SecuCypher SaaS platform, together with the authentication token, and if the authentication checks out the platform retrieves the key that was used to encrypt your message. This key gets encrypted with the unique public key you received from the browser and is sent back to the recipient’s browser. In the recipient’s browser the encrypted key gets decrypted by the private key that is available in memory of the browser. The recipient now has access to the decrypted contents of the email with a minimum of effort, all encryption/decryption processes take place automatically without any knowledge or expertise required from either sender or recipient. An option is available to download the original message in an unencrypted form which you can open in your mail client so you can provide a reply to the email the way you’re used to. A bonus feature is that you as a sender can retract the message key and thereby block access to the encrypted email if you sent it to the wrong recipient, thereby avoiding a data leak.

“Outside of these scenarios it is unlikely that the specific circumstances where you use an end-to-end encrypted email solution outweigh your fiduciary responsibilities.”

Finally, is there no use for end-to-end email encryption?

Of course, there are scenarios where this approach is a fitting solution. However they’re all either in the personal domain when you want to mail securely with friends or peers (who must be quite tech savvy) or when you work in a field where the value of end-to-end encryption outweighs the fiduciary obligations you have, for instance journalists communicating with sources or activists. Outside of these scenarios it is unlikely that the specific circumstances where you use an end-to-end encrypted email solution outweigh your fiduciary responsibilities.

The ultimate solution: safe and user-friendly

In summary the NIS2 directive requires you as an organization to implement secure communications. A classic end-to-end encrypted email solution like S/MIME or OpenPGP doesn’t allow you to apply anti-virus / malware or data leakage prevention which makes these solutions non-compliant with NIS2. If you want to comply with NIS2 and have good user experience for your clients, you should use a hybrid solution like SecuCypher.