For those who wanted a copy of my FileVault 2 talk at Penn State MacAdmins, here are links to the slides in PDF and Keynote format.

PDF: http://tinyurl.com/PSUMac2014PDF

Keynote slides: http://tinyurl.com/PSUMac2014key

The good folks at Penn State have posted the session videos from the Penn State MacAdmins Conference 2013. The sessions slides and videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:

http://macadmins.psu.edu/conference/resources/

As all the session videos have been posted to YouTube, I’ve linked my FileVault 2 session here:

The Extending OS X Management Systems with Scripting session I co-hosted with Jeremy Reichman is linked here:

While working with a colleague to prepare a FileVault 2 rollout at his institution, he reported that in his testing, the decryption process did not appear to be working correctly when he was booted from the Recovery HD partition and using the command line diskutil-based decryption procedure that I had posted. In his testing, he was finding that the CoreStorage volume that the FileVault 2 encryption process created was not being removed when the diskutil corestorage revert command was run. The drive was being decrypted, but the CoreStorage volume was being left behind. This caused problems in his testing, because he found that rebooting afterwards led to the Mac booting to a prohibited sign.

This symbol at boot means the system has found a bootable installation of Mac OS X on the system, but there is something wrong with it.

After some additional testing, he discovered that he actually needed to run diskutil corestorage revert twice in succession. Running diskutil corestorage revert the first time would decrypt the drive. Running diskutil corestorage revert a second time following the first command would then remove the unencrypted CoreStorage volume. Once the CoreStorage volume was removed, the Mac would then be able to reboot normally to the regular boot drive.

The behavior seems to be tied to the following:

1. Booting from a Mavericks Recovery HD partition (all testing was done with a 10.9.4 Recovery HD partition.)

2. Decrypting either of the following methods:

A. Using Recovery HD‘s Disk Utility to decrypt the FileVault 2-encrypted boot drive. This decryption method is described here.

B. Running diskutil corestorage -revert from the Terminal. This decryption method is described here.

3. Letting the drive get to Conversion Progress: 100% while booted from the Recovery HD partition. Conversion Progress status can be displayed by running the diskutil corestorage list command in Terminal.

4. Rebooting back to the main boot drive once Conversion Progress: has reached 100%.

The end result is a locked CoreStorage volume that will not unlock or mount on boot, or when accessed from a Recovery HD partition or Apple’s Internet Recovery. This was the root cause for the prohibited symbol at boot that my colleague was receiving.

In my testing, I did find it was possible to decrypt the drive via Disk Utility or the command line when it was attached as an external drive (via Target Disk Mode or other means) to a Mac that was booted to a full version of OS X 10.9.x. Once decrypted, I verified that the CoreStorage volume was removed. Once I had verified that, I further verified that I could now boot normally from the previously non-bootable hard drive.

One drawback to decrypting while attached to a regular 10.9.x boot drive is that you are not able to use an Institutional Recovery Key (IRK). Using that kind of recovery key for unlocking or decryption only works when booted from a Recovery HD partition or Internet Recovery. Since that’s precisely where our problem exists, I investigated further to see if there were alternate workarounds for this problem. For more details and the workarounds I found, see below the jump.

In my testing, I identified two workarounds for this issue:

A. Reboot from the Recovery HD partition before the drive fully decrypts

It appears that the issue is specific to completely finishing decryption while booted from a Mavericks Recovery HD partition. However, if you start decryption on a drive, then reboot, decryption will continue after the reboot.

To take advantage of this behavior, I tested and verified that if you start decryption while booted from the Recovery HD partition, then reboot from the Recovery HD partition to a drive running a full version of OS X 10.9.x, decryption will complete normally. As part of the decryption process, the CoreStorage volume is properly removed and the drive is converted back to a normal HFS+ drive.

B. Decrypt using the command line and run diskutil corestorage revert twice

In my testing, I verified my colleague’s finding that running diskutil corestorage revert will decrypt the drive. Once Conversion Progress: has reached 100%, running a second diskutil corestorage revert command will result in the the CoreStorage volume being removed and converting the drive back to a normal HFS+ drive. On reboot, the formerly encrypted drive will boot normally.

When you run the first diskutil corestorage revert command, you should see output like this:

Started CoreStorage operation on disk14 Macintosh HD
Core Storage LV UUID: D28C59B2-3720-4A3F-BCB0-6731338CEE44
Core Storage disk: disk0s2
Finished CoreStorage operation on disk14 Mac HD
Decryption in progress; use `diskutil coreStorage list` for status

Once Conversion Progress: has reached 100% and you run the second diskutil corestorage revert command, you should see output like this:

Started CoreStorage operation on disk14 Macintosh HD
Switching partition from Core Storage type to original type
Reclaiming space formerly used by Core Storage metadata
Ejected Logical Volume
Removing Physical Volume
Destroying Logical Volume Group
Remounting former Physical Volume as normal disk
Core Storage LV UUID: D28C59B2-3720-4A3F-BCB0-6731338CEE44
Core Storage disk: disk0s2
Finished CoreStorage operation on disk14 Macintosh HD
Decryption in progress; use `diskutil coreStorage list` for status

See below for screenshots showing how this should look for the following commands:

diskutil corestorage revert UUID_here -stdinpassphrase

diskutil corestorage revert UUID_here -passphrase recoverykey_here

diskutil corestorage revert UUID_here -recoveryKeychain /path/to/FileVaultMaster.keychain

I’ve filed a bug report with Apple about this issue. If you want to duplicate it, the bug ID number is available below:

17985943

For those who want more details on the bug report, I’ve also posted the bug report information at OpenRadar:

http://openradar.appspot.com/radar?id=5885738759487488

As part of Apple’s FileVault 2 encryption, Apple has provided for the use of recovery keys. These keys are a backup method to unlock FileVault 2’s encryption in the event that the usual method of logging using a user’s account password is not available.

There are two main types of recovery keys available:

1. Personal recovery keys – These are recovery keys that are automatically generated at the time of encryption. These keys are generated as an alphanumeric string and are unique to the machine being encrypted. In the event that an encrypted Mac is decrypted and then re-encrypted, the existing personal recovery key would be invalidated and a new personal recovery key would be created as part of the encryption process.

2. Institutional recovery keys – These are pre-made recovery keys that can be installed on a system prior to encryption and most often used by a company, school or institution to have one common recovery key that can unlock their managed encrypted systems.

Institutional keys are not automatically created and will need to be properly generated before they can be used. For more information on institutional recovery keys, see below the jump.

To help understand why institutional recovery keys work the way they do, here’s some historical background on institutional recovery keys and how they came to be used in FileVault 2.

FileVault 1 and the FileVaultMaster.keychain file

The sole part of Apple’s FileVault 1 (also known as legacy FileVault) that was carried over into FileVault 2 was the ability to use the FileVaultMaster.keychain file (stored in /Library/Keychains) as an institutional recovery key.

In FileVault 1 deployments, you were asked to set a Master Password when turning on FileVault 1’s encryption. When you set the Master Password, the FileVault 1 encryption process set the password that was entered as the password on the /Library/Keychains/FileVaultMaster.keychain file. In turn, the FileVaultMaster.keychain file contained two keys used for PKI certificate-based authentication (one public key and one private key). When the public and private keys are both stored in one keychain, the keychain can be used to unlock your FileVault 1-encrypted home folder in the event that the password to open it was lost or forgotten. The Master Password only unlocked the keychain and allowed the system to access those two PKI keys. This is the reason why you needed to set the Master Password before encrypting and why it was also important to use the same FileVaultMaster.keychain file across the machines where you wanted to make sure that the same recovery key was being used.

If you were deploying the same recovery key for your FileVault-encrypted Macs, Apple consistently recommended that you go into the FileVaultMaster.keychain file, remove the PKI private key, put the private key somewhere secure and deploy the FileVaultMaster.keychain file with only the public key inside. The reason was that, in the event that the password to the FileVaultMaster.keychain file was compromised, all the compromiser got was one half of the keypair (the public key half.) The private key would not be on the machine and thus not available to compromise the FileVault 1-encrypted homes on the machine. However, FileVault 1 would work with both the public and private keys stored in /Library/Keychains/FileVaultMaster.keychain.

In FileVault 2, Apple changed removing the private key from being a suggested best practice to being a technical requirement. If you want to use an institutional recovery key, your FileVaultMaster.keychain file needs to have just the public key in it. If both public and private keys are stored in the /Library/Keychains/FileVaultMaster.keychain file on a Mac, FileVault 2 will ignore the keychain and not use it as an institutional recovery key. In this case, enabling FileVault 2 encryption will automatically generate a personal recovery key.

Creating an Institutional Recovery Key

If you want to use an institutional recovery key on FileVault 2 encrypted Macs, you will need to create and configure a FileVaultMaster keychain. Apple has provided a way to create this keychain by using the security command’s create-filevaultmaster-keychain function. To create a FileVaultMaster.keychain file, run the following command:

security create-filevaultmaster-keychain /path/to/FileVaultMaster.keychain

You’ll be prompted for a password for the keychain. When provided, the keychain will be created and will contain both the private and public keys needed for recovering a FileVault 2-encrypted drive that uses this institutional recovery key. Make copies of the keychain and store them in a safe place. Also make sure to securely store copies of the password you used to create the keychain.

If you want to create the FileVaultMaster keychain in its proper place, run the security command with root privileges and use /Library/Keychains for the destination path.

Once you’ve made your copies, make another copy and remove the private key from that copy of the keychain. Once the private key is removed, the FileVaultMaster.keychain file is ready to be used for encrypting Macs with FileVault 2 with the institutional recovery key.

It doesn’t appear that the security main page includes information about the create-filevaultmaster-keychain function, but you can see what it does by running the security help command in Terminal and checking at the bottom of the list that appears.

A way to modify /Library/Keychains/FileVaultMaster.keychain so that it only has the public key inside would be to do the following:

1. Create the FileVaultMaster.keychain file using the security command.

2. Next, make several copies of the FileVaultMaster.keychain file that you just created and store the copies separately in secure locations. A locked safe would be a good place, or in an encrypted disk image that is on an access-restricted file share.

3. Next, unlock the newly-created FileVaultMaster.keychain file by running the following command and entering the keychain’s password when prompted for the password:

security unlock-keychain /Library/Keychains/FileVaultMaster.keychain

Note: The FileVaultMaster keychain will need to be unlocked from the command-line as the keychain will not unlock in Keychain Access by clicking on the lock.

4. If it succeeds, you’ll get the next system prompt. If not, get another copy of the FileVaultMaster.keychain file and try again. A FileVaultMaster.keychain file with an unknown password should not be used because there is no way to use it for recovery purposes without first knowing the keychain’s current password.

5. Once you’ve unlocked the FileVaultMaster.keychain file, open the Keychain Access application from /Applications/Utilities/.

6. In Keychain Access, go to File: Add Keychain… and add /Library/Keychains/FileVaultMaster.keychain.

7. Assuming you previously unlocked the FileVaultMaster.keychain file using the security command, it should show up as unlocked in Keychain Access.

8. Go into the FileVaultMaster keychain and remove the private key. (It should be called FileVault Master Password Key and its kind should be listed as private key.)

9. Relock the FileVaultMaster keychain

10. Copy the modified FileVaultMaster.keychain file (now with only the public key inside) to the /Library/Keychains directory of the Macs you want to encrypt with FileVault 2. For ease of deployment, you can package the FileVaultMaster.keychain file into an installer package. That installer package can then be deployed ahead of encryption to multiple machines using the system management tools used in your environment.

When deployed to /Library/Keychains on the Macs you want to encrypt with FileVault 2, the FileVaultMaster.keychain file should have the following permissions set:

Owner: root

Permissions: read and write

Group: wheel

Permissions: read only

Everyone

Permissions: read-only

Once the institutional recovery key is deployed to a unencrypted machine, enabling FileVault 2 via System Preferences should produce a message stating that “A recovery key has been set by your company, school or institution” instead of displaying the personal recovery key.

Using FileVaultMaster.keychain to recover your data

At this time, it’s not possible to unlock the encryption at the pre-boot login screen using a recovery key that’s been set with FileVaultMaster.keychain. Here’s an example of how to recover data from a system with an institutional recovery key that has both the private and public keys inside.

In this case, we’re assuming that the machine isn’t booting and you don’t know the password of a user authorized to unlock the encryption:

1. Boot the encrypted Mac from a Recovery HD partition or from Apple’s Internet Recovery.

2. Open Terminal.

3. Run the following command to get the Logical Volume UUID of the Mac’s encrypted partition:

diskutil corestorage list

4. With the UUID information acquired, run the following command to unlock the FileVaultMaster keychain:

security unlock-keychain /path/to/FileVaultMaster.keychain

5. Enter the keychain’s password when prompted to unlock the keychain.

6. Run the following command to unlock the encrypted Core Storage volume on the encrypted Mac, substituting the appropriate Logical Volume UUID for UUID_here:

diskutil corestorage unlockVolume UUID_here -recoveryKeychain /path/to/FileVaultMaster.keychain

7. You should then see output similar to the following.

Started CoreStorage operation
Logical Volume successfully unlocked
Logical Volume successfully attached as disk4
Logical Volume successfully mounted as /Volumes/Macintosh HD
Core Storage disk: disk4

If you open the Disk Utility application after this point, you should see the encrypted Mac’s hard drive as being mounted. At this point, with the disk unlocked and mounted, you should be able to recover your data using whatever tools you prefer.

Once you’ve unlocked the disk, you can also then decrypt the encrypted volume by using the FileVaultMaster.keychain file to authorize it.

To decrypt, run the following command on the encrypted Mac, substituting the appropriate Logical Volume UUID for UUID_here:

diskutil corestorage revert UUID_here –recoveryKeychain /path/to/FileVaultMaster.keychain

Note: A FileVault 2-encrypted drive must be unlocked before it can be decrypted.

When decrypting while booted from the Recovery HD partition on 10.9.x, there is a decryption-related bug to be aware of. See this post for more details.

Institutional recovery keys and fdesetup

fdesetup is a multifunctional tool for enabling and managing FileVault 2 in Mavericks. When used with an institutional recovery key, fdesetup can perform the following functions:

• Enable FileVault 2 encryption
• Support multiple recovery keys for FileVault 2, giving Mac admins more options for handling recovery situations.
• Rotate or remove both personal and institutional recovery keys on an as-needed basis.

Enabling FileVault 2 encryption with fdesetup using an institutional recovery key

In OS X 10.9.x, you are able to use the institutional recovery key with the fdesetup command line tool for managing FileVault 2 encryption to perform various actions. Among its various functions, fdesetup provides the ability to encrypt using the alphanumeric personal recovery key, an institutional recovery key using /Library/Keychains/FileVaultMaster.keychain, or both kinds of recovery key at the same time.

fdesetup will provide the alphanumeric personal recovery key by default. To use the institutional recovery key, the -keychain flag needs to be used when enabling encryption:

sudo fdesetup enable –keychain

The alphanumeric personal recovery key is displayed, but the encryption will also use the /Library/Keychains/FileVaultMaster.keychain file as an institutional recovery key. In case recovery is needed, either recovery key will work to unlock or decrypt the encrypted drive.

If you want to specify that only the FileVaultMaster.keychain institutional recovery key be used, both the -keychain and -norecoverykey flags need to be used when enabling encryption:

sudo fdesetup enable -keychain –norecoverykey

fdesetup is also capable of creating an institutional recovery key, using the -certificate flag to import an existing FileVault 2 public key. Once imported, fdesetup will automatically create a FileVaultMaster.keychain file to store the public key and save the keychain to /Library/Keychains.

The public key will need to be available as a DER encoded .cer certificate file. This certificate file can be created using the following procedure:

1. Access the FileVaultMaster keychain via the Keychain Access application.

2. Select the public key in the FileVaultMaster keychain.

3. In Keychain Access, select the File menu.

4. Under the File menu, select Export Items…

5. Set the File Format: export option to be Certificate (.cer)

6. Name and save the .cer file to a convenient location.

Once the certificate is available, the following command can be run to enable FileVault 2, automatically create the institutional recovery key with the supplied public key and store it as /Library/Keychains/FileVaultMaster.keychain:

sudo fdesetup enable -certificate /path/to/filename.cer

To specify that only the FileVaultMaster.keychain institutional recovery key be used, add the -norecoverykey flag to the command:

sudo fdesetup enable -certificate /path/to/filename.cer -norecoverykey

It is also possible to include the public key data in a plist file, which allows the use of a plist to set up the institutional recovery key. The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>username</string>
<key>Password</key>
<string>password</string>
<key>AdditionalUsers</key>
<array>
 <dict>
  <key>Username</key>
  <string>username</string>
  <key>Password</key>
  <string>password</string>
 </dict>
 <dict>
  <key>Username</key>
  <string>username</string>
  <key>Password</key>
  <string>password</string>
 </dict>
</array>
<key>Certificate</key>
<data>
(Certificate data goes here…)
</data>
</dict>
</plist>

Using a DER encoded certificate file that contains the public key, the public key data for the plist can be obtained using the base64 tool by using the following command:

base64 /path/to/filename.cer > /path/to/filename.txt

At this point, you would copy the data string contained in the text file and place it into the Certificate <data></data> value area of the plist file. You would store either the password of an existing FileVault 2-enabled user or (if available) an existing personal recovery key in the Password key in the plist.

Managing institutional recovery keys with fdesetup

fdesetup in Mavericks adds the new ability to change, add and remove institutional recovery keys. This gives Mac admins much greater ability to manage recovery keys, including the capability to quickly update or remove compromised institutional recovery keys in the event of a data breach or other problem.

You can add or change recovery keys using fdesetup changerecovery. To change to a new institutional recovery key, you will need to have the new public key available. If you have a new institutional public key available as a DER encoded certificate file, you can run the following command to replace the current institutional key:

sudo fdesetup changerecovery -institutional -certificate /path/to/filename.cer

If an institutional keychain is being used on this Mac, you will see a message that an existing FileVault Master keychain was found and moved. The reason for this is that, as part of this process, the current institutional key’s /Library/Keychains/FileVaultMaster.keychain file is replaced with a new /Library/Keychains/FileVaultMaster.keychain file that includes the new institutional recovery key’s public key.

While the former institutional key’s /Library/Keychains/FileVaultMaster.keychain was moved and not deleted, the former institutional recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
<key>Certificate</key>
<data>
(Certificate data goes here…)
</data>
</dict>
</plist>

You can also use the current institutional recovery key to authenticate the change to the new institutional key. If you have a keychain file available containing the private key of the current institutional key, you can run the following command to replace the current institutional key:

sudo fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer -key /path/to/filename.keychain

You’ll be prompted for the keychain’s password. Once entered, the current institutional key will be replaced with the new one.

In the event that the Mac in question does not have an institutional recovery key, running the commands above (with the exception of using the current institutional key for authentication) will add an institutional recovery key instead of changing an existing one.

Removing institutional recovery keys

You can remove recovery keys using fdesetup removerecovery. To remove institutional recovery keys, run the following command:

sudo fdesetup removerecovery -institutional

You’ll be prompted for the password of an existing FileVault 2-enabled user. Once entered, the institutional recovery key will be removed from the system and will no longer work.

The removal of the institutional key can also be automated using a properly formatted plist via a standard input stream (stdin). The plist is the same as the one used for removing the personal key.

Once the plist has been set up and properly formatted, run the following command to remove the institutional recovery key and reference the password or recovery key in the plist file:

sudo fdesetup removerecovery -institutional -inputplist < /path/to/filename.plist

You can also use the recovery key associated with an institutional key to authenticate the removal of that institutional key. Once authenticated, the institutional key is removed from the system and will no longer work.

If you have a keychain file containing the private key for the current institutional key available, you can run the following command to remove the current institutional key:

sudo fdesetup removerecovery -institutional -key /path/to/filename.keychain

