Comments

4 responses to “physical disk shredding, explained for paranoid sysadmins”

1. 2010/09/16

   Simon Waters

   Noted that DBAN docs recommend ATA secure erase for erasing remapped blocks.

   Although I suspect anyone who can retrieve anything useful after a quick “dd” of random numbers to the whole device is smart enough to find a simpler and cheaper way to extract relevant data. One can invoke ATA secure erase with hdparm, and it is more likely to tick boxes on boring conformance sheets.

   The hardest time to erase data is when the system no longer boots, and/or the disk drive no longer spin up. Always be sure to erase your data before that happens otherwise you end up groping around in dusty cupboards for weird SCSI controllers, or relying on abusing disk platters 😉

   Reply
2. 2010/09/19

   Alex

   Hey Alec,

   While on this subject, I’ve got a question I suspect some people on here probably know a bit about.

   The reading I have done on this is very mixed – if I DBAN my disk – does it really need to be shredded ? Some insist physical destruction is the only way to be sure – but others (eg Gutmann) say that with modern drives that you are safe with just a couple of overwrites.

   For say PCI data – I’m not going to argue about the disk being destroyed. But destroying disks gets quite expensive after a while in a large estate.

   So – if a disk is properly wiped does it need to be physically destroyed ?

   The best justification for both I can see is that wiping AND physical destruction protects you in the event of the failure of either process, ie where the disk isn’t wiped or destroyed.

   Or is overwriting as per Gutmann / DBAN just not good enough for some types of data ?

   Thanks,

   Alex

   Reply
3. 2010/09/19

   alecm

   Hi Alex, I’ll be brief to save argument:

   > if I DBAN my disk does it really need to be shredded

   Typically not, unless you’re storing nuclear launch codes or bank certificates, or unless someone is paying you to do that sort of thing.

   After DBAN the only real risk is a small number of blocks that the controller hardware may have copied/remapped after-having-been-written-upon, but to retrieve data from these will require a degree of foreknowledge, custom software, and a large dose of incentive – which few people will have.

   So if we’re talking a netbook-to-sell-on-ebay then just DBAN it. You can probably swallow that much risk.

   If you’re dealing with legal commitments or terminally anal-retentive nitpicky customers you’re better off using a good quality encrypted filesystem from Day1 and then trashing the key and ideally DBAN the disk – if well managed this is a due-diligence solution which no security geek could fault; in theory you could just trash the key but DBAN atop crypto gives two layers of near-impossibility-to-recover-from.

   EDIT: Oh, and tell the customer that that is how you do it, and get them to sign up to it.

   Reply
4. 2010/09/19

   alecm

   ps: what Gutmann is referring to is that the new ways of encoding data on a platter are so dense and so weird that the very attacks that he himself explained in the mid-90s are no longer relevant; there is less redundancy/imprecision/capability to take advantage of for recovery.

   Data destruction is weird, people get all emotive about it; I wrote an asynchronous-I/O disk scrubber for Sun to use on financial services grid systems – oddly only about 10% faster than “dd” for I/O – and I ended up having to scrub a disk and sending it off for assessment by Qinetiq to show it was working correctly; yet a piece of prefab software doing exactly the same thing much slower (sector writes) but with a known brandname would be waved through…

   The technical problem is well understood and solved, but what will never be solved is the politics of risk as filtered through the fearful and ignorant.

   Reply