Crypto-Shredding is NOT Nirvana for Right of Erasure or RTBF Compliance
Crypto-shredding sounds cool, high-tech and simple but is practical and suitable for only a few very specific use cases. Managing Right of Erasure, Right to be Forgotten (RTBF) or other row or record level deletion is NOT one of them.
Why?
- Unacceptable performance degradation of having every bulk read and write operation against the table with a key per row and usually many encrypted columns.
- Prohibitive implementation costs requiring code changes to each read and write operation.
- Inapplicability for business applications and analytics tools where code changes to constantly call decrypt functions is not an option.
- Key rotation considerations – Data Encryption Key (DEK), not just the Key Encryption Key (KEK)
Everyone KNOWS encrypted data is secure right? This is only true to the extent the key used to encrypt/decrypt the data is secure. Crypto-shredding relies on this secure key premise indefinitely.
If data is encrypted it is secure right?
Unfortunately, it is not that simple. Encryption is just another tool in the data security tool box, that when used appropriately, provides an added layer of security helping to reduce or eliminate certain risks or attack vectors. When used inappropriately, it only adds complexity, cost, and in some cases, added risk from misconfigurations or inadvertent loss of data.
Crypto Shredding is a term used to describe encrypting data then simply destroying the key used to decrypt when you want to permanently disable access to the data, leaving only encrypted copies everywhere but with no key to ever again decrypt the data.
The Data Owner enjoys a false sense of security while the risk from a brute force attack on the key remains the same. For some data privacy regulations or internal corporate policy, this also may not meet the requirement for permanent physical deletion.
Crypto-shredding is generally only a good fit when you must have many distributed copies of large data sets or files and can centrally manage and control just the keys used to encrypt and decrypt the data without having to continuously transmit large files or data sets especially over WAN connections. You are reducing the exposure of clear text data and the volume of data being transmitted over LAN or WAN networks and can focus on securing and transmitting only the encryption keys.
Like Digital Rights Management (DRM), It also requires implementing mechanisms that enable USE of the key to decrypt without providing a mechanism for keeping a copy of that provided key. You must also have a secure mechanism for sharing the key used to decrypt with authorized users and business processes at run-time, for one-time use, AND no ability to make a clear text copy of the data OR keep a copy of the key provided. Otherwise anyone granted access to decrypt who ever kept a copy of the keys would always be able to decrypt the records.
Crypto-shredding mechanisms are not just about deleting keys
This typically means additional application layers or major code changes to existing applications. Deleting a key is easy when there is only one secure copy of the key and all copies of the sensitive data are encrypted. Of course, you will still eventually have to physically delete the encrypted data to reduce data storage requirements with no way to now confirm or validate what you are deleting.
With many at-rest data encryption solutions you are simply replacing controlling access to the data with controlling access to the key used to encrypt the data. Many poorly thought out implementations simply add complexity and have a negative performance and operational impact, (including when leveraging a KMS or HSM) while doing nothing to eliminate risk. There is a very long list of companies that have spent $millions on noble, but ill-conceived attempts at implementing at-rest data encryption solutions only to give up after years of frustration.
Do you need data access control or data protection?
Think of data encryption as a data protection tool, not an access control tool. Use it to add an additional layer of security where it clearly adds value, reduces risk or eliminates specific attack vectors. Do NOT make the mistake of attempting to use it as an access control tool. You will only be replacing access controls to the key with access controls to the protected data encrypted with the key. Even the encrypted data (columns or rows) will still require access controls.
This is especially true for Row Level encryption where a separate key must be used to encrypt each record or row if Crypto-Shredding will be used to permanently block access to individual rows. You must still contend with physical deletion of encrypted records you can no longer re-identify. You must maintain auditable records of the entire key management and destruction process and links to which deleted key was associated with what record(s). Lots of added complexity for little or no benefit.
Rarely a good fit for row level security controls
For these reasons and more, this is rarely a good fit and often impractical to implement at scale for row level security controls enforcing Right of Erasure, Right to be Forgotten, Restriction or Limitation of Use/Processing and Consent & Preference Management privacy compliance requirements.
In the end, it is better to have reliable, effective, auditable, centrally managed, consistently applied, Purpose or Attribute Based Access Control (PBAC/ABAC), data protection and privacy compliance that leverages encryption technology where it IS most appropriate, improves data security and lower risk by eliminating one or more significant attack vectors or vulnerabilities.
SecuPi fully enables and supports more intelligent use and management of encryption technology as part of a data-centric approach to data protection, access control, accountability and privacy compliance. This is true whether it needs to be applied at the file level, column level or occasionally at the row level or simply to protect sensitive data in motion over unsecure networks.
Author: Les McMonagle
Chief Security Strategist, SecuPi
