The Danish Data Protection Agency’s New Requirements for Secure Email Communication

The Danish Data Protection Agency’s New Requirements for Secure Email Communication

Gain insight into how to stay GDPR compliant when you send emails that contain personal information—and how you take it a step further and incorporate general IT security in your email setup.

---

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:

1. A mapping of all the risks that the processing (of personal data, editors) entails and a categorization (scoring, likelihood, and severity) thereof
2. 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.

Forced TLS is not always secure enough

But how certain are you then that you’re complying with GDPR in this area?

Well, if it turns out that a hacker would somehow gain access to your email account, then encryption during transmission would not prevent the hacker from reading, changing, or cheating persons by sending emails in your name.

In such cases, Forced TLS will neither curb breaches of the confidentiality, integrity, or authenticity of data.

The hacker could gain access by guessing or finding out your password or the recipient’s password. In semi-open and easily accessible office environments, hackers would fairly easily be able to steal personal data while the responsible employees were absent.

Have a look at e.g. the small offices along the corridors of Denmark’s hospitals. Here, security should perhaps be increased to protect the patient files which contain very sensitive data.

It is with such contemplations at the back of the mind that IT experts and specialists apparently think that the Danish Data Protection Agency sets the bar low by its focus on encryption during transmission. Forced TLS creates a good basis, the point is, but it rarely becomes an adequate solution in itself.

Encrypted external email communication

You can use the S/MIME technology of the PersonalSign certificates to encrypt the contents of your emails and not only the communications channel (the tunnel) between the sender and the recipient.

But we cannot use PersonalSign to encrypt the contents of emails that are sent to private individuals:

Encryption and decryption (of contents, mind you) require that both the sender and recipient have an S/MIME certificate installed on their devices. We cannot expect that from the general private individual or our B2B contacts for that matter.

In the external communication, a PersonalSign certificate can nevertheless contribute by a digital email signature. The recipient can easily see that without a certificate on its device.

With a digital signature, you confirm your identity as a sender of the email, and you confirm that the contents of the email have not been changed during the transmission.

If the contents had been changed, the recipient will not be able to see the signature.

With S/MIME, you confirm the authenticity and the integrity of data to external parties. The certificate contributes to an extra security layer in relation to Forced TLS. In addition to man-in-the-middle attacks (MITM), it protects against phishing and spear phishing in external communication.

Summary

As for external communication, a PersonalSign certificate will provide the following additional value in addition to Forced TLS:

• A digital signature, i.e. safeguarding of the integrity of data and the authentication of the sender 
• Protection against phishing, spear phishing, MITM attacks, malware, and more

Internal emails: Protecting confidential and sensitive personal data

Often, there is a tendency to email personal data internally than externally out of the organization. Here, PersonalSign can contribute to the possibility of true end-to-end encryption:

When you encrypt an email via PersonalSign, others can not read it unless they have access to the recipient’s email account and, in addition, to the recipient’s private encryption key.

PersonalSign thus delivers the most secure type of email encryption that exists.

A digital signature will also prevent internal phishing and spear-phishing such as CEO fraud.

In short, PersonalSign can add the following increased value in relation to securing data in the in-house communication:

• A digital signature, i.e. safeguarding of the integrity of data and the authentication of the sender
• End-to-end encryption—the confidentiality of data including protection against malware, MITM attacks, phishing, and spear phishing