FileVault 2 Institutional Recovery Keys – Creation, Deployment and Use

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.