I just woke up to the fact that it looks like user data can be leaked when using FileVault and Migration Assistant on an SSD on a new Mac when following the default prompts.

When I set up a new Mac, it encourages me to "Transfer Information to This Mac" early in the process, before I'm allowed to enable FileVault. This is OK on an HDD because even though I'm copying my data to the new Mac in the clear, FileVault will eventually overwrite all of it with encryption.

On an SSD, however, it's impossible to overwrite data securely:

... the Mac's "Secure Erase Trash" function leaves 2/3rds of a file recoverable.

Mac fail: SSD security

... it is almost impossible to securely delete an individual file on an SSD, because the way that SSDs write and delete files is scattered, and a user has no control over what an SSD is doing where. If that's the kind of security you're looking for, your best bet is encryption ...

Ask Ars: How can I securely erase the data from my SSD drive?

So by the time I'm allowed to enable FileVault, it's too late. Even worse, I can't securely wipe the drive before selling the computer later:

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.

Mac OS X: About Disk Utility's erase free space feature (support.apple.com/kb/HT3680)

So it looks like the solution is:

  1. Skip the Migration Assistant when prompted.
  2. Create a new user account.
  3. Run Software Update to completion to generate more entropy before enabling FileVault in order to mitigate this "worst-case scenario, in which the PRNG has only been seeded with the least amount of entropy" — Infiltrate the Vault: Security Analysis and Decryption of Lion Full Disk Encryption (eprint.iacr.org/2012/374.pdf), page 9.
  4. Enable FileVault.
  5. Run the Migration Assistant.

I'm assuming that even though FileVault is still encrypting the disk before I run Migration Assistant (my computer tells me it has 36 minutes of encryption time remaining) that all new writes made by Migration Assistant will be encrypted and thus my data will never touch the NANDs in the clear.

Do you agree with the problem and my solution?

  • Are you sure that the manner in which Apple securely emptied trash in early 2011 (Snow Leopard was the latest OS X) is how they do it now? Also, are you sure when the SSD is deleted using other means than securely emptying trash the underlying mechanism is the same?
    – dwightk
    Feb 28 '14 at 16:14
  • 2
    Anyone who has physical control of a computer will ultimately be able to recover some data from it - it's simply a question of how much effort and time would be required in order to recover how much data. That said, if you're worried about any data ever being "in the clear," then yes, I agree with your solution - I'd let FV finish and then migrate or manually copy.
    – da4
    Feb 28 '14 at 16:29
  • 2
    @da4 Do you doubt the FileVault implementation? The underlying encryption? Or users using it properly? As to the OP, I think your strategy is reasonable. I'd also hold off on FV for a bit (maybe until updates are applied, etc.) on a brand-new system to give entropy a chance to build and make the key stronger.
    – zigg
    Feb 28 '14 at 18:17
  • 1
    @zigg Your speculation is spot on! See page 9 of eprint.iacr.org/2012/374.pdf: "For highly security-critical scenarios, the PRNG should be reseeded by manually writing entropy to /dev/random before activation of FileVault 2." Feb 28 '14 at 21:22
  • 1
    I would also skip the original encryption prompt and enable FileVault after the machine is configured. Then transfer your data over to the newly encrypted drive. As far as when you want to sell the computer later, you can just format the drive using disk utility and then install a fresh copy of the OS on the drive. Even though you can't securely erase files on an SSD the same, if you format the encrypted partition when you sell it, all of your files would still be encrypted and inaccessible to the new owner.
    – user125447
    May 25 '15 at 8:30

Your making a test user account with a short name different than the eventual user to be migrated is sound.

In practice, you will in time over write more and more of the data, but if you have the time to first establish a file vault key and have the drive completely encrypted before copying any sensitive data, you have a more secure system and can know that the data can be sanitized cryptographically as opposed to being over-written or actually erased.

You'll want to look for these lines in the diskutil cs list output to know it's ready for the start of data migration:

|       Conversion Status:       Complete
|       High Level Queries:      Fully Secure
|       |                        Passphrase Required

Encryption After Transfer: Lowest Risk

While you run the Migration Assistant, there is no additional security risk imposed by the encryption beginning after data transfer commences. In fact, this reduces the physical security risk through the following mechanism:

  • The longer the device is unencrypted, the longer it is susceptible to physical security threats (theft, James Bond), thus the greater the risk.
  • The longer it takes to transfer the data, the longer the device will be unencrypted. Thus it follows logically, that the longer it takes to transfer the data, the greater the risk.
  • The full-disk encryption process takes a while. It takes even longer if you are writing data at the same time due to i/o limits and CPU capability, unless you have a supercomputer.
  • The data transfer process takes a while. It takes longer if it is writing to an encrypted disk; and even a minor difference could be statistically significant in a threat and risk assessment.
  • Therefore, the faster the disk gets encrypted, the lower the risk; and the faster the data gets transfered, the lower the risk.
  • And therefore, the lowest security risk is offered by the current procedure: transfer the data first, then encrypt the disk.
  • This procedure presents lower risk than any procedure that would take more time, especially because as long as the computer is on and the encryption secrets are stored in active memory, the computer is wholly susceptible to a sophisticated threat agent.

Secure Erase Unnecessary with Full-Disk Encyption

Secure Erase provides no benefit when used on an SSD with full-disk encryption, because of how data is stored. But any potential benefit from using Secure Erase on any disk with full-disk encryption, could never be very large because no data would be retrievable without the encryption secrets. If the secrets are obtained by a threat agent, then the whole disk has been compromised.

Without full-disk encryption, files can be recovered from an SSD, sometimes, by a sophisticated theat agent, and not a script kiddie, at least not today. This is different from HDDs where for the past decade script kiddies and five year olds have had the tools readily at their disposal to easily recover deleted data from unencrypted HDDs.

  • 1
    Your "Encryption After Transfer" analysis appears correct for HDD but not SSD. The article about the failure of Secure Erase is to highlight the new limitation of SSD; it's not about combining it with full-disk encryption. My concern isn't about whether or not to use full-disk encryption (I use it) but that cleartext is leaked depending on when the encryption is turned on. Mar 10 '14 at 13:59

Here's a secure way to prevent unencrypted data from being written to the SSD: install your system and migrate onto a separate drive, being a USB hard drive, second SSD, etc. Once FileVault is enabled and unencrypted data is wiped, then image the drive over to your SSD. Now wipe the original drive.

A less secure but easy way is to manually trim the SSD using fsck. This will make the unused space appear to be all zeros to anybody reading the data out from the OS. They would have to either tamper with the drive firmware or remove the flash from the drive to get around this. Eventually, with use all the data on the drive will be overwritten.

To answer your second concern, the manufacturer provided secure wipe utility/boot disk will ensure all your SSD data is erased, either by commanding all the flash to be physically erased, or by destroying always-on encryption keys (iPhone style).

  • Thank you for your creative suggestions. I'm getting to the point where all of my drives are SSD, so using a separate drive doesn't help; I am concerned about the case of someone removing the flash from the device; do you know of a manufacturer provided utility for the drives sold by Apple? Mar 10 '14 at 13:55

You must log in to answer this question.

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