It is possible to use fdesetup removerecovery to remove one or both recovery keys on a particular Mac. Once the recovery keys are removed, the only way to unlock the FileVault 2 encryption is by using the password of an enabled account. That said, you can use fdesetup changerecovery to add one or both types of recovery keys back to the encrypted Mac.

Referencing an institutional recovery key in a fdesetup plist file

As part of the man page for fdesetup in OS X 10.9.x, Apple provides a sample plist file as a guide for those who want to import authentication credentials as part of running commands with fdesetup. As part of the plist, there are two plist keys that reference using a keychain that contains the private key for an institutional recovery key:

KeychainPath

KeychainPassword

For KeychainPath, you will need to provide the file path to the keychain as the plist value. For KeychainPassword, you will need to provide the password that unlocks that keychain.

For example, if you put the keychain into the /tmp directory, you would reference /tmp/filename.keychain as the KeychainPath plist value. If the password for unlocking that keychain is seKritPassword, you would reference seKritPassword as the KeychainPassword plist value. In my testing, it appears that you can leverage the KeychainPath and KeychainPassword plist keys with the following fdesetup commands.

fdesetup changerecovery

fdesetup removerecovery

If using the current institutional key to authenticate, the plist needs to follow the format shown below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeychainPath</key>
<string>/path/to/filename.keychain</string>
<key>KeychainPassword</key>
<string>password</string>
</dict>
</plist>

If you are using the current institutional key to authenticate a change to a new institutional recovery key, you can also embed the public key of the new institutional recovery key in the plist. In that case, the plist needs to follow the format shown below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeychainPath</key>
<string>/path/to/filename.keychain</string>
<key>KeychainPassword</key>
<string>password</string>
<key>Certificate</key>
<data>
(Certificate data goes here.)
</data>
</dict>
</plist>

Recovery key reporting

To go along with the ability to manage recovery keys, fdesetup enables Mac admins to detect which types of recovery keys are in use on a particular Mac. To check if an institutional recovery key is in use, run the following command:

sudo fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an institutional recovery key, this command will return true. Otherwise it will return false.

Security considerations

Institutional recovery keys have a weakness from the cryptographic point of view, which is that the concept inherently uses one private and public key pair to unlock the encryption of more than one encrypted volume. A malicious party who compromises the private key of an institutional recovery key means that all Macs encrypted using that institutional recovery key are vulnerable. In order to maintain their encryption protection, those Macs must have their institutional key changed to a new one.

That said, Apple has taken the following steps in FileVault 2 as of OS X 10.9.x to mitigate the possible vulnerability of a compromised private key:

1. Making it a technical requirement that the FileVaultMaster.keychain file only contain the public key when deployed to Macs that will be using the institutional recovery key for FileVault 2 encryption.

The public key is not sensitive information and was designed as such. You can post the contents of a public key to a public billboard without compromising the security of the encrypted volume.

2. Providing a way to replace a compromised recovery key.

Before OS X 10.9.x, you would need to decrypt an encrypted Mac before being able to change an existing institutional recovery key. In 10.9.x, fdesetup can be leveraged to assist in this situation in the following ways:

• Changing the compromised institutional key to a new one with fdesetup‘s changerecovery function
• End the use of an institutional key with fdesetup‘s removerecovery function

Conclusion

Every shop must consider its own security requirements and make its own judgments based on that. If you are thinking of using an institutional recovery key for your FileVault 2 deployment, hopefully the information provided here provides you with the needed knowledge to get you started.

Something that has usually been a manually-driven process for me has been FileVault 2 decryption when using an institutional recovery key. In large part, this is because you need to boot to either Recovery HD or Apple’s Internet Recovery. When you combine that with this known issue with decrypting when booted from Recovery HD or Apple’s Internet Recovery, it made me wish for a scripted process for decrypting when using an institutional recovery key.

Apparently, I should wish for things more often because @ttaniguti has developed a script that does precisely that. FileVault Rescue’s decrypt.sh script is designed to properly decrypt a FileVault 2-encrypted Mac using an institutional recovery key while the Mac is booted to Mavericks’ Recovery HD or Apple’s Internet Recovery.

In my testing, the script works fine on a FileVault 2-encrypted Mac running 10.9.5 and it avoids the known issues with decrypting while booted from Recovery HD by running diskutil cs revert twice at the proper times in the decryption process.

To use this script, you will need the following:

1. A FileVaultMaster.keychain file that contains the private key of your institutional recovery key.

2. The unlock password for the FileVaultMaster.keychain file stored in a plaintext file named pass.txt

Once you have both of these, copy the two files along with the decrypt.sh script to something that you’ll be able to access while booted to Mavericks’ Recovery HD or Apple’s Internet Recovery. A USB flash drive would work well here.

A YouTube video is available to show you how to use the script and I’ve linked it below:

Hat tip to Allister Banks for letting me know about this script.

To address this issue that caused problems for folks decrypting from Mavericks’ Recovery HD and Internet Recovery, Apple has made a change to Yosemite’s Recovery HD and Apple Internet Recovery with regards to FileVault 2 decryption. As of 10.10, you can initiate the decryption process from Yosemite’s Recovery HD and Internet Recovery, but the actual decryption will not proceed until you have booted from a drive that is running a regular Yosemite OS install.

When you decrypt from Yosemite’s Recovery HD, you will be notified that decryption is in progress and to run the following command to check on its progress:

diskutil cs list

When checked, you should see output for Conversion Status, Conversion Direction and Conversion Progress similar to what’s shown below:

• Conversion Status: Converting
• Conversion Direction: -none-
• Conversion Progress: -none-

These statuses will not change while you’re booted from Yosemite’s Recovery HD. If you reboot and boot back to Yosemite’s Recovery HD, you should see output for Conversion Status, Conversion Direction and Conversion Progress similar to what’s shown below:

• Conversion Status: Converting
• Conversion Direction: -none-
  
• Conversion Progress: Paused
  

Once booted from a regular Yosemite OS install, you should see decryption proceed.

I had filed a bug report about the decryption behavior in Mavericks’s Recovery HD which evolved into a bug report about this behavior. The bug report has been closed by Apple and I’ve posted the bug report at Open Radar now that the Yosemite NDA has been lifted. For those interested, the details are available via the link below:

http://openradar.appspot.com/radar?id=5885738759487488

One new window that appears in Apple’s Setup Assistant application for Yosemite is one that encourages new users of Yosemite to enable FileVault 2 encryption.

However, this Setup Assistant window appears to be selective as it appears for some users but not others. After some digging with the strings command, it looks like the FileVault 2 option in Setup Assistant does not appear in the following conditions:

1. The Mac is not a laptop.
2. The OS is unable to check the processor for certain features.
3. The processor does not support AES-NI.
4. The OS is booting from an external drive.
5. There’s more than one user account on the system.
6. The boot drive does not have a CoreStorage logical volume set up on it.
7. The boot drive is already encrypted.
8. The Mac was configured by the Device Enrollment Program to not display this option.
9. This window had already appeared for this drive and user account.
10. The user’s home folder is located somewhere other than the boot drive.
11. The user has not logged into iCloud on this machine.

These criteria can be examined using the following procedure:

1. Install Xcode or the Xcode Command Line Tools.
2. Once Xcode or the Xcode Command Line Tools are installed, open Terminal and run the following command:

strings /System/Library/CoreServices/Setup\ Assistant.app/Contents/SharedSupport/MiniLauncher | grep "FDE upsell"

On a 10.10.0 system, that should produce the following output:

Skipping FDE upsell,  machine is not a portable
Skipping FDE upsell, unable to inspect cpu features
Skipping FDE upsell, unable to gather cpu features
Skipping FDE upsell, CPU doesn't have AES instruction set
Skipping FDE upsell, somehow running buddy on a disk image
Skipping FDE upsell, not an internal volume
Skipping FDE upsell, not a single user system
Skipping FDE upsell, root disk is not a CSLV
Skipping FDE upsell, root disk is already FDE
Skipping FDE upsell, system was opted out via Device Enrollment Program setting
Skipping FDE upsell, already occurred for this volume and user
Skipping FDE upsell, user home volume is separate from the system volume
Skipping FDE upsell, not logged into iCloud

Apple’s release of Yosemite has brought with it the ability to use an Apple ID to unlock and reset a forgotten account password to log into a FileVault 2-encrypted Mac. You can use this ability in a couple of ways:

1. By setting up your iCloud account as your account on the Mac in question.

2. By associating your local or mobile network account on the Mac with an Apple ID, and selecting the option when enabling FileVault 2 to use your Apple ID to unlock the disk and reset your password.

Note: This method uses Apple’s services to store the needed FileVault 2 recovery key. If your Mac’s FileVault 2 recovery key is not being stored by Apple, you will not be able to use an Apple ID to reset your account’s ability to log into a FileVault 2-encrypted Mac.

For more details, see below the jump.

Here’s the procedure for resetting a forgotten account password using an account’s previously-registered Apple ID.

1. At the FileVault 2 pre-boot login screen, select the account in question.

2. Click on the question mark icon.

3. In the options displayed, click on the …reset it using your Apple ID option.

4. The Mac will reboot to your Mac’s recovery partition and access a Reset Password wizard.

5. When prompted, log in with your account’s associated Apple ID.

6. Depending on what type of account you have, the next few screens may be slightly different.

iCloud account

A. The Reset Password wizard will check the locked disk

B. The Mac will communicate back with Apple to match the iCloud user against the FileVault 2 recovery key that was stored with Apple.

C. The iCloud account will be re-enabled for FileVault 2

D. You’ll be prompted to restart. On login, your iCloud account password will be able to log in at the FileVault 2 pre-boot login screen.

Local or Mobile Network Account that’s associated with an Apple ID

A. The Reset Password wizard will check the locked disk.

B. The Mac will communicate back with Apple to match the Apple ID against the FileVault 2 recovery key that was stored with Apple.

C. You’ll be prompted to reset your account’s password to a new one.

Note: This may break the password sync for a mobile network account between the network account’s cached password on the Mac and the directory service.

D. You’ll be prompted to restart. On login, your now-reset account password will be able to log in at the FileVault 2 pre-boot login screen.

