Let's assume your organization maintains a customer database containing personal information such as contact details, purchase history, invoices, and other customer records.

• If this data belongs to your own customers and you determine how and why it is processed, your organization acts as a data controller under the GDPR.
• If, on the other hand, you process customer data on behalf of another organization, you act as a data processor.
• The individuals whose personal data is being processed are referred to as data subjects.

Whether you act as a data controller or a data processor, you are responsible for protecting customer data to ensure compliance with the GDPR, as it typically contains personal information.

To protect personal data, the GDPR highlights a range of technical measures, including encryption. However, not all encryption methods provide the same level of security. In this blog post, we compare different approaches to storing and sharing encrypted business data, from on-premises solutions to various cloud-based services.

Which storage and encryption approach offers the highest level of security for personal data against the most common attack scenarios?

The three approaches to storing encrypted personal data

There are three main approaches to protect your customers’ stored and shared data with encryption.

1. Local, on-premises storage with encryption

The GDPR’s aim is to protect people from the exposure of their personal data. According to the GDPR, personal data is defined as any information related to an identified or identifiable natural person. In the previous post, we showed that the definition of personal data depends on the context and eventually requires to check who can access the data and whether he or she can associate the data with any individual.

In the above scenarios, this means that the encrypted data is considered personal if any plausible attacker has reasonable chance of identifying the data subjects whose information is encrypted. In general, plausibility depends on the attacker's motivation (e.g., its incentives and disincentives to re-identify a data subject), while the probability of success depends on the technical difficulty of the attack (e.g., how easy it is to obtain the decrypted dataset). Motivation and success probability are not entirely independent. The easier an attack is, the more motivated an adversary can be, however, we are not concerned with this dependence now.

To answer our main questions, let’s perform a high-level risk-analysis and discuss the plausibility and success probability of some attacks aiming to re-identify any individual whose data is encrypted in the approaches described above. This will provide a clearer understanding of the advantages and disadvantages of each storage and encryption solution.

Approach 1: Local, on-premises storage of encrypted data

This solution is quite straightforward and secure only if your server, which might store the decryption key, or the terminal, which might be used to provide the passphrase to reconstruct the key, are well-protected.

However, setting up a high level of protection is much harder than you would think. Firewalls, anti-virus, or other standard security products are usually not enough. Sophisticated targeted attacks can circumvent even mainstream security products and use spear phishing and social engineering to install some malware onto your system.

For example, this can happen when one of your employees opens an innocuous attachment or click on a link in an e-mail which is forged by the attacker. When malware gets installed on any machine in your local network, they may exploit zero-day vulnerabilities of some software components of your system to get access to confidential files which might store the decryption key of your dataset. Alternatively, malware may log your keystrokes when you type the passphrase to decrypt your dataset. Even companies that invest heavily in data security are subject to such threats. So, why would it be hard (or implausible) in your case?

Approach 2: Cloud storage with server-side and in-transit encryption

Now, let’s see what happens if you upload your (unencrypted) customer data to a cloud provider who encrypts your dataset and stores it along with the encryption and decryption key in a secure place. Whenever you need your data, the provider decrypts them and sends the decrypted data back to you on a secure channel. How easy is it to re-identify persons if the datasets get leaked? Can your encrypted customer data be regarded as personal in this case?

Again, it depends on how easily the attacker, whoever it is, can get access to the decrypted customer data. For an external attacker (i.e., hacker), getting access to the provider’s server which stores the encrypted data might be technically more difficult than in the previous approach when you stored the encrypted data by yourself. This is simply because cloud providers are usually much more prepared for such attacks than you. Still, the likelihood of this attack is not negligible even in this case.

The real difference is the attacker’s motivation; if it knows that the provider stores the decryption key (or the unencrypted data) of many users like you, the attacker might be much more motivated to target the provider.

