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.
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:
- The Mac is not a laptop.
- The OS is unable to check the processor for certain features.
- The processor does not support AES-NI.
- The OS is booting from an external drive.
- There’s more than one user account on the system.
- The boot drive does not have a CoreStorage logical volume set up on it.
- The boot drive is already encrypted.
- The Mac was configured by the Device Enrollment Program to not display this option.
- This window had already appeared for this drive and user account.
- The user’s home folder is located somewhere other than the boot drive.
- The user has not logged into iCloud on this machine.
These criteria can be examined using the following procedure:
- Install Xcode or the Xcode Command Line Tools.
- 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
FileVault 2 decryption can be initiated but will not complete while booted from Yosemite’s Recovery HD
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:
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:
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: