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.
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.
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:
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:
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.
Keynote slides: http://tinyurl.com/PSUMac2014key
As part of the man page for fdesetup, 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 which contains the private key for an institutional recovery key:
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 file into the /tmp directory, you would reference /tmp/filename.keychain as the KeychainPath plist value. If the password to unlock that keychain is seKritPassword, you would reference seKritPassword as the KeychainPassword plist value.
One particular thing to note is that the KeychainPath entry on the fdesetup man page references that this works with certain fdesetup commands, but does not specify which commands are applicable.
As of OS X 10.9.4, it appears that you can leverage the KeychainPath and KeychainPassword plist keys with the following two fdesetup commands.
If using the current institutional key to authenticate, the plist should look like this.
<?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 will look like this.
<?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>
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 a 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. The password must be an account that has been enabled for FileVault 2 (i.e. an account that shows up at the FileVault 2 pre-boot login screen.) 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 Mavericks to support 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 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 to run the authrestart process and reference the password or recovery key in the plist file for authentication.
sudo fdesetup authrestart -inputplist < /path/to/filename.plist
The man page for fdesetup also indicates that you can use a keychain with both the private and public keys associated with an institutional recovery key to authenticate the authrestart process. Based on the manpage, you should be able to run the following command to run the authrestart process and reference the institutional recovery key for authentication.
sudo fdesetup authrestart -key /path/to/filename.keychain
As of OS X 10.9.3, this does not appear to work. Instead of being prompted for the keychain’s password and the Mac restarting, an Error: Unable to restart message is displayed and nothing else happens.
If manually restarted, the Mac will reboot to the FileVault 2 pre-boot login screen.
I’ve filed a bug with Apple at bugreport.apple.com about this behavior. If you want to also file a bug report on this, please reference the following bug ID when submitting your report:
I’ve got the details of my bug report posted at Open Radar:
I’ll be speaking about FileVault 2 at the Penn State MacAdmins Conference 2014, which is being held from July 8th – 11th, 2013 in State College. For those interested, my talk will be on Thursday, July 10th.