Does anyone have any experience of using the ATA secure erase commands from hdparm?
My understanding is that a BIOS can lock the drive from responding to the commands, and that some do and some don't. Mine appears to (hdparm -I /dev/sda shows "frozen" in the "Security" section), but I don't know how common it is to find a BIOS that allows this to work.
I have several drives to wipe and I'd certainly consider building a PC for the job but I have no idea how to find out if a BIOS will let me do it before I buy it.
On Mon, August 9, 2010 14:53, Mark Rogers wrote:
I have several drives to wipe and I'd certainly consider building a PC for the job but I have no idea how to find out if a BIOS will let me do it before I buy it.
Just use DBAN.
On 09/08/10 16:24, Martin A. Brooks wrote:
Just use DBAN.
We usually do, but Secure Erase is both much faster and more secure (it wipes areas DBAN can't get to), provided you have hardware that allows it to work. Most (modern) drives do, but a lot (most?) of mobos don't allow the commands through for security reasons. Thinking about this, having a virus that was able to send a secure wipe to a disk might be a very bad thing, so it's not a bad default, but it would be nice to be able to turn it off!
There is a DOS program (HDDErase) which can be run from a bootable disk the way that DBAN can, but it suffers the same problem when accessing the hardware, and I'd prefer to use hdparm as it will be more likely to tell me what is going on.
My understanding was that the multipass method of secure erasing was almost irrelevant now anyway.
I think all the secure erase does over dban is removes sector remapping data from the drive flash and tries to overwrite blocks marked as bad (which due to sector remapping dban or dd will skip)
Also there was a study conducted a few years ago that I am currently failing to find online that suggested that recovery of data after a layer of overwrites of even non random data was "improbable" now that storage densities are that much higher and things like perpendicular recording are commonplace.
In fact the same article linked to a challenge posted to data recovery specialists (that I believe has not been met) to recover data from a modern drive that had been subjected to just one pass of zeroing. Not withstanding that even when it was known to be possible the actual cost of the forensic work to do a recovery from something that had been overwritten multiple times was very very very time consuming and expensive.
So I would say that unless we are talking data under the official secrets act (in which case furnace destruction of the drive would be the obvious way to be 100% sure) then maybe even a single pass of /dev/urandom would be enough.
Something often undocumented about ATA Secure Erase is that as well as storage controller firmware sometimes blocking it, a lot of drive firmware will silently abort the command unless an ATA user password has been set on the drive first. So if you are having trouble getting it to work then try that first. Last time I played with it, it took me a while to discover this.
Another thing worth mentioning that rarely comes up.
If you really are *that* paranoid how do you know that a "secure erase" command built into the drive firmware is really doing its job and not just hiding the data from you after it is run ? I mean if you can't inspect the code or physically verify what is actually on the platters after then it could be just setting a flag on the drive to say "return nonsense from now on" and you'd be none the wiser. In that respect I feel it offers less assurance than using tools like dban.
On Mon, 09 Aug 2010 19:36:26 +0100 Wayne Stallwood ALUGlist@digimatic.co.uk allegedly wrote:
Another thing worth mentioning that rarely comes up.
If you really are *that* paranoid how do you know that a "secure erase" command built into the drive firmware is really doing its job and not just hiding the data from you after it is run ? I mean if you can't inspect the code or physically verify what is actually on the platters after then it could be just setting a flag on the drive to say "return nonsense from now on" and you'd be none the wiser. In that respect I feel it offers less assurance than using tools like dban.
<black helicopter alert>
And I recall reading something similar recently which postulated that given the current recording density of disks it would be perfectly feasible for manufacturers to have built in "secure mirror" partitions on the disks which would hold copies of all "deleted" data. Such partitions would only cough to their existence when prodded by those with the requisite secret incantation. :-)
So - short of total physical destruction you have no real assurance that your porn browsing history is just that - history.
</black helicopter alert>
Mick ---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
On 09/08/10 19:36, Wayne Stallwood wrote:
My understanding was that the multipass method of secure erasing was almost irrelevant now anyway.
This is my understanding too. Which makes one of DBAN's best features pointless!
I think all the secure erase does over dban is removes sector remapping data from the drive flash and tries to overwrite blocks marked as bad (which due to sector remapping dban or dd will skip)
It also does this much quicker than DBAN runs, so it's effectively "better" and faster, hence the appeal. On the other hand it's also more of a pain in the **** to get working....
Something often undocumented about ATA Secure Erase is that as well as storage controller firmware sometimes blocking it, a lot of drive firmware will silently abort the command unless an ATA user password has been set on the drive first. So if you are having trouble getting it to work then try that first. Last time I played with it, it took me a while to discover this.
This is all quite well documented in (I think) the hdparm documentation - I'm not in a position to check right now but most sets of instructions for secure erase with hdparm seem to link to it.
If you really are *that* paranoid how do you know that a "secure erase" command built into the drive firmware is really doing its job and not just hiding the data from you after it is run ?
Paranoia is one aspect, but I'm not particularly paranoid.
However, customers like to tick boxes, and the "secure erase" function of the hard drive seems to tick more boxes than DBAN, not least because DBAN goes out of its way not to provide any warranty. It was this aspect that got me looking at secure erase in the first place; realistically the data is not worth anything to anyone and /dev/random (or even /dev/zero) would be suficient from a strict security point of view.
I did read somewhere about hard drives that encrypt all stored data on the fly using en encryption key stored by the flash; to "wipe" the disk instantly al you need to is change the encryption key - all the old data becomes inaccessible. I can't find the reference to that now.
On Tue, Aug 10, 2010 at 01:04:39PM +0100, Mark Rogers wrote:
I did read somewhere about hard drives that encrypt all stored data on the fly using en encryption key stored by the flash; to "wipe" the disk instantly al you need to is change the encryption key - all the old data becomes inaccessible. I can't find the reference to that now.
I've got one in my laptop. Try searching for Seagate FDE.
Adam
On 10/08/10 13:04, Mark Rogers wrote:
However, customers like to tick boxes, and the "secure erase" function of the hard drive seems to tick more boxes than DBAN, not least because DBAN goes out of its way not to provide any warranty.
Do any of the drive manufacturers warranty the performance of the secure erase feature then...seems unlikely.
I get the box ticking thing, but I mean ok, put it another way. I have some Seagate drives in my machine that shipped with a firmware bug that can effectively offline them, without much chance of user recovery and with no warning just because an internal event log rolls over.
So if Seagate can ship drives with a bug as massive as that in their primary function. What are the chances that a little used and sparsely documented feature is checked heavily in QA before firmware builds are signed off ?
DBAN cannot afford to imply any warranty I doubt that statement is any reflection of known flaws in the software, more likely that their lawyer made them put it in.
On 10/08/10 23:09, Wayne Stallwood wrote:
Do any of the drive manufacturers warranty the performance of the secure erase feature then...seems unlikely.
Maybe not, but rightly or wrongly it's easier to have someone "trust" Seagate than some bloke called Darik!
So if Seagate can ship drives with a bug as massive as that in their primary function. What are the chances that a little used and sparsely documented feature is checked heavily in QA before firmware builds are signed off ?
Not great, I agree!
DBAN cannot afford to imply any warranty I doubt that statement is any reflection of known flaws in the software, more likely that their lawyer made them put it in.
Agreed, and there'll be similar terms in the warranties of the hard drive manufacturers, I am sure. But Darik doesn't hide them the way a commercial organisation does!
DBAN is likely better in many regards - it is open source and open to scrutiny, it's well established and well used, it's the one you'd attack if you wanted to prove you could defeat something and nobody has. If it was my own data and I was seriously worried about it, I'd DBAN rather than secure erase (and maybe do both). That said I have nothing that /dev/random wouldn't suffice for.
If I can find the right hardware and make all this work, I'd probably DBAN *and* secure erase, on the understanding that secure erase is fast enough to make this a viable option (and from looking at it, the most likely way to make it work is via E-SATA and not plugging the drive in until after the PC has booted, which means I could swap through multiple disks without rebooting if I wanted to, and could even do it from my desktop given that the BIOS has locked the commands out from my own master drive).
As an aside, though:
How secure would you consider wiping a single partition with /dev/random, compared with wiping the whole disk? The reason I ask is that in many cases the idea is to wipe the disk and then re-install the OS, and if the disk has a hidden recovery partition on it then that is by far the best way to restore the OS. Securely wiping the main partition(s) then re-installing would be the quickest way to achieve this, wouldn't it?
On 11/08/10 08:38, Mark Rogers wrote:
How secure would you consider wiping a single partition with /dev/random, compared with wiping the whole disk? The reason I ask is that in many cases the idea is to wipe the disk and then re-install the OS, and if the disk has a hidden recovery partition on it then that is by far the best way to restore the OS. Securely wiping the main partition(s) then re-installing would be the quickest way to achieve this, wouldn't it?
I can't see why it would be any less secure than applying it to the whole disk to be honest. Any sector remapping going on will be at a disk level not partition level anyway so it should make no odds.
However in situations where I might want to use the factory OS installation and in the common absence of removable recovery media I tend to take an image of recovery partitions anyway, so even if the disk dies I can reapply them.
Just be sure that the only thing stored in the recovery partition is the factory state.
On Mon, 9 Aug 2010 16:24:49 +0100 "Martin A. Brooks" martin@antibodymx.net allegedly wrote:
On Mon, August 9, 2010 14:53, Mark Rogers wrote:
I have several drives to wipe and I'd certainly consider building a PC for the job but I have no idea how to find out if a BIOS will let me do it before I buy it.
Just use DBAN.
Seconded.
Though it can take some time (upwards of 7 hours) on large (>500 gig disks) and/or slow (< recent dual core class intel) if you want to be sure you are safe.
Oh, and it won't work on USB disks.
Mick
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
-
Adam Bower -
Mark Rogers -
Martin A. Brooks -
mick -
Wayne Stallwood