Eventsourcing Patterns: Crypto-Shredding

Encrypt sensitive information in an event and delete the key.

By Mathias Verraes
Published on 13 May 2019



Crypto-Shredding

Encrypt sensitive information in an event and delete the key.

Problem

The problem is the same as for Forgettable Payloads: some attributes of an event should not be read by all consumers, and we should be able to delete them, without touching the event store.

Solution

Encrypt the sensitive attributes, with a different encryption key for each resource (such as a customer). Only give the key to consumers that require it. When the sensitive information needs to be erased, delete the encryption key instead, to ensure the information can never be accessed again. This effectively makes all copies and backups of the sensitive data unusable.

Discussion

The Crypto-Shredding pattern is of course only as good as your encryption and your key management practices. Today’s unbreakable encryption could be tomorrow’s infosec disaster.

If the consumers (such as projections) consistently store all sensitive information using encryption, it makes deletions extremely cheap, as only the key must be deleted, as opposed to deleting all copies. But this benefit can be achieved using Forgettable Payloads. Both patterns do not solve the problem of consumer storing encrypted data, or using the encrypted data to compute some new value (that may still be sensitive).

There is also a concern of legality: is Crypto-Shredding a sufficient implementation of delete requests under GDPR, or does the law consider the data not truly deleted?

UPDATE: Harrison J. Brown wrote the following answer to that question:

The legal question is important and the GDPR does actually state that encrypted personal information is still personal information. I spoke to my lawyer about this and they said that in the event of a breach you’d still have to notify the authority (the ICO, in the UK) though you might not have to tell the data subjects (since the breach wouldn’t affect them). This document from the European Commission states this clearly in section1, paragraph 5:

“A confidentiality breach on personal data that were encrypted with a state of the art algorithm is still a personal data breach, and has to be notified to the authority. Nevertheless, if the confidentiality of the key is intact, the data are in principle unintelligible to any person who is not authorised, thus the breach is unlikely to adversely affect the data subject and therefore doesn’t need to be notified to the data subject.” As for the deletion request scenario, the law does not consider deleting the encryption key equal to actually deleting the data itself. Encrypted personal data is still personal data, regardless of whether anyone has the key. So, if were asked by a data subject to delete their personal data and all you did was delete the encryption key you would not be complying with the removal request, at least according to the GDPR.

So, whilst this crypto-shredding pattern is, I think, really useful for certain types of data (business sensitive information, for example) I think your Forgettable Payloads pattern (where one stores the sensitive payload of an event in a separate store to control access and removal) is more appropriate for personal data.