Posted on by nura

Does user-encryption reduce GDPR requirements?

For a service provider handling private records, it is important whether it will be considered a controller/processor in GDPR terms or not. In the context of this post, a service provider includes any service that handles private records, such as cloud storage, identity management servers, medical services and social sharing mechanisms. With private records we mean pieces of sensitive data belonging to a data subject (which we call the ‘user’ for reasons of readability), such as a national ID number, a social security number, and even data for a MedTech or FinTech application.

GDPR Article 4 – (1) states that ‘personal data’ means any information relating to an identified or identifiable natural person, the ‘data subject’. Encrypting private records can significantly reduce the applicability of GDPR, because it renders the personal data unreadable for downstream analysis by the processor or by third parties and data thieves (see *1). Of course, this assumes that the encryption algorithm is well designed, that encryption is properly carried out and that key management is done adequately (see *2).

This post deals with ‘user encryption’ whereby the service provider has no access to the decryption key and has no access to the clear text version. If the service provider would have access to decryption key or to the clear text version, the data must clearly be considered personal data and the full weight of the GDPR regime applies.

Are user-encrypted private records personal data?

Encryption is making something unreadable for anybody without knowing its decryption key. Encryption is moving the problem of secrecy of the original private record to secrecy of its key. By moving the secrecy problem back to the user, the user-encrypted private records can freely be stored, processed and exchanged by anybody. They could even be published in a newspaper so to speak.

Some believe, however, that encryption is conceptually similar to pseudonymisation. Encrypted data would thus also be considered personal data under the GDPR, always. Encryption, however, is neither pseudonymisation nor anonymisation. Encrypted data is a series of bits that have no meaning on their own, while GDPR Recital (29) states that pseudonymisation is intended to allow general analysis. Encryption does not allow general analysis since the data is rendered non-analysable (see *3).

Some believe that when data can be traced back to an individual in any way, it is by definition personal data according to GDPR Article 4 – (1). In their opinion, the fact that the key is managed by another party would not alter this for a service provider: encryption would solely be an extra safeguard. The Breyer judgement (see [3]) may strengthen their opinion. Encryption, however, is not simply a mitigating measure for the service provider. Encryption can also be regarded as a measure of the user to shield personal data from their service provider (and for that matter for anybody else). In this logic, the service provider is not receiving personal data from the user but rather a stream of meaningless bits.

So even though encrypted private records remain personal data in general, the service provider does not need to consider it as personal data. Under GDPR terms, they can consider the data as non-personal because they cannot access the clear text, and even if their servers were breached, users would face little privacy risk since the data would also be unintelligible to the wrongdoers.

The GDPR itself recognises this concept, although in a slightly different context. GDPR Article 34 – 3(a), frees data controllers from having to notify affected individuals about a personal data breach if the controller has implemented […] encryption. It therefore also makes sense that a service provider can assume not to process personal data when handling user-encrypted data records. The mere fact that a service provider handles personal data does not automatically mean that they are also a processor.

Moreover, the service provider is simply a third party when handling user-encrypted private records. GDPR Article 4 – (10) states that ‘third party’ means a […] body other than the user, controller or processor […] that is authorised to process personal data. It is like the electricity supplier, who does not need to assume that its electricity is used to process personal data.

Are you always a third party when handling user-encrypted data?

GDPR is only applicable if the service provider has or can access the clear text version of the private records. In other words, when they can decrypt the user-encrypted data or at least have reasonable chances of obtaining the decrypting key [1]. So if the service provider can sufficiently prove that they cannot obtain the key in any reasonable way, they may consider the data as non-personal in GDPR terms. Note that it is only needed to take realistic chances of decryption into account, and not highly theoretical identification risks [2].

When a service provider wants to actually make use of the data, e.g. for reasons of analysis or for display to the user, they will need the decryption key. As soon as the data is decrypted, the service provider must consider the data as personal.

To keep considering the data as non-personal, the service provider must demonstrate that they actually do not have a decryption key and that they cannot claim it from the user. In cases they needed the key temporarily for maintenance or support, they need to consider it as personal data under GDPR regime. Also in case the service provider is providing the encryption service themselves, they will have the encryption key temporarily and thus possibly the decryption key as well.

