Securely erase internal SSD

Prior to giving away a MacBook Pro 17-inch Mid 2009 (El Capitan 10.11.6), I am planning to use FileVault to encrypt the internal SSD, then perform a standard erase to delete the FileVault key, as described here under “Cryptographic Erase”:

Anything special to be careful about?

Maybe I’m being overly anal here, but what about sections of the drive that didn’t get overwritten when you turned on encryption in FileVault? Wouldn’t those still be showing unscrambled/unencrypted leftovers that could in principle be read out by a malicious actor with access to the disk?

I realize for those people that start off by enabling FileVault this is not an issue. But if you have only recently turned on FileVault, as @davbro indicates, could this be a potential weakness? Would it makes sense to in addition run a secure erase on the portions of the drive that are considered “free” before you throw away the FV key? And would that even work properly considering SSDs and their wear leveling?

Thanks for mentioning that – I had the same question but forgot to put it into my original post.

If FileVault is able to complete its encryption of the drive, then the original plaintext versions of the files should not be available using the normal disk-block-access APIs. If Apple didn’t erase/overwrite those blocks, it would be a pretty lousy security protocol since any app could simply read through the device’s unallocated blocks to get the content.

But that only covers what you can access with software. A data recovery service that removes the flash chips or uses alternate firmware in the SSD controller might be able to access the “garbage” blocks of flash storage and these might contain data. This is the problem the MacObserver article is trying to solve.

As you may be aware, when you overwrite a logical block on an SSD, it doesn’t overwrite the corresponding physical block (the way it does on a hard drive). Instead, the physical block is marked as garbage and a new block is allocated for the new data.

At some unspecified point in the future (the specifics will depend on how the SSD controller firmware is implemented), the garbage will be “collected”. Without going into too much detail, the flash chips in SSDs erase data at a larger granularity than they can write data. So you might be able to write to individual 512-byte blocks (or maybe small collections of them), but you may only be able to erase large groups of physically-contiguous blocks (maybe several MB). During the garbage collection process, valid data is moved in order to create large blocks of contiguous storage that can be erased (either free or garbage blocks).

Garbage collection can be time consuming and it uses a lot of processor power in the SSD’s controller, so it is generally only done during idle periods or when required to complete requests (which usually kills performance). Which means that you have no way of knowing when the garbage blocks will actually get erased.

Furthermore, when you delete a file, its blocks may not get marked as garbage until they are overwritten (e.g. by a new file that is assigned the same logical blocks). If your SSD is using TRIM then this won’t be a problem - TRIM allows your system software to pro-actively tell the SSD controller that a deleted file’s blocks are garbage. This will make the data inaccessible to software, but the physical blocks won’t get erased until garbage collection can process them.

in other words, how much security do you require? If you only want to make the data inaccessible to software, then the encrypt-erase method will be more than sufficient. You could also just have software write zeros to every logical block, which will mark everything as garbage (and collect much of it).

If you need to protect against someone using data recovery forensics to bypass the SSD controller to read the garbage blocks, then there’s no way to be certain. If this matters to you, then you shouldn’t be giving away that SSD. If you can’t remove it from the Mac, then you may be out of luck.

Regarding the cryptographic erase mechanism, I question whether it is actually better than classical secure-erase mechanisms (writing random data followed by zeros to all blocks). I don’t think either mechanism is guaranteed to make data stored in garbage blocks inaccessible to someone directly accessing the flash chips.

The encryption process is going to overwrite every logical block, and if the drive is full of data, most of those blocks will be garbage collected. But the same thing will happen if you just write random data to the device two or three times. The result will probably be good enough, but you have no way to be 100% certain.

The only way to completely protect against direct access to the flash chips is to encrypt with FileVault from day-one, before you put your data on the SSD. Then you can be certain that your data never existed in plaintext on the device in any block. Discarding the key at that point will ensure it’s all inaccessible. But encrypting a drive full of data immediately prior to losing they key just seems to me like a computationally expensive version of writing random data to the device.