I’ve been working with the folks at Peachpit to create a FileVault 2 training video, geared towards Mac admins that want to learn more about FileVault 2. I’m happy to say that they’ve let me know that it’s now available and can be purchased from the following link:

http://www.peachpit.com/store/filevault-2-for-mac-os-x-decoded-learn-by-video-9780134095844

This video covers OS X Mavericks, as Yosemite was still covered under NDA at the time I was working on this. That said, the vast majority of the FileVault 2 information covered in the video will also apply to Yosemite.

Back in OS X 10.8.x, one of the newly-created fdesetup tool’s functions was to enable users for FileVault 2. To do so, you needed to provide both the username and password of either a previously enabled account or an admin account, as well as the password of the account you want to add.

One interesting twist was that the admin user in question did not themselves need to be enabled for FileVault 2. In my testing on 10.8.x, I found that an admin user could authorize the enabling of other accounts even if the admin account wasn’t enabled. An admin account could also enable itself using this process, by being both the authorizing admin account and the account being enabled.

In Mavericks and later, this behavior changed. If you’re using Mavericks or Yosemite, the fdesetup tool included with those operating systems now prevents non-enabled admin users from enabling other non-enabled users.

That seemed to close the book on non-enabled admin accounts being able to enable users for FileVault 2, until Google’s Macintosh Operations Team posted a script that they said would make a Mac unbootable.

As part of the discussion about that script, something really interesting was discovered. For more details, see below the jump.

At the time of posting, the script was designed to do the following:

If the Mac’s boot drive was FileVault 2-encrypted, the script:

1. Adds a new user called fde_locked_user with a random password.
2. Adds this user to the list of users who can unlock the disk.
3. Removes all other users.
4. Shuts down the machine.

If the Mac’s boot drive was not FileVault 2-encrypted, the script:

1. Renames /sbin/launchd to /sbin/launchd_disabled
2. Shuts down the machine

Unfortunately, as it was set up, the “If the Mac’s boot drive was FileVault 2-encrypted” part of the script didn’t work as intended when run on Mavericks or Yosemite. The reason it didn’t work as intended was that the script relied on Mountain Lion’s fdesetup behavior, where a non-enabled admin user (in this case, the root user) could enable the script-created “fde_locked_user” user account for FileVault 2.

When the script was run on Mavericks or Yosemite, non-enabled admin users could no longer enable accounts for FileVault 2. Testing on Mavericks and Yosemite showed that the “If the Mac’s boot drive was FileVault 2-encrypted” part of the script failed because fdesetup was not being provided acceptable authorization to enable the new fde_locked_user account that was being created by the script.

After some additional discussion and testing, it was discovered that it was possible to have the script work again as written on Mavericks and Yosemite, with one addition: the 10.8 version of the fdesetup tool.

As long as the 10.8 version of fdesetup is being used for the enablement process, it is possible to return to the Mountain Lion behavior of non-enabled admin users being able to enable accounts for FileVault 2. To take advantage of this, Google’s Macintosh Operations Team is now bundling the 10.8 fdesetup binary as part of the installer package that installs and runs their script.

Using the 10.8 fdesetup tool on 10.9.x and 10.10.x has been tested and verified to work on 10.9.x and on 10.10.0 / 10.10.1. It may break in future versions of OS X.

Update: I’ve opened a bug report with Apple about this behavior. For those that want to dupe it, the bug report ID is 18985048. For those interested in the details of the bug report, I’ve also posted the bug report to Open Radar:

http://openradar.appspot.com/radar?id=5306791864827904

Update 2: To presumably address any software distribution legal issues, Google has replaced the 10.8 fdesetup binary with a new Google-produced fdeadduser binary that has the same behavior in terms of enabling users for FileVault 2.

In 10.10.0 and 10.10.1, I’ve noticed an issue when enabling FileVault 2 via System Preferences when using an institutional recovery key.

In Mavericks and earlier versions of OS X, the behavior of System Preferences looked like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A list of users that can be enabled for FileVault 2 is displayed. The logged-in user account is marked with the green checkbox that shows that the account is enabled.
4. A message is displayed that a recovery key has been set by a company, school or institution.
5. A message prompting the user to restart is displayed.
6. Once the Restart button has been clicked, the FileVault 2 initialization process continues and restarts the Mac.
7. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

In Yosemite 10.10.0 and 10.10.1, the behavior of System Preferences looks like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A message is displayed that a recovery key has been set by a company, school or institution.
4. System Preferences then displays no additional messages and will appear to hang for up to two minutes.
5. The Mac restarts without further input from the user.
6. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

As Yosemite’s current behavior is different and omits several steps that were present in previous versions of OS X, I believe this is a bug in Yosemite instead of intended behavior.

To help get it fixed, I’ve filed a bug report. For those interested in duping it, it’s bug ID 19124344.

For those interested in the details, I’ve also posted the bug report to Open Radar:

http://openradar.appspot.com/19124344

One of the changes that Steve Jobs briefly mentioned in the course of the WWDC 2011 keynote address was that Apple had revamped its FileVault encryption solution for Mac OS X 10.7.x, changing it from encryption that primarily protected your accounts home folder to encryption that protects your whole boot volume. Since that initial announcement, FileVault 2 has evolved into an encryption solution that can be easily managed by both home users and enterprises alike.

That said, almost every technology solution has details and parts that aren’t generally well known and FileVault 2 is not different in that regard. To help Mac admins who are managing FileVault 2 in their own environment, I’ve put together a list of 10 things I’ve run across in my work with FileVault 2 that I’ve either been asked about frequently or which seem to be completely undocumented by Apple. Most of these I’ve previously documented in one form or another, so some of these may seem familiar. See below the jump for the list.

1. Password Changes And FileVault 2

FileVault 2 has a nifty password update procedure for its enabled accounts (i.e. the accounts that show up at the pre-boot login screen) If you change your accounts password, the OS will automatically and invisibly update your FileVault 2 pre-boot login. This helps ensure that your account is consistently using the same password across the board. For local accounts, this password update is triggered when changing the local accounts password via the Users & Groups preference pane in System Preferences.

If a FileVault 2-enabled account is an Active Directory or Open Directory mobile account (where the accounts password is being managed by the Active Directory or Open Directory directory service), it’s possible to change your password for your account without your Macs OS being aware of it. For example, many worksites have a policy that you must change your password on a scheduled interval and also provide a website where you can change your password. If your encrypted Mac was offline at the time that your password was changed, it may not receive that password change until the next time you start up.

In a case like this, here’s how the password update process should work:

1. The mobile account’s password gets changed outside the Mac.

2. You boot your encrypted Mac while connected to a network that allows connections between your Mac and the directory service that manages the account’s password.

3. The pre-boot login screen would accept the account’s old password.

The pre-boot login is taking the old password here because the OS is not running at this point in the boot process, and the Mac is unable to communicate with the directory service that manages the accounts password.

4. Next, you get the OS’s login window and type the accounts new password there. Since the OS is running at this point, it can communicate with the directory service and learn that the account has a new password. Once the new password has been accepted, the OS will allow the login process to complete and it will also update the FileVault 2 pre-boot login to use the new password.

5. After the new password has been accepted, the Mac should provide the option to update the login keychains password.

Once updated, the login keychain should be using the account’s new password as well.

2. The Guest User And FileVault 2

One unusual feature of FileVault 2 is that sometimes a Guest User icon will appear at the pre-boot login screen.

When you log in as that guest user, you don’t get access to your hard drive. The only thing you get access to is Safari and a network connection. Quitting out of Safari will return you to the FileVault 2 pre-boot login screen.

To my knowledge, Apple has never commented specifically about this guest user but it appears the guest user is an anti-theft measure. The guest user’s appearance at the pre-boot login screen is a feature tied to signing into iCloud and enabling the Find My Mac option.

One consequence of logging into the guest user is that, as soon as the Mac gets a network connection, it will immediately connect back to Apple and report its location information.

If you don’t sign in with iCloud and then enable Find My Mac from that machine, the Guest User icon will not appear on the FileVault pre-boot login screen. That said, mobile device management solutions that track a machine’s location may also trigger the Guest User icon to appear.

3. Enabling Non-Enabled Admin Users For FileVault 2 Via System Preferences

One challenge for Mac admins is figuring out ways to enable users for FileVault 2. One approach to enable non-enabled accounts that have administrative privileges is the following:

1. Log in at the OS login window as the non-enabled admin account.

2. Open System Preferences and go to the FileVault preference pane

3. Click the lock to unlock the FileVault preference pane and authenticate when prompted.

4. Click the Enable Users button in the FileVault preference pane

5. The previously non-enabled admin user account will appear with a green checkbox to show that the account has been enabled for FileVault 2.

This approach to allow admin users to enable themselves for FileVault 2 has worked since FileVault 2 was first introduced in Lion and it continues to work in Yosemite.

4. Creating An Institutional Recovery Key

If you want to use an institutional recovery key on FileVault 2 encrypted Macs, you will need to create and configure a FileVaultMaster keychain. Apple has provided a way to create this keychain by using the security command’s create-filevaultmaster-keychain function. To create a FileVaultMaster.keychain file, run the following command in the Terminal:

security create-filevaultmaster-keychain /path/to/FileVaultMaster.keychain

You’ll be prompted for a password for the keychain. When provided, the keychain will be created and will contain both the private and public keys needed for recovering a FileVault 2-encrypted drive that uses this institutional recovery key.

Make copies of the keychain and store them in a safe place. Also make sure to securely store copies of the password you used to create the keychain.

If you want to create the FileVaultMaster keychain in its proper place, run the security command with root privileges and use /Library/Keychains for the destination path.

Once you’ve made your copies, make another copy and remove the private key from that copy of the keychain. Once the private key is removed, the FileVaultMaster.keychain file is ready to be used for encrypting Macs with FileVault 2 with the institutional recovery key.

It doesn’t appear that the security man page includes information about the create-filevaultmaster-keychain function, but you can see what it does by running the security help command in the Terminal and checking at the bottom of the list that appears.

A way to modify /Library/Keychains/FileVaultMaster.keychain so that it only has the public key inside would be to do the following:

1. Create the FileVaultMaster.keychain file using the security command.

