5 ms·
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
by Damogran6 3y ago
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 3y agoHow do you "nuke" the key? It may still be on the drive (or other drives, or magnetic tape backups).
- ac29 3y agoIf 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 3y agoBut if that HSM module or machine suddenly dies, the system would lose all the customer's files. Not good.
- awesomeMilou 3y agoIf 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 https://wiki.archlinux.org/title/Self-encrypting_drives
- deleted 3y ago[deleted]
- Damogran6 3y agoThat's when you fall back to your backup processes....you HAVE backup processes, don't you? (They're resilient against ransomware, aren't they?)
- Damogran6 3y agoI'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.