[Mac_crypto] How FileVault Should Work (Re: TidBITS#719/01-Mar-04)

[R. A. Hettinga]

At 8:00 PM -0800 3/1/04, TidBITS Editors wrote:
>How FileVault Should Work
>-------------------------
>  by Adam C. Engst <ace@tidbits.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.
>
><http://www.apple.com/macosx/features/filevault/>
>
>
>**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.
>
><http://www.securemac.com/macosx-filevault-advisory.php>
>
>
>**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.
>
><http://www.pgp.com/>
>
>
>**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: rah@ibuc.com>
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'