2. Next, make several copies of the FileVaultMaster.keychain file that you just created and store the copies separately in secure locations. A locked safe would be a good place, or in an encrypted disk image that is on an access-restricted file share.

3. Next, unlock the newly-created FileVaultMaster.keychain file by running the following command and entering the keychain’s password when prompted for the password:

security unlock-keychain /Library/Keychains/FileVaultMaster.keychain

Note: The FileVaultMaster keychain will need to be unlocked from the command-line as the keychain will not unlock in Keychain Access by clicking on the lock.

4. If it succeeds, you’ll get the next system prompt. If not, get another copy of the FileVaultMaster.keychain file and try again. A FileVaultMaster.keychain file with an unknown password should not be used because there is no way to use it for recovery purposes without first knowing the keychains current password.

5. Once you’ve unlocked the FileVaultMaster.keychain file, open the Keychain Access application from /Applications/Utilities/.

6. In Keychain Access, go to File: Add Keychain and add /Library/Keychains/FileVaultMaster.keychain.

7. Assuming you previously unlocked the FileVaultMaster.keychain file using the security command, it should show up as unlocked in Keychain Access.

8. Go into the FileVaultMaster keychain and remove the private key. (It should be called FileVault Master Password Key and its kind should be listed as private key.)

9. Relock the FileVaultMaster keychain

10. Copy the modified FileVaultMaster.keychain file (now with only the public key inside) to the /Library/Keychains directory of the Macs you want to encrypt with FileVault 2. For ease of deployment, you can package the FileVaultMaster.keychain file into an installer package. That installer package can then be deployed ahead of encryption to multiple machines using the system management tools used in your environment.

When deployed to /Library/Keychains on the Macs you want to encrypt with FileVault 2, the FileVaultMaster.keychain file should have the following permissions set:

Owner: root

Permissions: read and write

Group: wheel

Permissions: read only

Everyone

Permissions: read-only

Once the institutional recovery key is deployed to an unencrypted machine, enabling FileVault 2 via System Preferences should produce a message stating that A recovery key has been set by your company, school or institution instead of displaying the personal recovery key.

5. Erasing A FileVault 2-Encrypted Volume From The Command Line

On occasion, it’s necessary to erase a FileVault 2-encrypted volume. However, sometimes Disk Utility won’t let you erase or repartition an encrypted drive until you unlock or decrypt. This can be an issue for a malfunctioning FileVault 2-encrypted volume that will not let you either unlock or decrypt.

To help with this, the diskutil tool provides a way to quickly delete CoreStorage volumes from the command line. This includes the ability to erase encrypted CoreStorage volumes (aka FileVault 2-encrypted volumes) without first deleting them.

To do this, first run the following command in the Terminal:

diskutil cs list

This will give you with a list of the CoreStorage volumes on your system. Unless you have a Fusion drive or multiple encrypted drives, your FileVault 2-encrypted drive should be the only one listed.

In the listing, you will want to select and copy the Logical Volume Group (LVG) alphanumeric UUID for your CoreStorage volume. The LVG should be the first UUID listed and its the one we want to delete.

Next, run the following command in the Terminal:

diskutil cs delete UUID_here

This command will delete the encrypted CoreStorage volume and reformat it as an unencrypted HFS+ volume.

6. Setting A Text-Only Login Banner For The FileVault 2 Pre-Boot Login Screen From The Command Line

It is possible to set a text-only banner message that appears in the following locations:

1. The FileVault 2 pre-boot login screen

2. The OS login window

3. The screensaver lock window

Brevity is best, as staying within a maximum of three lines will permit the banner text to be consistently displayed in all three locations. Exceeding the three-line limit may result in the text being cut off and not fully displayed.

You can set this banner text from the command line using the following defaults command, which should be run with root privileges:

defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"

However, if these functions were enabled from the command using the defaults command, they may show up at the OS login window and the screensaver lock window, but not the FileVault 2 pre-boot login screen.

The answer seems to be that, in addition to running the defaults commands, you also need to manually update the /System/Library/PrivateFrameworks/EFILogin.framework using the touch command. By running the touch command on the right part of the EFILogin framework, the OS will force the system to update the FileVault 2 pre-boot login screen to use the banner text.

For example, running the following commands with root privileges updates the FileVault 2 pre-boot login screen with a login banner:

defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"

touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources

On restart, the FileVault 2 pre-boot login screen should look like this, with the banner text now showing.

To remove these, you would need to boot back into the OS and run the following commands in the Terminal with root privileges:

defaults delete /Library/Preferences/com.apple.loginwindow LoginwindowText

touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources

On restart, the text should no longer appear at the FileVault 2 pre-boot login screen, the OS login window or the screensaver lock window.

7. Booting Into Single-User Mode On A FileVault 2-Encrypted Mac

A while back, I communicated with a Mac admin who was concerned about using FileVault 2 in his environment because he didnt want to lose access to tools like single-user mode. Like a number of Mac admins, hed found single-user mode valuable in helping to diagnose and fix issues on troublesome Macs.

Fortunately, Apple makes it reasonably easy to boot into single-user mode on a FileVault 2-encrypted system. here’s how to boot into single-user on a FileVault 2-encrypted system:

1. Hold down Command-S after powering the system.

2. The Mac will be begin booting into single user, then the FileVault 2 pre-boot login screen will appear.

3. Authenticate at the FileVault 2 pre-boot login screen by selecting an account and providing the accounts password.

4. The Mac will then unlock and continue booting into single-user mode.

8. Using Apple’s Internet Recovery To Unlock Or Decrypt Your FileVault 2-Encrypted Boot Drive

One of the new features that appeared with Macs that shipped with Mac OS X 10.7.x and later versions of OS X was Apple’s Internet Recovery. If you encounter a situation in which you cannot start from the Mac’s Recovery HD partition, such as where the internal hard drive has failed or when you’ve installed a new disk without an OS on it, Mac models that were released after July 2011 can use Internet Recovery. Internet Recovery lets you start your Mac directly from Apple’s servers using a NetBoot-like process and gives you the same functionality that Recovery HD does.

Because Internet Recovery has the same capabilities as your Macs Recovery HD partition, it can be used to unlock or decrypt a FileVault 2-encrypted Mac. This is potentially valuable in case of emergency, as it means that you can do recovery of a FileVault-encrypted drive even in a situation where the Macs Recovery HD partition has been damaged or corrupted in some way.

To force your Mac to boot to Internet Recovery, start up your Mac and hold down Command-Option-R on your keyboard. You should see a gray screen with an animated globe appear and display a message similar to Starting Internet Recovery. This may take a while.

Depending on your connection speed, it may also switch to a countdown clock to show you how long until its fully booted.

Once booted to Internet Recovery, you should see the Recovery interface and the available tools.

From there, you should be able to use Disk Utility or the Terminal applications to unlock or decrypt your FileVault 2-encrypted Mac.

9. FileVault 2 And UUIDs

A little-known fact about FileVault 2 is that it uses the GeneratedUID user attribute (also known as a UUID) of an account to help identify enabled accounts. For example, when you run the fdesetup list command in the Terminal, you’ll see the user information for FileVault 2-enabled accounts appear with both the username and UUID information.

For local accounts, the OS will properly generate a GeneratedUID user attribute to provide a UUID for the local account. Active Directory also generally handles this correctly on Macs, so I haven’t seen UUID problems occur for AD mobile users.

Where I’ve heard of problems have been with Macs bound to non-Apple LDAP servers. If the LDAP server doesn’t provide the GeneratedUID user attribute for its accounts, or it does not provide the UUID in the way that FileVault 2 is expecting, you may see one or more of the following behaviors:

• The LDAP account’s icon disappearing from the FileVault 2 pre-boot login screen – This behavior is generally caused by the GeneratedUID attribute not being set for the LDAP account.
• The account icon being present, but the password not matching the current password on the LDAP server – This behavior has been observed when the GeneratedUID does not match what FileVault 2 is expecting.

A good example of the latter behavior comes from a Mac admin who asked me about the issue he was seeing with passwords not updating. His shop was running an LDAP server as its directory service for its Macs and he had recently added the GeneratedUID user attribute to the accounts on the LDAP server as a fix for accounts disappearing from the FileVault 2 pre-boot login screen. Now, accounts were staying at the FileVault pre-boot login screen, but their passwords were not updating to match what was set on the LDAP server.

In discussing the problem, he mentioned that the UUIDs were using lower-case letters; did that matter? When I followed up on this, he confirmed that instead of his UUIDs looking like this:

7C9AFB0E-E06E-43FA-8E9F-1D410344D2AA

Instead they looked like this:

7c9afb0e-e06e-43fa-8e9f-1d410344d2aa

After confirming that Mac account UUIDs needed to use upper-case alphabetical characters and were case-sensitive, my colleague changed a test account’s UUID to use all upper-case for the alphabetical characters. At that point, FileVault 2 logins for that account began working properly.

If you have an LDAP server and your mobile LDAP accounts aren’t working properly with FileVault 2, here’s what should make FileVault 2 start working properly:

A. On your LDAP server(s), make sure that there’s an apple-generateduid value for your LDAP accounts – If an apple-generateduid value exists in LDAP for a user and is mapped properly to the GeneratedUID attribute on your Macs, FileVault 2 will use the apple-generateduid value stored in LDAP for its UUID.

B. Ensure that all alphabetical characters listed in the apple-generateduid value are using upper-case characters – It’s very important that the locally-set UUID value and the value stored in LDAP match exactly. Otherwise, you may see a recurrence of one or both of the undesired behaviors described above.

10. Automating fdesetup authrestart in 10.9.x or later

One of the more interesting functions in Apple’s fdesetup tool is the authrestart verb, which allows a FileVault 2-encrypted Mac to restart and bypass the FileVault 2 pre-boot login screen. Instead, the Mac reboots as an unlocked system and goes straight to the regular login window.

When you run the fdesetup authrestart command, it asks for a password or a personal recovery key. If using a password, the password must be an account that has been enabled for FileVault 2. After that, it puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.

