You can erase free space using Disk Utility. (/Applications/Utilities/Disk Utility.app
).
In the sidebar of Disk Utility, select “Macintosh HD” (or the drive where you’d originally stored the file). At the top of the window, select the “Erase” tab. Towards the lower left-hand corner of the window, there’s a button labelled Erase Free Space. This lets you overwrite all of the free space on the drive (which is where your deleted file currently resides). You can choose a one-pass, three-pass or seven-pass erase — hopefully that’s more than enough. And if not, I guess you can just do it multiple times.
As always with Disk Utility stuff, be a little careful. I did this a couple of years ago with a three-pass erase, something screwed up and I had to restore from a backup :(
If you have a USB Flash Drive of 8 GB of size, you can make a Lion Installer and use it to securely erase the Drive.
http://macintoshhowto.com/osx/how-to-make-an-os-x-lion-usb-thumb-drive.html
You can also make a USB Bootable Recovery Disk as explained here by Apple:
http://support.apple.com/kb/DL1433
Once you have done either you can hold down the OPTION
key while restarting your computer and booting from it.
When it loads up, it will give you a few different options, you will need to use the Disk Utility part and highlight your HD and choose the Erase Tab. Under the erase settings will be a security option when you can write the disk to 0 once or even multiple times.
There is a guide on it here:
https://discussions.apple.com/docs/DOC-3251
See the part where it says
How to Zero erase and install OS X
I hope that helps you out.
Updated
The guy at the bottom of this post:
http://forums.macrumors.com/showthread.php?t=1267158
points out a work around to securely erase the SSD drive in the MacBook Air through encryption.
This is what he says:
cmace127
I found a workaround.
Restart the computer and hold option to enter the setup screen. Go
into disk utility and select the drive. Erase the drive using "Mac OS
Extended (Case-sensitive, Journaled, Encrypted). Make a password for
the encryption, it doesn't matter what it is because you won't need
it. Hit "Erase". Now select the volume and the "Erase Free Space" and
"Security Options" buttons should no longer be grayed out. Click and
select your level of security and off you go. I presume "Erase Free
Space" and "Security Options" should do the same thing because you
just erased the drive so all space is considered free. This worked for
me so let me know if it helps.
Let me know if that's works, this should securely erase the drive since it will then be encrypted.
Also, in the future with Lion be sure to use FileVault 2 so that you don't have to worry about this again.
Best Answer
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):