Using a FileVault 2 institutional recovery key in Mavericks to generate an individual recovery key

A change that occurred between Mountain Lion and Mavericks is that it’s no longer possible to add additional users with fdesetup by using a non-enabled admin user’s credentials. Instead, you must use either a previously-enabled user’s credentials or use a personal recovery key (aka an individual recovery key) to authorize adding a user account with fdesetup add.

The recovery key option is specifically for the personal recovery key; there is not an option in fdesetup add to use the institutional recovery recovery. This is an issue for IT shops that are using fdesetup enable with the -defer option in combination with an institutional recovery key because the Mavericks way to authorize additional accounts depends on an enabled user’s password (which in this case would be an end-user’s password) or a personal recovery key (which doesn’t exist.)

There is a way to fix this in a roundabout way, by leveraging the ability of fdesetup in Mavericks to generate a new personal recovery key using fdesetup changerecovery. fdesetup changerecovery allows the use of an institutional recovery keychain to authorize the generation of a new personal recovery key. To do this, run the following command:

sudo fdesetup changerecovery -personal -key /path/to/keychain_with_both_private_and_public_recovery_keys_inside.keychain

You’ll be prompted for the password to unlock the institutional recovery keychain. Once that password is provided, a new personal recovery key will be generated.

To verify that this new recovery key is valid, run the following command:

sudo fdesetup validaterecovery

If the new personal recovery key is valid, you should receive a result of “true”.

fdesetup can also export the recovery key to a plist file by using the -outputplist flag. To generate a new personal recovery key and have it exported to a plist, run the following command:

sudo fdesetup changerecovery -personal -key /path/to/FileVaultMaster.keychain -outputplist > /path/to/new_recovery_key.plist

The plist should contain information similar to what’s shown below and include the new personal recovery key information in the RecoveryKey plist value.

<?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>Change</key>
	<true/>
	<key>EnabledDate</key>
	<string>2013-12-20 13:51:58 -0500</string>
	<key>HardwareUUID</key>
	<string>00000000-0000-1000-8000-000C2991B2C4</string>
	<key>HasMasterKeychain</key>
	<true/>
	<key>RecoveryKey</key>
	<string>MLZA-NZTC-MVLM-O82Q-Y8TW-F8FX</string>
	<key>SerialNumber</key>
	<string>VM401BlpPKGn</string>
</dict>
</plist>

fdesetup changerecovery doesn’t currently include a way to utilize the institutional recovery keychain without requiring a password to be entered, but it is possible to automate the password entry process using an expect script or other means. As an example, I’ve written an expect script which automates running the fdesetup changerecovery process described above to generate a new personal recovery key and export it to a plist.

	#!/usr/bin/expect
	log_user 0
	set password s3kr1tp4ssw0rd
	spawn fdesetup changerecovery -personal -key /path/to/keychain_with_both_private_and_public_keys_inside.keychain -outputplist > /path/to/new_recovery_key.plist
	expect "keychain: "
	send "$password\n"
	log_file -a /path/to/new_recovery_key.plist
	expect EOF

view raw

gistfile1.sh

hosted with ❤ by GitHub