For those who want to automate this process, Apple added some functionality to fdesetup authrestart in OS X 10.9.x to support importing the authentication via a properly formatted plist. The plist needs to follow the format shown below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist file.

Once the plist file has been set up and properly formatted, run the following command with root privileges to run the authrestart process and reference the password or recovery key in the plist file for authentication.

fdesetup authrestart -inputplist < /path/to/filename.plist

Once the command runs, it puts an unlock key in system memory and reboots the Mac to the OS login window. As part of the Mac’s restart, the reboot process will automatically clear the unlock key from memory.

Apple’s fdesetup tool includes a number of commands, including fdesetup sync. In the fdesetup manpage, sync is listed with the following description:

Synchronizes information from Open Directory to FileVault

Since the description is brief and vague, misunderstandings about what fdesetup sync‘s functions were almost inevitable. Based on my research, here’s fdesetup sync does:

1. Automate the disabling of FileVault 2-enabled accounts

fdesetup sync checks with a Mac’s directory service (Active Directory, Open Directory, OpenLDAP, etc.) to see which accounts have been removed. If an account has been removed from the directory service, running fdesetup sync on an encrypted Mac will automatically remove the account from the list of FileVault 2 enabled accounts. The sync only affects the account’s FileVault 2 status and will not remove the account or account home folder from the Mac.

An important thing to know is that fdesetup is only checking to see if the account is there or not there. It’s unable to determine if an account has been set to be disabled, so if an account has been disabled but the account is still there, fdesetup sync will not change the FileVault 2 status of the account in question.

2. Automate the update of accounts’ user pictures

fdesetup sync checks with a Mac’s directory service (Active Directory, Open Directory, OpenLDAP, etc.) to see which accounts have user pictures associated with the account. If an account’s user picture is updated on the directory service, running fdesetup sync will allow the updated user picture to also be displayed on the FileVault 2 pre-boot login screen.

In many cases, this information will also have been updated automatically by the OS without the need for fdesetup sync to be run.

With those capabilities in mind, here’s two common misunderstandings I’ve seen or heard of in connection with fdesetup sync:

1. fdesetup sync updates the passwords at the pre-boot login screen

It does not. Based on my research, it appears that this job may be handled by opendirectoryd’s FDESupport module. I haven’t confirmed that with Apple though, so for the moment, treat this information about FDESupport as being my opinion rather than a fact.

2. fdesetup sync can automatically add accounts to a FileVault 2-encrypted Mac.

It does not, and the manpage for fdesetup is explicit about this point elsewhere in the manpage.

NOTE: The manpage for fdesetup has a typo where it refers to a fdesetup “syncusers” command. This is actually referring to fdesetup sync.

One of the changes that Apple has introduced with Yosemite is a more straightforward way to recover from login problems at the FileVault 2 pre-boot login screen.

When a FileVault 2-encrypted Mac sits for more than a minute with an account selected at the FileVault 2 pre-boot login screen, a message like the one below should appear:

If you’re having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start it up in the Recovery OS.

If the instructions are followed, the Mac will boot from the Mac’s recovery partition on the next startup and go into a Reset Password wizard.

In the Reset Password wizard, there are currently three options available.

1. I forgot my password
2. My password doesn’t work when logging in
3. My keyboard isn’t working when typing my password to login

Each option will do different things, so let’s take a look at each. For more details, see below the jump.

I forgot my password

The I forgot my password option is most useful to folks who had chosen the option when enabling FileVault 2 to use their Apple ID to unlock the disk and reset your password.

If the user in question had set up their Apple ID to unlock the disk and reset their password, the following options are available:

A. Log in with your Apple ID

B. The Reset Password wizard will check the locked disk.

C. The Mac will communicate back with Apple to match the Apple ID against the FileVault 2 recovery key that was stored with Apple.

D. You’ll be prompted to reset your account’s password to a new one.

Note: This password reset process is designed to reset the password of a local account. If the password reset process is run against a network account which has been enable for FileVault 2, the password sync may be broken between the network account and the directory service that manages the account.

E. You’ll be notified that your password has been reset and that you can now reboot and log in at the FileVault 2 pre-boot login screen.

If the option of using an Apple ID to unlock the disk and reset passwords had not been chosen, the Reset Password wizard notifies the user that their FileVault recovery key had not stored with Apple and that iCloud FileVault recovery is not available. Instead, the user will need to provide their recovery key at the pre-boot login screen.

My password doesn’t work when logging in

The “My password doesn’t work when logging in” option will provide another option for resetting your password, but it relies on the user actually knowing the correct password or having the password to another FileVault 2-enabled account on the Mac.

If the user has the correct password or the password to another account on the Mac which has been enabled for FileVault 2, selecting the “My password doesn’t work when logging in” option will go through the following process:

A. Asking for a password to unlock the boot volume.

Note: This can be the user’s account password (if known and correct) or the password to another FileVault 2-enabled account on the Mac.

B. Select the relevant account.

Note: This password reset process is designed to reset the password of a local account. If the password reset process is run against a network account which has been enable for FileVault 2, the password sync may be broken between the network account and the directory service that manages the account.

C. Enter and verify a new password.

D. You’ll be notified that your password has been reset and that you can now reboot and log in at the FileVault 2 pre-boot login screen.

My keyboard isn’t working when typing my password to login

The “My keyboard isn’t working when typing my password to login” option will provide the option of decrypting your FileVault 2 encrypted Mac. If the user has their account password or the password to another FileVault 2-enabled account on the Mac, selecting the “My keyboard isn’t working when typing my password to login” option will go through the following process:

A. Asking for a password to disable the FileVault 2 encryption on the boot volume.

Note: This can be the user’s account password (if known and correct) or the password to another FileVault 2-enabled account on the Mac.

B. You’ll be notified that the boot volume has been decrypted and that you can now reboot and log in without being stopped at the FileVault 2 pre-boot login screen.

One thing to be aware of is that the decryption process has only been initiated. Decryption will proceed once the Mac has been booted from a drive that is running a regular installation of Yosemite.

One of the requirements when enabling an account for FileVault 2 is that the account’s own password must be provided in order for the account to be enabled. This is because the account’s password is used to generate a unique derived key via PBKDF2. This key is necessary for the account to unlock FileVault 2’s encryption, so the account’s password must be provided in order to enable an account.

Apple recognized that there would be situations where Mac admins would need to set up FileVault 2 for a person where the admin would not have the password for that person’s user account. To avoid the immediate need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with fdesetup‘s enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.

The property list file will be created as a root-only readable file and contain information similar to what’s show below.

Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.

Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:

fdesetup enable -user username -defer /path/to/filename.plist

If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.

If you don’t want to specify the account, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist

On logout, the user will be prompted to enter their account password.

Once entered, FileVault 2 will be enabled and the recovery information plist file will be created. Once the enabling process is complete, the Mac will restart.

An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.

In Yosemite, Apple added new options for fdesetup‘s -defer flag. These new options now allow Mac admins to set a deferred enablement with the following options:

1. Enforce FileVault 2 enablement at logout
2. Enforce FileVault 2 enablement at login
3. Enforce FileVault 2 enablement at both login and logout

For more information, see below the jump.

Yosemite adds the following options for fdesetup‘s enable verb’s -defer flag:

• -forceatlogin max_cancel_attempts
• -dontaskatlogout

These additional options allow a deferred FileVault 2 enablement to be enforced at the login window, rather than waiting for a logout or restart of the Mac in question. To demonstrate how this appears, I’ve made a video showing the following process:

1. Logging in at the OS login window
2. Being prompted to enable FileVault 2
3. The Mac performing initial FileVault 2 setup
4. The Mac automatically rebooting to the FileVault 2 pre-boot login screen.

Note: The video has been edited to artificially reduce the amount of time it took to initialize FileVault 2 setup. Run time of the pre-edited video was 1 minute, 12 seconds.

The -forceatlogin option must be set with an accompanying numerical value. This numerical value governs how many times the account which is being enabled can cancel having the FileVault 2 encryption process begin. For example, running the following command with root privileges will set a maximum number of ten cancellations:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 10

If the user chooses to cancel, they will need to select the Don’t Enable button in the dialog window which will appear. They will also be informed of how many more times they can log in before FileVault 2 encryption must be enabled.

If immediate enforcement is desired, setting a value of zero will enforce FileVault 2 encryption at the next login. To do this, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0

The fdesetup commands shown above will enforce FileVault 2 enablement at both login and logout. If only enforcement at login is desired, the -dontaskatlogout option can be used. This will prevent a deferred FileVault 2 enablement from being enforced at logout. For example, running the following command with root privileges will enforce FileVault 2 encryption at the next login but not prompt the user on logout:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0 -dontaskatlogout

The commands shown above will set up a deferred enablement with a personal recovery key (PRK). To set up a deferred enablement with an institutional recovery key (IRK), you will need to add the -keychain flag to the fdesetup command. For example, if you want to set up a deferred enablement of FileVault 2 where both a PRK and an IRK are used and the user is forced to enable FileVault 2 at the next login, run the following command with root privileges:

fdesetup enable -keychain -defer /path/to/filename.plist -forceatlogin 0

If you want to set up a deferred enablement where only an IRK is used and the user is forced to enable FileVault 2 at the next login, but not prompted at logout, run the following command with root privileges:

fdesetup enable -keychain -defer /path/to/filename.plist -forceatlogin 0 -dontaskatlogout -norecoverykey

With the release of Yosemite, Apple has continued to add functionality to fdesetup, a valuable command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption. This tool gives Mac administrators the following command-line abilities:

• Enable or disable FileVault 2 encryption on a particular Mac
• Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
• Enable one or multiple user accounts at the time of encryption
• Get a list of FileVault 2-enabled users on a particular machine
• Add additional users after FileVault has been enabled
• Remove users from the list of FileVault enabled accounts
• Add, change or remove individual and institutional recovery keys
• Report which recovery keys are in use
• Perform a one-time reboot that bypasses the FileVault pre-boot login
• Report on the status of FileVault 2 encryption or decryption

I’ll be taking you through all of the capabilities mentioned above, with a focus on showing exactly how they work. See below the jump for details.

