18

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?

  • Sidenote from my own experience: speaking strictly in terms of technical expertise, Linc Davis is without a doubt the most knowledgable member of the ASC. He can be rude and abrasive, but I've contributed to those forums for years and can say, without exaggeration, I've never seen him supply incorrect information - at this point, I take his answers as reliable source material. – njboot Sep 24 '14 at 4:26
  • I thought I read somewhere that those options disappear if you have an SSD and filevault enabled. Do you? – Harv Sep 24 '14 at 9:32
  • @njboot Agreed, Linc seems very knowledgeable, but I'd still like to see something more concrete. – Bill Sep 24 '14 at 11:05
  • @Harv No, I didn't have FileVault on. – Bill Sep 24 '14 at 11:05
15

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.

  • Your Terminal command solution is still relevant with High Sierra. Running from the installer, no "sudo" is required. — It's just what I needed! – ElmerCat Jan 29 '18 at 22:37
  • From man diskutil: " NOTE: This kind of secure erase is no longer considered safe.". I tried and the HD's free space was growing, this is suspicious. – gagarine Jan 28 at 18:15
5

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.

  • 1
    Unfortunately, as I mentioned, my SSD is just over four years old. So outdated articles might apply to me. And (also unfortunately) I already used the Erase tool in Disk Utility, so it's too late for me to delete the files and let TRIM work. – Bill Sep 24 '14 at 11:06
  • I ran into a lot of articles about ATA Secure Erase, but there doesn't seem to be a straightforward way to do perform one on a Mac. – Bill Sep 24 '14 at 11:07
  • If you have already wiped a drive that is not encrypted - your options are limited because if you tell the SSD to zero the drive - it will just ignore you. So I am filling up the drive with movies - I will then encrypt it (file vault) and then wipe it. – niico Jun 7 '16 at 9:18
  • 1
    @niico -- I believe you should be able to use the command line disk utility to zero the drive, which it should do by writing a series of temp files to the drive to fill it all up: sudo diskutil secureErase freespace 0 "/Volumes/[Disk Name]" – TheMadDeveloper Dec 28 '16 at 5:38
2

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.

0

man diskutil

secureErase

Erase, using a "secure" (but see the NOTE below) method, either a whole-disk (including all of its partitions if partitioned), or, only the free space (not in use for files) on a currently-mounted volume. Secure erasing makes it harder to recover data using "file recovery" software.

...

This kind of secure erase is no longer considered safe. Modern devices have wear-leveling, block-sparing, and possibly-persistent cache hardware, which cannot be completely erased by these commands. The modern solution for quickly and securely erasing your data is encryption. Strongly-encrypted data can be instantly “erased” by destroying (or losing) the key (password), because this renders your data irretrievable in practical terms. Consider using APFS encryption (FileVault).

Source:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .