Deleting Data for GDPR: Could encryption do the trick?
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading...

Deleting Data for GDPR: Could encryption do the trick?

A new article in CIO magazine proposes an outside-the-box method for GDPR data deletion. Here’s why that’s not a good idea…

After writing exhaustively about GDPR compliance for the better part of 2018, we figured why not kick 2019 off with a little more discussion about the EU’s General Data Protection Regulation. Specifically the “right to erasure,” and what that actually portends for most organizations.

Let’s be honest, while the GDPR’s right to be forgotten/right to erasure are a big win on the side of personal privacy, from a business standpoint this is a huge pain in the rear. I know this because I help handle deletion requests for The SSL Store and its subsidiaries. I see it first-hand. And generally the folks requesting the deletion are less than polite. They’re often disgruntled and generally threaten to be litigious.

The point I’m making is that despite what it does for personal privacy, these edicts are not business-friendly. And many companies and organizations are actively looking for better ways to comply with the rights afforded by the GDPR while minimizing the work that must be done on their end.

So today we’re going to look at the GDPR’s right to erasure, whether there could be an encryption solution and then we’ll finish by discussing why that solution would likely be a bad idea.

Let’s hash it out.

The GDPR’s Right to Erasure

Let’s start out by defining what the GDPR says about the right to be forgotten/the right to erasure and what organizations must do to comply with it.

Let’s start with the nomenclature, Article 17 of the GDPR, which lays out the rights of the data subject, refers to it as the “Right to Erasure (‘right to be forgotten’).” So the two are basically interchangeable.

Article 17, as well as some advice from Articles 12 & 23, plus recitals 55 & 56, outline the requirement for organizations to erase information at the behest of “data subjects.”

1.   The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:

Now, those grounds (and I’ll summarize for the sake of brevity) are:

  • The data is no longer necessary
  • Data subject withdraws consent for processing
  • The organization can’t satisfy its reason (legitimate interests) for processing
  • The data was unlawfully processed
  • Erasure is required to comply with a legal obligation
  • Consent was wrongfully obtained from a minor

When a data subject appeals to your organization for erasure of their personal data on one of those grounds, and you don’t have a superseding reason to keep it, not only are you obligated to delete it, but you’re also obligated to notify any partners you may have shared it with to delete it, too.

Obviously, this is not a productive use of company time and what many data subjects don’t realize is that deleting data from any website, let alone from a multi-headed corporate hydra is not all that simple. Where is all the data stored? What databases have copies? Is there any of this data that we are obligated legally or by industry standards to keep?

It’s not as easy as just pulling up a profile and clicking “delete.”

And unfortunately, not much has been done to define exactly how an organization should go about an erasure. This is, in my opinion, one of the greatest weaknesses of the GDPR. In its earnest attempt to have the GDPR be universally applicable the EU has failed to properly define certain aspects of its new regulation that really do require some specifics.

And that has led to some rather interesting ideas on how to do it in the least disruptive way possible.

Don’t encrypt your data and throw away the key instead of deleting it

In an article of New Zealand’s edition of CIO Magazine, a group of lawyers discuss how the GDPR’s right to erasure jives with the immutability of data recorded on a blockchain.

Now, I’ll preface with this: blockchain is an incredibly interesting technology that is far less useful than a lot of the marketing and crypto bros out there want you to believe. It is not a panacea. It can’t solve any business problem. And most of the people who mention it all the time couldn’t explain it to you in a concise way to save their lives.

That little outburst aside, Russell McVeagh (a prominent New Zealand-based law firm) lawyers Liz Blythe, Michael Taylor, Rachel O’Brien and Zoe Sims came up with a rather unique solution to the problem: how do you satisfy the GDPR’s right to erasure requirement on a blockchain?

Their answer: encryption.

Could personal data stored on a blockchain be effectively ‘deleted’ by encrypting it and then destroying the private key so it can never be read? There is currently no firmly established answer, but there are reasons to be hopeful that this would be an acceptable solution.