Enabling Filevault 2 Encryption For One Or Multiple Users

fdesetup is amazingly flexible when it comes to enabling FileVault 2 encryption from the command-line. To start with the simplest method, run the following command with root privileges to enable FileVault 2 encryption:

fdesetup enable

You’ll be prompted for the username and password of the primary user, which is the account you will work with at the FileVault 2 pre-boot login screen once the encryption is turned on.

If everything’s working properly, you’ll next be given an alphanumeric personal recovery key and prompted to restart.

VERY IMPORTANT: The fdesetup-generated personal recovery key is not saved anywhere outside the machine. Make a record of it or you will not have a recovery key available to help unlock your Mac’s encryption in case of a problem.

You can also enable additional user accounts at the time of encryption, as long as the accounts are either local or mobile accounts on the Mac being encrypted. Run the following command with root privileges to enable FileVault 2 and specify the accounts you want:

fdesetup enable -user username -usertoadd other_username -usertoadd yet_another_username

You’ll be prompted for the passwords of the accounts specified. After that, you’ll be given an alphanumeric personal recovery key and prompted to restart. All of the accounts specified should appear at the FileVault 2 pre-boot login screen.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>username</string>
<key>Password</key>
<string>password</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
</array>
</dict>
</plist>

Additional users can be included as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Once the plist has been set up and properly formatted, run the following command with root privileges to enable FileVault 2 encryption and reference the account information in the plist file:

fdesetup enable -inputplist < /path/to/filename.plist

Since the accounts and passwords are in the plist file, fdesetup does not need to prompt for passwords. Instead, the alphanumeric personal recovery key is displayed and the user is prompted to restart. All of the accounts specified in the plist file should appear at the FileVault 2 pre-boot login screen.

To avoid the need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with the enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.

The property list file will be created as a root-only readable file and contain information similar to what’s show below.

Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.

Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:

fdesetup enable -user username -defer /path/to/filename.plist

If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.

If you don’t want to specify the account, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist

On logout, the user will be prompted to enter their account password.

Once entered, FileVault 2 will be enabled and the recovery information plist file will be created. Once the enabling process is complete, the Mac will restart.

An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.

In Yosemite, Apple has added additional options for fdesetup‘s -defer flag. These new options now allow Mac admins to set a deferred enablement with the following options:

1. Enforce FileVault 2 enablement at logout
2. Enforce FileVault 2 enablement at login
3. Enforce FileVault 2 enablement at both login and logout

Yosemite adds the following options for fdesetup‘s -defer flag:

• -forceatlogin max_cancel_attempts
• -dontaskatlogout
  

These additional options allow a deferred FileVault 2 enablement to be enforced at the login window, rather than waiting for a logout or restart of the Mac in question.

The -forceatlogin option must be set with an accompanying numerical value. This numerical value governs how many times the account being enabled can choose to defer having the FileVault 2 encryption process begin. For example, running the following command with root privileges will set a maximum number of ten deferral opportunities:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 10

If the user chooses to defer, they will need to select the Don’t Enable button in the dialog window when it will appear. They will also be informed of how many more times they can log in before FileVault 2 encryption must be enabled.

If immediate enforcement is desired, setting a value of zero will enforce FileVault 2 encryption at the next login. To do this, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0

The fdesetup commands shown above will enforce FileVault 2 enablement at both login and logout. If only enforcement at login is desired, the -dontaskatlogout option can be used. This will prevent a deferred FileVault 2 enablement to be enforced at logout. For example, running the following command with root privileges will enforce FileVault 2 encryption at the next login but not prompt the user on logout:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0 –dontaskatlogout

Enabling Filevault 2 Encryption Using One Or Multiple Recovery Keys

Another capability of FileVault 2 in Yosemite is the ability to use the alphanumeric personal recovery key, an institutional recovery key using /Library/Keychains/FileVaultMaster.keychain, or both kinds of recovery key at the same time.

As seen in the earlier examples, fdesetup will provide the alphanumeric personal recovery key by default. To use the institutional recovery key, the -keychain flag needs to be used when enabling encryption:

fdesetup enable –keychain

The alphanumeric personal recovery key is displayed, but the encryption will also use the /Library/Keychains/FileVaultMaster.keychain institutional recovery key. In case recovery is needed, either recovery key will work to unlock or decrypt the encrypted drive.

If you want to specify that only the FileVaultMaster.keychain institutional recovery key be used, both the -keychain and -norecoverykey flags need to be used when enabling encryption:

fdesetup enable -keychain –norecoverykey

fdesetup is also capable of creating an institutional recovery key, using the -certificate flag to import an existing FileVault 2 public key. Once imported, fdesetup will automatically create a FileVaultMaster.keychain file to store the public key and save the keychain to /Library/Keychains.

The public key will need to be available as a DER encoded .cer certificate file. Once the certificate is available, the following command can be run with root privileges to enable FileVault 2, automatically create the institutional recovery key with the supplied public key and store it as /Library/Keychains/FileVaultMaster.keychain:

fdesetup enable -certificate /path/to/filename.cer

To specify that only the FileVaultMaster.keychain institutional recovery key be used, add the -norecoverykey flag to the command:

fdesetup enable -certificate /path/to/filename.cer -norecoverykey

It is also possible to include the public key data in a plist file, which allows the use of a plist to set up the institutional recovery key. The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>username</string>
<key>Password</key>
<string>password</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
</array>
<key>Certificate</key>
<data>
(Certificate data goes here…)
</data>
</dict>
</plist>

Using the public key’s DER encoded certificate file, the public key data for the plist can be obtained using the base64 tool by using the following command:

base64 /path/to/filename.cer > /path/to/filename.txt

At this point, you would copy the data string contained in the text file and place it into the Certificate value area of the plist file. You would store either the password of an existing FileVault 2-enabled user or (if available) an existing personal recovery key in the Password key in the plist.

Forcing A Restart When Enabling Filevault 2 Encryption

Along with the various options for enabling, it’s also possible to force a restart of the Mac once FileVault 2 has been successfully configured. This can help automate the process of enabling FileVault 2 on a Mac if no input from a logged-in user is needed.

For example, an institution may want to pre-configure its Macs to automatically encrypt with FileVault 2 at first boot with a local admin account enabled. It also wants to use only the institutional recovery key. If a plist with the desired account information and public key data to create the institutional recovery key is available, the following command could be run with root privileges to enable FileVault 2 and force a restart at the first boot:

fdesetup enable -inputplist < /path/to/filename.plist -norecoverykey -forcerestart

Once fdesetup had finished enabling the accounts in the plist file and creating /Library/Keychains/FileVaultMaster.keychain, the Mac would immediately restart and display the enabled accounts at the pre-boot login screen.

If you want to use the alphanumeric personal recovery key with -forcerestart, you will also need to output the personal recovery key and other information into a plist file. Taking the example above, the institution’s automated setup would run the following command with root privileges to automatically encrypt with FileVault 2 at first boot using both types of recovery key and a local admin account enabled:

fdesetup enable -inputplist < /path/to/filename.plist -outputplist > /path/to/recoverykeyinfo.plist –forcerestart

Disabling Filevault 2 Encryption

In contrast to all of the various options available for enabling FileVault 2 using fdesetup, the command to turn off FileVault 2 encryption is the following:

fdesetup disable

Adding Additional Users After Filevault 2 Has Been Enabled

Once FileVault 2 has been enabled, you can add additional users using fdesetup. To do so, you will need to a) wait until the FileVault 2 encryption has completed and b) provide both the username and password of a previously enabled account as well as the password of the account you want to add. The following command run with root privileges will enable a user account named otheruser:

fdesetup add -usertoadd username_goes_here

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>username</string>
<key>Password</key>
<string>password</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
</array>
</dict>
</plist>

When adding additional users using a plist file, the top level Username key is ignored, and the Password key value should either be an existing FileVault user’s password or the recovery key. Additional users can be added as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Once the plist has been set up and properly formatted, run the following command with root privileges to add additional users by referencing the account information in the plist file:

fdesetup add -inputplist < /path/to/filename.plist

Listing Current Filevault 2 Users

To list all accounts enabled for FileVault 2, run the following command with root privileges:

fdesetup list

All accounts will be listed with both the accounts’ username and UUID

Removing Users From The List Of Filevault 2 Enabled Accounts

You can remove users from the list of FileVault enabled accounts by using either their username or the account’s UUID. To remove the account using the username, run the following command with root privileges:

fdesetup remove -user username_goes_here

To remove the account using the account’s UUID, run the following command with root privileges:

fdesetup remove -uuid UUID_goes_here

In both cases, successful removal of the account will not produce any additional output. If the account being removed is not currently enabled for use with FileVault 2, an error message will be displayed.

Managing Individual And Institutional Recovery Keys

fdesetup in Yosemite includes the ability to change, add and remove both personal and institutional recovery keys. This gives Mac admins much greater ability to manage recovery keys, including the capability to quickly update or remove compromised personal and/or institutional recovery keys in the event of a data breach or other problem.

You can add or change recovery keys using fdesetup changerecovery. To change to a new personal key, run the following command with root privileges:

fdesetup changerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user or the existing personal recovery key. Once entered, a new personal recovery key will be generated and displayed. The former personal recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, run the following command with root privileges to change to a new personal recovery key and reference the password or recovery key in the plist file:

fdesetup changerecovery -personal -inputplist < /path/to/filename.plist

In the event that the Mac in question does not have a personal recovery key, running the commands above will add a personal recovery key instead of changing an existing one.

To change to a new institutional recovery key, you will need to have the new public key available. If you have a new institutional public key available as a DER encoded certificate file, you can run the following command with root privileges to replace the current institutional key:

fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer

If an institutional keychain is being used on this Mac, you will see a message that an existing FileVault Master keychain was found and moved. The reason for this is that, as part of this process, the current institutional key’s /Library/Keychains/FileVaultMaster.keychain file is replaced with a new /Library/Keychains/FileVaultMaster.keychain file that includes the new institutional recovery key’s public key.

While the former institutional key’s /Library/Keychains/FileVaultMaster.keychain file was moved and not deleted, the former institutional recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
<key>Certificate</key>
<data>
(Certificate data goes here…)
</data>
</dict>
</plist>