I have a similar question on a nonworking Mac. My wife’s old 2011 iMac’s power supply went. It doesn’t turn on. I could pay $275 to fix the power supply which is more than the machine is worth just to reformat the drive. But I’m not sure I want it tossed without making sure the dish is wiped. After all, it has financial and logging information on it. And bring an old machine, I doubt the drive is encrypted.

I am just a normal user, with both business and personal files that I want to keep out of the hands of hackers, identity thieves, etc.

After Googling around I found this statement by chown33, a MacRumors discussion forum moderator, reassuring – if, of course, it is true:

“FileVault’s Full Disk Encryption doesn’t encrypt just files. It encrypts the blocks that the file data is stored in. When you turn on FileVault, the OS starts encrypting the blocks that make up the volume. This includes header blocks, directory blocks, the blocks where file data is stored, and even unused blocks that have no file data in them.”

Your thoughts?

I believe with an SSD/flash storage one issue may be that the disk has a large collection of spare blocks and, because of wear leveling done by the disk firmware, some spare storage blocks are put into service with a disk write and the existing blocks are marked as spare by the drive, but they are not accessible to the computer’s disk controller. Those blocks will eventually be put back into service in the future. So, the issue may be that running FileVault will not touch those spared blocks, so they will potentially have unencrypted old data in them if FileVault is done very recently.

(I could be mistaken about this however.)

1 Like

In the MacRumors discussion I quoted, chown33 continues:

"Until the encryption is complete, some data may still be at risk, because some blocks haven’t been encrypted yet. This is why it’s important to let the encryption finish.

Once encryption has finished, every block on the disk is encrypted."

Again, this may not be correct, but otherwise “every block on the disk” seems to be pretty categorical, no?

100% correct…which is why all users should enable FileVault…Apple should make the default that it is enabled and offer the save to iCloud or write the recovery key down as part of initial setup…that way the user has to turn it off.

That is how FileVault 2 works (and how most modern disk encryption software works). The disk blocks are encrypted and the OS’s file system runs over that. (This is different from the orginal FileVault, which replaced your home directory with an encrypted disk image that is mounted when you log in.)

This, however, doesn’t change the fact that garbage blocks of flash storage may have old data until they are collected. Nothing software-based (including FileVault) can affect garbage flash blocks. Only the SSD controller’s firmware can affect that.

Yes. But we’re talking about the logical blocks that are accessible via software. Not the physical blocks of flash storage that these logical blocks are mapped onto.

Someone bypassing the normal SATA/NVMe interface and directly reading the flash chips (maybe using modified SSD controller firmware) can also read the physical blocks that are not assigned to any logical blocks. Any physical blocks that contain non-collected garbage might contain data from deleted/overwritten files.

One bit of good news for Apple users is that Macs with T2 chips have hardware encryption built-in. If you try to read the raw flash chips without the paired T2 chip, you’ll get garbage.

I assume (hopefully correctly) that Apple has hardened the T2 to prevent installation of a hacked BridgeOS, since such a hack would also violate the secure enclave where all kinds of secure data is stored.

So if you’re on a Mac with a T2 (or an M1), then making the data inaccessible to software should be sufficient.

If your Mac is old enough that there is no T2, then the SSD should be replaceable. If you’re worried about low-level forensics, you can replace your SSD with a new one and physically destroy the old one.


Not quite. Several older MBPs (≥ 2016 IIRC) don’t have a T2 (≥ 2018), yet they already came with soldered SSDs. Same I believe for the 12" Retina MB. In those cases, assuming you can’t boot the Mac, you’re left taking a drill to the flash chips. :wink:

1 Like

I’m not sure I need to protect myself against data recovery forensics or not.

What levels of expertise and expense are required to employ them?

Are they something only government intelligence agencies, etc., i.e., not most ordinary criminals, are likely to be able to afford, or at least have the desire and dedication to use?

This really boils down to a personal question IMHO. Only you know what risk you are comfortable taking. Personally, I would not be to concerned about myself. I’m 100% certain a state sponsored actor or an entity with serious financial resources could read out my flash storage if they were really determined. I assume, however, that I personally am just not interesting enough to warrant such resources. Of course if you’re a prominent dissident or somebody who works with classified information, that balance could certainly tip the other way. For myself, I’m assuming if I mechanically damage the flash (or platters of spinning rust) that will rule out pretty much any regular criminal from easily being able to spy on my information.

