How and Why to Enable FileVault Encryption on Your Mac

Posted by Jim Tanous on January 2, 2014
How to Enable FileVault

A reader recently emailed us asking about FileVault, Apple’s encryption scheme on Mac OS X. She wasn’t sure what it did, or if she should enable it on her new MacBook. The feature is by no means new, but the recent release of OS X Mavericks and the ever-increasing number of users new to the Apple platform warranted a fresh look at FileVault. So, exactly what is FileVault?

The Original FileVault

First, it’s important to clarify that the version of FileVault currently in use since OS X Lion is FileVault 2, which represents a significant change from the original FileVault, called “Legacy FileVault” by Apple. But before we explain FileVault 2, let’s talk about its predecessor.
FileVault was first introduced in 2003 as part of Mac OS X 10.3 Panther as an on-the-fly encryption scheme for protecting a user’s data. Once enabled, a user’s data was encrypted by the operating system within a sparse disk image (later operating systems utilized the more efficient sparse bundle disk images). While a user’s account password could unlock the FileVault encryption when logging into the Mac, the user would also need to create a “Master Password” in the event that the user account password was lost. While logged in, Legacy FileVault would decrypt and re-encrypt data as the user needed it, all on demand.
While certainly not required, the benefit of FileVault was that user data was protected from unauthorized users or thieves who lacked the necessary password. If your Mac was stolen, for example, FileVault-encrypted data would be very difficult for a thief to access. While less technologically savvy thieves under normal circumstances may be thwarted by a user account password, those with any experience would be easily able to pull the Mac’s hard drive, attach it to a second system, and enjoy unfettered access to the drive’s data. But if the user’s data was encrypted, it would generally be safe from those without the FileVault password.
But there were several issues with the Legacy FileVault. First, it only encrypted the user’s home folder. While most users maintain all of their important data inside their home folder, some may have files scattered throughout the Mac’s system drive, inadvertently or not. These files outside the home folder, which also include other user accounts on the Mac that haven’t enabled FileVault, would be totally unprotected in the event of theft or other unauthorized access.
There were also problems with the encryption method used by the first implementation of FileVault. The scheme utilized cipher-block chaining, or CBC, modes of encryption which, by the end of the original’s FileVault’s lifespan, could be reliably cracked by experienced hackers. Further, from a more user-centric perspective, the way that FileVault handled encryption of only the user home folder led to issues and annoyances with tasks like file sharing and automatic backups.
Make no mistake, Legacy FileVault offered relatively good protection for most users, and was certainly better than nothing when it came to protecting critical data of a personal or business nature. But there was certainly room for improvement and, like it does so often with its consumer products, Apple decided to change things significantly for the next version of FileVault.
Continued on page 2.

17 thoughts on “How and Why to Enable FileVault Encryption on Your Mac”

