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

I'm about to trade in a 2010 MacBook Pro with an SSD. However, I'm unable to do a Secure Erase from the recovery disk (as I used to do with mechanical hard drives before selling or giving away a computer) since the "Security Options" button is grayed out.

Based on an article in Apple's knowledge base, the button is intentionally disabled for SSD's because:

Note: With 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.

This sounds good to me, and this view was confirmed both at the Genius Bar and by calling Apple.

The problem is that almost every article I can find on this subject contradicts Apple's optimistic view about erasing an SSD. Because SSD's dynamically remap blocks on write and because they have large chunks of free space inaccessible to the OS, it's impossible to overwrite the entire drive.

The single explanation that could reconcile these two perspectives is that MacBook SSD's are "self-encrypting", i.e. they generate a random key and store it in the disk's metadata and encrypt all data stored to the drive with that key (additional explanation here). When I use Disk Utility's Erase button on an SSD, the Mac clears out that key, so even though the data hasn't been overwritten, it's all inaccessible ciphertext now that the key is gone, and is as good as zeroed-out.

The problem is that all I can find to back this view up is a post by a knowledgeable member of the Apple Support Forums. Does anyone know if this is really true? Could you point me to something verifying that Apple's SSD's do this?

Solution 1:

Not so much that it's not necessary...

I'm a couple years late to the party, but it might be worth pointing out that Apple (who has now entirely remove "Secure Erase" options from the Disk Utility app) hasn't really removed the option because it "isn't necessary" — according to its El Capitan security release notes, they did it because they can't guarantee a secure erase:

Description: An issue existed in guaranteeing secure deletion of Trash files on some systems, such as those with flash storage. This issue was addressed by removing the “Secure Empty Trash” option.

Glenn Fleishman, gives a good overview of this in "How to replace El Capitan's missing Secure Empty Trash." The fact that, currently, the only DoD/NSA approved SSD sanitation procedure is smelting or shredding the drive into a fine powder somewhat echoes the challenge in being able to wipe a drive, for sure.

It is pretty difficult to recover data from an SSD...

As Trane Francks explained, recovering data from an SSD is, by default, pretty difficult. The data isn't necessarily encrypted, but it is distributed data over many locations in order to perform as few writes as possible to a single location (both for performance and for drive longevity). So once data is deleted, find the place a file used to reside in is like putting together a multi-million piece jigsaw puzzle (all before any garbage collecting the drive may decide to do). It is possible to recover files from an SSD, but this usually requires a lot of extra effort.

To make it hard for recovery tools...

Encrypting a SSD with any kind of suitably secure key, and then erasing that key, makes it virtually impossible to recover any data. This can be done, on a Mac, by enabling FileVault, booting into recovery mode, unlocking and then deleting the drive with Disk Utility.

If you're just looking to make sure stuff is securely erased without nuking existing data, you could try using the diskutil terminal command — the command line version of DiskUtility, wherein secure erase options have not been removed:

sudo diskutil secureErase freespace 0 "/Volumes/[Disk Name]"

This should attempt to write and delete a couple tempfiles which will fill up the entire hard drive. In doing so, every available space should be filled and then cleared.

Good information on all these options can be found in "How to Securely Erase a Mac SSD".

Also, you can always try to run some data recovery tools to see if there is data that is still immediately available.

Solution 2:

The problem that I see with "almost every article" is that they're 3-4 years old. Some of them even mention attempting degaussing the drives as a means of clearing out data. That implies a lack of understanding of how Flash storage works in the first place. Seriously. Degaussing?

"ATA Secure Erase" is a means of telling the drive to zero out all the blocks. As well, simply mounting an SSD and deleting all the files with TRIM enabled will cause all the pages to be zeroed on any block that contained data. Of course, that assumes that TRIM has been correctly implemented. Usually, TRIM erase commands are completed by an SSD controller in a few minutes.

http://en.wikipedia.org/wiki/Write_amplification

http://en.wikipedia.org/wiki/Data_remanence#Data_on_solid-state_drives

It's worth noting that this business of recovering data from erased SSDs is not possible by your garden-variety hackers. The techniques the white papers generally describe involve disemboweling the drives and examining individual memory components.

From a consumer-grade perspective, it should be more than sufficient to boot to your recovery partition, delete the primary data partition, repartition the volume and format. It's hard to imagine anybody buying a used MacBook and hunting for data. If you really want to go the distance, you can encrypt your drive with FileVault prior to removing the partitions. At that point, even if a would-be cracker were to hack apart the drive to hunt for data, anything they found would be encrypted anyway.

I just don't consider that to be likely. If you really cannot take the chance, then purchase a replacement HDD and trade it in keeping the SSD.

I also agree with njboot: Linc knows his stuff.

Solution 3:

The correct answer of course is that instead of "secure erase for ssds" there should be a feature called "replace ssds hardware encryption key".

Then, once the SSD where user did not use separate encryption goes into read-only state, you can send the command to replace the key.

For performance oriented use it would also be preferable that bitlocker would have option to use only the hardware level encryption if support is present. Depending on the config (ultrabook vs desktop) there might be some perf and power saving features. Eg. if you have ultrabook running at TDP cap like Surface, then run some VM's in it, there could be some battery waste from doing encryption twice. Hard to say if it's significant or not without actual measurements but I have measured on desktop that bitlocker does affect ssd perf a bit so it's expected theres some impact.

Also since I separately encrypt the VM's, the system actually has 4 layers of encryption : ssd internal, host bitlocker, vm guest bitlocker and finally folder encryption. The VM are synchronized to external USB SSD so if the laptop or your bag is taken/lost during travel then it's likely that you atleast have one these so you can just buy another ssd or laptop and resume work as if nothing happened. Changes are differentially uploaded to cloud backup. The reason for not solely using cloud storage is that some work can require a lot of local assets available with low latency such as game development for example or studio work.