1

I have a compliance question around crypto shredding and CCPA. I'm basically just wondering if crypto shredding is sufficient to comply with the CCPA customer deletion requests.

I know that crypto shredding has it's own downsides (quantum computers??), but if data is only stored for a period of time (on the order of years), it seems reasonable to assume that crypto shredding keys that encrypt a specific user's data will make that data inaccessible. Does this still count as deletion though from a legal perspective?

My question is specific to CCPA, but I'm also curious about crypto shredding in relation to laws requiring data erasure in general.

An example of an implementation of crypto shredding might be: - Create a unique key pair for each customer using the strongest encryption available at the time. - Encrypt all customer data with these keys. - Customer data may then be combined into large archival files (on tape or CD backup), with each record of a customer's data being encrypted with their own specific keys. - A CCPA deletion request comes in, and we purge the key store of the decryption keys for that customer. - At this point we can no longer reasonably retrieve a customers data, even though it lives on archival media for a period of time. The only possible method of retrieval would be if decryption technology vast exceeded what we have available today.

I'm mainly looking for resources around the legal ramifications around this. My initial research shows that there are exceptions to archival storage of such data, but doesn't have anything regarding crypto shredding. My current assumption is that since this isn't theoretically permanent, it's not a valid way to delete data according to the law.

markwatson
  • 113
  • 3

2 Answers2

3

The CCPA statute doesn't provide a technical definition of "delete". This means that until a court case interprets the law otherwise, you can take whatever actions you deem technically sufficient to render the data "deleted". What would be important is that, if you were challenged in court for not deleting a client's data, you could convince a judge that the data was deleted, destroyed, or somehow rendered unrecoverable.

What this typically means in practice is that you would need to consult with your organization's attorney, CCPA compliance team, or risk management team about your proposed data deletion solution.

That said, any legal defense would be on much firmer ground if you employed an existing industry or national standard for data destruction. Consider following something like NIST SP 880-88, which is a national standard for media destruction. It defines three levels of media sanitization: clear, purged and destroyed. No rational interpretation of California law would require you to physically destroy a hard disk that once held a person's data, so you can probably eliminate "destroyed" as a path you'd need to follow. To clear means to remove the data using overwriting techniques, but is not necessarily defense against a forensic laboratory recovery of the data. To purge is to render the data unreadable by an attacker using state-of-the-art laboratory techniques. And they specifically cover Cryptographic Erase as a valid purge technique, when certain factors exist.

Just be aware that Cryptographic Erase is actually a very complex solution to achieve in practice. It involves maintaining separate keys for each block or category of stuff you wish to destroy. That's pretty easy when it's a one-key-per-hard-disk-controller relationship to be used for purging an SSD or HD of all its data, but a lot harder when you're only trying to delete a few rows from a database. You certainly could maintain one key per customer, but that might be a lot of keys to manage, and require an expensive and complex key management system.

John Deters
  • 33,650
  • 3
  • 57
  • 110
1

I don't know if it is legally conform. But I'd suggest you to keep following in mind. When you delete a decryption key, it is impossible to guarantee that there is no copy of this key. A copy could be done purposely, e.g. as a back up. A copy can be also stolen. You cannot prove that a copy of the key does not exist. Thus despite deleting the key there is a risk that data can be decrypted. I would discourage you from using it.

What are alternatives? There are multiple standard procedures. One of them is based on multiple rewriting data storage with random data.

mentallurg
  • 8,536
  • 4
  • 26
  • 41
  • 1
    "When you delete a decryption key, it is impossible to guarantee that there is no copy of this key." But that's true of the underlying data too. How is this any different? – Joseph Sible-Reinstate Monica May 31 '20 at 06:49
  • @JosephSible-ReinstateMonica: I don't understand your question. Please reformulate it more precisely. Until then, here a few words more. The OP suggests to encrypt the data on the disk and to destroy the key. But if somebody has got a copy of this key (e.g. because you occasionally saved the key somewhere), he can decrypt **all the data on the disk**. But if you rewrite data on the disk with random data, there is no way to restore the original data. This is the huge difference: In one case there is a risk that data will be **fully** restored, in the other case there is no way restore them. – mentallurg May 31 '20 at 09:36
  • 1
    What's the difference between saving the key somewhere else and saving the underlying data somewhere else? Why are you concerned about the former but not the latter? – Joseph Sible-Reinstate Monica May 31 '20 at 15:24
  • @JosephSible-ReinstateMonica: What saving of data you mean? The OP is about *shredding* of data, not saving. The purpose (not explicitly mentioned here) is to make data on the disk not readable for anyone who gets access to this disk. For instance, a disk has reached the maximum guaranteed number of working hours and must be replaced. When you store sensitive data on this disk, you want that nobody can read them. There are different methods to reach that: to destroy it physically, to destroy its magnetic field, to override data etc. The OP asks about possible risks of it... – mentallurg May 31 '20 at 18:08
  • 1
    I'm saying that "shredding the key might not be good enough because there might be another copy of the key somewhere" is equivalent to "shredding the data might not be good enough because there might be another copy of the data somewhere". – Joseph Sible-Reinstate Monica May 31 '20 at 18:09
  • @JosephSible-ReinstateMonica: OK, now it is clear what you mean :) Normally not "might be another copy", but *for sure* there will be a copy. You replace a disk with a new one. You copy *all of the data* (or all of the secret data) to the new disk. But we don't care about this. Why? Because if you have secret data on a disk, normally you care that nobody gets access to them if he/she is not authorized to do that.... – mentallurg May 31 '20 at 18:19
  • @JosephSible-ReinstateMonica: ... That's why when you create a copy stored in the same room you don't increase the risks. But when you throw away a disk that needs to be replaced, the you do create a risk, because many people can get access to it. That's why you want to make data unreadable. – mentallurg May 31 '20 at 18:20
  • But if it's okay to have a second copy of the data as long as it's safe, why is it not okay to have a second copy of the key as long as it's safe? – Joseph Sible-Reinstate Monica May 31 '20 at 18:20
  • @JosephSible-ReinstateMonica: Because it is impossible to disclose all data on the disk (say 4 TB) *occasionally*. Where as it is *much easier* do disclose password occasionally: by copy-pasting it into wrong application window, by picking up a wrong entry in password manager. – mentallurg May 31 '20 at 18:24
  • @JosephSible-ReinstateMonica: ... Or you can loose your device where your passwords are stored and smb. can get access to password from the data on the disk. Where as getting access to data on the disk directly is much harder. That's why we estimate the risk that attacker gets password much higher that a risk that an attacker gets access to the disk directly. – mentallurg May 31 '20 at 18:27