C says:
*Warning: I’m not currently tech involved enough to confirm the Apple rep was right or to have followed up about the whys and hows, but want to share a recent experience of losing all my HD content as a warning. My mid-2012 MacBook Air, running on Mountain Lion, crashed and after a hard reboot would only go to a reinstall screen. I tried everything, and was desperate to recover my data, and, working with Apple, was ultimately left with the only solution of wiping my hard disk and reinstalling the OS, without any data recovery. I was able to see the SSD using Disk Utility but there was no way to mount it to try to recover it or copy it elsewhere. I was told by the Apple rep at the Genius Bar, who confirmed it with a second colleague who was supposedly a “guru” in this, that this was happening and therefore there was no way to recover my data, even if I paid for very expensive data recovery services, because I had apparently turned on FireVault (I don’t remember this, and the laptop only offered me the reinstall and never asked me for a FireVault login/password as an alternative) and encrypted my data. The outcome: I had to take a deep breath, let go, and go ahead with the wipe and reinstall.
Phil Harris says:
I was multitasking when I was configuring FileVault2 and missed the page with the backup key, so I did not record it. If I disable FileVault and then reenable it will I get a new backup key?
beerbaron23 says:
I have to chime in that this is an excellent article, well balance on all ends including explanations, tech speak and to the point.
Michael Alderete says:
If you encrypt your system with File Vault 2, can you still use that machine in Target Disk Mode? How does that work?
michael says:
I turned on firevault and let it do its encryption, copied down the encryption key. The problem is that when I power off and power back on, I am not asked for the encryption key. What am i doing wrong?
Alana says:
There are two ways of gaining access: (1) through your admin (or other authorised) account with its password, or (2) with the recovery key. The latter is an emergency backup and not something you type in every time.
Teemu Leisti says:
An excellent article.
Ant says:
Do we trust Apple with backdoors and keys? 😛
sudon't says:
“Because the Mac will have to encrypt and decrypt data as the user calls for it, there will be a slight performance hit…”
Why would there a performance hit if when one “logs in with the correct password, the entire drive is unlocked”? If that is the case, the only place I can see a slowdown would be at boot and shutdown, not during normal computer use. Or is it the case that files are encrypted/decrypted on the fly, only when they are called?
This leaves me wondering what state your hard drive would be in if someone came along and yanked the cord out of the wall, (in the case of a desktop)? Would all your files be in an unlocked state, or just the open ones?
Nick Yasnov says:
I know, I’m a bit late to the party, but I could try give you the answer. If you’re already know the answer, this might be useful for other people reading the comments.
> Or is it the case that files are encrypted/decrypted on the fly, only when they are called?
> This leaves me wondering what state your hard drive would be in if someone came along and yanked the cord out of the wall, (in the case of a desktop)? Would all your files be in an unlocked state, or just the open ones?
Encryption is a slow task. In layman terms, the process consists of three steps: reading the file, encoding the file, writing the file. So if your disk has reading-writing speed about 100 MB/s (Megabytes/s), then a single 100 MB file will encode in roughly 3 seconds. If you have 1 TB disk, it will take about 9 hours to just encrypt the data. Then it will take 9 hours to decrypt it all back. So they surely aren’t being decrypeted as the user enters his password. Otherwise, the user will wait forever until he will boot. And then he will be forced to encrypt it again when he shuts down the computer. This isn’t user friendly. And it would be a pain in the ass to keep the data consistent if the encryption process will be interrupted.
What actually happens, is right after you encrypted all your data with FileVault, it is already stored in unreadable format. If someone will steal your disk and plug it to his PC, he won’t find anything useful, anything at all. Even with data recovery tools. The disk will be full of random bytes, white noise. While booting, the system will prompt a password to the data and will read and store keys for files unlocking in RAM after the correct password is entered. From this moment, if someone will gain access to RAM, he could steal the keys. That’s why it’s important to not install untrusted software. Before the user entered his password for the first time after booting, the data is fully protected.
So when any program tries to read the data from disk, these requests are actually passed through a special layer which reads the encrypted file from disk, decrypts it with keys stored in RAM, and gives the result to the program. So program doesn’t even suspect the file it tries to read is encrypted, it’s all transparent for user and a programmer, the decryption happens on the fly and the result is stored in RAM only. This will slow down the performance a bit because of the decryption overhead for each I/O operation. “The drive is unlocked” part means only that the keys are loaded into RAM to be used when a file will be read next time, not that all files are magically become decrypted (as it takes insane amount of time even on SSDs).
iOS have the similar protection system named Data Protection which behaves just like this. However, there are four security levels: None, Complete, Complete unless open, Complete until first authentication. Every program can use any level it wants when creating its own files. The most user data (messages, photos, email) is protected with Complete level by default since iOS 8, and user can’t turn it off. What these protection level mean?
On iOS, the whole disk is _always_ encrypted with AES-256 cipher which uses unique device key and user password. When the device is booted, all the files (except those that use None level) are protected and no way someone can read them. After the user entered his password, those files that use Complete until first authentication are unlocked. While device is locked, all files that use Complete level will be protected and no way someone can read them. After first authentication, the system loads keys needed for unlock files with corresponding level of protection. After user unlocks the device, additional keys, needed for unlocking files with Complete level of protection, are read into RAM and stored there until the device is locked again. So again, if someone gains access to the RAM, the data is compromised. But it’s not an easy task, and you need to install such software yourself, because it requires the device to be unlocked. So if someone steals your device, even if he bypass the password, he wouldn’t be able to read the data because this password is one of two keys needed to unlock the protection. If its entering is bypassed, it doesn’t even exist in the memory. This makes it easy to remote wipe the device. Just all the keys are deleted, and the encrypted files become useless to the thief. Data protections is so successful, that FBI tries to ask the US Government to force Apple to release the OS version that allows to just brute-force the password (there are limits after which the system slows down the password entering attempts), not even read the encrypted data, because the password isn’t stored anywhere and is needed to read the files.
Sander says:
Two questions:
1. Suppose I turn filevault 2 on and my mac dies but the harddisk is not to blame. When i connect the mac’s harddisk to another computer, can I still acces the data (e.g. after entering the master password)?
2. I use an application that mirrors my Mac’s harddisk on my NAS. Is filevault 2 likely to cause any issues? Will these files be encrypted too?
Veronica says:
Is there anyway to retrieve my photos from File Vault 1 from an external hard drive? I had my computer wiped because I could not remember my File Vault password from two years ago. I backed up all my family photos (40,000 photos) onto my external hard drive before wiping my computer, through Time Machine. I am so sad that I cannot access my photos on the external hard drive now. How can I access them?! Any suggestions?
TekRevue says:
Is the Time Machine backup encrypted, too? If not, and if the drive still works, you should be able to restore from that backup using Migration Assistant. As the Time Machine drive now contains the only potential copies of your photos, I’d recommend paying the Apple Store a visit so that they can help guide you through the process.
Veronica says:
The Time Machine backup is also encrypted 🙁
I was at the apple store when I wiped my mac. There was some miscommunication, and I thought that my external hard drive safely stored all my photos. I am praying for a miracle! I am going to go visit the apple store again tomorrow. Thank you for your suggestion and for responding so quickly!
vampyren says:
I know it wont help with your problem but I suggest you buy something like mSecure and save your passwords securely. It cost a bit but its priceless when you need to remember an important password. I have mSecure on my iphone, Mac and Android phone. It wasnt the cheapest solution or product but after several years those initial costs are meaningless. I have had so much use for this app that i cant be without it now. I save all my passwords for work, home, websites and much more in there. I wish you good luck at the Store …..
BruceWayne says:
Great article. Very helpful to a casual mac user such as me. Informative and readable. Very much appreciated.
Sam says:
I’m running Mountain Lion 10.8.5 on a MacBook Pro 13″. I have a FAT32 partition on my disk and don’t care if it gets encrypted or not. Will I run into problems enabling and using Filevault 2 on the main partition? I also use Parallels Desktop with Windows 7 & 8 virtual machines. Will these still work? I often use SuperDuper to create bootable USB backups. If my internal disk crashes, I can boot from an external USB backup drive and continue working until the internal drive is replaced and data is restored. Will my backup/restore scenario that I described above still work if I enable Filevault 2?
Paul Wasmund says:
Have you done any recovery testing on Mavericks? I have been testing fileVault encryption and recovery procedures recently and while the standard schemes using the recovery partition and commands such as diskutil cs revert and diskutil cs unlockVolume work as expected on Lion and Mountain Lion recovery volumes, the same is not true using a Mavericks recovery volume. For example, I unlock the recovery keychain and try to mount a fileVault volume using
diskutil cs unlockVolume lvUUID -recoverykeychain /path/to/recovery.keychain
This hangs on Mavericks even though the exact same command works on older recovery volumes. No error is given, the command just puts up its indefinite character passed progress bar, asks for permission to access the private key in the keychain which is granted and never does anything else.
Alan Goldberg says:
One of the things that put me off using FV1 was the performance hit that encryption made on video apps like iMovie.
Have you done any testing to see the performance of video capture if you are storing your data files to the encrypted drive with FV2?
greendrawer says:
Really not sure why “you’ll need to remember your user account password or recovery key”
qualifies as one of the reasons as to why Filevault 2 is “not perfect”. Especially as the “first and most important” reason as to why it’s not perfect (?)
TekRevue says:
“Not Perfect” means that new users will forever lose access to their data if they can’t remember an account password or recovery key. This is true with many encryption schemes (some use hardware keys like USB drives), but this article is targeted at new Mac or new FileVault users, and we were trying to stress the reality that data could be irrevocably lost without a password. A “perfect” scenario, which may not exist today, is one that protects user data without the risk of permanent loss (think future implementations based on fingerprints, DNA, etc.)
The reference to not needing a separate password is just pointing out that you only need an account password, as compared to third party solutions that are often set up with their own passwords (although I suppose a user of something like TrueCrypt could set their encryption password to match their account password).
Frederick D says:
Great article. Thank you for the history lesson on File Vault 2 as well. It is good background information. What I have been using as an additional layer of protection is the SecuriKey Pro USB token. This works with a standard Mac or a File Vault 2 protected Mac to add two-factor authentication. Without the USB token it is not possible to log into the Mac, nor unlock the File Vault 2 encryption.
It is very cool and easy to use.
fight.the.stupids says:
Any issues with using Target Mode on a Mac encrypted with Filevault 2? For example, if a person wanted to use Migration Assistant and the current Mac is using Filevault 2, are you just required to put in one of the usernames/passwords? Or are you required to enter a Master Password? How does that work? Thanks.
TekRevue says:
I haven’t looked at this exact scenario since Lion launched but, as I recall, a migration with Migration Assistant should work just fine with the correct user account password (if migrating FV2 to FV2) or correct master password (FV1 to FV2). There have been some reports of issues after migration (“unable to log in to the FileVault user account”) but you can solve this by deleting the user account, leaving the user data intact, and then recreating a new user with the same name to point to the existing data. See Apple Support Article TS4184 for more on this.
To verify this, I’ll enable FV2 on one of our MacBooks and do a test migration. I’ll report back if anything is different from my recollections. The data is encrypting now; should have results in a few hours.
TekRevue says:
Okay, so after testing it out, when you try to mount a FV2-protected Mac via Target Disk Mode, OS X will ask for an unlock password. This can be any password that was authorized to boot the Mac during FileVault setup. https://www.tekrevue.com/wp-content/uploads/2014/01/filevaultTDM.jpg
Once the password is entered, the drive mounts and acts the same as any other external drive. As for Migration Assistant, it doesn’t look like FV2 settings are transferred over, so you’ll need to do that manually after the migration. So it seems to go: TDM old Mac to new > unlock old Mac with any authorized password > copy data unencrypted to new Mac > reboot new Mac and reenable FV2.
fight.the.stupids says:
Thanks a lot for trying that out. Migration Assistant is a great feature and to be able still use it with FV2 is great.

Leave a Reply

Your email address will not be published. Required fields are marked *

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.