Apple,Articles,Security June 5, 2012 at 12:00 am

FileVault 2: The Silent Protector

Introduction

It comes as part of an amazing revolution that the devices we carry are increasingly smaller and lighter. For the first time in history, we have truly mobile devices, including laptops. This also means that they’re more likely to be misplaced or be carried with us in hostile environments, both network-wise and physically. There’s no more firewall-at-the-border stopping attacks on these devices. Protection has to happen at the device itself in most cases. Apple’s updated version of FileVault—FileVault 2—provides one part of this protection.

What is FileVault?

Simply put, FileVault is Apple’s solution to protect data at rest by using encryption. It does not protect against network-based attacks, nor does it protect data in transit, like email or web pages loading. It’s not what will save you from local escalation exploits or using weak passwords. It will stop someone who has physical access to your machine (or even just the storage from your device) from reading the data on it that you consider sensitive.
If you’ve used the original version of FileVault, please throw everything you know about it out the window. Introduced in OS X 10.4, FileVault 1 used an encrypted disk image to protect your home directory—and only your home directory. FileVault 2 goes a level higher and encrypts an entire storage volume. (Or, a level “lower,” depending on your viewpoint.)
Let’s look at FileVault 2 from a high level, the way Apple intends people to interact with it: via the GUI.

Turn It On (Again)

The FileVault interface is accessed through the “Security & Privacy” Preference Pane, under the FileVault tab. Apple makes this a pretty simple affair: a single button labeled, “Turn On FileVault…”

FileVault Pref Pane

FileVault Pref Pane

 

Of course, there is some requisite warning material: “You will need your login password or a recovery key to access your data. A recovery key is automatically generated as part of this step. If you forget both your password and recovery key, the data will be lost.” Pretty severe. Of course, it wouldn’t really be protecting the data if there were an easy way around it. Deciding to proceed, one clicks on the “Turn On FileVault…” button. If you have more than one user account on your machine, you’re asked to choose which users to enable for FileVault. Effectively, this controls who can unlock the disk. (More specifically, which credentials can unlock the disk.)

Enable Users for FileVault

Enable Users for FileVault

 

To enable an account for FileVault, you will need to know the account’s password. User accounts can also be added in later on. Once you choose which users to enable and continue, as promised, a recovery key is generated.

Recovery Key Display

Recovery Key Display

 

As the warning indicates, once you start encrypting the volume, you’ll either need your passphrase or this recovery key to unlock the disk. A loss of both means that volume is now an unreadable, scrambled mess. So, store this recovery key safely! One option that you’re offered is to store this recovery key with Apple.

Store the recovery key

Store the recovery key

 

If you can’t trust yourself to shove this recovery key in a password manager or other encrypted medium on a separate device, then you should probably choose this option. If you do, that recovery key will be associated with your AppleID.
You’re asked to restart to begin encrypting. Do so. You can even use your computer while the disk encrypts in the background while you use it like usual. That’s it.
Now, that’s ideal for Apple’s target user-base: consumers.

To the Enterprise

