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.
Keynote slides: http://tinyurl.com/macit14fv2keynote
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.
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:
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.
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.
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.