Crypto-shredding

Crypto-shredding is the practice of 'deleting' data by deliberately deleting or overwriting the encryption keys.[1] This requires that the data have been encrypted. Data comes in these three states: data at rest, data in transit and data in use. In the CIA triad of confidentiality, integrity, and availability all three states must be adequately protected.

Getting rid of data at rest like old backup tapes, data stored in the cloud, computers, phones, and multi-function printers can be challenging when confidentiality of information is of concern; when encryption is in place it allows for smooth disposal of data. Confidentiality and privacy are big drivers of encryption.

Motive

The motive of deleting data can be: defect product, old product, no further use of data, no legal right to retain data any longer, etc. Legal obligations can come from rules like: the right to be forgotten, the General Data Protection Regulation, etc.

Use

In some cases everything is encrypted (eg. harddisk, computer file, database, etc.) but in other cases only specific data (eg. passport number, social security number, bank account number, person name, record in a database, etc.) is encrypted. In addition the same specific data in one system can be encrypted with another key in another system. The more specific each piece of data is encrypted (with different keys) the more specific data can be shredded.

Example: iOS devices use crypto-shredding when activating the "Erase all content and settings" by discarding all the keys in 'effaceable storage'. This renders all user data on the device cryptographically inaccessible.[2]

Best practices

  • Storing encryption keys securely is important for shredding to be effective. There is no effect when a encryption key is shredded when it has already been compromised (copied). A Trusted Platform Module addresses this issue. A hardware security module is one of the safest ways to use and store encryption keys.
  • Bring your own encryption refers to a cloud computing security model to help cloud service customers to use their own encryption software and manage their own encryption keys.
  • Salt: Hashing can be inadequate for confidentiality, because the hash is always the same. For example: The hash of a specific social security number can be reverse engineered by the help of rainbow tables. Salt addresses this problem.

Security considerations

  • Data in use. For example: the encryption keys temporarily used in RAM can be threatened by cold boot attacks, hardware advanced persistent threats, rootkits/bootkits, computer hardware supply chain attacks, and physical threats to computers from insiders (employees).
  • Data remanence: For example: When data on a harddisk is encrypted after it has been stored there is a chance that there is still unencrypted data on the harddisk. Encrypting data does not automatically mean it will overwrite the exact same location of the unencrypted data. Also bad sectors cannot be encrypted afterwards. It is better to have encryption in place before storing data.
  • Hibernation is a threat to the use of an encryption key. When an encryption key is loaded into RAM and the machine is hibernated at that time, all memory, including the encryption key, is stored on the harddisk (outside of the encryption key's safe storage location).

The mentioned security issues are not specific to crypto-shredding, but apply in general to encryption. In addition to crypto-shredding, data erasure, degaussing and physically shredding the physical device (disk) can mitigate the risk further.

See also

References

  1. Crypto-shredding in 'The Official ISC2 Guide to the SSCP CBK' ISBN 1119278651
  2. Crypto-shredding using effaceable storage in iOS on stanford.edu
  3. Factsheet post quantum cryptography on ncsc.nl
  4. Post Quantum-Crypto for dummies on wiley-vch.de
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.