I’ll be speaking about FileVault 2 at the JAMF Nation User Conference 2013, which is being held from October 15th – 17th, 2013 in Minneapolis, MN. For those interested, my talk will be on Wednesday, October 17th.
For a description of what I’ll be talking about, please see the Understand FileVault 2 and Manage Disk Encryption with the Casper Suite session description. You can see the whole list of speakers here on the Sessions page.
For those who wanted a copy of my FileVault 2 talk at JAMF Nation User Conference 2013, here are links to the slides in PDF and Keynote format.
PDF – http://tinyurl.com/jnuc2013fv2PDF
Keynote – http://tinyurl.com/jnuc2013fv2keynote
With the release of OS X Mavericks, Apple has added additional features 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:
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 the 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 to enable FileVault 2 encryption:
sudo 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 to enable FileVault 2 and specify the accounts you want:
sudo 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 to enable FileVault 2 encryption and reference the account information in the plist file:
sudo 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 also has a -defer flag 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 to defer enabling FileVault 2 and specify the account you want:
sudo 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:
sudo 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.
Another capability of FileVault 2 in Mavericks 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:
sudo 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:
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. 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 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 <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.
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 to enable FileVault 2 and force a restart at the first boot:
sudo 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 to automatically encrypt with FileVault 2 at first boot using both types of recovery key and a local admin account enabled:
sudo fdesetup enable -inputplist < /path/to/filename.plist -outputplist > /path/to/recoverykeyinfo.plist –forcerestart
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:
sudo fdesetup disable
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 will enable a local user named administrator:
sudo fdesetup add -usertoadd administrator
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 to add additional users by referencing the account information in the plist file:
sudo fdesetup add -inputplist < /path/to/filename.plist
To list all accounts enabled for FileVault 2, run the following command:
sudo fdesetup list
All accounts will be listed with both the accounts’ username and UUID
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:
sudo fdesetup remove -user username
To remove the account using the account’s UUID, run the following command:
sudo fdesetup remove -uuid UUID_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.
fdesetup in Mavericks adds the new 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:
sudo 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 to change to a new personal recovery key and reference the password or recovery key in the plist file:
sudo 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 to replace the current institutional key:
sudo 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 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 a 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.
You can remove recovery keys using fdesetup removerecovery. To remove the current personal recovery key, run the following command:
sudo 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 to remove the current personal recovery key and reference the password or recovery key in the plist file:
sudo fdesetup removerecovery -personal -inputplist < /path/to/filename.plist
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.
To go along with the ability to manage recovery keys, fdesetup in Mavericks 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:
sudo 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:
sudo fdesetup hasinstitutionalrecoverykey
If FileVault 2 is using an institutional recovery key, this command will return true. Otherwise it will return false.
fdesetup in Mavericks 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:
sudo 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.
fdesetup authrestart may not be supported by all Mavericks-compatible Macs. To verify if a specific Mac supports authrestart, run the following command:
sudo fdesetup supportsauthrestart
If the Mac supports fdesetup authrestart, this command will return true. Otherwise it will return false.
fdesetup can report on FileVault 2 encryption or decryption status. The following command will display the current state:
sudo fdesetup status
fdesetup was already a Swiss Army knife for enabling and managing FileVault 2 when it first appeared in Mountain Lion. In Mavericks, Apple has built on that strong foundation to add even more functionality. fdesetup in Mavericks 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 it’s greatest strengths are:
If you’re managing FileVault 2 encryption in your own environment, I strongly recommend using this tool. Properly used, it will save you time and give encryption options available with no other software.
Over the past few months, I’ve told hundreds of people the following information about fdesetup in Mountain Lion:
“Once the Mac has been fully encrypted with FileVault 2, you can add additional users using fdesetup. To do so, you will need 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.
There’s something that’s interesting to know about this method: the admin user in question does not themselves need to be enabled for FileVault 2. In my testing, I found that an admin user can authorize the enabling of other accounts even if the admin account wasn’t enabled. An admin account can also enable itself using this process, by being both the authorizing admin account and the account being enabled. This is similar to the System Preferences behavior, where an admin account could enable itself by logging in and clicking the lock in the FileVault preference pane.
Since a key has to be involved somewhere, I’ve got an inquiry open with Apple as to why this works but I haven’t heard back yet.“
I’ve now heard back. See below the jump for the details.
Mountain Lion
In Mountain Lion, once FileVault 2 is enabled, fdesetup uses the keys which become available after the volume is unlocked. It prompts for credentials in case those keys are no longer available. This was how non-enabled admin users were able to enable other non-enabled users; fdesetup had access to the needed key.
In the case of the example below, fv2admin is a non-enabled admin user on this Mountain Lion Mac.
Using fdesetup on Mountain Lion, fv2admin can enable other non-enabled users like the fv2user account.
fv2admin can enable its own account by being both the authorizing account and the account being enabled.
Mavericks
In Mavericks, fdesetup now prevents non-enabled admin users from enabling other non-enabled users.
On a Mavericks Mac, fv2admin gets an authorization error when trying to enable the fv2user account.
fv2admin can also no longer enable itself.
That said, if your encrypted Mavericks Mac has a personal recovery key available, the personal recovery key can be used to authorize non-enabled accounts.
In the case of the example below, this Mavericks Mac is set up with a personal recovery key. Using fdesetup on Mavericks, the fv2admin account can use sudo to run fdesetup and enable other non-enabled users by entering the personal recovery key when prompted for a password or recovery key.
Another approach to enable non-enabled admin accounts 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 preference pane and authenticate when prompted.
4. Click the Enable Users button in the preference pane
5. The previously non-enabled admin user account will appear with a green checkbox to show that the account has been enabled.
This approach has worked since FileVault 2 was first introduced in Lion and it continues to work in Mavericks.
One great thing about using FileVault 2 to encrypt your Mac is that Apple’s OS installers are aware of how to work with a FileVault 2-encrypted Mac. For example, you can upgrade from OS X 10.8.5 to OS X 10.9.0 on a FileVault 2-encrypted Mac using the same process that you would use on an unencrypted Mac.
Since this is a process that’s more easily shown than explained, I’ve made a three minute video showing the process as I saw it.
Here’s the procedure I used:
Note: The video has been edited to artificially reduce the amount of time the installer takes to run. Run time of the pre-edited video was 50 minutes.
Did you notice that something was missing from this upgrade procedure?
I was never asked to log in at the FileVault 2 pre boot login screen. Why?
During the upgrade process, an unlock key is being put into the SMC by the Mavericks installer to unlock the encrypted volume at boot. The reboot process then automatically clears the key from the SMC. This process is similar to how fdesetup authrestart works, except that the user is not being prompted to authorize it.
This behavior is convenient, but it’s something that the user should be asked specifically to authorize. As part of that, I’d previously filed a bug report 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:
14148042
I’ve got the details of my bug report posted at Open Radar:
http://openradar.appspot.com/radar?id=4931511514038272
I’ve updated the FileVault 2 status check scripts so that they’re now able to correctly handle Macs running Mavericks. The scripts should now report accurately on the FileVault 2 status of Macs running 10.7.x – 10.9.x.
The changes are now available as part of my regular script. They have also been rolled into both the Casper Extension Attribute and the Absolute Manage Custom Info Item scripts. Use them in good health and please let me know if you find any problems with them.
Apple officially announced on Monday, November 11th that the FIPS 140-2 validations for the cryptographic modules used by iOS 7 and OS X 10.9.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 today’s announcement, Apple has released KBase articles and guidance for security offices who deal with encryption:
OS X Mavericks: Apple FIPS Cryptographic Modules v4.0 – http://support.apple.com/kb/HT6051
Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mavericks v10.9 – http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT6051/APPLEFIPS_GUIDE_CO_OSX10.9.pdf
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 Mavericks v10.9 documentation, in the Compliant Applications and Services section.
JAMF Software has posted the session video for my FileVault 2 session from JAMF Nation User Conference 2013.
For those interested, the JNUC session videos are available on YouTube. For convenience. I’ve linked my FileVault 2 session here:
I was recently wrong on the internet again, but as always making a mistake gave me a chance to learn from it. What I learned was the method Mac admins choose to use upgrading their Macs to Mavericks may have behavior that apply specifically to FileVault 2-encrypted Macs. See below the jump for details.
There are two main ways that Mac admins are generally upgrading Macs to Mavericks:
When upgrading a FileVault 2-encrypted Mac to Mavericks, you may see the following behavior when rebooting as part of the upgrade process:
createOSXInstallPkg – The Mac will boot to the FileVault 2 pre-boot login screen and require an account password to unlock. Once provided, the Mac boots and the upgrade process will proceed.
Apple’s Mavericks installation methods – The Mac will reboot without stopping at the pre-boot login screen during the upgrade process. Once the upgrade process is completed, the Mac will resume the expected behavior of booting to the FileVault 2 pre-boot login screen.
The difference has to do with which OS’s installation method is being used. Greg reverse-engineered 10.7′s installation process (see timestamp [18:43:31 UTC]) when he built createOSXInstallPkg (originally known as InstallLionPkg). That installation method does not include the Apple Mavericks installer’s ability to store an unlock key in system memory or the SMC so the disk is not automatically unlocked at boot. With the disk being locked, the Mac will boot to the FileVault 2 pre-boot login screen so that it can be unlocked. To help illustrate this, I’ve made a video showing the behavior.
Apple’s installation method does include putting an unlock key in memory, so the Apple Mavericks installer will keep supplying the unlock key as needed until the upgrade process is completed. At that point, the process that stores the key in memory stops running and the Mac goes back to the expected boot behavior where the Mac boots to the FileVault 2 pre-boot login for authentication before unlocking the disk. To help illustrate this, I’ve made a video showing the behavior.
When upgrading a FileVault 2-encrypted Mac to Mavericks, you may see the following behavior if the disk being upgraded is in the process of encrypting or decrypting:
createOSXInstallPkg – Installation of the createOSXInstallPkg installer fails.
Apple’s Mavericks installation methods – Upgrade proceeds without errors.
The difference here has to do with lines 835 – 858 of the postflight script in a createOSXInstallPkg-built OS X installer.
target_volume_is_corestorage_or_raid = False
# check the install volume to see if it's CoreStorage
cs_state = getCoreStorageStatus(installvolumepath)
if cs_state in ['Encrypted', 'Not encrypted']:
target_volume_is_corestorage_or_raid = True
# make sure we can find the Apple_Boot helper partition before
# we continue
helper_partitions = findBootHelperPartitions(installvolumepath)
if not helper_partitions:
cleanupFromFailAndExit(
'Cannot find a Recovery partition set as a boot helper for '
'CoreStorage volume %s. Cannot continue.' % installvolumepath)
print ('%s appears to be a CoreStorage volume.'
% installvolumepath)
elif cs_state == 'Not CoreStorage':
target_volume_is_corestorage_or_raid = False
else:
# volume is being converted to or from Core Storage
# we should not install now.
cleanupFromFailAndExit(
'Cannot install to CoreStorage volume %s in the middle of '
'conversion. Current state is: %s.\nPlease wait for conversion '
'to complete, restart, and try again.'
% (installvolumepath, cs_state))
As a safety check, this section of the postflight script checks to see if target drive has a CoreStorage volume and if it is in the process of converting. A converting CoreStorage volume means the drive is either being encrypted or decrypted.
If a converting CoreStorage volume is detected, this section of the postflight script prevents the install process from proceeding. In turn, the installer stops and reports an installation failure. To help illustrate this, I’ve made a video showing the behavior.
Apple’s Mavericks installation methods does not include this check and proceeds without errors on a converting CoreStorage volume. To help illustrate this, I’ve made a video showing the behavior.
With Apple’s release of OS X 10.9.1, it looks like the automated FV 2 unlock process that Apple built into the Mavericks install process has been included with OS X updates. To illustrate, I’ve made a video showing the following process:
Note: The video has been edited to artificially reduce the amount of time the install process takes to run. Run time of the pre-edited video was 14 minutes.
How is the pre-boot login screen bypassed?
During the upgrade process, an unlock key is being put into the SMC by the update process to unlock the encrypted volume at boot. The reboot process then automatically clears the key from the SMC. This process is similar to how fdesetup authrestart works, except that the user is not being prompted to authorize it.
How is the Mac automatically logging into my account following the update?
This question is unresolved at this time and this behavior is worrisome to me. Walking away at the wrong moment may give an opportunity for someone to get physical access to my Mac without my knowledge.
The length of that window of vulnerability is going to be determined by when the screensaver kicks in, as enabling FileVault 2 will also set your Mac to require your account’s password before exiting the screensaver.
Do you have information about how the Mac is automatically logging into an account after an update? Please let me know in the comments.
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.
I recently purchased a new MacBook Pro Retina for my own use and encrypted it with FileVault 2. As part of setting it up, I ran the following command to ensure that the laptop hibernated (where the contents of the RAM are written to disk) and also have the FileVault 2 key automatically removed from the saved RAM state when I put the laptop to sleep:
sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25
I then put my laptop to sleep and shortly thereafter went to sleep myself.
The next morning, I went to wake up my laptop. I expected to see my account icon and a password blank at the FileVault 2 login screen, which would indicate that it had been asleep.
Instead, I saw the icons for all of the FileVault 2-enabled accounts on my laptop.
That indicated that my laptop had turned off instead of being asleep. For more details, see below the jump.
I hadn’t had this issue on my previous laptop, which was a 13 inch 2011 MacBook Pro. Then I remembered that my new laptop supported Apple’s new Power Nap technology and the old one had not.
My working theory at that point was that Power Nap woke up my laptop. Because the FileVault 2 key had been removed from memory, the waking process then stopped and waited for the account password to be entered.
In a situation like this, the Mac will shut down within a few minutes as a safety measure. This shutdown happens because the OS isn’t running and there’s no way for the functionality available at the FileVault 2 pre-boot login screen to monitor or control the laptop’s temperature.
That would mean that the sequence of events would go like this:
Working with this theory, I went into the Energy Saver settings in System Preferences and disabled the Power Nap settings for both the power adapter and battery.
The Power Nap settings can also be disabled by running the following command in the Terminal:
sudo pmset -a darkwakes 0
Adding -a to the pmset command will disable Power Nap for the Battery, Power Adapter and UPS Energy Saver settings.
Once I’d disabled Power Nap, I thought the problem would be solved. Nothing else should wake it up, right? Then I put my laptop to sleep the next night and tried to wake it the following morning. The laptop was off again, so not fixed.
After doing more research, I ran across this thread in the Apple Discussions forums, where people were discussing how their 2013 Airs and Retinas were waking unexpectedly from sleep and saw this post. In particular, the fact that the problem seemed to stop after pmset‘s standby and standbydelay settings were changed. After verifying the difference between pmset’s autopoweroff and standby settings, I then ran the following commands in Terminal:
sudo pmset -a darkwakes 0
sudo pmset -a standby 0
sudo pmset -a standbydelay 0
I then ran the pmset command again to enable hibernation and and remove the FileVault key from memory:
sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25
Once I did that, my pmset settings looked like this:
After making those changes to my power management settings, my encrypted laptop started sleeping and waking like I wanted it to.
To verify that Power Nap was still part of the issue, I re-enabled Power Nap in my Power Adapter settings and put my laptop to sleep for two hours.
When I tried to wake it, the laptop was off again, so I re-disabled Power Nap. Since then, no problems have been seen.
I’ll be speaking about FileVault 2 at MacIT 2014, which is being held from March 26th – 29th, 2014 in San Francisco. For those interested, my talk will be on Wednesday, March 26th.
For a description of what I’ll be talking about, please see the IT804: Managing Mavericks’ FileVault2 with fdesetup session page, which is linked on the MacIT Wednesday Full Agenda page.
Recently, I was asked how to disable FileVault 2 without needing to go into System Preferences. The general idea was that an organization may want to provide their users without admin rights a way to turn off FileVault 2 on an as-needed basis.
Most of the work I’ve done has been focused around turning on FileVault 2 and managing it, rather than providing a way for users to turn it off. That said, fdesetup on both Mountain Lion and Mavericks provides a way to disable FileVault 2 with proper authorization.
To disable FileVault 2 on the Mac you’re logged into, run the following command with root privileges:
fdesetup disable
You’ll be prompted for either the password of an enabled user or a personal recovery key.
Note: If a personal recovery key was not set up on a particular Mac, you’ll only be prompted for the password of an enabled user.
Once the password or personal recovery key has been entered, the Mac will begin to decrypt.
For those who want to automate this procedure, you can do this using an expect script or other means. As an example, I’ve written an expect script which automates running the fdesetup disable process described above.
One of the functions added to the fdesetup tool on 10.9 is removerecovery. This function removes the current recovery key(s) from a FileVault 2-encrypted Mac and can be used to remove with the personal and/or institutional recovery keys from a Mac.
One interesting aspect of this is that this function can be used to remove all recovery keys from a FileVault 2-encrypted Mac running Mavericks. Once the recovery keys have been removed from your Mac, only FileVault 2-enabled accounts will be able to unlock or decrypt it. For more details, see below the jump.
Note: I do not advocate removing all recovery keys from your system. They’re designed as a fallback way to get into your machine in case of a problem.
To remove an existing personal recovery key, run the command below 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.
To remove an existing institutional key, run the command below with root privileges:
fdesetup removerecovery -institutional
You’ll be prompted for the password of an existing FileVault 2-enabled user. You can also use an existing personal recovery key if applicable.
To double-check that the recovery keys have been removed, fdesetup has additional functions to tell you if a personal or institutional key is in use. To verify if the personal recovery key has been removed, run the command below with root privileges:
fdesetup haspersonalrecoverykey
If it returns false, the FileVault 2 encryption on this Mac does not currently have an associated personal recovery key.
To verify if the institutional recovery key has been removed, run the command below with root privileges:
fdesetup hasinstitutionalrecoverykey
If it returns false, the FileVault 2 encryption on this Mac does not currently have an associated institutional recovery key.
A FileVault 2-encrypted Mac without any associated recovery keys should return false to both commands.
Another way to verify that all recovery keys have been removed is to look in the FileVault preference pane in System Preferences. If a personal recovery key is being used on a FileVault 2-encrypted Mac (either by itself, or in combination with the institutional key), the FileVault preference pane should display the following message:
A recovery key has been set.
If an institutional key is being used as the sole recovery key, the FileVault preference pane should display the following message:
A recovery key has been set by your company, school or institution.
If all recovery keys have been removed from the encrypted Mac, there should be no message displayed in the FileVault preference pane.
For those who wanted a copy of my FileVault 2 talk at MacIT 2014, here are links to the slides in PDF and Keynote format.
PDF: http://tinyurl.com/macit14fv2PDF
Keynote slides: http://tinyurl.com/macit14fv2keynote
Unlocking or decrypting a FileVault 2-encrypted Fusion drive from the command line can be a little different from how you would handle a non-Fusion drive. This is because Apple has created Fusion drives by using the Core Storage volume manager that they first introduced in OS X 10.7.x. Normally when you enable FileVault 2, there is not an existing Core Storage volume on the drive being encrypted and the FileVault 2 process creates it. When a drive is decrypted using the diskutil cs revert command, that CoreStorage volume is then removed as part of the process.
However, with Fusion drives, not only is there an existing CoreStorage volume present before encryption, you want to make sure it’s not being removed as part of the decryption process. Doing so would destroy the Fusion drive setup and potentially result in the loss of all data stored on the Fusion drive.
There’s two tools that you can use to safely decrypt a Fusion drive on OS X Mavericks:
fdesetup
fdesetup includes the disable verb, which turns off FileVault 2 encryption on a FileVault 2-encrypted Mac. To decrypt using fdesetup, run the following command with root privileges:
fdesetup disable
You’ll be prompted for the password of an account that’s authorized to unlock the encryption, or the personal recovery key if available. Once provided, decryption of the encrypted volume will begin. One limitation of using fdesetup to decrypt is that you’ll need to be booted from the same boot drive that you want to decrypt, as you can’t specify a different drive with fdesetup.
diskutil
diskutil is able to decrypt FileVault 2-encrypted drives other than the one you’re booted from, but you’ll need to identify the Logical Volume UUID of the encrypted drive using the following command:
diskutil cs list
Running that command will give you a listing of all Core Storage volumes. To help identify what you’re looking for, I’ve highlighted the UUID of the encrypted drive in this example:
Once you have the UUID, you can then either unlock or decrypt the encrypted volume using the following commands. If the goal is to decrypt, be aware that you’ll need to unlock the drive first.
Using the password of an authorized account on the command line
To unlock, run the following command:
diskutil cs unlockVolume UUID -stdinpassphrase
The -stdinpassphrase flag will cause the command to prompt you for the password of an account that’s authorized to unlock the encryption. If successful, the drive will unlock and mount. You should see output similar to that shown below.
Once you’ve unlocked the disk, you can then decrypt it and return it to being an unencrypted Core Storage volume.
To decrypt, run the following command:
diskutil cs decryptVolume UUID -stdinpassphrase
You’ll be prompted for the password of an account that’s authorized to unlock the encryption. Once provided, decryption of the encrypted volume will begin.
Using the personal recovery key on the command line
If you don’t have the password of any of the authorized accounts and the Mac has a personal recovery key associated with it, you can use the personal recovery key to authorize. The commands are mostly the same, but instead of using the -stdinpassphrase flag, you instead use -passphrase and enter the recovery key.
To unlock, run the following command:
diskutil cs unlockVolume UUID -passphrase recoverykey
If successful, the drive will unlock and mount. You should see output similar to that shown below.
Once you’ve unlocked the drive, you should also be able to decrypt it using this command:
diskutil cs decryptVolume UUID -passphrase recoverykey
Using the institutional recovery key on the command line
Assuming that the FileVault 2 encryption on your Fusion drive is using an institutional key, you can unlock or decrypt the encryption using a FileVaultMaster keychain that contains both the public and private key of your institutional recovery key. One requirement is that you will need to be booted from a Recovery HD partition or from Internet Recovery. Here’s how to do this:
1. Copy the FileVaultMaster keychain that contains both the public and private key of your institutional recovery key to a drive that you can access from Recovery HD.
2. Boot to Recovery HD.
3. Get the Logical Volume UUID of the encrypted drive by running the following command:
diskutil cs list
4. With the UUID information acquired, run the following command to unlock the FileVaultMaster.keychain:
security unlock-keychain /path/to/FileVaultMaster.keychain
Once this command is run, you’ll need to enter the keychain’s password when prompted. If the password is accepted, you’ll be taken to the next prompt.
5. Run the following command to unlock the encrypted Core Storage volume on the encrypted Mac:
diskutil cs unlockVolume UUID -recoveryKeychain /path/to/FileVaultMaster.keychain
6. You should then see output similar to the following:
Once you’ve unlocked the disk, you can then decrypt the encrypted Core Storage volume by running the following command:
diskutil cs decryptVolume UUID -recoveryKeychain /path/to/FileVaultMaster.keychain
Verifying decryption
Once the Fusion drive has been completely decrypted, it should still be listed as a Core Storage volume when diskutil cs list is run. The relevant values to check if a Fusion drive is encrypted or not are these:
Encryption Type:
Conversion Status:
Conversion Direction:
Has Encrypted Extents:
On an encrypted Fusion drive, these values should be like the ones shown below:
Encryption Type: AES-XTS
Conversion Status: Complete
Conversion Direction: -none-
Has Encrypted Extents: Yes
On an decrypting Fusion drive, these values should be like the ones shown below:
Encryption Type: AES-XTS
Conversion Status: Converting
Conversion Direction: backward
Has Encrypted Extents: Yes
On a Fusion drive that has just been decrypted, these values should be like the ones shown below:
Encryption Type: AES-XTS
Conversion Status: NoConversion
Conversion Direction: -none-
Has Encrypted Extents: No
On a Fusion drive that has never been encrypted, or been decrypted then restarted at least once since the decryption finished, these values should be like the ones shown below:
Encryption Type: None
Conversion Status: NoConversion
Conversion Direction: -none-
Has Encrypted Extents: No
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.
For a description of what I’ll be talking about, please see the Managing Mavericks’ FileVault 2 with fdesetup session description. You can see the whole list of speakers here on the Sessions page.
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:
17423687
I’ve got the details of my bug report posted at Open Radar:
http://openradar.appspot.com/radar?id=6385064946434048
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:
KeychainPath
KeychainPassword
For KeychainPath, you will need to provide the file path to the keychain as the plist value. For KeychainPath, 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.
fdesetup changerecovery
fdesetup removerecovery
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>
