GDPR and Emails - The Need and Drawbacks of Encrypting Emails

With the GDPR in full effect now, some companies still struggle with the processes to make their IT compliant to the new regulations. Since the GDPR covers many aspects of data security as well as reasons for data leakage there is almost not a single IT process not effected by the new European law. While most of the process to change are quite obvious, some are not.

Such a required change is the need to encrypt emails which contain personal information of clients and customers, employees or anyone else. Since article 25 of the GDPR requires data protection "by design and by default" for all business (IT) processes for products and services and the whole law is supposed to make personal data more secure and to prevent data leaks more unlikely, many lawyers argue that this new law requires all emails to be encrypted by default. Even though it is not clear now, if this is true or not, it makes sense to – if you did not do so already, to think about the consequences.

Remember: An email is like a postcard! When you send an email, some people like for example the enterprise IT administrator or the internet service provider can read its content if they want to. Therefore sending a normal email including personal or sensitive information without encryption is considered to be illegal under GDPR.

Email encryption is not as common as it should be. That is because of the fact, that implementation of this feature is not easy. There are currently two different methods available to choose from:

Transport encryption

Transport encryption means that the email(s) will be encrypted when they are send (transferred) from one server to another. The emails are send through an encrypted tunnel when using this method. The emails are encrypted when the depart from one server and decrypted when the arrive on the other server. All emails on the server are not encrypted when they are stored on the server. Sending encrypted emails over the internet you would use for example the POP3S email transfer protocol with the Transport Layer Security (TLS) network protocol (which is the new name for the Secure Sockets Layer (SSL) protocol used for quite some years now).

TLS combined with POP3S therefore creates an encryption tunnel – also known as site-to-site-encryption or end-to-end-encryption, which is a great solution when you connect two servers directly. However most companies do not have such close relations that they connect their email servers directly. Most likely there will be some other server on the way, where the emails will pass through. Therefore another solution is needed… such as…

Content encryption

When using content encryption the email will be encrypted and not the network transport tunnel where the email is transferred through. Today the most common standards for email content encryption is either the S/MIME (Secure/Multipurpose Internet Mail Extensions) standard or using Open PGP.

S/MIME can be for example implemented in your MS Exchange Server. S/MIME is based on asymmetric cryptography and uses a pair of of mathematically related keys to operate. Those are the public and private keys. An email is encrypted with the recipient (not the senders) public key, while the email is decrypted with your private key. Even though the technology of S/MIME is not easy to explain, I try to keep it simple here: When implementing S/MIME in an MS Exchange Server a certificate is produced which contains the signature of the user and also contains his public key. When he sends another user (user "B") this signature, he proves that he is the person he claims to be and gives his email recipient his public key and therefore gives him the right to send him encrypted emails. When user B then sends an encrypted email the next time to user A, the email client of user A „recognizes“ that the email is from a secure and known sender, searches for his private key inside the email client and decrypts the email on the fly.

The same procedure is true for OpenPGP. It is also based on public and private key exchange for encryption and decryption of emails. You generate a pair of keys – one that encrypts the email (the public key) and the other one that decrypts the encrypted email (the private key). You share your public key to all those persons you want to get encrypted emails from. Once you receive an encrypted email from a known source your email client will decrypt your email. That is how it works. However implementing an OpenPGP solution can be quite time-consuming and difficult. An example of how this can be done, can be found here…

Nowadays when enterprises use encryption for emails they implement S/MIME in their MS Exchange or other email exchange server while private individuals use OpenPGP based encryption solutions like for example GnuPG or other open source variants.

The dangers of email encryption

As we have seen using transport email encryption like TLS means that on both the sender as well as on the receiving email server (as well as the email clients) the messages as well as their attachments are stored non-encrypted. Therefore when an email server malfunctions like for example when an internal hard disk drive fails or when the whole systems stops due to user errors of the software, data recovery experts like those from Ontrack Data Recovery are able to reassemble the file systems as well as the emails without greater challenges.

However when content encryption – regardless if S/MIME, OpenPGP or a gateway solution – is used, there can be cases where recovery of encrypted emails is challenging.

In any case the so-called public and private keys must be available to the data recovery experts in order to begin or try to recover any emails. If these keys – or in case of the private key, which is actually a certificate – are not available, then there is not a slight chance to recover the original content inside the email.

Since for example the smallest symmetric key length (or key size) of OpenPGP is 128 Bit, it would take 1.44 billon years to crack that symmetric encryption key. And with 256 Bit keys most crypto experts state that it is impossible even for governmental security agencies and their supercomputers to decrypt that encryption key.

Therefore you should always keep and store your encryption keys, certificates or decryption passwords separate from the original email server or desktop computer so when a data loss occurs, then the data recovery experts can use them later on when they were able to recover the encrypted raw data.