You can also use the current institutional recovery key to authenticate the change to the new institutional key. If you have a keychain file available containing the private key of the current institutional key, you can run the following command with root privileges to replace the current institutional key:

fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer -key /path/to/filename.keychain

You’ll be prompted for the keychain’s password. Once entered, the current institutional key will be replaced with the new one.

In the event that the Mac in question does not have an institutional recovery key, running the commands above (with the exception of using the current institutional key for authentication) will add a institutional recovery key instead of changing an existing one.

Removing Individual And Institutional Recovery Keys

You can remove recovery keys using fdesetup removerecovery. To remove the current personal recovery key, run the following command with root privileges:

fdesetup removerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user or the existing personal recovery key. Once entered, the personal recovery key will be removed from the system. The former personal recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the current personal recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -personal -inputplist < /path/to/filename.plist

To remove institutional recovery keys, run the following command with root privileges:

fdesetup removerecovery -institutional

You’ll be prompted for the password of an existing FileVault 2-enabled user, or a personal recovery key if one is available. Once entered, the institutional recovery key will be removed from the system and will no longer work.

The removal of the institutional key can also be automated using a properly formatted plist via a standard input stream (stdin). The plist is the same as the one used for removing the personal key.

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the institutional recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -institutional -inputplist < /path/to/filename.plist

You can also use the recovery key associated with an institutional key to authenticate the removal of that institutional key. Once authenticated, the institutional key is removed from the system and will no longer work.

If you have a keychain file containing the private key for the current institutional key available, you can run the following command with root privileges to remove the current institutional key:

fdesetup removerecovery -institutional -key /path/to/filename.keychain

It is possible to use fdesetup removerecovery to remove one or both recovery keys on a particular Mac. Once the recovery keys are removed, the only way to unlock the FileVault 2 encryption is by using the password of an enabled account. That said, you could use fdesetup changerecovery to add one or both types of recovery keys back to the encrypted Mac.

Recovery Key Reporting

To go along with the ability to manage recovery keys, fdesetup in Yosemite enables Mac admins to detect which types of recovery keys are in use on a particular Mac. To check if a personal recovery key is in use, run the following command with root privileges:

fdesetup haspersonalrecoverykey

If FileVault 2 is using a personal recovery key, this command will return true. Otherwise it will return false.

To check if an institutional recovery key is in use, run the following command with root privileges:

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an institutional recovery key, this command will return true. Otherwise it will return false.

One-Time Filevault 2 Encryption Bypass

fdesetup in Yosemite has the authrestart verb, which allows a FileVault 2-encrypted Mac to restart, bypass the FileVault 2 pre-boot login screen, and goes straight to the OS login window. To restart and bypass the FileVault 2 pre-boot login screen, run the following command with root privileges:

fdesetup authrestart

When you run the fdesetup authrestart command, it asks for the password of an existing FileVault 2-enabled user or a personal recovery key.

Once authenticated, the authrestart process puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.

It’s also possible to automate this process by importing the authentication via a properly formatted plist. The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

You would store either the password of an existing FileVault 2-enabled user or a personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, use the following command with root privileges to run the authrestart process and reference the password or recovery key in the plist file for authentication:

fdesetup authrestart -inputplist < /path/to/filename.plist

fdesetup authrestart may not be supported by all Yosemite-compatible Macs. To verify if a specific Mac supports authrestart, run the following command with root privileges:

fdesetup supportsauthrestart

If the Mac supports fdesetup authrestart, this command will return true. Otherwise it will return false.

Reporting On Filevault 2 Encryption Or Decryption Status

fdesetup can report on FileVault 2 encryption or decryption status. Running the following command with root privileges will display the current state:

fdesetup status

Conclusion

In Yosemite, Apple has continued the evolution of the fdesetup tool to add even more functionality. fdesetup in Yosemite can enable FileVault 2, add and remove users from the list of FileVault 2 authorized accounts, manage recovery keys, report on FileVault 2’s status and more. Among its greatest strengths are:

• It allows options for automating FileVault 2 setups via scripting.
• fdesetup’s defer option can be used to set up a self-service procedure for enabling encryption either at login or logout.
• It supports multiple recovery keys for FileVault 2, giving Mac admins more options for handling recovery situations.
• It allows you to rotate or remove recovery keys on an as-needed basis.
• It provides a one-time method for bypassing encryption on restart, to accommodate situations where an encrypted Mac needs to be restarted from a remote location.

Managing FileVault 2 encryption using this tool will save you time and give encryption options available with no other software.

I’d previously written a post about Yosemite’s FileVault 2 pre-boot recovery options and how they can be accessed via the FileVault 2 pre-boot login screen. This process uses a Reset Password wizard to help users recover from login problems at the FileVault 2 pre-boot login screen.

I recently learned that the FileVault 2 Reset Password wizard can also be manually launched while booted from the Recovery partition. For more details, see below the jump.

Accessing the FileVault 2 Reset Password wizard

1. Boot to the Recovery HD partition
2. Open Terminal from the Utilities menu

3. In Terminal, type the following command:

filevaultrecovery

4. FileVault 2’s Reset Password wizard should appear.

For more information about the Reset Password wizard and how it works, please see the link below:

https://derflounder.wordpress.com/2015/01/17/yosemites-filevault-2-pre-boot-recovery-options/

Hat tip: Rhys Thornett in the JAMF Nation forums.

When a FileVault 2-encrypted Mac sits for more than a minute with an account selected at the FileVault 2 pre-boot login screen, a message like the one below should appear:

If you’re having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start it up in the Recovery OS.

If the instructions are followed, the Mac will boot from the Mac’s recovery partition on the next startup and go into a FileVault 2 Reset Password wizard.

In the Reset Password wizard, there are currently three options available.

1. I forgot my password
2. My password doesn’t work when logging in
3. My keyboard isn’t working when typing my password to login

However, if you don’t want or need to use the Reset Password wizard, there’s not an obvious way to get back to the FileVault 2 pre-boot login screen. There’s no visible way to quit, and rebooting the Mac using the power button will return you to the Reset Password wizard.

Thanks to research by the folks in the ##osx-server IRC room, it looks like there’s a relatively straightforward way to reset the boot process:

1. While booted to the initial Reset Password wizard screen, press and hold the power button on your Mac to shut it down
2. Reset NVRAM
3. Once the NVRAM reset procedure has been completed, let the Mac boot.

At that point, you should be taken to the FileVault 2 pre-boot login screen instead of the Reset Password wizard.

Credit to arrose in the ##osx-server IRC room for figuring this out.

Update 5-28-2015: As elvisizer mentioned in the comments, there is also the option of revealing the hidden menu at the top of the screen and using the Startup Disk preferences to select your hard drive and reboot back to FileVault 2 pre-boot login screen. Since this is easier to show rather than explain, I’ve made a short video of the process.

Note: The password used to unlock the drive in the Startup Disk preferences can be the password of any account that appears on the Mac’s FileVault 2 pre-boot login screen. If you can log in at the pre-boot login screen, you should be able to enter your password to unlock.

When Yosemite was released in October 2014, one of the changes it introduced was including a new FileVault 2 enablement option in Apple’s Setup Assistant. This option encouraged new users of Yosemite to enable FileVault 2 encryption and had the choice to enable FileVault 2 selected by default.

When the encryption process began, a significant issue then appeared for a number of users where the Mac would report Encryption paused during the encryption process, then never resume the encryption process.

This produced a situation where the Mac could not complete encryption, but would not decrypt either because the encryption process had not completed. The only fix appeared to be deleting the existing CoreStorage volume, which addressed the issue at the cost of deleting everything stored on the boot drive.

Fortunately, OS X 10.10.3 includes a fix that should stop this issue from occurring on OS X 10.10.3 and later. There is also now a procedure that should fix Macs still affected by this problem. For more details, see below the jump.

The root cause for the encryption pausing and not resuming was a problem with resizing the CoreStorage volume. When the CoreStorage volume was unable to grow, the encryption was paused and could not resume until the resize issue was addressed.

To fix this issue:

1. Update your Mac to 10.10.3, or boot from an alternate drive which is running 10.10.3.
2. Unlock the encrypted drive if necessary
3. Open Terminal
4. Run the following command to get the disk identifier for the boot drive:

diskutil list

5. Once you have the disk identifier information, run the following command with root privileges:

fsck_cs -y disk_identifier_goes_here

Running the fsck_cs tool should repair the CoreStorage volume and address the resizing issue. As part of the output, it should show that encryption is resuming.

Apple announced on Saturday, August 8th that the FIPS 140-2 validations for the cryptographic modules used by iOS 8 and OS X 10.10.x have now been completed. This is significant news for folks who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)

For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.

As part of the announcement, Apple has released KBase articles and guidance for security offices who deal with encryption:

OS X Yosemite: Apple FIPS Cryptographic Modules v5.0 – http://support.apple.com/kb/HT205017

Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Yosemite v10.10 – https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT205017/APPLEFIPS_GUIDE_CO_OSX10.10.pdf

According to Apple, the OS X Yosemite Cryptographic Modules, Apple OS X CoreCrypto Module v5.0 and Apple OS X CoreCrypto Kernel Module v5.0, require no setup or configuration to be in “FIPS Mode” for FIPS 140-2 compliance on devices running OS X Yosemite v10.10.

FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Yosemite v10.10 documentation, in the Compliant Applications and Services section.

For more information about the validation certification, please see below the jump.

iOS 8

Module Name: Apple iOS CoreCrypto Module, v5.0
Certificate #2396: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2015.htm#2396
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2396.pdf

Module Name: Apple iOS CoreCrypto Kernel Module, v5.0
Certificate #2407: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2015.htm#2407
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2407.pdf

OS X Yosemite v10.10

Module Name: Apple OS X CoreCrypto Module, v5.0
Certificate #2408: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2015.htm#2408
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2408.pdf

Module Name: Apple OS X CoreCrypto Kernel Module, v5.0
Certificate #2411: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2015.htm#2411
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2411.pdf