GDPR and email encryption: The perfect partners?

With the GDPR having been in full effect for a couple of weeks, some companies are still struggling 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 unaffected by the new European law. While most of the process to change are quite obvious, some are not.

Does GDPR require email encryption?

Yes, one of the required changes is the need to encrypt emails which contain personal information of clients, 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 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 think about the consequences (if you hadn’t already).

Remember: an email is like a postcard! When you send an email, some people, 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 the GDPR.

Types of email encryption

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 sent (transferred) from one server to another. The emails are sent through an encrypted tunnel when using this method. The emails are encrypted when they depart from one server and decrypted when they arrive on the other server. Emails are not encrypted when they are stored on a server.

When sending encrypted emails over the internet you can use POP3S email transfer 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 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 would connect their email servers directly, and it is highly likely the emails would have to pass through another seperate server.

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 Open PGP.

S/MIME can be e implemented in your MS Exchange Server. S/MIME is based on asymmetric cryptography and uses a pair of mathematically related keys to operate - public and private. An email is encrypted with the recipient’s (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, we have tried to explain it simply 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, giving him the right to send encrypted emails. When user B then sends an encrypted email the next time to user A, the email client of user A recognises 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 in the way that 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 with 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. 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 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 and receiving email servers (as well as the email clients) the messages, as well as their attachments, are stored non-encrypted. Therefore, when email server malfunctions for example, when an internal hard disk drive fails or when the whole systems stop due to user errors of the software, data recovery experts like Ontrack are able to reassemble the file systems and emails without too many issues.

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 no chance of recovering the original content inside the email.

For example, the smallest symmetric key length (or key size) of OpenPGP is 128 Bit; it would take 1.44 billion years to crack that symmetric encryption key. With 256 Bit keys, most crypto experts state that it is impossible to even for governmental security agencies and their supercomputers to decrypt such an 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. Then when a data loss does occur, data recovery experts can use them later on when the encrypted raw data has been retrieved.