[Mac_crypto] How FileVault Should Work (Re: TidBITS#719/01-Mar-04)
R. A. Hettinga
Tue, 2 Mar 2004 18:16:44 -0500
At 8:00 PM -0800 3/1/04, TidBITS Editors wrote:
>How FileVault Should Work
> by Adam C. Engst <email@example.com>
> 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
> 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
>* 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.
R. A. Hettinga <mailto: firstname.lastname@example.org>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'