Since the encrypted private records still concern personal data, what about other provisions of the GDPR, such as breach notification and protection against theft, loss or tampering? For these cases, the user may still want to conclude a solid services agreement with the service provider.

What to do in case of a data breach?

GDPR Article 34 – 3(a), frees data controllers from having to notify affected individuals about a personal data breach if the controller has implemented encryption. However, this exception typically applies only when the key remains secure. The exception may thus not apply when the decryption key is breached along with the encrypted data.

Unfortunately, many widespread data security practices do not manage decryption keys sufficiently enough to justify an assumption that stolen encrypted data cannot be fully exposed. If whoever is handling the incident response does not thoroughly investigate the encryption system and key management practices that had been implemented, there is no way to properly ascertain whether an encryption exception is being correctly applied or misused to avoid reporting an actual breach.

How many service providers know how to properly analyse the risk of compromise for stolen encrypted data? Does the service agreement include recommendations to (a) abandon and delete all copies of decryption keys for the data that had been stolen, and (b) compare the data sets stolen during different incidents, to ascertain whether encrypted data and the decryption key were each stolen at different times?

Why are these important? Consider a scenario of multiple intrusion and data theft incidents. In a first incident, only encrypted data was stolen. The key remained secure, and the encryption exception was properly relied upon. However, a copy of the decryption key for the stolen data was retained by the owner for a “just in case” situation. Sometimes people are reluctant to entirely delete certain things; it’s human nature.

But then, there was a second incident, handled by different response team. The second response team correctly ascertained that no personally identifiable information was stolen and so concluded that there was no breach.

Can you spot both of the problems? After the first incident, the data should have been encrypted with a different key and all copies of the earlier decryption key for the stolen data should have been destroyed as soon as possible. That would have precluded a risk of that key being stolen. Also, if that decryption key had been stolen during the second incident, then the combination of both incidents did actually result in a breach. But it went undetected and unreported, because the second team had not been directed to identify any possible relationship among the different incidents.

Conclusions

User-encryption of private records can lead to the non-applicability of the GDPR and might thus be an important privacy preserving technology for service providers. There is, however, still legal uncertainty regarding the applicability of the GDPR for encrypted data. For example, service providers have to determine whether a decryption might be reasonably likely, also taking into account the use of future decryption technologies and the security of the key management. Additionally, other provisions of the GDPR not related to confidentiality need to be taken into account. Taking privacy protection seriously is a risk management function. It is not a simple on/off question: to be compliant or not.

References

[1] Cf. Spindler, Verhandlungen des 69. Deutschen Juristentages, Band I, Gutachten, 2012, pp. 115 et seq.

[2] Cf. Esayas, European Journal of Law and Technology, Vol 6, No 2 (2015), p. 6; Commission Decision 2000/520/EC of 26 July 2000, Official Journal of the European Communities L 215/7 (24)

[3] https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2020/guidelines-072020-concepts-controller-and-processor_en

For a more comprehensive legal discussion, following sources may be helpful:

Notes

*1 What was GDPR again? The goal of the regulation is to protect citizens against carelessness of service providers. The ultimate goal is to protect their fundamental rights of citizens, including the right to privacy, non-discrimination, human dignity and freedom of thought, conscience and religion. GDPR compliance is not a binary question for the service provider. It is rather a risk management question balancing cost with the risk of reputational and financial loss.

*2 Encryption should be at least 256 bit (see NSA recomm) for symmetrical algorithms (whereby decryption uses the same key as encryption). Access to the key should be protected by an Hardware Secure Module, or Vault. Access to the vault should be best in class and require a password, PIN, face-ID or fingerprint to open it. Key generation can be based on a high entropy password (e.g. 15 characters of all type) or a random generator sufficiently resilient against prediction.

*3 is encryption a form of pseudonymisation? GDPR Article 4 – (5) defines ‘pseudonymisation’ as the processing of personal data in such a manner that the personal data can no longer be attributed to a specific user without the use of additional information. This would also apply to encryption.Recital 26 states that to determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. The binary bits of encrypted data alone does not yield any information of the person, nor is the person identifiable in any way. Moreover, Recital (29) assumes that pseudonymisation still allows general analysis; encryption obviously does not allow further analysis.

Leave a comment