What you may have noticed in that description is that is doesn’t scale: everything is done through the GUI. Unlike FileVault 1, which had a setting in managed preferences that forced an encrypted home folder, FileVault 2 currently has no such control. Let’s face it—it’s not a great strategy to cross your fingers and simply hope that the people in your organization open the Security Pref Pane and encrypt their drive.
Apple’s only advice for organizations is the same as it was for FileVault 1: encrypt to a FileVaultMaster.keychain with a single key. I will not expand on or explain this further, as it is seriously flawed. The main problem with this method is that the recovery key can never be rotated. Once someone has the FileVault keychain and the password, they will have unrestricted (and unaudited) access to all Macs encrypted to this key.
If you do want to use FileVault in an enterprise setting, Google has an open source solution called Cauliflower Vest (http://code.google.com/p/cauliflowervest).  It provides a way to automate the encryption process, gather and escrow the recovery key to your own server. You can read more about Cauliflower Vest in the wiki at the site.  (Ed Note: Ed is a contributor to Cauliflower Vest).

System Changes

Once you enable FileVault 2, several things change about your system:

  • You will need to enter a password prior to boot, via EFI. Apple has designed this screen to resemble the main login window as closely as possible, so most users won’t really even notice the difference.
  • Apple automatically passes the credentials that unlock the boot volume along to the system, bypassing the login window for the user, so they’re not presented with two logins.
  • The “Require password for sleep and screen saver” option in the Security & Privacy Preference Pane is automatically enabled. What good is an encrypted disk if someone can just walk up to a booted machine and easily access its contents?


How Does FileVault 2 Work?

Compared to the bare file system, or even FileVault 1, FileVault 2 seems like magic. How does it work? The first thing to know is that Apple has included a Logical Volume Manager (LVM) with OS X Lion. This is what FileVault 2 gets to ride on top of. Here’s a conceptual picture of how CoreStorage works with, and then presents volumes:


Physical media still exists—we really can’t get away from that, as the data need to be stored somewhere. CoreStorage doesn’t really care what the media is, though: traditional spinning-plater drives, SSD, USB storage or even a disk image. Represented above in green, we have three volumes that reside on some physical disks. These three volumes are converted into CoreStorage volumes and imported into a Logical Volume Group (LVG). This sets up a “pool” of storage. Volumes can be added to and removed from the pool after creation. A LVG is represented with a UUID. This LVG is then brought into a Logical Volume Family (LVF). An LVF maintains properties about the volumes in a LVG and presents these Logical Volumes (LV) to the system. CoreStorage creates new device nodes for each LV. As shown in the visualization above, the LVs, in blue, have a device node (disk1, disk2, disk3). The ‘key’ icon associated with the LVF shows that encryption is one of the properties maintained about the LVG. This is the layer at which the encryption key resides.
When you “Turn On FileVault…”, one of the steps converts your disk to a CoreStorage volume. Of course, when you “Turn On FileVault…”, only your boot disk is encrypted. Naturally, this fits Apple’s 99% case and is the right fit for the bulk of Mac users on the planet. That said, FileVault cannot and will not encrypt any other drives you may have attached to your system. That’s up to you.

Encrypting on your own

So, you want to encrypt a volume besides your boot drive. Using what we know about CoreStorage, let’s look at how we accomplish this.
Apple has added an entire subset of commands to the diskutil command line utility. The CoreStorage commands are all prefixed with…wait for it…”corestorage” (or “cs” for short, which I’ll use from here out). The easiest to start with is “convert”. “convert” will take care of all the smaller, manual steps for you. This means creating a LVG and adding a physical volume to it, creating the LVF, optionally encrypting it, exporting the device node and mounting it. Here’s an example of converting a disk and encrypting it:

$ diskutil cs convert /dev/disk5s2 -stdinpassphrase
New passphrase for converted volume:
Started CoreStorage operation on disk5s2 transfer1
Resizing disk to fit Core Storage headers
Creating Core Storage Logical Volume Group
Attempting to unmount disk5s2
Switching disk5s2 to Core Storage
Waiting for Logical Volume to appear
Mounting Logical Volume
Core Storage LVG UUID: 89FEEA75-AA62-452D-8541-812BC7B362BB
Core Storage PV UUID: 426D6764-6B30-4F74-AE56-D272FE273199
Core Storage LV UUID: B80B1A57-D9DC-4165-BA7B-245E83A6BCE7
Core Storage disk: disk6
Finished CoreStorage operation on disk5s2 transfer1
Encryption in progress; use `diskutil coreStorage list` for status

Take note of the “Resizing disk to fit Core Storage headers” part—the CoreStorage headers are fairly large and will fail to be added if there’s not enough space for any reason. The convert subcommand is a non-destructive way to CoreStorage-enable and encrypt a single physical volume. This is supported on the boot volume, too. Just like enabling FileVault via the GUI, the disk is encrypted in the background while remaining available for use. At any time that an encrypted device is mounted, a passphrase is requested.

Fig 6-Finder Requests Authentication

Finder Requests Authentication

The encryption process running in the background can even be interrupted (for example, by sleep or shutdown). If you’re using removable media, you can also eject the volume and remount it on a different machine, where the encryption process will resume (CoreStorage-capable machine, of course, so, 10.7 or higher).
As the final line of output mentions, you can check on the status by using ‘diskutil coreStorage list”:

$ diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 89FEEA75-AA62-452D-8541-812BC7B362BB
=========================================================
Name: transfer1
Sequence: 1
Free Space: 0 B (0 B)
|
+- Logical Volume Family C4D5B372-0B53-427B-9B0D-301242793C0A
----------------------------------------------------------
Sequence: 6
Encryption Status: Unlocked
Encryption Type: AES-XTS
Encryption Context: Present
Conversion Status: Converting
Has Encrypted Extents: Yes
Conversion Direction: forward
|
+-> Logical Volume B80B1A57-D9DC-4165-BA7B-245E83A6BCE7
---------------------------------------------------
Disk: disk6
Status: Online
Sequence: 4
Size (Total): 3690983424 B (3.7 GB)
Size (Converted): 220200960 B (220.2 MB)
Revertible: Yes (unlock and decryption required)
LV Name: transfer1
Volume Name: transfer1
Content Hint: Apple_HFS

This output shows that of 3.7GB, 220.2MB have been converted so far. Additionally, the conversion status of the LVF is listed as “Converting” during this process (and “Complete” when done). You can also see if a disk is encrypting or decrypting by the conversion direction status (“Forward” while encrypting, “-none’” when complete, and “Backward” while decrypting).
If you’re interested in creating and manipulating CoreStorage volumes manually, you can do that, too. Unlike the convert command, these commands are destructive and will erase all of the data on the volume! You have been warned. For example, to create a CoreStorage LVG from physical volume:

$ diskutil cs create fvpool disk8

Then, to create a LVF associated with this pool:

$ diskutil cs createvolume D40D2BD3-74F3-4A26-9CD7-B4421BFC9432 jhfs+ csfv1lvf

Note, now, that when running a standard ‘diskutil list’, you’ll see the CoreStorage header partition on these converted disks:

$ diskutil list
[snip]
/dev/disk4
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *102.4 MB disk4
1: Apple_CoreStorage 102.4 MB disk4s1
/dev/disk5
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS fvpoollvf *64.6 MB disk5
[snip]

Concerns

Encryption Eats CPU

It’s true that the process of reading an encrypted block from disk, decrypting it and then presenting it to upper layers is more expensive CPU-wise than not having to do so. However, modern Intel CPUs have special instructions that optimize the operations of the AES encryption used for FileVault 2. Outside of extreme cases of I/O, you won’t notice the encryption. Even less so on SSD/Flash drives.

Won’t Upgrades Cause Issues?

Unlike third-party encryption tools, having a ‘real’ encryption solution baked in from Apple, this doesn’t seem to be a concern. FileVault 2 is a part of the OS at a low enough level that mounting and manipulating encrypted drives can be handled without issue. All point updates in the lifetime of 10.7 have been problem-free.

How Do I Help a User With Encryption?

You’ll need the user to enter their passphrase, or provide you with their credentials (unwise) or recovery key. As mentioned above, for institutional escrow of recovery keys, look at the Cauliflower Vest project from Google (http://code.google.com/p/cauliflowervest).

Mounting Other Partitions at Boot

If you fall outside of the 99% case that has a single disk with a single partition, and may have your home directory on a separate partition, there’s a problem: the OS unlocks the boot drive via EFI, prior to actual boot. But a separate volume won’t be unlocked until you login…which won’t be possible without an accessible home directory. Justin Ridgewell has a clever solution to this problem: “unlock,” a LaunchDaemon that stores a disk’s passphrase in the system keychain and mounts the volume during boot: https://github.com/jridgewell/unlock

TL;DR

With FileVault 2, built-in full disk encryption comes to OS X. It is inexpensive in not only cost, but system resources and in user-adjustment. Protecting data at rest is a critical component of an overall security strategy for mobile devices, particularly laptops. Your iPhone is encrypted, and its backups are likely encrypted. Think about how much more you can store on a laptop-class device.Thanks to the AES instruction set on modern Intel CPUs, performance doesn’t take a hit. For personal machines or those that belong to a business, there aren’t any reasons not to encrypt your disks.

About Edward Marczak

Edward Marczak is a lifer in the technology arena. He is a frequent speaker at technology conferences and the co-founder of MacTech Conference. He writes a monthly column for, and is the Executive Editor of MacTech Magazine. His days are currently spent on the Mac team at Google. Past the technology, Edward is a husband and father and enjoys travelling and playing music. Edward has authored two books about Macintosh administration: Advanced Mac OS X Administration and Enterprise Mac Managed Preferences.

Leave a reply

You must be logged in to post a comment.