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.
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.
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:
- Logging into a FileVault 2 encrypted Mac
- Verifying that I was on 10.9.0 and encrypted
- Opening the Mac App Store and installing the 10.9.1 update
- Mac reboots and bypasses the FileVault 2 pre-boot login screen
- Mac automatically logs into my account
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.
Upgrading a FileVault 2 encrypted Mac to 10.9 – Differences between CreateOSXInstallPkg and Apple’s Mavericks installation methods
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.
“Understand FileVault 2 and Manage Disk Encryption with the Casper Suite” session video from JNUC 2013 now available
For those interested, the JNUC session videos are available on YouTube. For convenience. I’ve linked my FileVault 2 session here:
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
According to Apple, the OS X Mavericks Cryptographic Modules, Apple OS X CoreCrypto Module v4.0 and Apple OS X CoreCrypto Kernel Module v4.0, require no setup or configuration to be in “FIPS Mode” for FIPS 140-2 compliance on devices running OS X Mavericks v10.9.
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.
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.
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:
- Logged into my FileVault 2 encrypted Mac
- Verified that I was on 10.8.5 and encrypted
- Launched Install OS X Mavericks.app
- Authenticated when requested
- Selected my boot drive and let it proceed with the upgrade
- The upgrade process restarted the Mac
- After the upgrade process finished, the Mac restarted
- The upgrade process finished
- I clicked the buttons to skip the Apple ID setup
- I then verified that I was now on 10.9.0 and still encrypted
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:
I’ve got the details of my bug report posted at Open Radar:
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.
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:
- Enable or disable FileVault 2 encryption on a particular Mac
- Use a personal recovery key, an institutional recovery key, or both kinds of recovery key
- Enable one or multiple user accounts at the time of encryption
- Get a list of FileVault 2-enabled users on a particular machine
- Add additional users after FileVault has been enabled
- Remove users from the list of FileVault enabled accounts
- Add, change or remove individual and institutional recovery keys
- Report which recovery keys are in use
- Perform a one-time reboot that bypasses the FileVault pre-boot login
- Report on the status of FileVault 2 encryption or decryption
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.