Is encryption required?
You could easily be led to believe that the Danish Data Protection Agency makes a new non-negotiable requirement for encryption of emails if you read the press release, “Stricter practice in relation to encrypted emails”, issued by the authority on 23 July 2018.
That is, however, not the case.
The approach by GDPR and the Danish Data Protection Agency to safeguard personal data is risk-based.
It means that the higher the risk that personal data falls into the wrong hands and the larger the adverse effect it may cause, the better you will have to safeguard your data.
Encryption is a possible security measure, but it all depends on your infrastructure and the individual categories of data you must secure, as one of the technicians of the Danish Data Protection Agency told us.
Risk assessments are mandatory
However, the Danish Data Protection Agency has a deadline for compliance with GDPR in the field of emails:
As per January 1, 2019, businesses must have secured personal data, which is distributed both internally and externally through emails.
But how do you become compliant when security depends on infrastructure? How can your specific business avoid potential fines from the Danish Data Protection Agency?
In this respect, the Danish Data Protection Agency could have worded their requirements a bit clearer.
However, the agency’s information material and statements to the press outline a procedure:
The first thing you have to do is to make a risk assessment. This is mandatory—everybody who distributes personal data through email must make one.
How to make a risk assessment
A risk assessment consists of:
- A mapping of all the risks that the processing (of personal data, editors) entails and a categorization (scoring, likelihood, and severity) thereof
- An assessment of what constitutes adequate technical and organizational measures to ensure that the regulation is complied with
Some businesses also have to make an impact assessment. Both assessments will shed light on how the infrastructure of the business is designed, which personal data that the business sends, and how these data should be protected.
Encryption applies to confidential and sensitive personal data
Personal data is not just personal data. They come in three different categories that should be safeguarded at different levels.
When the Danish Data Protection Agency speaks about encryption, this typically applies to the so-called confidential and sensitive personal data.
Encryption during transmission could mean forced TLS
Encryption is also a broad term. The Danish Data Protection Agency talks about encryption during transmission (or submission), which is different from encryption at rest or what is also called end-to-end encryption.
TRUSTZONE delivers end-to-end encryption through our PersonalSign certificates.
If we are going to express it in technical terms, the most widespread type of encryption during transmission is what is called Forced TLS (Transport Layered Security).
These days, most mail servers support TLS. That applies to e.g. Gmail, Outlook and Hotmail.
If both parties support the technology, TLS will encrypt your email on its way from the sender to the recipient. That is, during the transmission.
That takes place in the same way as a connection is encrypted between a browser and an https-secured website server.
TLS creates a kind of tunnel between the sender and the recipient. A third party cannot, e.g. through malware – capture, read and involve in the communication.
The contents, i.e. emails sent forth and back through the tunnel, are not encrypted, but the communications channel through which the contents passes, is. That way, third parties are prevented from looking through the walls of the tunnel and gaining access to the contents.
However, it is a problem that the standard TLS setting on chiefly all mail servers is only “opportunistic TLS”.
This means that the sender’s server prefers TLS during transmission (but makes no requirement to that effect).
If the recipient’s mail server does not support TLS, the email will nonetheless be sent to the recipient’s server, which in this case is typically an unencrypted POP3 or SMTP server.
Thus, the communication can be captured, manipulated or otherwise compromised relatively easy.
The same applies on the way in the transmission. In some scenarios, a hacker can arrange that TLS server stations are missing en route, and if there are no alternatives, the sender’s mail server will use an unencrypted server as an intermediary station. Here, the communication can again be captured and compromised.
However, the problem can be avoided by using the setting “Forced TLS”. With this setting, the mail server requires that the recipient’s server and stations in transit all use TLS.
If there are servers en route that do not support TLS, the sender gets a message that the email cannot be sent to the said address.
This setting, this type of encryption will “normally (… ) be a suitable security measure – to both public and private players (… ) in the transmission of confidential and sensitivepersonal data by email through the internet.”
This is the way we must interpret the message from the Danish Data Protection Agency.
According to an article in Version2, the Danish Data Protection Agency further recommends that as a minimum it is the second-most recent TLS 1.2 with the AES standard that the businesses should use for encryption during transmission.
Forced TLS poses problems
There are reasons why Forced TLS is not simply set as a new default setting on marked leading mail servers supporting TLS (Gmail, Outlook, Apple mail etc.).
According to German IT security expert Hanno Böck, there are several major issues at play:
“One obvious problem is that the setting prohibits mail servers from talking to other servers not supporting TLS.
Actually, a German mail host began offering such an option but explicitly warns that it might stop emails from being delivered. Notably, the second-largest political party in Germany opposed STARTTLS.”
But, Böck continues, there’s a more elusive problem: “The certificate issue. [note: Böck refers to the fact that many mail servers don’t have valid certificates and that generally speaking, mail servers, don’t consistently check certificate validity –Ed.].
“Even if certificates were successfully validated, there would still be other issues”, Böck concludes. He suggests this blog article as background reading.