The reasons they offer are that (a.) it would be ironic if GDPR thwarted the “promise of blockchain,” (b.) as mentioned earlier the GDPR “is vague as to when exactly personal data is “erased,”” and (c.) “the concept of encryption is already recognised [sic] in the GDPR.”

Now, in fairness they also offer three points of caution, centering around logistics, the patchwork of legal regulations in various jurisdictions and the threat of the future.

And I applaud the unorthodox thinking that led to such a unique approach.

But this is a bad idea.

If, as so many politicians in Western nations have called for, encryption that makes use of backdoors or key escrow is “responsible encryption,” encrypting something and then purposely deleting the key so it can never be decrypted would probably be “irresponsible encryption.”

Frankly, if you’re looking for a purely one-way process the better answer might be to hash the data, but encrypting it is definitely not the way to go.

And the reason for that is in their final “note of caution.”

3. In theory, any type of encryption can be broken given enough time, energy and processing power. What is considered secure today may not be secure in the future. Merely encrypted data is therefore at risk – and working out the nature and extent of that risk will be an important part of the discussion.

That is 100% true, if a little bit understated. Most of our current cryptosystems will be under immediate threat from quantum computing when it becomes viable in about a decade. RSA is already facing challenges from various exploits, it’s already ill-advised to use it for key generation, and it’s really only a matter of time before we have to discard it entirely.

What’s ultimately going to be needed if there’s any possibility for this idea to be viable are post-quantum cryptosystems. And there is some work being done on that front. Organizations like ISARA are hard at work developing post-quantum or quantum-proof encryption and we’re already seeing some of the fruit of that labor in its partnership with DigiCert, where they’re creating digital certificates for IoT devices with both a standard cryptosystem and a post-quantum one to ensure the long-term health of the devices they’re installed on.

We would need to consider something similar for this to work. And even then, there will be a finite time before those cryptosystems are compromised. There will likely never be a completely unbreakable cryptosystem, and that itself is the fatal flaw with this suggestion.

Because if anyone were to try this method – encrypting data to delete it and then throwing away the key – they would really just be creating a treasure trove of data to mine once the cryptosystem that was used is compromised.

You’re not really deleting it, you’re just deleting it “for now.”

That’s not really in the spirit of the regulation and it’s also not a good idea from a compliance standpoint. As much as it stinks, just delete the data (or come up with a bulletproof reason not to). Just don’t encrypt it and throw away the key or you’re only inviting trouble down the line.

As always, leave any comments or questions below…

Hashed Out by The SSL Store is the voice of record in the SSL/TLS industry.
3 comments
  • While I was reading your explanation about the data encryption deletion issue I was thinking that perhaps an individual like myself would be wanting to purchase something on say, Amazon. I would be on the Amazon website, sign in, and put my purchases in the shopping cart. The difference for checking out would be that I would be logged into Amazon but Amazon would come to my location safe box location and I would give Amazon an entry code to get in and make this one time per purchase. Then the purchase would be completed in my private safe box location. Every time I want to shop on Amazon or any other website for that matter, the website and I would communicate together but ultimately, after my purchases are in the shopping cart the retailer would come to my safebox to request a code to get in and complete the purchase. And that would be the end. Any time another purchase would be undertaken, the retailer or whomever would need/request a new code from me in real time, and this code would always be fresh. All transactions would regenerator fresh code from the originator to complete a transaction and then there would be nothing left to delete once the transaction was completed because the the transaction would be completed within the individual safe box location and therefore secure. I don’t know if this makes any sense but this is what came up in my mind when I was reading your article. Thanks very much.

  • Upon further reflection the payment process could be made into steps the retailer would come to the safe box location get the entry code come in and complete the purchase and then the payment information would be sent to the credit card company who would send a reply to the individual making the purchase and the retailer so that it would be validated by both parties. This would ensure the security of the transaction for the individual making the purchase, for the credit card company, and the retailer.

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *

Author

Patrick Nohe

Hashed Out's Editor-in-Chief started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. He also designs the visuals for Hashed Out and serves as the Content Manager for The SSL Store™.