How FileVault Should Work
We’ve been uniformly negative about FileVault, the new security feature that Apple added to Mac OS X 10.3 Panther, but that doesn’t mean we dislike the idea of protecting sensitive data. The problem is that Apple chose an overly simplistic approach that may be easy to use and understand but ends up making users more vulnerable to other problems.
FileVault Basics — Conceptually, FileVault is easy to understand, since it makes use of a variety of existing Mac OS X technologies. When you turn on FileVault, Mac OS X creates a special type of disk image and stores your entire Home folder inside. The disk image is unusual in two ways: it’s encrypted with AES 128-bit encryption and it’s a "sparse image," which means that it takes up only as much as space on disk as the data it contains. During setup, copying all your data to the encrypted disk image can take some time: with the 6.6 GB Home folder on my 12-inch PowerBook G4, it took 73 minutes to set up.
By the way, pay attention to FileVault’s dire warnings about remembering your password. Apart from the master password you can set up when turning on FileVault, there are no back doors into FileVault, so you’re out of luck if you don’t have a backup. (This is of course a good thing: a security feature with a back door is worthless.)
Once FileVault is set up and working, you should notice it in only two ways. First, if you like to login automatically, FileVault turns that setting off (which makes sense from a security point of view), although you can turn automatic login back on. Second, for some applications, particularly on slower Macs, disk-related activities may be slower.
Should your Mac be stolen, the miscreant won’t be able to access anything in your FileVault-protected Home folder, assuming, of course, that your account wasn’t logged in when the computer is stolen and that your password was sufficiently secret and difficult to guess. It’s worth noting that when you’re logged in and can access your data, it’s also accessible to anyone who could learn your username and password and break into your computer remotely, or to hypothetical malicious or just poorly written programs.
There is one caveat to FileVault’s security: it doesn’t securely erase the original files that it adds to its encrypted disk image, so take this into account if you’re worried about a thief using a disk editor to recover deleted data from a stolen Mac.
FileVault Problems — Although FileVault sounds good in theory, it suffers from some serious design flaws. The most serious is that it’s an all-or-nothing protection of your Home folder, and only your Home folder. Of course, your Home folder is where all your data is (at least for most people), but just because data is in your Home folder doesn’t mean you need to protect it from prying eyes. And more to the point, there’s usually no need to waste disk space, CPU power, and time (entering passwords) protecting the very largest pieces of data: movies, music, and photos.
For instance, my Home folder is nearly 40 GB in size. Of that, my Movies folder contains about 2.4 GB, my Pictures folder holds 13.4 GB, and another folder stores 7.7 GB of Web logs. My Music folder has only 1.3 GB of files in it, but if I stored my iTunes Music folder on my Mac rather than on a server, that would be another 17.7 GB of data. So right off the bat, 24.8 GB of the 40 GB of data in my Home folder needs no protection at all. But there’s no way to tell FileVault to ignore all those folders.
Putting unnecessary data into FileVault has three negative implications. First, there’s added overhead in dealing with files that don’t need to be encrypted. Maybe the performance hit is noticeable in a given situation, maybe not, but there’s no reason to waste CPU cycles encrypting and decrypting files that aren’t sensitive. Second, and this is the real reason I don’t use FileVault, a disk image is a single file, and if your hard drive suffers physical or logical damage to the sectors that contain the FileVault disk image, you could lose the entire thing. No one should be surprised by that fact – it’s no different than losing any other file when a disk becomes corrupt. But there is a huge difference between losing a single file and losing every piece of your user data. Third, let’s say that you try FileVault and decide you don’t want to continue using it, so you turn it off. FileVault must then copy all your data out of the disk image and back to your Home folder, deleting the disk image file when it’s done. If your Home folder is too large, you must delete some files to free up enough disk space for both copies.
Put bluntly, you know those warnings about putting all your eggs in one basket? FileVault is that basket.
Along with the flaw of being too broad in the scope of what it protects, FileVault also increases your risk of data loss from unrelated events. Because FileVault stores your data in a disk image, it needs to write data to the image gracefully on logout. In the event that you should experience a kernel panic, system freeze, filesystem-corrupting bug, or even a power outage, the chance of losing data increases with FileVault. That’s because the encryption layer adds complexity to recovering from improperly closed files, as does the fact that the FileVault disk image is itself a file that could be corrupted. Although Mac OS X is usually quite stable, in the real world, it can still crash in ugly ways at times.
In fact, while I was testing FileVault on my PowerBook for this article, I installed some updates via Software Update and when prompted, rebooted. FileVault told me my Home folder was using more space than necessary and said it could recover the extra space. But before I could click a button, the Mac kernel panicked. I restarted, and it came back up fine, but it continued to kernel panic on every reboot. Needless to say, I turned off FileVault, which took another 28 minutes.
Even when Mac OS X remains stable, power outages can cause data loss. Not everyone has a laptop (which would switch to battery instantly in the event of a power failure) or an uninterruptible power supply (UPS), though I personally consider a UPS essential equipment. Over the years I’ve amassed a UPS collection that lets me protect every desktop Mac we own, along with our TiVo.
Lastly, as much as I hope it’s clear that using FileVault increases the need for a solid backup strategy, FileVault itself makes backing up a little more difficult. Backup applications must have access to the encrypted files, which means you must be logged in during the backup. For personal backup applications, that’s probably a good assumption, but it’s less true when backing up networked Macs via Retrospect Client, which can happen when no user is logged in. In situations like that, Retrospect can’t access the files and won’t back them up; at least Retrospect 6.0 knows to ignore the FileVault sparse image files by default, since backing them up would be a huge waste of backup media. Having multiple users with FileVault turned on also complicates matters, since only logged-in users can have their files backed up.
For Serious Security — Although I don’t doubt the security of the encrypted disk image that FileVault uses, I don’t think that people with truly sensitive data should rely on FileVault, for the simple reason that it lacks the paranoid mindset that’s necessary for the highest levels of security. That’s why the PGPdisk feature in PGP 8.0, which also offers encrypted disk images for storing sensitive data, is a better solution in such cases. Some of the added security features in PGPdisk include:
The option to re-encrypt all the data on a PGP disk, enabling you to change your underlying encryption key (if you believe it has been compromised) or to switch to a different encryption algorithm.
An inactivity timer that can automatically dismount PGPdisks after your Mac has been idle for some amount of time. The inactivity timer lessens the likelihood that someone could steal a computer and be able to access a mounted PGPdisk.
Support for multiple users, such that multiple people can have their own passphrases for the same PGPdisk. Although using additional passphrases conceivably increases the vulnerability of the PGPdisk, it’s probably better than having a single passphrase traded around.
The capability to change the passphrases easily.
Protection of the passphrase in RAM by erasing it immediately after use (the passphrase is actually turned into a key), preventing passphrases from being written to disk due to virtual memory swapping, and protection against the derived key staying in RAM long enough to build up a static charge that can apparently be read by equipment owned by major governments.
In short, if you need the utmost in security, you should use PGP over FileVault.
Rethinking FileVault — Despite this condemnation of how Apple chose to implement FileVault and the concern that it’s not spook-level security, I think the idea of FileVault is an excellent one, so I offer this simple suggestion of how it could be improved.
Instead of making FileVault an all-or-nothing deal that takes over the user’s Home folder, let it apply to any given folder. You could Control- or right-click the folder to choose Protect with FileVault for a selected folder. Not knowing exactly what happens behind the scenes, I don’t know if it would make more sense to have a single FileVault sparse image file to which each protected folder would be added or if creating a new sparse image file for each protected folder would be easier. The latter approach might allow different passwords, which could be useful in certain situations where you protect some folders with a simple password that you don’t mind if your colleagues or family members know (but which a thief wouldn’t) and other folders with a totally private password that only you know and could enter when you accessed the associated folder.
Allowing users to specify exactly which folders should be protected by FileVault not only eliminates or reduces the severity of most the problems outlined previously, it gives users necessary flexibility. For instance, as much as the Pictures and Movies folders probably don’t contain anything particularly sensitive for most people, I’m sure there are plenty of people with photo or movie collections that they’d prefer stayed private. Others may wish to protect only a Quicken data folder, or data related to sensitive work projects.
The real question I have is just how hard making this change actually is. Could a savvy independent developer use FileVault’s underlying technologies and provide the top-level interface via a simple contextual menu plug-in? After all, you can use Disk Utility to create encrypted sparse image files, and it’s trivial to add disk images to the Startup Items list so they are mounted automatically at login, after which an alias or symbolic link to the encrypted version could replace the original folder. It sounds good in theory, and since you can perform all the necessary actions manually today, it would seem a relatively easy task to wrap into a contextual menu command. If anyone implements my idea, be sure to let me know, and in the meantime, I’d encourage anyone who has been frustrated by FileVault to create and use encrypted sparse images for your sensitive data.