Finally, potential (internal) attackers include the cloud provider itself as well as its employees who can easily get your decryption key. Although the provider does not have much incentive to snoop into your customer dataset due to the potential legal repercussions and reputation loss, a disappointed or financially motivated employee is somewhat more likely to do it.

Approach 3: Cloud storage with client-side, end-to-end encryption

This solution combines the advantages of the previous approaches; only you know the decryption key, but the data is safely stored by the provider. Now, I’ll suppose the worst-case, namely, the attacker somehow obtained a copy of the encrypted customer data. As shown above, in Approach 1, this step itself is not straightforward at all but certainly feasible as many infamous cases have exemplified in the recent past.

Now, can the attacker associate the encrypted data with one of your customers? In theory, no. The encrypted data can only be linked to a customer if the data gets successfully decrypted. In an ideal world, this is only possible if the attacker guesses your decryption key. If the key size is 256 bits and your key is totally random, the probability that the attacker guesses your key is about 1:2²⁵⁶. Just to illustrate how small it is, the number of all atoms in our galaxy is much less than 2²⁵⁶. 

So, we can certainly say that no attacker has reasonable chance to guess your key, which would mean that your encrypted customer data is considered as some uninterpretable totally random “garbage” data to anybody who does not have the key (including the attacker). Therefore, as long as the data cannot be decrypted, its breach is harmless to the data subjects.

However, the world is never ideal. First, your decryption key is generated from your passphrase or password. If your passphrase is easy to guess, the attacker can decrypt your encrypted customer data. If the attacker has reasonable chance to guess your passphrase, for example by installing a malware on your device which logs your keystrokes like in Approach 1, the encrypted data can be regarded as personal; if it gets leaked, data subjects can be re-identified. This also means that you have to be careful and take several precautions to minimize at least the risks of brute-force attacks, such as having strong passwords, uniquely generated for each service you use.

Second, the encryption algorithm used by you or your provider may be vulnerable to some attacks. This applies to all the three approaches, though. For example, the attacker may exploit some design flaws in the encryption scheme. Although such an attack is not totally unrealistic, it is quite unlikely nowadays especially if your provider applies standardized encryption schemes (like Tresorit).

A second and more plausible way of breaking the encryption scheme is by exploiting implementation flaws in some software components used by the encryption scheme. These flaws (or any other backdoors) can be intentionally placed inside the code, for example, due to governmental solicitation. Still, this is unlikely if the provider uses open source implementations, or is transparent about their operations and how they manage government requests.

However, exploiting unintentional implementation flaws (e.g., a typical buffer overflow) is much more plausible. Indeed, implementation flaws are unavoidable as long as humans develop software. The best that you and your provider can do is to use standardized algorithms and be transparent as much as possible, as well as regularly update software components.

Conclusion: Cloud storage with end-to-end encryption is winning

In the following table, you can see a concise summary of the discussion above regarding the plausibility and probability of success of the two attackers considered in our analysis: the cloud provider (or its employees) and a hacker. The table estimates both the plausibility and the success probability of the most powerful attack available to each attacker. We assess these factors using a four-level scale: low, moderate, significant, and high.

What is the best solution, then? As you can see, cloud storage combined with client-side, end-to-end encryption is the approach in which encrypted customer data is least likely to be considered personal data and used to re-identify data subjects. This is primarily because the provider has no reasonable means of accessing the decryption keys (and therefore the decrypted customer data). As a result, attackers are generally less motivated to target the provider than in scenarios where the cloud provider stores the decryption keys.

About the author

Gergely Acs is an Assistant Professor at the Budapest University of Technology and Economics (BME), Hungary, and member of the Laboratory of Cryptography and System Security (CrySyS). Before joining CrySyS Lab, Gergely was a research scholar and engineer at INRIA, France. His research focuses on different aspects of data privacy and security including privacy-preserving machine learning, data anonymization, and data protection impact assessment (DPIA). He received his M.S. and Ph.D. degrees from BUTE.