[Damogran6]

I've had this argument til I'm blue in the face.

1. Nuke the key and an encrypted drive is indistinguishable from noise. 1a. When SAN sizes get STUPIDLY LARGE, miltiple writes are cost and energy prohibitive, crushing is cheap, cert revocation is cheaper and leaves a device with residual value. 2. In the datacenter, data at rest is not a target, the attack happens higher up the stack where the OS/SQL/App can read the data 3. Areal density is such that a drive in a RAID array doesn't have much to offer up*

(* = I'm willing to lose #3 if #1 is utilized.)

But there's always some mouthbreather n00b or auditor or person that took a forensics class once that stands in the way.

[deepsun]

How do you "nuke" the key? It may still be on the drive (or other drives, or magnetic tape backups).

[ac29]

If I can store drive encryption keys on a HSM in my old, consumer grade laptop, I would hope that large storage systems have at least the same degree of protection.

[deepsun]

But if that HSM module or machine suddenly dies, the system would lose all the customer's files. Not good.

[awesomeMilou]

If I understand it correctly, the HSM on the HDD dying is about as likely as a HDD PCB failure. Of course in these scenarios you can't just swap the PCB's to recover the data, but in an Enterprise setting you would have mitigated this anyways, by using a form of redundant storage. If you rely on just one drive for your data's continued existence, you're doomed anyways.

[0] https://wiki.archlinux.org/title/Self-encrypting_drives

[Damogran6]

That's when you fall back to your backup processes....you HAVE backup processes, don't you? (They're resilient against ransomware, aren't they?)

[deepsun]

But parent said to "nuke" the encryption key. :shrug:

[Damogran6]

I'm the parent. Take the key that decrypts the disk...overwite/dealloc/zero/forget the key...the disk is ready for it's next mission.

[Damogran6]

I'm going to trust the storage manufacturers when they offer a secure erase function that it whole disk encrypts, and secure erase removed the decrypt keys everywhere they exist. It's a conversation you have when you establish the vendor, and they're the ones that own the risk (fiancial, reputational, etc) if it turns out the key is stored in plain text on ring 0, sector 0, disk 0 and someone talks about it at Defcon.

The point is: I'm tired of 'well what if?'...that comes up EVERY time there's a question about data destruction....'we should shred it "just to be sure"' is stupid.