This is something that can’t be done casually. If you’re just trying to make sure the new owner doesn’t run an “unerase” utility or some other kind of recovery software, then what you’re doing will work just fine.

Directly reading the chips may be possible by a data recovery company, but they will charge a lot of money for the service. And I’m sure there are government agencies that can do it as well. But I doubt anyone will go through the time and expense unless there is something specific (and valuable) for them to go after. It’s just too much work to get data like credit card numbers, which they can steal from somebody else much more easily.

But you’re in luck. Since you’re dealing with a fairly old Mac (a 2009 model), your SSD is a 2.5" SATA device. If you’re concerned about someone trying to recover erased data from it, just remove the SSD (and maybe replace it with a new one if you want to be nice to the next owner).

You can get a good 256GB SSD for $50 (Crucial MX500). And the replacement procedure isn’t too difficult if you’re careful (iFixit instructions).

Without saying too much detail…I used to be in the government Intel business…and the only way to ensure no recovery is physical destruction. Even with multi pass random data written to a drive…electron microscopy can sometimes recover things…but it is expensive…hundreds of thousands of dollars…and is never 100% that I’m aware of. When we had broken drives…we took them in a party of 2 people with loaded .45 pistols out to a local foundry and watched them melt and pour the crucible out so we could verify there was nothing less. And that was with 1990 level tech…I’m sure t(e state of t(e art has advanced since then. 3 letter agencies have sufficient supercomputer horsepower to brute force a lot of even encrypted data…and again that was 30 years back.

When I have dead drives…the platters get taken out, bent all up with a hammer, and then left out in t(e rain for a couple months before going into the trash. I eneable FileVault out of the box on internal soldered SSDs and then would erase them to kill the encryption key before letting them out of my possession…but then I’m paranoid from having been in that arena.

Most normal criminals don’t have enough money or supercomputers to do t(e job…but then 30 years later maybe they do…but you have to be enough of a target to make the investment worthwhile.

1 Like

I’m curious about this subject. I wonder if someone can confirm or refute my suppositions.

It seems to me that even if someone had the resources, technology and motivation to try to extract whatever was left of a device treated this way, all he would get would be random blocks. No files, just blocks. Reassembling files would be like patching together shredded documents. Shredded documents in which many, if not most of the shreds — at random — have been burned.

That doesn’t rule out the possibility that some isolated block contains sensitive text like, “Bailey Building and Loan online password: pw123”.

It seems like it would be an awful lot of effort, unless the attacker knows there is a likelihood of some very, very valuable data.

(Of course passwords should be stored only in Keychain or another password manager, and should never occur in plaintext, regardless of the Filevault status of your device. If you do have passwords in plaintext, they should be changed ASAP.)

1 Like

I am aware of government paranoia in this area, and it might even be justified, but to my knowledge, nobody has ever actually extracted viable data. Researchers have found magnetic after-images on hard drive platters, but I’ve never read about anyone actually managing to extract a file.

Unless you are managing government secrets, I wouldn’t worry about this.

Yes, but it really depends on the nature of the data.

If I have a Microsoft Office document, which is a compressed zip file, it may be pretty hard to put all the blocks in the correct order (especially if some have been wiped due to garbage collection).

On the other hand, if I’ve got a plain text file (as are many of my documents), then there’s valid data in even a single block and if I find multiple blocks, it may not be too hard to figure out how to put them together.

Of course, any file or file system that is encrypted pretty much eliminates this possibility. The goal of any good cryptographic system is to make encrypted data look like random noise to anyone without the key.

I have no firsthand knowledge…but folks I worked with said they had such…and agreed that it was hard and expensive…and mostly gave fragmentary data anyway. But 30 odd years later…it might not need to be a nation to have sufficient computer resources to do so…but still not cheap so the expected payoff would have to justify the price. Most of us just aren’t that interesting.