By Rinzwind


2011-01-12 19:38:31 8 Comments

I'm pretty new to SSD technology, so I don't know how it compares to hard drives when it comes to securely erasing the drive. Is it enough to run Disk Utility and erase the drive with the option "overwrite with zeroes", or is this designed for hard drives? Are there other actions that should be taken?

I'm not looking for NSA-grade security though, just the kind of wipe you'd do if you're returning or selling the Mac.

3 comments

@Gordon Davisson 2011-01-12 21:34:00

It depends on your paranoia level. Because of the way SSDs handle writing data, doing a zero-once on an SSD is not as good as doing so on a hard drive.

When you write a particular data page on an HD, the new data is simply written over the old data, replacing it. Write zeros over the whole disk and all the old data will be gone. SSDs, on the other hand, cannot simply overwrite individual pages. In order to replace the data on a page, the old data must first be erased, and SSDs cannot erase individual pages; they have to erase entire blocks consisting of many pages.

So what happens when you ask an SSD to overwrite, say, page #5, is that the SSD leaves the data on page #5 alone, but marks it as invalid, allocates another currently-blank page (say, #2305), writes the new data to page #2305, and makes a note that next time the OS asks for page #5 it should get #2305 instead. The original page #5 data sits there until some later time, when the drive needs more space, moves any remaining valid pages away from the block, and erases it. SSDs have more physical memory capacity than they expose to the computer, so they can juggle blocks like this for a while before actually having to erase anything (and when they do actually erase something, there's no good way to predict which blocks of leftover data will be chosen for erasure). See this AnandTech review for way more details (warning: it's fairly long, and the relevant stuff is spread around).

Net result: if you write zeros over the "whole" drive, you haven't actually overwritten all the old data. You have updated the controller's translation table so it'll never return any of the old data to the OS (those pages are all invalid). But if someone's hardcore enough to bypass the controller, they could get some of your data back.

Overwriting twice will probably work, but it depends on the controller's allocation strategy. Overwriting twice with random data (diskutil randomDisk 2 /dev/diskN) is a little more likely to work, but still not guaranteed. Both of these also have some bad side-effects: they uses some of the lifetime of the drive, and also increase the logical fragmentation on the SSD, decreasing its write performance.

Note that recent versions of OS X's graphical Disk Utility disable the secure erasure options on SSDs (for the reasons discussed above), but the command-line version still allows them. BTW, I have also seen several recommendations to securely erase SSDs by converting them to encrypted format, but this is (if anything) slightly less secure than overwriting with random data.

The best way to secure-erase an SSD is to invoke the controller's built-in secure-erase feature. This should (if the controller designers did their jobs) truly erase all blocks, and also have the side-effect of resetting the logical page map, essentially defragmenting it and restoring its original performance. Unfortunately, most of the utilities I've seen for doing this (e.g. CMRR's HDDErase) run under DOS, which won't boot on a Mac. I did find a posting on macrumors with (rather complex) instructions for doing a secure erase from a GParted boot CD. It might also be possible to use Parted Magic from a bootable flash drive, but I have not tried this.

Researchers at the Non-Volatile Systems Lab at UCSD have tested various ways of sanitizing SSDs by "erasing" the drive, then disassembling it to bypass the controller, and checking for remnant data (summary, full paper). Their results mostly agree with what I said above (and also show that the built-in secure-erase command isn't always implemented properly):

Our results lead to three conclusions: First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs.

@Rinzwind 2011-01-14 11:31:52

Thanks for the extensive answer. It's not a problem for me to run a Terminal command as you suggest. But for future reference: what can regular users who are not so comfortable with Terminal do? Simply use Disk Utility's 7-pass option?

@Gordon Davisson 2011-01-14 21:24:10

I don't know if I can really "recommend" any of the options at this point -- they all kinda suck. Any of the overwrite options will use up the drive's lifetime write limit, and tend to increase fragmentation and decrease performance. The best thing would be for Apple to add ATA-secure-erase (i.e. the controller-based option) as an option in Disk Utility, but who knows when/if that'll happen.

@Dolan Antenucci 2011-08-03 00:30:26

@Gordon - That was a great and informative response! +1

@samthebrand 2014-05-22 00:18:05

Hi @GordonDavisson. Curious if anything's changed since you wrote this answer (there have been a few OS updates since).

@Gordon Davisson 2014-05-22 04:56:17

@SamtheBrand: Not much has changed. I added a note that Disk Utility (GUI version) now disallows secure erase on SSDs (because it doesn't really work), fixed the link to HDDErase, and added a note that Parted Magic might work (though I haven't tried it).

@Scott Pack 2014-05-24 02:43:47

I'd be careful with this advice. There's enough good information in here to disguise the bad advice. No matter how many times you overwrite you can't trust the results since the drive controller hides the wear level transactions. The secure erase command is unreliable due to inconsistent, or non existent, implementation. The best choice is sufficiently early encryption and losing the key. The only guarantee is physical destruction.

@Rinzwind 2014-12-15 20:32:11

@GordonDavisson: I was wondering if your answer didn’t leave out a key sentence saying that an SSD drive is usually larger than the size the SSD controller gives out to the OS, which is why you can fill up the “whole” drive (as the OS sees it) with zeroes, while still not having filled up the “whole” drive (as the controller sees it). I was rereading your answer and realized you don't seem to explicitly say so, I think I originally picked that up from the AnandTech article (page 9, “Free Space to the Rescue”): anandtech.com/show/2738/9.

@Gordon Davisson 2014-12-16 05:26:26

@Rinzwind: You're right; I added a sentence making this point explicit.

@Lri 2013-05-09 18:02:30

The "Security Options..." button in Disk Utility is currently grayed out for SSDs. According to http://support.apple.com/kb/HT3680, erasing an SSD normally might be secure enough:

Note: With OS X Lion and an SSD drive, Secure Erase and Erasing Free Space are not available in Disk Utility. These options are not needed for an SSD drive because a standard erase makes it difficult to recover data from an SSD. For more security, consider turning on FileVault 2 encryption when you start using the SSD drive.

It is still possible to run something like diskutil secureErase freespace 4 disk0s2 from Terminal on the recovery partition.

Simply turning on FileVault 2 before erasing the drive is probably a better option though. According to this answer, performing a remote wipe also just erases the encryption key if FileVault 2 is enabled:

Yes, when you remotely wipe the computer it does a secure wipe. Apple even warns you that it could take as long as a day. However, if your drive was encrypted with FileVault 2, then it is not necessary to erase the disk. It is sufficient to securely erase the encryption key(s) stored on the disk, so that's what they do. It's very quick and as secure as the underlying encryption system is, which for now is very secure.

http://training.apple.com/pdf/wp_osx_security.pdf:

FileVault 2 provides IT departments with the ability to erase the encryption key from a given Mac at any time to ensure that encrypted data cannot be accessed by either user login or data recovery tools. This process is referred to as a remote wipe.

@Gordon Davisson 2013-09-08 15:48:59

Turning on encryption (i.e. FileVault) before storing sensitive data is an excellent option, but it occurs to me that the process used to "erase" the encryption key may not be fully secure for the same reason that a standard secure erase isn't -- the old encryption key will still be stored in the flash, just in a page that's mapped out. So someone who can bypass the controller could still get at the "erased" key...

@supersize 2016-09-28 12:57:02

@GordonDavisson but if you then enable encryption again when formatting the drive, the old encryption key should be overwritten hence the old data is securely not accessible?

@Gordon Davisson 2016-09-28 17:58:19

@supersize The old encryption key might be overwritten, but it depends on exactly which physical pages get erased during the reformat, and that's something the drive firmware controls, not the operating system.

@dan 2013-07-16 22:54:07

Open a terminal and type the following command:

df -k

Note the first column corresponding to the partition of the SSD you would like to irreversibly erase. Let's say it is /dev/disk1s2.

Type the following command:

dd if=/dev/zero of=/dev/rdisk1s2 bs=100k

where /dev/rdisk1s2 is the raw device associated with your partition on SSD. This command will completely write this partition from 1st block available to the last one. This command will last long (~1/2 h for 100 Gbytes) with no nice scroll bar of progress.

Once this command return you the prompt of your shell the disk has been completly and irreversibly erased. Start Disk Utility and check this partition. It will tell you it is dammaged beyond any form of repair. And it is right.

Just format this partition as you like.

Here is what is happening at the physical blocks level:film of dd & DU erasing an SSD

@Gordon Davisson 2013-09-08 15:44:21

This is equivalent to Disk Utility's option to overwrite with zeroes, and won't be fully secure on SSDs for the same reason. See my answer for the detailed explanation.

@dan 2013-09-09 20:49:20

→ Gordon: I read your answer, and I think I understood it, and I upvoted it for its quality. My answer is using the raw disk device and not the block one (as Disk Utility). This has to be verified on SSD (with trustable tools) but as far as I know on old standard HD using caches, the raw disk interface was the easy way to avoid this cache. An SSD device is simply an HD disk where the cache is the full capacity, and the physical disk is removed.

@Gordon Davisson 2013-09-10 02:23:20

Using the raw device (/dev/rdisk*) bypasses the OS caches, but does not bypass the flash translation layer (which is the source of the problem I described). In fact, there's no way to bypass it from the OS -- the device controller simply never exposes the true raw flash store to the bus (SATA or whatever), and since the OS can only interact with the drive over the bus, there's no way for it to get raw-enough access to do a secure overwrite.

@dan 2014-09-21 14:09:55

The first pas of dd is here not only to bypass some cache level (we don't have any way to know their capacity), but to exhaust them partially (this is the figure 3 state). The second pass will really have to find new blocks and securely erase them.

@Gordon Davisson 2014-09-21 14:42:54

That's still not enough, for two reasons: first, when Disk Utility formats the disk, it only overwrites a little bit of it (the partition table, volume headers, etc), and there's no guarantee that's enough to exhaust the extra capacity. Second, there's no guarantee at all that the extra writing DU does will hit different physical blocks than what dd erased earlier -- depending on the controller's allocation strategy, it's entirely possible you're just erasing the same physical blocks over & over. That's why I said that even overwriting all space twice might not be enough.

@David C. 2018-06-07 18:14:04

Writing all zeros will mark all of the non-zeroed physical pages as garbage. SSDs will eventually collect that garbage and erase the pages. But there is no way to know when such garbage collection may actually take place.

Related Questions

Sponsored Content

9 Answered Questions

[SOLVED] Is there a way to securely erase an SSD on my MacBook Air?

  • 2012-06-17 20:51:24
  • James
  • 46570 View
  • 29 Score
  • 9 Answer
  • Tags:   macbook-pro ssd

2 Answered Questions

[SOLVED] Securely erase deleted files?

1 Answered Questions

[SOLVED] How to securely erase Apple NVME SSD?

3 Answered Questions

[SOLVED] Why is a secure erase 'not necessary' for SSD's?

1 Answered Questions

1 Answered Questions

[SOLVED] Secure erase ssd with Snow leopard (10.6.8)

  • 2017-01-31 20:06:17
  • user294185
  • 438 View
  • 0 Score
  • 1 Answer
  • Tags:   security ssd

2 Answered Questions

3 Answered Questions

[SOLVED] How To Securely Erase Free Space Using Terminal?

3 Answered Questions

[SOLVED] FileVault security hole when used on SSDs

Sponsored Content